DOCSLIB.ORG

Formal Verification for Real-World Cryptographic Protocols and Implementations Nadim Kobeissi

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Formal Verification for Real-World Cryptographic Protocols and Implementations Nadim Kobeissi Formal Verification for Real-World Cryptographic Protocols and Implementations Nadim Kobeissi To cite this version: Nadim Kobeissi. Formal Verification for Real-World Cryptographic Protocols and Implementations. Computer Science [cs]. INRIA Paris; Ecole Normale Supérieure de Paris - ENS Paris, 2018. English. tel-03245433v1 HAL Id: tel-03245433 https://hal.inria.fr/tel-03245433v1 Submitted on 22 Dec 2018 (v1), last revised 1 Jun 2021 (v4) 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. institut national de recherche en informatique et automatique accredited by école normale supérieure doctoral thesis Formal Verification for Real-World Cryptographic Protocols and Implementations Author: Supervisors: Nadim Kobeissi Karthikeyan Bhargavan Bruno Blanchet Referees: Examiners: Stéphanie Delaune – irisa, rennes Cas Cremers – cispa-helmholtz center, saarbruecken Tamara Rezk – inria, sophia antipolis Stéphanie Delaune – irisa, rennes Antoine Delignat-Lavaud – microsoft research, cambridge Ralf Küsters – university of stuttgart, stuttgart David Pointcheval – école normale supérieure, paris A thesis submitted in fulfillment of the requirements for the degree of Doctor of Computer Science from the ED386 école doctorale and defended on december 10th, 2018 2 3 There is always some madness in love. But there is also always some reason in madness. And those who were seen dancing were thought to be insane by those who could not hear the music. Friedrich Nietzsche Thanks to God that he gave me stubbornness when I know I am right. John Adams إلى أبي، حسن. 4 Abstract Individuals and organizations are increasingly relying on the Web and on user-facing applications for use cases such as online banking, secure messaging, document shar- ing and electronic voting. To protect the confidentiality and integrity of these com- munications, these systems depend on authentication and authorization protocols, on application-level cryptographic constructions and on transport-layer cryptographic pro- tocols. However, combining these varied mechanisms to achieve high-level security goals is error-prone and has led to many attacks even on sophisticated and well-studied applications. This thesis aims to develop methods and techniques for reasoning about, designing and implementing cryptographic protocols and secure application components rele- vant to some of the most frequently used cryptographic protocols and applications. We investigate and formalize various notions of expected guarantees and evaluate whether some of the most popular secure channel protocols, such as secure messaging protocols and transport protocols often operating at the billion-user scale, are capable of meeting these goals. In this thesis, we ask: can existing major paradigms for formal protocol verification serve as guidelines for the assessment of existing protocols, the prototyping of pro- tocols being designed, and the conception of entirely new protocols, in a way that is meaningful and reflective of their expected real-world properties? And can we develop novel frameworks for formal verification and more secure implementation based on these foundations? We propose new formal models in both symbolic and computational formal verifi- cation frameworks for these protocols and applications. In some of the presented work, we obtain a verification methodology that starts from the protocol and ends at the im- plementation code. In other parts of our work, we develop a dynamic framework for generating formal verification models for any secure channel protocol described in a lightweight syntax. Ultimately, this thesis presents formal verification approaches for existing protocols reaching towards their implementation as well as methods for pro- totyping and formally verifying new protocols as they are being drafted and designed. 5 6 Acknowledgments Being able to work on this research at INRIA has been the most essential opportunity that I have been given in my life. Furthermore, no more essential opportunity will ever arise in my life, since my future will undeniably be rooted in what I’ve been allowed to work on at INRIA, in the researchers of INRIA taking me in and teaching me the posture and adroitness necessary for good research. Being at INRIA has taught me much more than the proper formal analysis of cryp- tographic protocols. It taught me just how difficult and uncompromising true scientific rigor can be and the importance of a diligent and forward-looking work ethic. It also taught me patience, helped me expand my perspective with regards to the viewpoints of others and my sense of good faith during teamwork. It helped me mature into some- one less sure of his intuition while nevertheless radically strengthening that intuition in the same process. The researchers at INRIA are part of an institution that morally and intellectually is larger than life, where the bottom line, the net product ends up being uncompromising research pushed forward with equal amounts of passion and prudence. I hope that I can carry with me what I’ve been given at INRIA by imparting the insights of what I’ve been able to work on and the values that determine how the work is to be done. Most of the contributions herein that can be considered my own are largely due to my acting as a sort of highly opinionated melting pot for Karthik’s decades-long vision for Web security, Antoine’s first explaining to me that, in F?, “types are proofs”, Bruno’s unnerving, laser-like focus and rigor — I could go on to cover every member of the PROSECCO research group in words that seem inflated but aren’t really. Being at INRIA taught me how to think. Working with these people taught me more than I could have ever learned on my own and made me into more than I could have hoped to become. I am also deeply grateful for Cedric and Antoine’s hosting me at Microsoft Research for the duration of my internship and most of all for actually letting me call my in- ternship project “QuackyDucky”, even keeping that name after integrating it into the Project Everest stack well after my departure. I would have never received this oppor- tunity were it not for the trust and good faith that Graham, Harry and Philippe put in me during my first year. Their confidence was pivotal in my being given a chance to learn how to do actual science. Regarding the thesis committee, who likely already groaned at the prospect of yet another big thesis to read and are even more apprehensive about it after reading this warm, fuzzy essay, I can promise you cookies at the defense. As for Karthik, what I owe him is beyond evaluation. 7 8 Contents Abstract 5 Acknowledgments 7 Contents 12 Introduction 13 1 Formal Verification for Secure Messaging 31 1.1 A Security Model for Encrypted Messaging ............... 32 1.1.1 Threat Model ............................ 33 1.1.2 Security Goals ........................... 33 1.2 Symbolic Verification with ProVerif .................... 34 1.2.1 Secret Chats in Telegram ..................... 35 1.2.2 Towards Automated Verification ................. 36 1.3 Formally Verifying SP ........................... 36 1.3.1 Protocol Overview ......................... 36 1.3.2 Protocol Verification ........................ 38 1.3.3 Other Protocols: OTR ....................... 41 1.4 Cryptographic Proofs with CryptoVerif ................. 42 1.4.1 Assumptions ............................ 42 1.4.2 Indifferentiability of HKDF .................... 43 1.4.3 Protocol Model ........................... 50 1.4.4 Security Goals ........................... 50 1.4.5 Results ............................... 51 1.5 Conclusion and Related Work ....................... 51 2 Formal Verification for Transport Layer Security 53 2.0.1 Our Contributions ......................... 54 2.1 A Security Model for TLS ......................... 54 2.2 TLS 1.3 1-RTT: Simpler, Faster Handshakes ............... 55 2.2.1 Security Goals for TLS ...................... 55 2.2.2 A Realistic Threat Model for TLS ................ 57 2.2.3 Modeling the Threat Model in ProVerif ............. 59 2.2.4 Modeling and Verifying TLS 1.2 in ProVerif ........... 60 2.2.5 Verification Effort ......................... 62 2.2.6 1-RTT Protocol Flow ....................... 62 2.2.7 Modeling 1-RTT in ProVerif ................... 64 2.2.8 1-RTT Security Goals ....................... 65 2.2.9 Verifying 1-RTT in Isolation ................... 66 9 10 CONTENTS 2.2.10 Verifying TLS 1.3 1-RTT composed with TLS 1.2 ........ 66 2.3 0-RTT with Semi-Static Diffie-Hellman .................. 67 2.3.1 Protocol Flow ............................ 67 2.3.2 Verification with ProVerif ..................... 68 2.3.3 Unknown Key Share Attack on DH-based 0-RTT in QUIC, OPTLS, and TLS 1.3 ............................ 69 2.4 Pre-Shared Keys for Resumption and 0-RTT .............. 69 2.4.1 Protocol Flow ............................ 70 2.4.2 Verifying PSK-based Resumption ................. 71 2.4.3 An Attack on 0-RTT Client Authentication ........... 71 2.4.4 The Impact of Replay on 0-RTT and 0.5-RTT ......... 72 2.5 Computational Analysis of TLS 1.3
Load more

Recommended publications
  • Cryptography
    56 Protecting Information With Cryptography Chapter by Peter Reiher (UCLA) 56.1 Introduction In previous chapters, we’ve discussed clarifying your security goals, determining your security policies, using authentication mechanisms to identify principals, and using access control mechanisms to enforce poli- cies concerning which principals can access which computer resources in which ways. While we identified a number of shortcomings and prob- lems inherent in all of these elements of securing your system, if we re- gard those topics as covered, what’s left for the operating system to worry about, from a security perspective? Why isn’t that everything? There are a number of reasons why we need more. Of particular im- portance: not everything is controlled by the operating system. But per- haps you respond, you told me the operating system is all-powerful! Not really. It has substantial control over a limited domain – the hardware on which it runs, using the interfaces of which it is given control. It has no real control over what happens on other machines, nor what happens if one of its pieces of hardware is accessed via some mechanism outside the operating system’s control. But how can we expect the operating system to protect something when the system does not itself control access to that resource? The an- swer is to prepare the resource for trouble in advance. In essence, we assume that we are going to lose the data, or that an opponent will try to alter it improperly. And we take steps to ensure that such actions don’t cause us problems.
    [Show full text]
  • M3AAWG Best Common Practices for Mitigating Abuse of Web Messaging Systems, Version 1.1 Updated March 2019 (2010)
    Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) M3AAWG Best Common Practices for Mitigating Abuse of Web Messaging Systems, Version 1.1 Updated March 2019 (2010) The reference URL for this document is www.m3aawg.org/WebMessagingAbuse Table of Contents Updated in this Version ......................................................................................................................................................... 1 Introduction ........................................................................................................................................................................... 1 Typical Attacks ...................................................................................................................................................................... 2 Monitoring and Alerting ....................................................................................................................................................... 2 Proactive Defense .................................................................................................................................................................. 3 UI Access ........................................................................................................................................................................................................... 3 Web Application Security ..............................................................................................................................................................................
    [Show full text]
  • Cross-Domain Communications
    CSE 361: Web Security Cross-domain Communication Nick Nikiforakis 2 A World Without Separation between Sites http://kittenpics.org https://gmail.com 3 The Same-Origin Policy for JavaScript • Most basic access control policy • controls how active content can access resources • Same-Origin Policy for JavaScript for three actions • Script access to other document in same browser • frames/iframes • (popup) windows • Script access to application-specific local state • cookies, Web Storage, or IndexedDB • Explicit HTTP requests to other hosts • XMLHttpRequest 4 The Same-Origin Policy for JavaScript • Only allows access if origins match Protocol Hostname Port • Origin defined by protocol, hostname, and port http://example.org:80/path/ Originating document Accessed document Non-IE Browser Internet Explorer http://example.org/a http://example.org/b http://example.org http://www.example.org http://example.org https://example.org http://example.org http://example.org:81 5 Domain Relaxation • Two sub-domains of a common parent domain want to communicate • Notably: can overwrite different port! • Browsers allow setting document.domain property • Can only be set to valid suffix including parent domain • test.example.org -> example.org ok • example.org -> org forbidden • When first introduced, relaxation of single sub-domain was sufficient • Nowadays: both (sub-)domains must explicitly set document.domain 6 Domain Relaxation http://sub.kittenpics.org http://kittenpics.org document.domain = "kittenpics.org" document.domain = "kittenpics.org" 7 Domain Relaxation http://sub.kittenpics.org http://kittenpics.org document.domain = "kittenpics.org" Cross-Origin Communication 9 Cross-origin communication • Subdomains of the same domain can use domain relaxation when they want to talk to one another.
    [Show full text]
  • PCI Assessment Evidence of PCI Policy Compliance
    PCI Assessment Evidence of PCI Policy Compliance CONFIDENTIALITY NOTE: The information contained in this report document is for the Prepared for: exclusive use of the client specified above and may contain confidential, privileged and non-disclosable information. If the recipient of this report is not the client or Prospect or Customer addressee, such recipient is strictly prohibited from reading, photocopying, distributing or otherwise using this report or its contents in any way. Prepared by: Your Company Name Evidence of PCI Policy Compliance PCI ASSESSMENT Table of Contents 1 - Overview 1.1 - Security Officer 1.2 - Overall Risk 2 - PCI DSS Evidence of Compliance 2.1 - Install and maintain firewall to protect cardholder data 2.1.1.1 - Requirements for firewall at each Internet connections and between DMZ and internal network zone 2.1.1.2 - Business justification for use of all services, protocols and ports allowed 2.1.2 - Build firewall and router configurations that restrict connections between untrusted networks and the cardholder data environment 2.1.2.1 - Restrict inbound and outbound to that which is necessary for the cardholder data environment 2.1.2.3 - Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet 2.1.2.4 - Implement stateful inspection (also known as dynamic packet filtering) 2.1.2.5 - Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet 2.2 - Prohibition of vendor-supplied default password for systems and security parameters 2.2.1
    [Show full text]
  • Self-Encrypting Deception: Weaknesses in the Encryption of Solid State Drives
    Self-encrypting deception: weaknesses in the encryption of solid state drives Carlo Meijer Bernard van Gastel Institute for Computing and Information Sciences School of Computer Science Radboud University Nijmegen Open University of the Netherlands [email protected] and Institute for Computing and Information Sciences Radboud University Nijmegen Bernard.vanGastel@{ou.nl,ru.nl} Abstract—We have analyzed the hardware full-disk encryption full-disk encryption. Full-disk encryption software, especially of several solid state drives (SSDs) by reverse engineering their those integrated in modern operating systems, may decide to firmware. These drives were produced by three manufacturers rely solely on hardware encryption in case it detects support between 2014 and 2018, and are both internal models using the SATA and NVMe interfaces (in a M.2 or 2.5" traditional form by the storage device. In case the decision is made to rely on factor) and external models using the USB interface. hardware encryption, typically software encryption is disabled. In theory, the security guarantees offered by hardware encryp- As a primary example, BitLocker, the full-disk encryption tion are similar to or better than software implementations. In software built into Microsoft Windows, switches off software reality, we found that many models using hardware encryption encryption and completely relies on hardware encryption by have critical security weaknesses due to specification, design, and implementation issues. For many models, these security default if the drive advertises support. weaknesses allow for complete recovery of the data without Contribution. This paper evaluates both internal and external knowledge of any secret (such as the password).
    [Show full text]
  • Cryptographic Control Standard, Version
    Nuclear Regulatory Commission Office of the Chief Information Officer Computer Security Standard Office Instruction: OCIO-CS-STD-2009 Office Instruction Title: Cryptographic Control Standard Revision Number: 2.0 Issuance: Date of last signature below Effective Date: October 1, 2017 Primary Contacts: Kathy Lyons-Burke, Senior Level Advisor for Information Security Responsible Organization: OCIO Summary of Changes: OCIO-CS-STD-2009, “Cryptographic Control Standard,” provides the minimum security requirements that must be applied to the Nuclear Regulatory Commission (NRC) systems which utilize cryptographic algorithms, protocols, and cryptographic modules to provide secure communication services. This update is based on the latest versions of the National Institute of Standards and Technology (NIST) Guidance and Federal Information Processing Standards (FIPS) publications, Committee on National Security System (CNSS) issuances, and National Security Agency (NSA) requirements. Training: Upon request ADAMS Accession No.: ML17024A095 Approvals Primary Office Owner Office of the Chief Information Officer Signature Date Enterprise Security Kathy Lyons-Burke 09/26/17 Architecture Working Group Chair CIO David Nelson /RA/ 09/26/17 CISO Jonathan Feibus 09/26/17 OCIO-CS-STD-2009 Page i TABLE OF CONTENTS 1 PURPOSE ............................................................................................................................. 1 2 INTRODUCTION ..................................................................................................................
    [Show full text]
  • Unlocking the Fifth Amendment: Passwords and Encrypted Devices
    Fordham Law Review Volume 87 Issue 1 Article 9 2018 Unlocking the Fifth Amendment: Passwords and Encrypted Devices Laurent Sacharoff University of Arkansas School of Law, Fayetteville Follow this and additional works at: https://ir.lawnet.fordham.edu/flr Part of the Constitutional Law Commons, and the Criminal Procedure Commons Recommended Citation Laurent Sacharoff, Unlocking the Fifth Amendment: Passwords and Encrypted Devices, 87 Fordham L. Rev. 203 (2018). Available at: https://ir.lawnet.fordham.edu/flr/vol87/iss1/9 This Article is brought to you for free and open access by FLASH: The Fordham Law Archive of Scholarship and History. It has been accepted for inclusion in Fordham Law Review by an authorized editor of FLASH: The Fordham Law Archive of Scholarship and History. For more information, please contact [email protected]. UNLOCKING THE FIFTH AMENDMENT: PASSWORDS AND ENCRYPTED DEVICES Laurent Sacharoff* Each year, law enforcement seizes thousands of electronic devices— smartphones, laptops, and notebooks—that it cannot open without the suspect’s password. Without this password, the information on the device sits completely scrambled behind a wall of encryption. Sometimes agents will be able to obtain the information by hacking, discovering copies of data on the cloud, or obtaining the password voluntarily from the suspects themselves. But when they cannot, may the government compel suspects to disclose or enter their password? This Article considers the Fifth Amendment protection against compelled disclosures of passwords—a question that has split and confused courts. It measures this right against the legal right of law enforcement, armed with a warrant, to search the device that it has validly seized.
    [Show full text]
  • Pgpfone Pretty Good Privacy Phone Owner’S Manual Version 1.0 Beta 7 -- 8 July 1996
    Phil’s Pretty Good Software Presents... PGPfone Pretty Good Privacy Phone Owner’s Manual Version 1.0 beta 7 -- 8 July 1996 Philip R. Zimmermann PGPfone Owner’s Manual PGPfone Owner’s Manual is written by Philip R. Zimmermann, and is (c) Copyright 1995-1996 Pretty Good Privacy Inc. All rights reserved. Pretty Good Privacy™, PGP®, Pretty Good Privacy Phone™, and PGPfone™ are all trademarks of Pretty Good Privacy Inc. Export of this software may be restricted by the U.S. government. PGPfone software is (c) Copyright 1995-1996 Pretty Good Privacy Inc. All rights reserved. Phil’s Pretty Good engineering team: PGPfone for the Apple Macintosh and Windows written mainly by Will Price. Phil Zimmermann: Overall application design, cryptographic and key management protocols, call setup negotiation, and, of course, the manual. Will Price: Overall application design. He persuaded the rest of the team to abandon the original DOS command-line approach and designed a multithreaded event-driven GUI architecture. Also greatly improved call setup protocols. Chris Hall: Did early work on call setup protocols and cryptographic and key management protocols, and did the first port to Windows. Colin Plumb: Cryptographic and key management protocols, call setup negotiation, and the fast multiprecision integer math package. Jeff Sorensen: Speech compression. Will Kinney: Optimization of GSM speech compression code. Kelly MacInnis: Early debugging of the Win95 version. Patrick Juola: Computational linguistic research for biometric word list. -2- PGPfone Owner’s
    [Show full text]
  • A Trusted Infrastructure for Symbolic Analysis of Event-Driven Web
    A Trusted Infrastructure for Symbolic Analysis of Event-Driven Web Applications Gabriela Sampaio Imperial College London, UK [email protected] José Fragoso Santos INESC-ID/Instituto Superior Técnico, Universidade de Lisboa, Portugal Imperial College London, UK [email protected] Petar Maksimović Imperial College London, UK [email protected] Philippa Gardner Imperial College London, UK [email protected] Abstract We introduce a trusted infrastructure for the symbolic analysis of modern event-driven Web applica- tions. This infrastructure consists of reference implementations of the DOM Core Level 1, DOM UI Events, JavaScript Promises and the JavaScript async/await APIs, all underpinned by a simple Core Event Semantics which is sufficiently expressive to describe the event models underlying these APIs. Our reference implementations are trustworthy in that three follow the appropriate standards line-by-line and all are thoroughly tested against the official test-suites, passing all the applicable tests. Using the Core Event Semantics and the reference implementations, we develop JaVerT.Click, a symbolic execution tool for JavaScript that, for the first time, supports reasoning about JavaScript programs that use multiple event-related APIs. We demonstrate the viability of JaVerT.Click by proving both the presence and absence of bugs in real-world JavaScript code. 2012 ACM Subject Classification Software and its engineering → Formal software verification; Software and its engineering → Software testing and debugging Keywords and phrases Events, DOM, JavaScript, promises, symbolic execution, bug-finding Digital Object Identifier 10.4230/LIPIcs.ECOOP.2020.28 Acknowledgements Fragoso Santos, Gardner, and Maksimović were partially supported by the EPSRC Programme Grant ‘REMS: Rigorous Engineering for Mainstream Systems’ (EP/K008528/1) and the EPSRC Fellowship ‘VetSpec: Verified Trustworthy Software Specification’ (EP/R034567/1).
    [Show full text]
  • Get Started with HTML5 ● Your Best Bet to Experiment with HTML5 – Safari – Chrome As of – Beta: Firefox 4 and IE 9
    BibhasBibhas BhattacharyaBhattacharya CTO,CTO, WebWeb AgeAge SolutionsSolutions [email protected]@webagesolutions.com www.webagesolutions.com/trainingwww.webagesolutions.com/training Get Started With HTML5 ● Your best bet to experiment with HTML5 – Safari – Chrome As of – Beta: FireFox 4 and IE 9. October 2010 ● Test your browser: – html5test.com – html5demos.com – www.findmebyip.com/litmus ● JavaScript library to test for HTML5 features – www.modernizr.com Browser Support ● Dreamweaver CS5 11.0.3 update will install HTML5 compatibility pack. ● CS4 and CS3 users should download the pack from Dreamweaver Exchange. ● See a demo: – www.youtube.com/watch?v=soNIxy2sj0A DreamWeaver Story - The canvas element - Custom audio & video player - New semantic elements - Geolocation (header, section, footer etc.) - Local data storage - New form input elements - Web SQL & IndexedDB (e-mail, date, time etc.) - Offline apps - Audio and video - Messaging - CSS3 - Web worker - Push using WebSocket For web page designers For developers What's New in HTML5? SimplifiedSimplified <!DOCTYPE html> DOCTYPEDOCTYPE <html> <head> <title>Page Title</title> Simplified <meta charset="UTF-8"> Simplified charsetcharset settingsetting </head> <body> <p>Hello World</p> </body> </html> Basic HTML 5 Document ● Elements that have no special visual styling but are used to provide structure and meaning to the content. ● HTML4 semantic elements – div (block) – span (in line) ● HTML5 semantic elements – header, footer, section, article, aside, time and others..
    [Show full text]
  • Case Study on the Official Scripts Electronic Applications in Bantul)
    I.J. Information Engineering and Electronic Business, 2017, 4, 1-6 Published Online July 2017 in MECS (http://www.mecs-press.org/) DOI: 10.5815/ijieeb.2017.04.01 The Implementation of Pretty Good Privacy in eGovernment Applications (Case Study on the Official Scripts Electronic Applications in Bantul) Didit Suprihanto Department of Electrical Engineering Universitas Mulawarman, Kalimantan Timur, Indonesia, 75123 Email: [email protected] Tri Kuntoro Priyambodo Department of Computer Sciences & Electronics, Universitas Gadjah Mada, Yogyakarta, Indonesia, 55281 Corresponding Author Email: [email protected] Abstract—eGovernment application has evolved from the world [1]. The United Nations‘ global survey reports simply appearing as a website providing news and some ICT indicators that point to the measure of how far information, to the application that provides various a nation has gone in the implementation of e-governance services through online transactions. Provision of online such as: 1.E-readiness, 2.Web measure index, 3. transactions require the effectively and safely service, so Telecommunications infrastructure index, 4. Human the users can make sure that the entry data is secure and capital index, 5. E-participation index[2] will not be used by other parties which are not authorized. Information security is a major factor in the service of Security is also necessary for the service provider side of eGovernment. The using of the host to host in previous online transactions, it is necessary to keep the system, and services of eGovernment is considered as lacking in the data transactions sent through the communications security. Therefore, it needs more security to serve clients media and the data stored in the database are secured.
    [Show full text]
  • I2P, the Invisible Internet Projekt
    I2P, The Invisible Internet Projekt jem September 20, 2016 at Chaostreff Bern Content 1 Introduction About Me About I2P Technical Overview I2P Terminology Tunnels NetDB Addressbook Encryption Garlic Routing Network Stack Using I2P Services Using I2P with any Application Tips and Tricks (and Links) Conclusion jem | I2P, The Invisible Internet Projekt | September 20, 2016 at Chaostreff Bern Introduction About Me 2 I Just finished BSc Informatik at BFH I Bachelor Thesis: "Analysis of the I2P Network" I Focused on information gathering inside and evaluation of possible attacks against I2P I Presumes basic knowledge about I2P I Contact: [email protected] (XMPP) or [email protected] (GPG 0x28562678) jem | I2P, The Invisible Internet Projekt | September 20, 2016 at Chaostreff Bern Introduction About I2P: I2P = TOR? 3 Similar to TOR... I Goal: provide anonymous communication over the Internet I Traffic routed across multiple peers I Layered Encryption I Provides Proxies and APIs ...but also different I Designed as overlay network (strictly separated network on top of the Internet) I No central authority I Every peer participates in routing traffic I Provides integrated services: Webserver, E-Mail, IRC, BitTorrent I Much smaller and less researched jem | I2P, The Invisible Internet Projekt | September 20, 2016 at Chaostreff Bern Introduction About I2P: Basic Facts 4 I I2P build in Java (C++ implementation I2Pd available) I Available for all major OS (Linux, Windows, MacOS, Android) I Small project –> slow progress, chaotic documentation,
    [Show full text]