Simple Protocol for Encrypted Messaging (SPEM)
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
MASTERCLASS GNUPG MASTERCLASS You Wouldn’T Want Other People Opening Your Letters and BEN EVERARD Your Data Is No Different
MASTERCLASS GNUPG MASTERCLASS You wouldn’t want other people opening your letters and BEN EVERARD your data is no different. Encrypt it today! SECURE EMAIL WITH GNUPG AND ENIGMAIL Send encrypted emails from your favourite email client. our typical email is about as secure as a The first thing that you need to do is create a key to JOHN LANE postcard, which is good news if you’re a represent your identity in the OpenPGP world. You’d Ygovernment agency. But you wouldn’t use a typically create one key per identity that you have. postcard for most things sent in the post; you’d use a Most people would have one identity, being sealed envelope. Email is no different; you just need themselves as a person. However, some may find an envelope – and it’s called “Encryption”. having separate personal and professional identities Since the early 1990s, the main way to encrypt useful. It’s a personal choice, but starting with a single email has been PGP, which stands for “Pretty Good key will help while you’re learning. Privacy”. It’s a protocol for the secure encryption of Launch Seahorse and click on the large plus-sign email that has since evolved into an open standard icon that’s just below the menu. Select ‘PGP Key’ and called OpenPGP. work your way through the screens that follow to supply your name and email address and then My lovely horse generate the key. The GNU Privacy Guard (GnuPG), is a free, GPL-licensed You can, optionally, use the Advanced Key Options implementation of the OpenPGP standard (there are to add a comment that can help others identify your other implementations, both free and commercial – key and to select the cipher, its strength and set when the PGP name now refers to a commercial product the key should expire. -
Webrtc and XMPP
webRTC and XMPP Philipp Hancke, XMPP Summit 2013 What is this webRTC thing … …and why should XMPP developers care? . I assume you know what XMPP is… . … you might have heard of Jingle . the XMPP framework for establishing P2P sessions . used for VoIP, filesharing, … . … you might have also heard about this webRTC thing . doing VoIP in the browser . without plugins . „no more flash“ . Do you want to know how it relates to XMPP ? Philipp Hancke © ESTOS GmbH 2013 2 What is webRTC? . P2P sessions between browsers . no servers involved in media transfer . using open standards . Javascript API in the browser . also an BSD-licensed C++ library from Google . Want to know more? . Listen to the evangelists! . Justin Uberti http://www.youtube.com/watch?v=E8C8ouiXHHk . Jose de Castro http://vimeo.com/52510068 . Cullen Jennings http://vimeo.com/cullenfluffyjennings/rtcwebexplained Philipp Hancke © ESTOS GmbH 2013 3 Initiating P2P sessions . initiate a P2P session between two browsers . negotiate media codecs, NAT traversal, etc . media is sent P2P . you need a session initiation protocol . SIP? . JSEP? . H.323? . Jingle! . webRTC does not mandate a signalling protocol . WG decision Philipp Hancke © ESTOS GmbH 2013 4 Call Flow - JSEP Philipp Hancke © ESTOS GmbH 2013 5 Jingle . You can use Jingle as signalling protocol . together with BOSH or XMPP over websockets in the browser . Demo later . But… . webRTC uses the Session Description Protocol as an API . Jingle does not use SDP . You need a mapping SDP -> Jingle -> SDP . Complicated, but doable . Topic for breakout Philipp Hancke © ESTOS GmbH 2013 6 Call Flow - Jingle Philipp Hancke © ESTOS GmbH 2013 7 webRTC-Jingle usecases . -
Securing Email Through Online Social Networks
SECURING EMAIL THROUGH ONLINE SOCIAL NETWORKS Atieh Saberi Pirouz A thesis in The Department of Concordia Institute for Information Systems Engineering (CIISE) Presented in Partial Fulfillment of the Requirements For the Degree of Master of Applied Science (Information Systems Security) at Concordia University Montreal,´ Quebec,´ Canada August 2013 © Atieh Saberi Pirouz, 2013 Concordia University School of Graduate Studies This is to certify that the thesis prepared By: Atieh Saberi Pirouz Entitled: Securing Email Through Online Social Networks and submitted in partial fulfillment of the requirements for the degree of Master of Applied Science (Information Systems Security) complies with the regulations of this University and meets the accepted standards with respect to originality and quality. Signed by the final examining commitee: Dr. Benjamin C. M. Fung Chair Dr. Lingyu Wang Examiner Dr. Zhenhua Zhu Examiner Dr. Mohammad Mannan Supervisor Approved Chair of Department or Graduate Program Director 20 Dr. Christopher Trueman, Dean Faculty of Engineering and Computer Science Abstract Securing Email Through Online Social Networks Atieh Saberi Pirouz Despite being one of the most basic and popular Internet applications, email still largely lacks user-to-user cryptographic protections. From a research perspective, designing privacy preserving techniques for email services is complicated by the re- quirement of balancing security and ease-of-use needs of everyday users. For example, users cannot be expected to manage long-term keys (e.g., PGP key-pair), or under- stand crypto primitives. To enable intuitive email protections for a large number of users, we design Friend- lyMail by leveraging existing pre-authenticated relationships between a sender and receiver on an Online Social Networking (OSN) site, so that users can send secure emails without requiring direct key exchange with the receiver in advance. -
An Empirical Survey on How Much Security and Privacy Customers Want in Instant Messengers
SECURWARE 2016 : The Tenth International Conference on Emerging Security Information, Systems and Technologies An Empirical Survey on how Much Security and Privacy Customers Want in Instant Messengers Thomas Paul Hans-Joachim Hof MuSe – Munich IT Security Research Group Munich University of Applied Sciences Munich University of Applied Sciences Lothstrasse 64, Munich, Germany Lothstraße 64, Munich, Germany e-mail: [email protected] e-mail: [email protected] Abstract— Instant messengers are popular communication developers of future instant messengers to decide on tools used by many people for everyday communication, as security features to implement. well as for work related communication. Following the This paper is structured as follows: Section II discusses disclosure of a massive surveillance system by Edward related work. Section III presents the design of the user Snowden, many users became aware of the risks of unsecure survey. Section IV discusses in detail the findings of the communication. Users increasingly ask for secure communication. However, unsecure instant messengers are still user survey. Section V presents the features of an ideal popular nowadays. This could be due to the fact, that, besides instant messenger fulfilling all the user preferences the large number of available instant messengers, no instant identified by the survey. A market simulation is used to messenger fully satisfies the users preferences. To research the show the potential of this ideal instant messenger. Section acceptance of security mechanisms in instant messengers, this VI summarizes the findings of the paper. paper presents an evaluation of user preferences for secure instant messengers. A user survey was conducted to rate the II. -
Wiretapping End-To-End Encrypted Voip Calls Real-World Attacks on ZRTP
Institute of Operating Systems and Computer Networks Wiretapping End-to-End Encrypted VoIP Calls Real-World Attacks on ZRTP Dominik Schürmann, Fabian Kabus, Gregor Hildermeier, Lars Wolf, 2017-07-18 wiretapping difficulty End-to-End Encryption SIP + DTLS-SRTP (SIP + Datagram Transport Layer Security-SRTP) End-to-End Encryption & Authentication SIP + SRTP + ZRTP Introduction Man-in-the-Middle ZRTP Attacks Conclusion End-to-End Security for Voice Calls Institute of Operating Systems and Computer Networks No End-to-End Security PSTN (Public Switched Telephone Network) SIP + (S)RTP (Session Initiation Protocol + Secure Real-Time Transport Protocol) 2017-07-18 Dominik Schürmann Wiretapping End-to-End Encrypted VoIP Calls Page 2 of 13 wiretapping difficulty End-to-End Encryption & Authentication SIP + SRTP + ZRTP Introduction Man-in-the-Middle ZRTP Attacks Conclusion End-to-End Security for Voice Calls Institute of Operating Systems and Computer Networks No End-to-End Security PSTN (Public Switched Telephone Network) SIP + (S)RTP (Session Initiation Protocol + Secure Real-Time Transport Protocol) End-to-End Encryption SIP + DTLS-SRTP (SIP + Datagram Transport Layer Security-SRTP) 2017-07-18 Dominik Schürmann Wiretapping End-to-End Encrypted VoIP Calls Page 2 of 13 wiretapping difficulty Introduction Man-in-the-Middle ZRTP Attacks Conclusion End-to-End Security for Voice Calls Institute of Operating Systems and Computer Networks No End-to-End Security PSTN (Public Switched Telephone Network) SIP + (S)RTP (Session Initiation Protocol + Secure Real-Time -
Encryption Procedure
Encrypting Software for Transmission to NIST 1. Scope NIST requires that all software submitted by the participants be signed and encrypted. Signing is done with the participant’s private key, and encrypting is done with the NIST project public key, which is published at http://www.nist.gov/itl/iad/ig/encrypt.cfm. NIST will validate all submitted materials using the participant’s public key, and the authenticity of that key will be verified using the key fingerprint. This fingerprint must be submitted to NIST as part of the signed participant agreement. By encrypting the submissions, we ensure privacy; by signing the submission, we ensure authenticity (the software actually belongs to the submitter). NIST will not take ownership of any submissions that are not signed and encrypted. All cryptographic operations (signing and encrypting) shall be performed with software that implements the OpenPGP standard, as described in Internet RFC 4880. The freely available Gnu Privacy Guard (GPG) software, available at www.gnupg.org, is one such implementation. 2. Submission of software to NIST NIST requires that all software submitted by the participants be signed and encrypted. Two keys pairs are needed: • Signing is done with the software provider's private key, and • Encryption is done with the NIST project public key, which is available at http://www.nist.gov/itl/iad/ig/encrypt.cfm 2.1. Project Specific Parameters The values for the project specific parameters (ProjectName, ProjectPublicKey, and ProjectEmail) mentioned in this document are found at http://www.nist.gov/itl/iad/ig/encrypt.cfm 1 2.2. Creating participant cryptographic key pair The steps below show how to create a public/private key pair and fingerprint using the GPG software. -
Investigating Mobile Messaging Security
Technische Universitat¨ Munchen¨ Department of Informatics Interdisciplinary Project in Electrical Engineering Investigating Mobile Messaging Security Elias Hazboun Technische Universitat¨ Munchen¨ Department of Informatics Interdisciplinary Project in Electrical Engineering Investigating Mobile Messaging Security Untersuchung von Mobile Messaging Sicherheit Author Elias Hazboun Supervisor Prof. Dr.-Ing. Georg Carle Advisor Dr. Matthias Wachs, Quirin Scheitle Date April 27, 2016 Informatik VIII Chair for Network Architectures and Services Abstract In this report we document our work in analyzing the security of a selection of mobile messaging apps. Focusing on network based security, we studied traffic generated by the apps to gain an understanding of the current state of applying encryption and authentication protocols. Our findings show a positive trend in security with developers steadily improving security with newer app updates partly due to the increased scrutiny from the community and academia. Although not all apps analyzed had perfect state of the art security properties, none have shown any major vulnerabilities exploited by normal adversaries. It was also evident that only one app - namely TextSecure - is using the industry standard TLS for server-client authentication and security while others have opted for custom made protocols and algorithms. I Contents 1 Introduction 1 1.1 Research Question . .2 1.2 Outline . .2 2 Background and Related Work 3 2.1 Methodology . .3 2.1.1 App Selection . .3 2.1.2 Approach . .3 2.2 Definition of Security Concepts . .4 2.2.1 Layers of Encryption . .4 2.2.2 Transport Layer Security Protocol (TLS) . .5 2.2.3 Perfect Forward Secrecy (PFS) . .5 2.2.4 Asynchronous Messaging Security . -
CS 255: Intro to Cryptography 1 Introduction 2 End-To-End
Programming Assignment 2 Winter 2021 CS 255: Intro to Cryptography Prof. Dan Boneh Due Monday, March 1st, 11:59pm 1 Introduction In this assignment, you are tasked with implementing a secure and efficient end-to-end encrypted chat client using the Double Ratchet Algorithm, a popular session setup protocol that powers real- world chat systems such as Signal and WhatsApp. As an additional challenge, assume you live in a country with government surveillance. Thereby, all messages sent are required to include the session key encrypted with a fixed public key issued by the government. In your implementation, you will make use of various cryptographic primitives we have discussed in class—notably, key exchange, public key encryption, digital signatures, and authenticated encryption. Because it is ill-advised to implement your own primitives in cryptography, you should use an established library: in this case, the Stanford Javascript Crypto Library (SJCL). We will provide starter code that contains a basic template, which you will be able to fill in to satisfy the functionality and security properties described below. 2 End-to-end Encrypted Chat Client 2.1 Implementation Details Your chat client will use the Double Ratchet Algorithm to provide end-to-end encrypted commu- nications with other clients. To evaluate your messaging client, we will check that two or more instances of your implementation it can communicate with each other properly. We feel that it is best to understand the Double Ratchet Algorithm straight from the source, so we ask that you read Sections 1, 2, and 3 of Signal’s published specification here: https://signal. -
Cheat Sheet – Common Ports (PDF)
COMMON PORTS packetlife.net TCP/UDP Port Numbers 7 Echo 554 RTSP 2745 Bagle.H 6891-6901 Windows Live 19 Chargen 546-547 DHCPv6 2967 Symantec AV 6970 Quicktime 20-21 FTP 560 rmonitor 3050 Interbase DB 7212 GhostSurf 22 SSH/SCP 563 NNTP over SSL 3074 XBOX Live 7648-7649 CU-SeeMe 23 Telnet 587 SMTP 3124 HTTP Proxy 8000 Internet Radio 25 SMTP 591 FileMaker 3127 MyDoom 8080 HTTP Proxy 42 WINS Replication 593 Microsoft DCOM 3128 HTTP Proxy 8086-8087 Kaspersky AV 43 WHOIS 631 Internet Printing 3222 GLBP 8118 Privoxy 49 TACACS 636 LDAP over SSL 3260 iSCSI Target 8200 VMware Server 53 DNS 639 MSDP (PIM) 3306 MySQL 8500 Adobe ColdFusion 67-68 DHCP/BOOTP 646 LDP (MPLS) 3389 Terminal Server 8767 TeamSpeak 69 TFTP 691 MS Exchange 3689 iTunes 8866 Bagle.B 70 Gopher 860 iSCSI 3690 Subversion 9100 HP JetDirect 79 Finger 873 rsync 3724 World of Warcraft 9101-9103 Bacula 80 HTTP 902 VMware Server 3784-3785 Ventrilo 9119 MXit 88 Kerberos 989-990 FTP over SSL 4333 mSQL 9800 WebDAV 102 MS Exchange 993 IMAP4 over SSL 4444 Blaster 9898 Dabber 110 POP3 995 POP3 over SSL 4664 Google Desktop 9988 Rbot/Spybot 113 Ident 1025 Microsoft RPC 4672 eMule 9999 Urchin 119 NNTP (Usenet) 1026-1029 Windows Messenger 4899 Radmin 10000 Webmin 123 NTP 1080 SOCKS Proxy 5000 UPnP 10000 BackupExec 135 Microsoft RPC 1080 MyDoom 5001 Slingbox 10113-10116 NetIQ 137-139 NetBIOS 1194 OpenVPN 5001 iperf 11371 OpenPGP 143 IMAP4 1214 Kazaa 5004-5005 RTP 12035-12036 Second Life 161-162 SNMP 1241 Nessus 5050 Yahoo! Messenger 12345 NetBus 177 XDMCP 1311 Dell OpenManage 5060 SIP 13720-13721 -
Enterprise Edition
Secure Communication. Simplified. SAFECHATS Problem Most companies use popular insecure email and ⛔ messaging services to communicate confidential information P The information flow within the Company is ⛔ disorganized Metadata is exposed and available to third-party ⛔ services SAFECHATS Introducing SAFECHATS Ultra-secure communication solution P Designed with security in mind SAFECHATS Why SAFECHATS? ✔ Information is always end-to-end encrypted by default P ✔ All-in-one communication suite: • Text messaging (one-on-one and group chats) • Voice calls • File transfers (no size and file type limits) SAFECHATS How does SAFECHATS solve the problem? ✔ Customizable white label solution ✔ Integrates with existing softwareP infrastructure ✔ Enterprise-wide account and contact list management, supervised audited chats for compliance SAFECHATS What makes SAFECHATS different? ✔ Your own isolated cloud environment or on-premise deployment P ✔ Customizable solution allows to be compliant with internal corporate security policies ✔ No access to your phone number and contact list SAFECHATS Screenshot Protection ✔ Notifications on iOS P ✔ DRM protection on Android SAFECHATS Identity Verification ✔ Protection from man-in-the-middle attacksP ✔ SMP Protocol SAFECHATS Privacy Features ✔ Show / hide messages and files P ✔ Recall messages and files ✔ Self-destructing messages and files SAFECHATS Additional Protection ✔ History retention control P ✔ Application lock: • PIN-code • Pattern-lock on Android devices • Touch ID on iOS devices SAFECHATS How does SAFECHATS -
Instant Messaging
Instant Messaging Internet Technologies and Applications Contents • Instant Messaging and Presence • Comparing popular IM systems – Microsoft MSN – AOL Instant Messenger – Yahoo! Messenger • Jabber, XMPP and Google Talk ITS 413 - Instant Messaging 2 Internet Messaging •Email – Asynchronous communication: user does not have to be online for message to be delivered (not instant messaging) • Newsgroups • Instant Messaging and Presence – UNIX included finger and talk • Finger: determine the presence (or status) of other users • Talk: text based instant chatting application – Internet Relay Chat (IRC) • Introduced in 1988 as group based, instant chatting service • Users join a chat room • Networks consist of servers connected together, and clients connect via a single server – ICQ (“I Seek You”) • Introduced in 1996, allowing chatting between users without joining chat room • In 1998 America Online (AOL) acquired ICQ and became most popular instant messaging application/network – AIM, Microsoft MSN, Yahoo! Messenger, Jabber, … • Initially, Microsoft and Yahoo! Created clients to connect with AIM servers • But restricted by AOL, and most IM networks were limited to specific clients • Only recently (1-2 years) have some IM networks opened to different clients ITS 413 - Instant Messaging 3 Instant Messaging and Presence • Instant Messaging – Synchronous communications: message is only sent to destination if recipient is willing to receive it at time it is sent •Presence – Provides information about the current status/presence of a user to other -
Obstacles to the Adoption of Secure Communication Tools
Obstacles to the Adoption of Secure Communication Tools Ruba Abu-Salma M. Angela Sasse Joseph Bonneau University College London, UK University College London, UK Stanford University & EFF, USA Anastasia Danilova Alena Naiakshina Matthew Smith University of Bonn, Germany University of Bonn, Germany University of Bonn, Germany Abstract—The computer security community has advocated Recent mobile phone-based secure communication tools widespread adoption of secure communication tools to counter have often been designed to hide security from the user com- mass surveillance. Several popular personal communication tools pletely (albeit at some security cost [1]). WhatsApp famously (e.g., WhatsApp, iMessage) have adopted end-to-end encryption, and many new tools (e.g., Signal, Telegram) have been launched deployed E2E encryption to approximately a billion users with security as a key selling point. However it remains unclear through a code update to its application for messages, voice if users understand what protection these tools offer, and if they calls and video communications [18], with only negligible value that protection. In this study, we interviewed 60 partici- changes to the user experience. Some other communication pants about their experience with different communication tools tools (e.g., Signal, Threema) have launched with security and their perceptions of the tools’ security properties. We found that the adoption of secure communication tools is hindered by as an explicit selling point, but they also hide nearly all fragmented user bases and incompatible tools. Furthermore, the cryptographic details. vast majority of participants did not understand the essential There are key differences in the security model of dif- concept of end-to-end encryption, limiting their motivation to ferent E2E-encrypted tools, in addition to a large gap in adopt secure tools.