DOCSLIB.ORG

Whatsapp E2E Encryption Roo

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Whatsapp E2E Encryption Roo Raúl Siles Founder & Senior Security Analyst [email protected] www.dinosec.com @ dinosec March 4, 2017 WhatsApp End To End Encryption Demystified 2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com Outline • Secure / Private messaging and WhatsApp • Crypto introduction and properties • Signal protocol – X3DH and Prekeys – Double Ratchet • Backdoor, vulnerability, bug or feature? • Conclusions • References 2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 2 Secure Messaging & Private Communications https://www.eff.org/secure-messaging-scorecard 2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 3 Alice & Bob 2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 4 WhatsApp Evolution 2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 5 WhatsApp E2E Encryption • WhatsApp E2E encryption is based on the Signal protocol • The app uses Noise Pipes (transport) to communicate with WhatsApp servers • WhatsApp servers can know messages exist (even if content is unknown) – To, From, When, etc. • Registration process (SMS), contacts, etc. • Verify the other party key – View contact info - Encryption: Security code https://www.whatsapp.com/security/ 2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 6 Signal Protocol • Previously named Axolotl protocol • WhatsApp: End-to-End (E2E) encryption – Since March 31, 2016 • Other apps: TextSecure (Android), Signal (iOS/ Android), Facebook Messenger, Google Allo… – Variants of Signal protocol (Double Ratchet): Wire (Proteus), Matrix (Olm), Pond, Conversations, ChatSecure, Cryptocat: OMEMO (XMPP)… • Limit the damage of a compromise • Minimize trust in the messaging infrastructure (servers) Main features/protocols: X3DH, prekeys & Double Ratchet 2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 7 Who Is Behind This Protocol? • Moxie Marlinspike and Trevor Perrin • Open Whisper Systems (OWS) https://whispersystems.org 2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 8 Crypto Introduction 2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com Diffie-Hellman (DH) • Or how to exchange a shared secret key (in a secure way) over an insecure channel • Discrete logarithm (or elliptic curve discrete logarithm) • "# %&' ( = * • # = log∝ * %&' ( – ( is a prime >≈ 1.024 bits • Non-authenticated – Vulnerable to MitM attacks "Diffie-Hellman" (THOTH - Píldora 38): http://www.criptored.upm.es/thoth/ http://www.criptored.upm.es/thoth/material/texto/pildora038.pdf 2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 10 Diffie-Hellman (DH) Exchange Alice p, " Bob Agreement: (mod p) p is a prime number " is a primitive root mod p 0 SECRETS 1 "0 %&' 2 = 3 "1 %&' 2 = 4 56 %&' 2 = "1 0 %&' 2 78 %&' 2 = "0 1 %&' 2 "10 %&' 2 = S = "01 %&' 2 Shared Secret 2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 11 DH Nomenclature • DH (Diffie-Hellman) • DHE (DH Ephemeral) • ECDHE (Elliptic Curve DHE) – Key agreement protocol to exchange a shared secret key (in a secure way) over an insecure channel using key pairs (public & secret/private) – Both parties have a pair of (elliptic curve) keys • Public and secret/private keys – Reference ECDH functions: X25519 & X448 Long-term keys (static) vs. Ephemeral keys (temporary) 2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 12 Elliptic Curve Diffie-Hellman (ECDH) • Curve25519 function (Daniel J. Bernstein, 2005) – Curve25519 (elliptic curve) or X25519 (DH exchange function) – 32-byte public & secret/private keys and 32-byte shared secret – Shared secret can be used to authenticate (hash of the shared secret) & encrypt messages – Very high speed function offering ≈128 bits of security 255 – 9(;<=), where p is the prime number 2 − 19 and E is the elliptic curve y2 = x3 + 486662x2 + x (using the base point x=9) – Validate public keys off-line • Vulnerable to MitM attacks 2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 13 Elliptic Curve Diffie-Hellman (ECDH) Exchange Alice 9 Bob Agreement: (base point) 9 is a public value 0 SECRET/PRIVATE KEYS 1 ?@ABC25519 0, 9 = 3 PUBLIC ?@ABC25519(1, 9) = 4 KEYS ?@ABC25519 0, 4 ?@ABC25519(1, 3) ?@ABC25519 0, ?@ABC25519(1, 9) = S = ?@ABC25519 1, ?@ABC25519(0, 9) Shared Secret (32-byte) 2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 14 Crypto Properties 2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com Crypto Properties • (Perfect) Forward Secrecy (PFS) • Plausible deniability or plausibly deniable encryption • Break-in recovery or future secrecy Provided by the Signal protocol 2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 16 (Perfect) Forward Secrecy (PFS) • "Property of secure communication protocols in which compromise of long-term keys does not compromise past session keys." – "Encrypted communications and sessions recorded in the past cannot be retrieved and decrypted should long-term secret keys or passwords be compromised in the future." • (Perfect) Forward secrecy or security (PFS) • Provided by SCIMP (Silent Circle Instant Messaging Protocol) – Usage of ephemeral (temporary per-message) keys & KDF • "Pre-Compromise Security" BREAK PAST PRESENT FUTURE https://en.wikipedia.org/wiki/Forward_secrecy 2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 17 Plausible Deniability or Cryptographic Deniability • Parties can convincingly deny that a message is encrypted, that it (or its associated plaintext) even exists or that it is able to decrypt it – A party can be absolutely sure a message was sent by the other party (it was not forged by an adversary), but… – A party can not prove to anyone else that a given message was written by the other party (digital signatures) • Provided by OTR (Off-The-Record) vs. GPG/PGP – Keys derived from (ephemeral) shared secrets & renewed https://whispersystems.org/blog/simplifying-otr-deniability/ 2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 18 Break-in Recovery or Future Secrecy • "Property of secure communication protocols in which compromise of current keys does not compromise future session keys." – Current key material can not be used to calculate the key material for future subsequent messages (DH exchanges) – Self-healing (Axolotls) • Provided by OTR (Off-The-Record) • Post-Compromise Security (PCS) – https://eprint.iacr.org/2016/221 BREAK PAST PRESENT FUTURE https://whispersystems.org/blog/advanced-ratcheting/ 2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 19 X3DH 2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com X3DH • X3DH or "Extended Triple Diffie-Hellman" • Key agreement protocol – Parties mutually authenticate each other based on public keys – Provides forward secrecy and cryptographic deniability • Establishing long-term encrypted sessions between users – Establish a shared session key or secret key (SK) – Asynchronous sessions, when a party (Bob) can be offline but has previously published / cached some info to a server – The other party (Alice) wants to send an encrypted message to Bob, and also share a secret key for future communications 2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 21 Pre-generated or Pre-loaded Keys (Prekeys) • Forward secrecy in asynchronous messaging scenarios – Asynchronous messaging uses long-live sessions – Initial key exchange for the first message • Initialization of messaging sessions without the presence of the remote party (asynchronous communication) – A key exchange is required to send a message – A key exchange requires messages from both parties • Sender has to wait for the recipient to respond… blocked! – Pre-generate keys and submit (pre-load) them to the messaging server: One-time prekeys (OPK) https://whispersystems.org/blog/asynchronous-security/ 2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 22 X3DH Pre-Requisites • Stateful protocol: First message creates the session state – Bob's "prekey bundle" can be considered as the 1st message • Once the session has been established, the session key must be renewed (forward secrecy) using a ratchet • Key directory (e.g. WhatsApp servers) • X3DH must define three parameters: – Curve: X25519 (or Curve25519) – Hash: SHA256 ("HmacSHA256") – Info: string value identifying the app using X3DH ("WhisperText") 2017 © Dino Security S.L. All rights reserved. Todos los derechos reservados. www.dinosec.com 23 X3DH Phases 1. User registration and key publication – Bob publishes his identity key and prekeys to a server 2. X3DH key exchange and initial message submission – Alice fetches a “prekey bundle” for Bob from the server, and uses it to calculate the shared session key or secret key, and sends an initial message to Bob 3. Initial message reception – Bob receives and processes Alice’s initial message, and uses it to calculate the same shared session key or secret key 2017 © Dino
Load more

Recommended publications
  • Group Messaging for Secure Asynchronous Collaboration
    Group Messaging for Secure Asynchronous Collaboration Matthew A. Weidner Churchill College A dissertation submitted to the University of Cambridge in partial fulfilment of the requirements for the degree of Master of Philosophy in Advanced Computer Science University of Cambridge Computer Laboratory William Gates Building 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom Email: [email protected] June 6, 2019 Declaration of originality I, Matthew A. Weidner of Churchill College, being a candidate for the M.Phil in Advanced Computer Science, hereby declare that this report and the work described in it are my own work, unaided except as may be specified below, and that the report does not contain material that has already been used to any substantial extent for a comparable purpose. The word count excludes appendices. Signed: Date: This dissertation is copyright c 2019 Matthew A. Weidner. All trademarks used in this dissertation are hereby acknowledged. Acknowledgements I would like to thank my supervisors, Dr. Alastair Beresford and Dr. Martin Kleppmann, for their time and valuable input on this project throughout the year, including feedback on multiple drafts of this dissertation. I also thank Michael Dodson for providing feedback on a draft of Chapter 4. I was supported by a Churchill Scholarship from the Winston Churchill Foundation of the USA. Group Messaging for Secure Asynchronous Collaboration Abstract End-to-end encrypted applications improve users' privacy by making their data unread- able to anyone besides their intended recipients. In particular, their data is unreadable to application servers. Although end-to-end encryption is currently deployed only for messaging apps, recent academic work shows that it is possible to create end-to-end en- crypted asynchronous collaborative applications, like Google Docs but without a trusted server, by layering Conflict-free Replicated Data Types (CRDTs) on top of a secure group messaging protocol.
    [Show full text]
  • Key Derivation Functions and Their GPU Implementation
    MASARYK UNIVERSITY FACULTY}w¡¢£¤¥¦§¨ OF I !"#$%&'()+,-./012345<yA|NFORMATICS Key derivation functions and their GPU implementation BACHELOR’S THESIS Ondrej Mosnáˇcek Brno, Spring 2015 This work is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 4.0 International License. https://creativecommons.org/licenses/by-nc-sa/4.0/ cbna ii Declaration Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Ondrej Mosnáˇcek Advisor: Ing. Milan Brož iii Acknowledgement I would like to thank my supervisor for his guidance and support, and also for his extensive contributions to the Cryptsetup open- source project. Next, I would like to thank my family for their support and pa- tience and also to my friends who were falling behind schedule just like me and thus helped me not to panic. Last but not least, access to computing and storage facilities owned by parties and projects contributing to the National Grid In- frastructure MetaCentrum, provided under the programme “Projects of Large Infrastructure for Research, Development, and Innovations” (LM2010005), is also greatly appreciated. v Abstract Key derivation functions are a key element of many cryptographic applications. Password-based key derivation functions are designed specifically to derive cryptographic keys from low-entropy sources (such as passwords or passphrases) and to counter brute-force and dictionary attacks. However, the most widely adopted standard for password-based key derivation, PBKDF2, as implemented in most applications, is highly susceptible to attacks using Graphics Process- ing Units (GPUs).
    [Show full text]
  • Public Key Cryptography Public Key Cryptography
    Public Key Cryptography Public Key Cryptography • Symmetric Key: – Same key used for encryption and decrypiton – Same key used for message integrity and validation • Public-Key Cryptography – Use one key to encrypt or sign messages – Use another key to decrypt or validate messages • Keys – Public key known to the world and used to send you a message – Only your private key can decrypt the message Public Key Private Key Plaintext Ciphertext Plaintext Encryption Decryption ENTS 689i | Network Immunity | Fall 2008 Lecture 2 Public Key Cryptography • Motivations – In symmetric key cryptography, a key was needed between every pair of users wishing to securely communicate • O(n2) keys – Problem of establishing a key with remote person with whom you wish to communicate • Advantages to Public Key Cryptography – Key distribution much easier: everyone can known your public key as long as your private key remains secret – Fewer keys needed • O(n) keys • Disadvantages – Slow, often up to 1000x slower than symmetric-key cryptography ENTS 689i | Network Immunity | Fall 2008 Lecture 2 Cryptography and Complexity • Three classes of complexity: – P: solvable in polynomial time, O(nc) – NP: nondeterministic solutions in polynomial time, deterministic solutions in exponential time – EXP: exponential solutions, O(cn) • Cryptographic problems should be: increasing P – Encryption should be P difficult – Decryption should be P with key NP – Decryption should be NP for attacker EXP • Need problems where complexity of solution depends on knowledge of a key ENTS
    [Show full text]
  • The Double Ratchet Algorithm
    The Double Ratchet Algorithm Trevor Perrin (editor) Moxie Marlinspike Revision 1, 2016-11-20 Contents 1. Introduction 3 2. Overview 3 2.1. KDF chains . 3 2.2. Symmetric-key ratchet . 5 2.3. Diffie-Hellman ratchet . 6 2.4. Double Ratchet . 13 2.6. Out-of-order messages . 17 3. Double Ratchet 18 3.1. External functions . 18 3.2. State variables . 19 3.3. Initialization . 19 3.4. Encrypting messages . 20 3.5. Decrypting messages . 20 4. Double Ratchet with header encryption 22 4.1. Overview . 22 4.2. External functions . 26 4.3. State variables . 26 4.4. Initialization . 26 4.5. Encrypting messages . 27 4.6. Decrypting messages . 28 5. Implementation considerations 29 5.1. Integration with X3DH . 29 5.2. Recommended cryptographic algorithms . 30 6. Security considerations 31 6.1. Secure deletion . 31 6.2. Recovery from compromise . 31 6.3. Cryptanalysis and ratchet public keys . 31 1 6.4. Deletion of skipped message keys . 32 6.5. Deferring new ratchet key generation . 32 6.6. Truncating authentication tags . 32 6.7. Implementation fingerprinting . 32 7. IPR 33 8. Acknowledgements 33 9. References 33 2 1. Introduction The Double Ratchet algorithm is used by two parties to exchange encrypted messages based on a shared secret key. Typically the parties will use some key agreement protocol (such as X3DH [1]) to agree on the shared secret key. Following this, the parties will use the Double Ratchet to send and receive encrypted messages. The parties derive new keys for every Double Ratchet message so that earlier keys cannot be calculated from later ones.
    [Show full text]
  • On the Security of the PKCS#1 V1.5 Signature Scheme
    On the Security of the PKCS#1 v1.5 Signature Scheme Tibor Jager1 Saqib A. Kakvi1 Alexander May2 September 10, 2018 1Department of Computer Science, Universitat¨ Paderborn ftibor.jager,[email protected] 2Hortz Gortz¨ Institute, Ruhr Universitat¨ Bochum [email protected] Abstract The RSA PKCS#1 v1.5 signature algorithm is the most widely used digital signature scheme in practice. Its two main strengths are its extreme simplicity, which makes it very easy to implement, and that verification of signatures is significantly faster than for DSA or ECDSA. Despite the huge practical importance of RSA PKCS#1 v1.5 signatures, providing formal evidence for their security based on plausible cryptographic hardness assumptions has turned out to be very difficult. Therefore the most recent version of PKCS#1 (RFC 8017) even recommends a replacement the more complex and less efficient scheme RSA-PSS, as it is provably secure and therefore considered more robust. The main obstacle is that RSA PKCS#1 v1.5 signatures use a deterministic padding scheme, which makes standard proof techniques not applicable. We introduce a new technique that enables the first security proof for RSA-PKCS#1 v1.5 signatures. We prove full existential unforgeability against adaptive chosen-message attacks (EUF-CMA) under the standard RSA assumption. Furthermore, we give a tight proof under the Phi-Hiding assumption. These proofs are in the random oracle model and the parameters deviate slightly from the standard use, because we require a larger output length of the hash function. However, we also show how RSA-PKCS#1 v1.5 signatures can be instantiated in practice such that our security proofs apply.
    [Show full text]
  • How Secure Is Textsecure?
    How Secure is TextSecure? Tilman Frosch∗y, Christian Mainkay, Christoph Badery, Florian Bergsmay,Jorg¨ Schwenky, Thorsten Holzy ∗G DATA Advanced Analytics GmbH firstname.lastname @gdata.de f g yHorst Gortz¨ Institute for IT-Security Ruhr University Bochum firstname.lastname @rub.de f g Abstract—Instant Messaging has gained popularity by users without providing any kind of authentication. Today, many for both private and business communication as low-cost clients implement only client-to-server encryption via TLS, short message replacement on mobile devices. However, until although security mechanisms like Off the Record (OTR) recently, most mobile messaging apps did not protect confi- communication [3] or SCIMP [4] providing end-to-end con- dentiality or integrity of the messages. fidentiality and integrity are available. Press releases about mass surveillance performed by intelli- With the advent of smartphones, low-cost short-message gence services such as NSA and GCHQ motivated many people alternatives that use the data channel to communicate, to use alternative messaging solutions to preserve the security gained popularity. However, in the context of mobile ap- and privacy of their communication on the Internet. Initially plications, the assumption of classical instant messaging, fueled by Facebook’s acquisition of the hugely popular mobile for instance, that both parties are online at the time the messaging app WHATSAPP, alternatives claiming to provide conversation takes place, is no longer necessarily valid. secure communication experienced a significant increase of new Instead, the mobile context requires solutions that allow for users. asynchronous communication, where a party may be offline A messaging app that claims to provide secure instant for a prolonged time.
    [Show full text]
  • PKCS #15— a Cryptographic-Token Information Format Standard
    THE ADVANCED COMPUTING SYSTEMS ASSOCIATION The following paper was originally published in the USENIX Workshop on Smartcard Technology Chicago, Illinois, USA, May 10–11, 1999 PKCS #15— A Cryptographic-Token Information Format Standard Magnus Nyström RSA Laboratories © 1999 by The USENIX Association All Rights Reserved Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org PKCS #15 – A Cryptographic Token Information Format Standard Magnus Nyström RSA Laboratories, Bedford MA 01730, USA E-mail: [email protected] acceptance and use of them both by application Abstract developers and by consumers will be muted. We identify the need for a portable format for storage of To optimize the benefit to both the industry and end- user credentials (certificates, keys) on cryptographic users, it is important that solutions to these issues be tokens such as integrated circuit cards (IC cards). Given developed in a manner that supports a variety of this need, a recent proposal in the area, RSA operating environments, application programming Laboratories' PKCS #15 is described and compared with interfaces, and a broad base of applications. Only previous and related work. through this approach can the needs of constituencies be supported and the development of credentials-activated applications encouraged, as a cost-effective solution to 1 Background and Motivation meeting requirements in a very diverse set of markets.
    [Show full text]
  • Security & Privacy for Mobile Phones
    Security & Privacy FOR Mobile Phones Carybé, Lucas Helfstein July 4, 2017 Instituto DE Matemática E Estatística - USP What IS security? • That GRANTS THE INFORMATION YOU PROVIDE THE ASSURANCES above; • That ENSURES THAT EVERY INDIVIDUAL IN THIS SYSTEM KNOWS EACH other; • That TRIES TO KEEP THE ABOVE PROMISES forever. Security IS ... A System! • That ASSURES YOU THE INTEGRITY AND AUTHENTICITY OF AN INFORMATION AS WELL AS ITS authors; 1 • That ENSURES THAT EVERY INDIVIDUAL IN THIS SYSTEM KNOWS EACH other; • That TRIES TO KEEP THE ABOVE PROMISES forever. Security IS ... A System! • That ASSURES YOU THE INTEGRITY AND AUTHENTICITY OF AN INFORMATION AS WELL AS ITS authors; • That GRANTS THE INFORMATION YOU PROVIDE THE ASSURANCES above; 1 • That TRIES TO KEEP THE ABOVE PROMISES forever. Security IS ... A System! • That ASSURES YOU THE INTEGRITY AND AUTHENTICITY OF AN INFORMATION AS WELL AS ITS authors; • That GRANTS THE INFORMATION YOU PROVIDE THE ASSURANCES above; • That ENSURES THAT EVERY INDIVIDUAL IN THIS SYSTEM KNOWS EACH other; 1 Security IS ... A System! • That ASSURES YOU THE INTEGRITY AND AUTHENTICITY OF AN INFORMATION AS WELL AS ITS authors; • That GRANTS THE INFORMATION YOU PROVIDE THE ASSURANCES above; • That ENSURES THAT EVERY INDIVIDUAL IN THIS SYSTEM KNOWS EACH other; • That TRIES TO KEEP THE ABOVE PROMISES forever. 1 Security IS ... A System! Eve | | | Alice "Hi" <---------------> "Hi" Bob 2 Security IS ... Cryptography! Eve | | | Alice "Hi" <----"*****"------> "Hi" Bob 3 Security IS ... Impossible! The ONLY TRULY SECURE SYSTEM IS ONE THAT IS POWERED off, CAST IN A BLOCK OF CONCRETE AND SEALED IN A lead-lined ROOM WITH ARMED GUARDS - AND EVEN THEN I HAVE MY doubts.
    [Show full text]
  • HSM SECURITY Securing PKCS#11 Interfaces
    HSM SECURITY Securing PKCS#11 Interfaces Whitepaper v1.9 August 2019 Cryptosense | HSM Security Whitepaper 2 Contents 1. Introduction 3 2. Brief History of PKCS#11 3 3. Overview of PKCS#11 Design 3 4. Threat Scenario and Security Properties for PKCS#11 4 5. Attacking PKCS#11 HSM Security 5 5.1. Memory corruption attacks 5 5.2. Non-compliant PKCS#11 Implementations 6 5.3. Errors in Crypto Implementation 7 5.4. Attacks on Compliant PKCS#11 Implementations 7 6. Errors in Using the HSM 9 6.1. Insecure Crypto Mechanisms 10 6.2. Misuse of Crypto 10 6.3. Key Management Failures 10 7. Summary 10 8. About Cryptosense 11 9. Bibliography 11 This document is protected by copyright. No part of the document may be reproduced or redistributed in any form by any means without the prior written authorization of Cryptosense. This document is provided “as is" without any warranty of any kind. Cryptosense SA cannot be held responsible for any misconduct or malicious use of this document by a third party or damage caused by any information this document contains. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Cryptosense SA, 231 Rue Saint-Honoré, 75001 Paris France cryptosense.com © Cryptosense 2019 Cryptosense | HSM Security Whitepaper 3 1. Introduction Modern applications that use cryptography usually access that functionality via an application program interface (API) to a software or hardware cryptographic provider. Security-critical applications often make use of Hardware Security Modules (HSMs): special purpose computers that provide high-speed cryptographic services whilst keeping key material inside a tamper- sensitive enclosure.
    [Show full text]
  • Modern End-To-End Encrypted Messaging for the Desktop
    Die approbierte Originalversion dieser Diplom-/ Masterarbeit ist in der Hauptbibliothek der Tech- nischen Universität Wien aufgestellt und zugänglich. http://www.ub.tuwien.ac.at The approved original version of this diploma or master thesis is available at the main library of the Vienna University of Technology. http://www.ub.tuwien.ac.at/eng Modern End-to-End Encrypted Messaging for the Desktop DIPLOMARBEIT zur Erlangung des akademischen Grades Diplom-Ingenieur im Rahmen des Studiums Software Engineering and Internet Computing eingereicht von Richard Bayerle Matrikelnummer 1025259 an der Fakultät für Informatik der Technischen Universität Wien Betreuung: Privatdozent Dipl.Ing. Mag. Dr. Edgar Weippl Mitwirkung: Dr. Martin Schmiedecker Wien, 2. Oktober 2017 Richard Bayerle Edgar Weippl Technische Universität Wien A-1040 Wien Karlsplatz 13 Tel. +43-1-58801-0 www.tuwien.ac.at Modern End-to-End Encrypted Messaging for the Desktop DIPLOMA THESIS submitted in partial fulfillment of the requirements for the degree of Diplom-Ingenieur in Software Engineering and Internet Computing by Richard Bayerle Registration Number 1025259 to the Faculty of Informatics at the TU Wien Advisor: Privatdozent Dipl.Ing. Mag. Dr. Edgar Weippl Assistance: Dr. Martin Schmiedecker Vienna, 2nd October, 2017 Richard Bayerle Edgar Weippl Technische Universität Wien A-1040 Wien Karlsplatz 13 Tel. +43-1-58801-0 www.tuwien.ac.at Erklärung zur Verfassung der Arbeit Richard Bayerle Seestraße 67 78315 Radolfzell am Bodensee Deutschland Hiermit erkläre ich, dass ich diese Arbeit selbständig verfasst habe, dass ich die verwen- deten Quellen und Hilfsmittel vollständig angegeben habe und dass ich die Stellen der Arbeit – einschließlich Tabellen, Karten und Abbildungen –, die anderen Werken oder dem Internet im Wortlaut oder dem Sinn nach entnommen sind, auf jeden Fall unter Angabe der Quelle als Entlehnung kenntlich gemacht habe.
    [Show full text]
  • Introduction to Public Key Infrastructures
    Introduction to Public Key Infrastructures Johannes A. Buchmann • Evangelos Karatsiolis Alexander Wiesmaier Introduction to Public Key Infrastructures 123 Johannes A. Buchmann Evangelos Karatsiolis FB Informatik FlexSecure GmbH TU Darmstadt Darmstadt Darmstadt Germany Germany Alexander Wiesmaier AGT International Darmstadt Germany ISBN 978-3-642-40656-0 ISBN 978-3-642-40657-7 (eBook) DOI 10.1007/978-3-642-40657-7 Springer Heidelberg New York Dordrecht London Library of Congress Control Number: 2013954524 © Springer-Verlag Berlin Heidelberg 2013 This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Exempted from this legal reservation are brief excerpts in connection with reviews or scholarly analysis or material supplied specifically for the purpose of being entered and executed on a computer system, for exclusive use by the purchaser of the work. Duplication of this publication or parts thereof is permitted only under the provisions of the Copyright Law of the Publisher’s location, in its current version, and permission for use must always be obtained from Springer. Permissions for use may be obtained through RightsLink at the Copyright Clearance Center. Violations are liable to prosecution under the respective Copyright Law. The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use.
    [Show full text]
  • Analysis of Key Management in Matrix
    Bachelor thesis Computing Science Radboud University Analysis of key management in Matrix Author: First supervisor/assessor: Floris Hendriks Prof. J.J.C. Daemen s4749294 [email protected] Second supervisor: Dr. B.J.M. Mennink [email protected] Second assessor: Dr. C.E. Dobraunig [email protected] January 17, 2020 Abstract This thesis presents an analysis of Matrix’s key management. Matrix is an end-to-end encrypted and decentralised application layer proto- col, developed by The Matrix.org Foundation C.I.C. The protocol is used, among other applications, to end-to-end encrypt messages in a decen- tralised chat system. To date, Matrix is not equipped with a clear and well-described overview on how keys enable end-to-end encryption in a decentralised network. This thesis therefore describes how keys in Ma- trix are established, used, stored, exchanged and verified. Moreover, the analysis also explores the limitations of Matrix’s key management and potential improvements. Contents 1 Introduction3 1.1 Research questions........................5 1.2 Structure..............................6 2 Preliminaries7 2.1 Data formats used in Matrix...................7 2.2 Security principles........................8 2.2.1 Forward secrecy......................8 2.2.2 Backward secrecy.....................8 2.2.3 Deniability.........................8 2.2.4 Confidentiality.......................8 2.2.5 Integrity..........................9 2.2.6 Authentication.......................9 2.3 Cryptographic primitives used in Matrix............9 2.3.1 Cryptographic hash functions..............9 2.3.2 HMAC............................9 2.3.3 HKDF............................ 10 2.3.4 Cryptographic ratchets.................. 10 2.3.5 Curve25519........................ 11 2.3.6 EdDSA and Ed25519..................
    [Show full text]