DOCSLIB.ORG

Your Engines: Dynamically Loadable Contemporary Crypto

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Your Engines: Dynamically Loadable Contemporary Crypto Start your ENGINEs: dynamically loadable contemporary crypto Nicola Tuveri Billy Bob Brumley Tampere University, Tampere, Finland Tampere University, Tampere, Finland Abstract—Software ever-increasingly relies on building blocks with respect to this paper, the NaCl [1] project—and its implemented by security libraries, which provide access to fork libsodium2—are especially relevant, as they aim at evolving standards, protocols, and cryptographic primitives. providing practical and efficient strong confidentiality and These libraries are often subject to complex development models and long decision-making processes, which limit the ability of integrity with a special emphasis on the simplicity of the contributors to participate in the development process, hinder provided programming interface. Unfortunately, after years, the deployment of scientific results and pose challenges for OS we notice that, even if gathering momentum and being adopted maintainers. In this paper, focusing on OpenSSL as a de-facto in various new projects, this approach fails in meeting the standard, we analyze these limits, their impact on the security needs of mainstream projects. of modern systems, and their significance for researchers. We propose the OpenSSL ENGINE API as a tool in a framework Another related development sprouting off this research is to overcome these limits, describing how it fits in the OpenSSL HACL*3 [2], a verified cryptographic library that implements architecture, its features, and a technical review of its internals. the NaCl API: it provides mathematical guarantees on memory We evaluate our methodology by instantiating libsuola, a new safety, timing side-channel safety and functional correctness ENGINE providing support for emerging cryptographic standards (with respect to the published primitive specification), while such as X25519 and Ed25519 for currently deployed versions of OpenSSL, performing benchmarks to demonstrate the viability producing portable C code that is as fast as state-of-the-art C and benefits. The results confirm that the ENGINE API offers (1) implementations. an ideal architecture to address wide-ranging security concerns; Alongside the development of NaCl, research efforts were (2) a valuable tool to enhance future research by easing testing also spent on the related SUPERCOP benchmarking suite and facilitating the dissemination of novel results in real-world systems; and (3) a means to bridge the gaps between research as part of the eBACS project [3] for the benchmarking of results and currently deployed systems. cryptographic systems: many researchers from industry and academia submitted new cryptographic primitives or alterna- I. INTRODUCTION tive implementations for benchmarking. Included submissions Following current common best practices for the develop- are benchmarked across different architectures and toolchains ment of secure systems, most applications rely on crypto- and undergo several automated tests. But still, most of these graphic primitives for which widely accepted standards have programming and scientific efforts fail to reach widespread been published after extensive studies to ensure that breaking adoption through mainstream libraries. We defer to Section II them is believed computationally infeasible. As the available for an in-depth analysis of the limits of the OpenSSL project computation power increases and new attacks and algorithms from the point of view of researchers that might help ex- to improve the performance of theoretic attacks are developed, plaining this gap. In here, to further substantiate the existence these standards are periodically revised to raise the security and relevance of this gap, we focus on the implementation of level of the recommended primitives. emerging cryptographic standards based on Curve25519 [4, 5]. Considering the complexity of protocols and algorithms X25519, the Diffie-Hellman cryptosystem, originally released and the number of potential pitfalls concerning details at in 2005, promises, due to the properties of the underlying every level of abstraction, the software implementation of curve design, simpler and faster implementations, with en- such evolving standards is a daunting and complex task and hanced resistance to side-channel attacks. Ed25519, formally application developers are strongly advised not to implement introduced in 2011, is a digital signature system based on their own crypto but to rely on existing well-established the twisted Edwards equivalent of Curve25519. It delivers fast cryptographic libraries, among which OpenSSL1 is the most digital signature generation and verification, short signatures, widely adopted. Still, in addition to the complexity of their and enhanced resistance to side-channel attacks. programming interfaces, bugs and defects in these libraries These cryptosystems have since gathered momentum, gain- are often the cause of cryptographic failures in the security ing official support in OpenSSH in 2014, in BoringSSL in layer of modern information systems. 2015, in the Google Chrome Internet browser TLS/QUIC Previous research focused on the development of new cryp- protocol support in April 2016, and finally becoming part tographic software libraries as a solution to these problems: 2https://libsodium.org/ 1https://www.openssl.org 3https://github.com/mitls/hacl-star of IETF RFC 7748 [6] (X25519) in January 2016 and RFC Outline: Section II presents further claims motivating our 8032 [7] (Ed25519) in January 2017, and becoming officially contribution. Section III contains an analysis of the OpenSSL recommended for implementations of TLS 1.3 (RFC 8446 [8]) architecture and the ENGINE API. Section IV presents lib- and earlier versions (RFC 8422 [9]) since August 2018. suola, an ENGINE we developed to demonstrate how to use OpenSSL officially added support for X25519 in August the ENGINE API as a framework to offer alternative or miss- 2016, with release 1.1.0, while Ed25519 support landed only ing implementations in OpenSSL. In Section V we present and very recently in a release version, after a long development evaluate experimental results comparing the default implemen- cycle, with the release of 1.1.1 on September 11, 2018. tation of X25519 and Ed25519 (or the lack thereof) against While implementation details are examined in Section III-D, the implementations provided through our custom ENGINE here we highlight that the original implementation chosen and analyze the limits of our proposed methodology and how by the OpenSSL development team favored portability over it addresses the concerns exposed in Section II. Section VI optimization, and as a result using these cryptosystems in presents a brief analysis of related work, focusing on the applications built on top of OpenSSL, do not always yield mechanisms deployed by other security libraries, frameworks the expected performance in comparison with other elliptic and operating systems to allow the transparent adoption of curve (EC) implementations (e.g., NIST P-256). alternative cryptographic implementations. We conclude in This does not seem to be a consequence of a lack of trusted Section VII. optimized implementations for the most widespread architec- tures supported by OpenSSL, as the mentioned SUPERCOP II. MOTIVATION project includes several implementations tested on different As mentioned in Section I, this work is partially motivated architectures and alternative libraries like libsodium and by the rigidity of currently deployed, ubiquitous cryptography BoringSSL ship optimized implementations for popular ar- software libraries. This rigidity impacts real-world security chitectures. It rather shows that new research, even after at least via two avenues, which this section summarizes: it the time required for gaining trust and widespread adoption amplifies software assurance issues due to the small circle in other mainstream projects and standards, still requires a of contributors, and furthermore restricts the practical ability long additional time to be included in OpenSSL, affecting of OS vendors to provide predictable and steady support researchers, developers and users. throughout the product life cycle. Our contribution: To address these limits, in this work: While our intent is not to belittle the efforts of the OpenSSL (1) we present an analysis of the OpenSSL ENGINE API project, to motivate our contributions, here we briefly highlight and its benefits for bridging gaps between cryptographic re- some limits of the project from the point of view of researchers search and practical real-world implementations of cryptosys- that might explain the gap highlighted in the introduction: tems—the analysis in itself is novel, as available resources ap- (1) lack of unified quality reference documentation on the pear to be outdated; (2) we develop an ENGINE to demonstrate overall software architecture of the library, on API design how to use the ENGINE API as a framework to transparently choices, and frequently on the details of public and inter- integrate alternative implementations or new functionality in nal functions and data structures; (2) complex ad-hoc build OpenSSL, making them available to existing applications; system; (3) strong constraints on the choice of programming (3) we evaluate experimental results, by benchmarking our languages (C and custom “augmented” ASM syntax) and libsuola ENGINE, demonstrating the viability and the coding style; (4) being a complex and huge project ongoing benefits of the proposed solution across different versions of very
Load more

Recommended publications
  • Secure Socket Layer (SSL) Transport Layer Security (TLS)
    Secure Socket Layer (SSL) Transport Layer Security (TLS) © André Zúquete Advanced Network Security TLS (Transport Layer Security, RFC 5246): Goals w Secure communication protocol over TCP/IP ® Standard inspired by SSL V3 (Secure Sockets Layer) ® Handles secure sessions per application over TCP/IP • Initially conceived for HTTP traffic • Currently being used by other kinds of traffic w Security mechanisms ® TCP payload protection • Confidentiality • Stream integrity ® Key distribution ® Peer authentication • Server authentication (the normal scenario) • Client authentication • Usually a person • Not usually explored © André Zúquete Advanced Network Security 1 Change Handshake Alert IMAP, Cipher Protocol Protocol HTTP Spec. etc. IMAP, TLS/SSL: HTTP etc. Protocols Record Protocol w Handshake Protocol TCP ® Key distribution • Master secrets (48 bytes) • Computed with DH; or • Chose by the client, upload to the server encrypted with the server’s public key • Session keys • Computed from a master secret and two nonces exchanged ® Peer authentication • Asymmetric encryption with long-term or ephemeral keys • Public key certificates for long-term public keys w Record Protocol ® Handling of secure data records ® Compression, confidentiality, integrity control © André Zúquete Advanced Network Security TLS/SSL versions w SSL ® 1.0 ® 2.0: 1995, prohibited by RFC 6176 (2011) ® 3.0: 1996, RFC 6101 (2011), deprecated by RFC 7568 (2015) w TLS ® 1.0: 1999: RFC 2246 SSL BEAST (2011) ® 1.1: 2006: RFC 4346 ® 1.2: 2008: RFC 5246 ® 1.3: 2018: RFC 8446 © André
    [Show full text]
  • ROADS and BRIDGES: the UNSEEN LABOR BEHIND OUR DIGITAL INFRASTRUCTURE Preface
    Roads and Bridges:The Unseen Labor Behind Our Digital Infrastructure WRITTEN BY Nadia Eghbal 2 Open up your phone. Your social media, your news, your medical records, your bank: they are all using free and public code. Contents 3 Table of Contents 4 Preface 58 Challenges Facing Digital Infrastructure 5 Foreword 59 Open source’s complicated relationship with money 8 Executive Summary 66 Why digital infrastructure support 11 Introduction problems are accelerating 77 The hidden costs of ignoring infrastructure 18 History and Background of Digital Infrastructure 89 Sustaining Digital Infrastructure 19 How software gets built 90 Business models for digital infrastructure 23 How not charging for software transformed society 97 Finding a sponsor or donor for an infrastructure project 29 A brief history of free and public software and the people who made it 106 Why is it so hard to fund these projects? 109 Institutional efforts to support digital infrastructure 37 How The Current System Works 38 What is digital infrastructure, and how 124 Opportunities Ahead does it get built? 125 Developing effective support strategies 46 How are digital infrastructure projects managed and supported? 127 Priming the landscape 136 The crossroads we face 53 Why do people keep contributing to these projects, when they’re not getting paid for it? 139 Appendix 140 Glossary 142 Acknowledgements ROADS AND BRIDGES: THE UNSEEN LABOR BEHIND OUR DIGITAL INFRASTRUCTURE Preface Our modern society—everything from hospitals to stock markets to newspapers to social media—runs on software. But take a closer look, and you’ll find that the tools we use to build software are buckling under demand.
    [Show full text]
  • Using Frankencerts for Automated Adversarial Testing of Certificate
    Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations Chad Brubaker ∗ y Suman Janay Baishakhi Rayz Sarfraz Khurshidy Vitaly Shmatikovy ∗Google yThe University of Texas at Austin zUniversity of California, Davis Abstract—Modern network security rests on the Secure Sock- many open-source implementations of SSL/TLS are available ets Layer (SSL) and Transport Layer Security (TLS) protocols. for developers who need to incorporate SSL/TLS into their Distributed systems, mobile and desktop applications, embedded software: OpenSSL, NSS, GnuTLS, CyaSSL, PolarSSL, Ma- devices, and all of secure Web rely on SSL/TLS for protection trixSSL, cryptlib, and several others. Several Web browsers against network attacks. This protection critically depends on include their own, proprietary implementations. whether SSL/TLS clients correctly validate X.509 certificates presented by servers during the SSL/TLS handshake protocol. In this paper, we focus on server authentication, which We design, implement, and apply the first methodology for is the only protection against man-in-the-middle and other large-scale testing of certificate validation logic in SSL/TLS server impersonation attacks, and thus essential for HTTPS implementations. Our first ingredient is “frankencerts,” synthetic and virtually any other application of SSL/TLS. Server authen- certificates that are randomly mutated from parts of real cer- tication in SSL/TLS depends entirely on a single step in the tificates and thus include unusual combinations of extensions handshake protocol. As part of its “Server Hello” message, and constraints. Our second ingredient is differential testing: if the server presents an X.509 certificate with its public key.
    [Show full text]
  • Mac OS X Server Administrator's Guide
    034-9285.S4AdminPDF 6/27/02 2:07 PM Page 1 Mac OS X Server Administrator’s Guide K Apple Computer, Inc. © 2002 Apple Computer, Inc. All rights reserved. Under the copyright laws, this publication may not be copied, in whole or in part, without the written consent of Apple. The Apple logo is a trademark of Apple Computer, Inc., registered in the U.S. and other countries. Use of the “keyboard” Apple logo (Option-Shift-K) for commercial purposes without the prior written consent of Apple may constitute trademark infringement and unfair competition in violation of federal and state laws. Apple, the Apple logo, AppleScript, AppleShare, AppleTalk, ColorSync, FireWire, Keychain, Mac, Macintosh, Power Macintosh, QuickTime, Sherlock, and WebObjects are trademarks of Apple Computer, Inc., registered in the U.S. and other countries. AirPort, Extensions Manager, Finder, iMac, and Power Mac are trademarks of Apple Computer, Inc. Adobe and PostScript are trademarks of Adobe Systems Incorporated. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. Netscape Navigator is a trademark of Netscape Communications Corporation. RealAudio is a trademark of Progressive Networks, Inc. © 1995–2001 The Apache Group. All rights reserved. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company, Ltd. 062-9285/7-26-02 LL9285.Book Page 3 Tuesday, June 25, 2002 3:59 PM Contents Preface How to Use This Guide 39 What’s Included
    [Show full text]
  • Open Source Documentation Used in WAP4410N, Version 2.0.5.X
    Open Source Used In WAP4410N 2.0.5.x This document contains the licenses and notices for open source software used in this product. With respect to the free/open source software listed in this document, if you have any questions or wish to receive a copy of the source code to which you are entitled under the applicable free/open source license(s) (such as the GNU Lesser/General Public License) , please contact us at http://www.cisco.com/go/smallbiz_opensource_request. In your requests please include the following reference number 78EE117C99-24342489 En ce qui a trait au logiciel gratuit ou à exploitation libre figurant dans ce document, si vous avez des questions ou souhaitez recevoir une copie du code source, auquel vous avez droit en vertu des licences gratuites ou d'exploitation libre applicables (telles que licences GNU Lesser/General Public), veuillez communiquer avec nous à l'adresse http://www.cisco.com/go/smallbiz_opensource_request. Dans vos demandes, veuillez inclure le numéro de référence 78EE117C99-24342489 Contents 1.1 ag7100 1.0 1.1.1 Available under license 1.2 binutils 2.16.1 1.2.1 Available under license 1.3 busybox 1.1.0 1.3.1 Available under license 1.4 ccache 2.4 78-20798-01 Open Source Used In WAP4410N 2.0.5.x 1 1.4.1 Available under license 1.5 dhcp 0.1 1.5.1 Available under license 1.6 gcc 3.4.4 1.6.1 Available under license 1.7 genext2fs 1.3 1.7.1 Available under license 1.8 hostapd 0.5.9 1.8.1 Available under license 1.9 libiconv 1.8 1.9.1 Available under license 1.10 libupnp 1.2.1 1.10.1 Available under license
    [Show full text]
  • Lattice-Based Cryptography - a Comparative Description and Analysis of Proposed Schemes
    Lattice-based cryptography - A comparative description and analysis of proposed schemes Einar Løvhøiden Antonsen Thesis submitted for the degree of Master in Informatics: programming and networks 60 credits Department of Informatics Faculty of mathematics and natural sciences UNIVERSITY OF OSLO Autumn 2017 Lattice-based cryptography - A comparative description and analysis of proposed schemes Einar Løvhøiden Antonsen c 2017 Einar Løvhøiden Antonsen Lattice-based cryptography - A comparative description and analysis of proposed schemes http://www.duo.uio.no/ Printed: Reprosentralen, University of Oslo Acknowledgement I would like to thank my supervisor, Leif Nilsen, for all the help and guidance during my work with this thesis. I would also like to thank all my friends and family for the support. And a shoutout to Bliss and the guys there (you know who you are) for providing a place to relax during stressful times. 1 Abstract The standard public-key cryptosystems used today relies mathematical problems that require a lot of computing force to solve, so much that, with the right parameters, they are computationally unsolvable. But there are quantum algorithms that are able to solve these problems in much shorter time. These quantum algorithms have been known for many years, but have only been a problem in theory because of the lack of quantum computers. But with recent development in the building of quantum computers, the cryptographic world is looking for quantum-resistant replacements for today’s standard public-key cryptosystems. Public-key cryptosystems based on lattices are possible replacements. This thesis presents several possible candidates for new standard public-key cryptosystems, mainly NTRU and ring-LWE-based systems.
    [Show full text]
  • Post-Quantum Authentication in Openssl with Hash-Based Signatures
    Recalling Hash-Based Signatures Motivations for Cryptographic Library Integration Cryptographic Libraries OpenSSL & open-quantum-safe XMSS Certificate Signing in OpenSSL / open-quantum-safe Conclusions Post-Quantum Authentication in OpenSSL with Hash-Based Signatures Denis Butin, Julian Wälde, and Johannes Buchmann TU Darmstadt, Germany 1 / 26 I Quantum computers are not available yet, but deployment of new crypto takes time, so transition must start now I Well established post-quantum signature schemes: hash-based cryptography (XMSS and variants) I Our goal: make post-quantum signatures available in a popular security software library: OpenSSL Recalling Hash-Based Signatures Motivations for Cryptographic Library Integration Cryptographic Libraries OpenSSL & open-quantum-safe XMSS Certificate Signing in OpenSSL / open-quantum-safe Conclusions Overall Motivation I Networking requires authentication; authentication is realized by cryptographic signature schemes I Shor’s algorithm (1994): most public-key cryptography (RSA, DSA, ECDSA) breaks once large quantum computers exist I Post-quantum cryptography: public-key algorithms thought to be secure against quantum computer attacks 2 / 26 Recalling Hash-Based Signatures Motivations for Cryptographic Library Integration Cryptographic Libraries OpenSSL & open-quantum-safe XMSS Certificate Signing in OpenSSL / open-quantum-safe Conclusions Overall Motivation I Networking requires authentication; authentication is realized by cryptographic signature schemes I Shor’s algorithm (1994): most public-key
    [Show full text]
  • Using Unsniff Network Analyzer to Analyze SSL / TLS
    Whitepaper – SSL / TLS Analysis using Unsniff Network Analyzer Whitepaper : Using Unsniff Network Analyzer to analyze SSL / TLS A number of applications today use SSL and TLS as a security layer. Unsniff allows authorized users to analyze these applications by decrypting the SSL/TLS streams in real time. This is done without interrupting the SSL streams in any way. Unsniff can also strip out the SSL/TLS layer completely and analyze the application protocols as if the security layer never existed. For example: If you are working with a secure web server, you can analyze the HTTPS protocol, including the ability to reconstruct complete web pages. References : RFC2246 (TLS 1.0), RFC2459 (X.509v3), PKCS Standards (RSA Website) Feature overview Working with PDUs and Streams Decrypting SSL/TLS Analyzing upper layer protocols Howto : Analyzing a secure Microsoft IIS web server Howto : Analyzing a secure Apache web server Howto : Analyzing protocols tunneled via stunnel FAQ 1/12 © Unleash Networks, All rights reserved Whitepaper – SSL / TLS Analysis using Unsniff Network Analyzer Feature Overview Unsniff shows SSL/TLS records as separate entities in the PDU sheet irrespective of SSL records how they were carried at the link layer. Stream Monitor entire SSL / TLS sessions in real time via the Streams sheet. analysis Provided you have the servers private key material you can decrypt SSL / TLS Decryption sessions in real time. Most of the popular ciphers are supported. Advanced Unsniff supports SSL / TLS features such as session reuse and cipher renegotiation. Decryption SSL/TLS only acts as a transport layer for higher layer protocols. Ultimately we are interested in the analysis of higher layer protocols such as HTTP, LDAP etc.
    [Show full text]
  • Scalable Verification for Outsourced Dynamic Databases Hwee Hwa PANG Singapore Management University, [email protected]
    Singapore Management University Institutional Knowledge at Singapore Management University Research Collection School Of Information Systems School of Information Systems 8-2009 Scalable Verification for Outsourced Dynamic Databases Hwee Hwa PANG Singapore Management University, [email protected] Jilian ZHANG Singapore Management University, [email protected] Kyriakos MOURATIDIS Singapore Management University, [email protected] DOI: https://doi.org/10.14778/1687627.1687718 Follow this and additional works at: https://ink.library.smu.edu.sg/sis_research Part of the Databases and Information Systems Commons, and the Numerical Analysis and Scientific omputC ing Commons Citation PANG, Hwee Hwa; ZHANG, Jilian; and MOURATIDIS, Kyriakos. Scalable Verification for Outsourced Dynamic Databases. (2009). Proceedings of the VLDB Endowment: VLDB'09, August 24-28, Lyon, France. 2, (1), 802-813. Research Collection School Of Information Systems. Available at: https://ink.library.smu.edu.sg/sis_research/876 This Conference Proceeding Article is brought to you for free and open access by the School of Information Systems at Institutional Knowledge at Singapore Management University. It has been accepted for inclusion in Research Collection School Of Information Systems by an authorized administrator of Institutional Knowledge at Singapore Management University. For more information, please email [email protected]. Scalable Verification for Outsourced Dynamic Databases HweeHwa Pang Jilian Zhang Kyriakos Mouratidis School of Information Systems Singapore Management University fhhpang, jilian.z.2007, [email protected] ABSTRACT receive updated price quotes early could act ahead of their com- Query answers from servers operated by third parties need to be petitors, so the advantage of data freshness would justify investing verified, as the third parties may not be trusted or their servers may in the computing infrastructure.
    [Show full text]
  • You Really Shouldn't Roll Your Own Crypto: an Empirical Study of Vulnerabilities in Cryptographic Libraries
    You Really Shouldn’t Roll Your Own Crypto: An Empirical Study of Vulnerabilities in Cryptographic Libraries Jenny Blessing Michael A. Specter Daniel J. Weitzner MIT MIT MIT Abstract A common aphorism in applied cryptography is that cryp- The security of the Internet rests on a small number of open- tographic code is inherently difficult to secure due to its com- source cryptographic libraries: a vulnerability in any one of plexity; that one should not “roll your own crypto.” In par- them threatens to compromise a significant percentage of web ticular, the maxim that complexity is the enemy of security traffic. Despite this potential for security impact, the character- is a common refrain within the security community. Since istics and causes of vulnerabilities in cryptographic software the phrase was first popularized in 1999 [52], it has been in- are not well understood. In this work, we conduct the first voked in general discussions about software security [32] and comprehensive analysis of cryptographic libraries and the vul- cited repeatedly as part of the encryption debate [26]. Conven- nerabilities affecting them. We collect data from the National tional wisdom holds that the greater the number of features Vulnerability Database, individual project repositories and in a system, the greater the risk that these features and their mailing lists, and other relevant sources for eight widely used interactions with other components contain vulnerabilities. cryptographic libraries. Unfortunately, the security community lacks empirical ev- Among our most interesting findings is that only 27.2% of idence supporting the “complexity is the enemy of security” vulnerabilities in cryptographic libraries are cryptographic argument with respect to cryptographic software.
    [Show full text]
  • Security Issues in the Diffie-Hellman Key Agreement Protocol
    Security Issues in the Diffie-Hellman Key Agreement Protocol Jean-Franc¸ois Raymond and Anton Stiglic Zero-Knowledge Systems Inc. jfr, anton ¡ @zeroknowledge.com Abstract Diffie-Hellman key agreement protocol [20] implementations have been plagued by serious security flaws. The attacks can be very subtle and, more often than not, have not been taken into account by protocol designers. In this summary we discuss both theoretical attacks against the Diffie-Hellman key agreement pro- tocol and attacks based on implementation details . It is hoped that computer se- curity practitioners will obtain enough information to build and design secure and efficient versions of this classic key agreement protocol. 1 Introduction In their landmark 1976 paper “New Directions in Cryptography”[20], Diffie and Hell- man present a secure key agreement protocol that can be carried out over public com- munication channels. Their protocol is still widely used to this day. Even though the protocol seems quite simple, it can be vulnerable to certain attacks. As with many cryptographic protocols, the Diffie-Hellman key agreement protocol (DH protocol) has subtle problems that cryptographers have taken many years to discover. This vulnerability is compounded by the fact that programmers often do not have a proper understanding of the security issues. In fact, bad implementations of crypto- graphic protocols are, unfortunately, common [2]. In this work, we attempt to give a comprehensive listing of attacks on the DH proto- col. This listing will, in turn, allow us to motivate protocol design decisions. Note that throughout this presentation emphasis is placed on practice. After reading this paper, one might not have an extremely detailed understanding of previous work and theoret- ical problems, but should have a very good idea about how to securely implement the DH protocol in different settings.
    [Show full text]
  • Master's Thesis
    Securing In-Boat CAN Communication over the Internet Using a Cell Phone as Wi-Fi Router with Limited Hardware Master's Thesis in Computer Science and Engineering RICKARD PERSSON ALESANDRO SANCHEZ Chalmers University of Technology Department of Computer Science and Engineering Gothenburg, Sweden 2015 The Author grants to Chalmers University of Technology and University of Gothen- burg the non-exclusive right to publish the Work electronically and in a non-commercial purpose make it accessible on the Internet. The Author warrants that he/she is the author to the Work, and warrants that the Work does not contain text, pictures or other material that violates copyright law. The Author shall, when transferring the rights of the Work to a third party (for example a publisher or a company), acknowledge the third party about this agreement. If the Author has signed a copyright agreement with a third party regarding the Work, the Author warrants hereby that he/she has obtained any necessary permission from this third party to let Chalmers University of Technology and University of Gothenburg store the Work electronically and make it accessible on the Internet. Securing In-Boat CAN Communication over the Internet Securing In-Boat CAN Communication over the Internet Using a Cell Phone as Wi-FI Router with Limited Hardware Rickard, Persson Alesandro, Sanchez ©Rickard Persson, June 2015 ©Alesandro Sanchez, June 2015 Examiner: Tomas Olovsson Chalmers University of Technology Department of Computer Science and Engineering SE-412 96 G¨oteborg Sweden Telephone + 46 (0)31-772 1000 Department of Computer Science and Engineering Gothenburg, Sweden June 2014 Abstract Opening a communication channel to the internal vehicle bus of pleasure boats through the Internet, offers benefits such as remote diagnostics and software update of boat components.
    [Show full text]