├── LICENSE ├── README.md ├── chat-projects.md ├── roadmap.md └── threat-models.md /LICENSE: -------------------------------------------------------------------------------- 1 | CC0 1.0 Universal 2 | 3 | Statement of Purpose 4 | 5 | The laws of most jurisdictions throughout the world automatically confer 6 | exclusive Copyright and Related Rights (defined below) upon the creator and 7 | subsequent owner(s) (each and all, an "owner") of an original work of 8 | authorship and/or a database (each, a "Work"). 9 | 10 | Certain owners wish to permanently relinquish those rights to a Work for the 11 | purpose of contributing to a commons of creative, cultural and scientific 12 | works ("Commons") that the public can reliably and without fear of later 13 | claims of infringement build upon, modify, incorporate in other works, reuse 14 | and redistribute as freely as possible in any form whatsoever and for any 15 | purposes, including without limitation commercial purposes. These owners may 16 | contribute to the Commons to promote the ideal of a free culture and the 17 | further production of creative, cultural and scientific works, or to gain 18 | reputation or greater distribution for their Work in part through the use and 19 | efforts of others. 20 | 21 | For these and/or other purposes and motivations, and without any expectation 22 | of additional consideration or compensation, the person associating CC0 with a 23 | Work (the "Affirmer"), to the extent that he or she is an owner of Copyright 24 | and Related Rights in the Work, voluntarily elects to apply CC0 to the Work 25 | and publicly distribute the Work under its terms, with knowledge of his or her 26 | Copyright and Related Rights in the Work and the meaning and intended legal 27 | effect of CC0 on those rights. 28 | 29 | 1. Copyright and Related Rights. A Work made available under CC0 may be 30 | protected by copyright and related or neighboring rights ("Copyright and 31 | Related Rights"). Copyright and Related Rights include, but are not limited 32 | to, the following: 33 | 34 | i. the right to reproduce, adapt, distribute, perform, display, communicate, 35 | and translate a Work; 36 | 37 | ii. moral rights retained by the original author(s) and/or performer(s); 38 | 39 | iii. publicity and privacy rights pertaining to a person's image or likeness 40 | depicted in a Work; 41 | 42 | iv. rights protecting against unfair competition in regards to a Work, 43 | subject to the limitations in paragraph 4(a), below; 44 | 45 | v. rights protecting the extraction, dissemination, use and reuse of data in 46 | a Work; 47 | 48 | vi. database rights (such as those arising under Directive 96/9/EC of the 49 | European Parliament and of the Council of 11 March 1996 on the legal 50 | protection of databases, and under any national implementation thereof, 51 | including any amended or successor version of such directive); and 52 | 53 | vii. other similar, equivalent or corresponding rights throughout the world 54 | based on applicable law or treaty, and any national implementations thereof. 55 | 56 | 2. Waiver. To the greatest extent permitted by, but not in contravention of, 57 | applicable law, Affirmer hereby overtly, fully, permanently, irrevocably and 58 | unconditionally waives, abandons, and surrenders all of Affirmer's Copyright 59 | and Related Rights and associated claims and causes of action, whether now 60 | known or unknown (including existing as well as future claims and causes of 61 | action), in the Work (i) in all territories worldwide, (ii) for the maximum 62 | duration provided by applicable law or treaty (including future time 63 | extensions), (iii) in any current or future medium and for any number of 64 | copies, and (iv) for any purpose whatsoever, including without limitation 65 | commercial, advertising or promotional purposes (the "Waiver"). Affirmer makes 66 | the Waiver for the benefit of each member of the public at large and to the 67 | detriment of Affirmer's heirs and successors, fully intending that such Waiver 68 | shall not be subject to revocation, rescission, cancellation, termination, or 69 | any other legal or equitable action to disrupt the quiet enjoyment of the Work 70 | by the public as contemplated by Affirmer's express Statement of Purpose. 71 | 72 | 3. Public License Fallback. Should any part of the Waiver for any reason be 73 | judged legally invalid or ineffective under applicable law, then the Waiver 74 | shall be preserved to the maximum extent permitted taking into account 75 | Affirmer's express Statement of Purpose. In addition, to the extent the Waiver 76 | is so judged Affirmer hereby grants to each affected person a royalty-free, 77 | non transferable, non sublicensable, non exclusive, irrevocable and 78 | unconditional license to exercise Affirmer's Copyright and Related Rights in 79 | the Work (i) in all territories worldwide, (ii) for the maximum duration 80 | provided by applicable law or treaty (including future time extensions), (iii) 81 | in any current or future medium and for any number of copies, and (iv) for any 82 | purpose whatsoever, including without limitation commercial, advertising or 83 | promotional purposes (the "License"). The License shall be deemed effective as 84 | of the date CC0 was applied by Affirmer to the Work. Should any part of the 85 | License for any reason be judged legally invalid or ineffective under 86 | applicable law, such partial invalidity or ineffectiveness shall not 87 | invalidate the remainder of the License, and in such case Affirmer hereby 88 | affirms that he or she will not (i) exercise any of his or her remaining 89 | Copyright and Related Rights in the Work or (ii) assert any associated claims 90 | and causes of action with respect to the Work, in either case contrary to 91 | Affirmer's express Statement of Purpose. 92 | 93 | 4. Limitations and Disclaimers. 94 | 95 | a. No trademark or patent rights held by Affirmer are waived, abandoned, 96 | surrendered, licensed or otherwise affected by this document. 97 | 98 | b. Affirmer offers the Work as-is and makes no representations or warranties 99 | of any kind concerning the Work, express, implied, statutory or otherwise, 100 | including without limitation warranties of title, merchantability, fitness 101 | for a particular purpose, non infringement, or the absence of latent or 102 | other defects, accuracy, or the present or absence of errors, whether or not 103 | discoverable, all to the greatest extent permissible under applicable law. 104 | 105 | c. Affirmer disclaims responsibility for clearing rights of other persons 106 | that may apply to the Work or any use thereof, including without limitation 107 | any person's Copyright and Related Rights in the Work. Further, Affirmer 108 | disclaims responsibility for obtaining any necessary consents, permissions 109 | or other rights required for any use of the Work. 110 | 111 | d. Affirmer understands and acknowledges that Creative Commons is not a 112 | party to this document and has no duty or obligation with respect to this 113 | CC0 or use of the Work. 114 | 115 | For more information, please see 116 | 117 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | Secure Chat 2 | =========== 3 | 4 | This repository holds notes for planning for next generation secure chat. 5 | 6 | 7 | -------------------------------------------------------------------------------- /chat-projects.md: -------------------------------------------------------------------------------- 1 | # Existing Chat Projects and Protocols 2 | 3 | Does the world really need another secure chat project? Despite the large number of existing projects, none of these projects are positioned meet the "new chat" experience of popular applications such as WhatsApp, WeChat, Kik Messenger, etc. 4 | 5 | ## Open source projects 6 | 7 | **TextSecure** 8 | 9 | Advantages: 10 | 11 | * Advanced Axolotl message encryption. 12 | * Cross platform iOS and Android. 13 | * Asynchronous messaging with PFS. 14 | * Strong public key cryptography that is invisible to the user (it uses Trust on First Use to validate keys). 15 | * Leverages your existing mobile contact list. 16 | 17 | Disadvantages: 18 | 19 | * TextSecure uses your phone number as a unique identifier. This prevents you from ever using aliases or pseudo-anonymous identifiers, and puts the user at the mercy of the telco. 20 | * TextSecure does not support federation (outside a small set of pre-approved routing organizations). 21 | 22 | Plans are underway to add the option of using an email address as an identifier and extending the protocol to support a more open federation. 23 | 24 | **ChatSecure** 25 | 26 | ChatSecure is a nice, general purpose XMPP client with OTR support for Android. It is a fine example of "old chat", and could be modified to provide a "new chat" experience. 27 | 28 | **Telegram** 29 | 30 | Despite Telegram's claim of using advanced super-secure encryption, their design essentially rests on trusting the server for everything. The user can have "secure" chats by manually verifying awkward keys, but it is unlikely that anyone does. Telegram should be considered snake-oil, albeit snake-oil with a lot of money behind it. 31 | 32 | **P2pChat** 33 | 34 | Peer-to-peer approaches like P2pChat (and the proprietary Bittorrent Chat) have the key advantage of not relying any third parties, but they suffer when it comes to the kind of user experience Newchat is trying to achieve: 35 | 36 | Disadvantages: 37 | 38 | * user identifiers are random and hard to remember 39 | * there is no data availability, because nothing is backed up to the cloud 40 | * there are problems with responsiveness and scalability, because of a reliance on spotty peer-to-peer networks instead of stable provider-to-provider networks. 41 | * it is difficult to switch devices 42 | * it can be resource intensive for a mobile device 43 | * direct device to device message routing leaks association meta-data to a network observer 44 | 45 | Advantages: 46 | 47 | * There is no need to validate keys because user identifiers are the keys themselves. 48 | * There is no need to trust any third party for anything. 49 | 50 | **CryptoCat** 51 | 52 | CryptoCat consists of two primary elements: one is the web-based chat application (typically loaded via a browser extension), and the other is the cryptocat protocol for encrypted group chat. The future plan for CryptoCat is to switch from a custom protocol to using mpOTR (multi-party Off-The-Record). Cryptocat currently uses OTR for two party chats. 53 | 54 | Advantages: 55 | 56 | * Very low barrier to entry, just open the web page or install the browser extension. 57 | 58 | Disadvantages: 59 | 60 | * No support for offline messages. 61 | * The browser environment offers limited security. 62 | * Public key authentication is awkward and identities are not stable. 63 | 64 | **Surespot** 65 | 66 | Surespot is an open source mobile messaging app designed to work with a single provider (it is not federated). 67 | 68 | * Uses a custom chat encryption protocol. So far, no outside analysis. 69 | 70 | Advantages: 71 | 72 | * At first look, it seems to have reasonable security. 73 | 74 | Disadvantages: 75 | 76 | * Is not federated, and will only work with other surespot users. One could fork the code and host their own provider, but these users would not be able to talk with the surespot users. 77 | 78 | ## Proprietary projects 79 | 80 | **Proprietary apps, proprietary protocols** 81 | 82 | Recently, many proprietary secure chat applications have been released. These approaches all suffer from some common problems: 83 | 84 | * The software and the service come from the same organization. Ultimately, despite the fancy crypto, it all boils down to trusting the organization. 85 | * Key validation requires trusting the central organization. 86 | * There is no interoperability with other providers. 87 | 88 | These include: 89 | 90 | * SilentCircle 91 | * [Threema](https://threema.ch) 92 | * Seecrypt 93 | * Wickr 94 | * Perzo 95 | * Silent 96 | * Wisper 97 | * [Gliph](https://gli.ph) 98 | 99 | **Proprietary apps, open protocols** 100 | 101 | Heml.is is a proprietary chat application that uses open protocols (XMPP and OpenPGP). However, it does not support federation (single provider model). Ultimately, like other single-provider models, the user must place trust in the provider. 102 | 103 | **Proprietary apps, p2p protocols** 104 | 105 | Bittorrent Chat is a p2p-based chat application that uses bittorrents DHT to find other users. Messages are relayed direct from IP to IP. Users are identified by their public key. This has all the advantages and disadvantages of other p2p-based chat approaches (see above). 106 | -------------------------------------------------------------------------------- /roadmap.md: -------------------------------------------------------------------------------- 1 | # Introduction 2 | 3 | The way people use chat and instance message has evolved considerable since the days of simple SMS or ICQ. Since then, a new type of chat has started to rapidly overtake old chat. The user experience of "new chat" or "chat 2.0" is marked by support for asynchronous messages (aka offline messages), private groups, rich inline media, no status updates, and the ability to smoothly switch from device to device without losing the conversation. New chat promises that your data will always be available, your message will always get delivered, you can read your chat history, and you can use whatever device you want. 4 | 5 | New chat is not simply old chat with better features. It is a distinct user experience that has replaced old methods of instant messaging. Many users are starting to use new chat apps as a replacement for social networking: they create private chat groups where they share updates, pictures, and links. Unfortunately, the tools we have for secure chat have not kept pace with this development. 6 | 7 | This document is a draft roadmap for creating the next generation of secure chat that is easy, secure, with the user experience that people have come to expect. As a placeholder, this document will refer to this new secure chat as "Newchat". 8 | 9 | # Required features 10 | 11 | These are the required and highly desirable features of a new chat system in the long run. The essential question this document attempts to ask is, "what is the best way to incrementally get there?" 12 | 13 | User experience features: 14 | 15 | * Asynchronous: The ability send messages to people when they are offline and ensure the recipient will receive them. 16 | * Multi-devices: The user must be able to seamlessly switch devices without losing any messages. If stored, user messages must be encrypted locally when saved to local disk or backed up to cloud storage. 17 | * Friendly identity: Users should be identified by an easy to remember identifier that is stable over time. The assumed format is username@domain for unique identifiers (like email, SIP, and XMPP chat). 18 | * Groups: Users today demand the ability to form private group chats. The primary need here is not for ad-hoc group chats, but private chats where the list of allowed users is determined in advance. 19 | * Media-rich: Users must be able to securely attach links, images, media streams, and other resources to their chat messages. 20 | * Robust mobile support: Good support for mobile requires more than just a nice mobile app, it also requires alternatives to always-open TCP connections (aka push notifications) and support for "Stream Management" (so the server and client can gracefully restore a dropped connection). 21 | * Guaranteed delivery: If a message does not reach the recipient, the sender should be alerted to the error. 22 | * Offline support: Despite the proliferation of network connectivity, network quality in practice can be very spotty. Ideally, client applications should allow the user to interact with the chat system while offline, and automatically re-synchronize with other users when network is restored. 23 | 24 | Security features: 25 | 26 | * Forward secret message encryption: Forward secrecy ensures that an attacker cannot later decrypt messages once they have discovered the private key of any of the participants or once they have cracked the encryption by other means. This is typically accomplished by using "ephemeral" message encryption keys that are frequently discarded, making decryption of past messages very difficult. 27 | * Authenticity: The public keys of other chat participants must be strongly authenticated. 28 | * Invisible keys: The confidentiality of messaging encryption relies on the proper use of public key cryptography, but in practice this is both conceptually and practically too difficult for the common user to manage correctly. Instead, the goal here is "invisible keys" where all the key management happens automatically and without the user's knowledge, but with the highest level of security. This includes functions such as key generation, key discovery, key validation, key expiration, and key synchronization. 29 | * Meta-data protection: The routing and message encryption protocols must not leak metadata which could disclose the parties involved in a given communication. 30 | 31 | Infrastructure features: 32 | 33 | * Federated: The protocol must support open federation that allows participants from different service providers to be able to easily communicate. 34 | * Provider best practices: The long term goal of this roadmap is to entirely remove liability from the service provider and allow the user to use the provider without trusting them. However, in the medium term, there are likely to be many areas where a service provider can still enhance the security of the user, such as in ensuring authenticated, encrypted transport when relaying messages among servers, preventing timing attacks, and aiding in key validation by endorsing user keys. 35 | 36 | # Chat Protocols 37 | 38 | In order for two or more Newchat compatible clients to communicate with one another, they must each support the following protocols: 39 | 40 | * Message Transport and Routing 41 | * Message Encryption 42 | * Key Discovery and Validation 43 | * Resource Linking 44 | 45 | ## Message Transport and Routing 46 | 47 | A baseline assumption of this roadmap is that Newchat will use a model of open federation, possibly with some peer-to-peer elements for securing routing metadata. 48 | 49 | In the traditional model of federated XMPP chat, messages are passed from the user's client to their service provider, relayed to the recipient's provider, and then finally delivered to the recipient's client. A federated model ensures that the user is not locked into a single provider, they are able to communicate with users from other providers, and that multiple organizations all have a stake in seeing the system work well and securely. This model also provides users with a high degree of data availability and responsiveness (messages are available when they want them and they are delivered quickly). 50 | 51 | However, even when all messages are encrypted, a strict federation of this type has one fatal flaw: the user is forced to trust their service provider with all their metadata and routing information. In one variation of the federated model, this problem is solved by making the message sender's client application deliver a message directly to the recipient's provider, via some anonymization system. 52 | 53 | Other possible models include: 54 | 55 | * Central Authority: In this model, a single organization is responsible for routing all messages. A purely centralized model is easier to implement, at the cost of making it very difficult to externally verify the security properties of the system. Centralized systems locks the user into a particular provider and limits their control over their own data. Unless the software is carefully distributed independently of the central authority, the user must always trust the central authority no matter what additional cryptography is added to the system. 56 | * Peer-to-Peer: In this model, message routing and transport is handled by a network of dynamic and ad-hoc nodes, typically comprised of software running on the end users' devices. A purely decentralized peer-to-peer model takes the provider out the picture, but typically requires identifiers that are not human friendly, is difficult to make resistant to traffic analysis, is typically too resource intensive for mobile devices, is slower, and sacrifices data availability. 57 | 58 | It is likely that Newchat will eventually need to combine elements of all three models (centralized, federated, and peer-to-peer) in order to take advantage of the particular solutions that each approach solves better than the others. For example, imagine a system with the following elements: 59 | 60 | 1. An optional centralized registry that maps phone numbers to user identifiers, in order to allow automatic upgrades to a secure channel when communicating via traditional mobile SMS or voice. This registry could be a "closed federation", with a fixed number of authorized registrars. 61 | 1. An open federation of chat providers that give each user a stable unique identifier and the ability to receive messages. 62 | 1. An optional peer-to-peer mechanism for delivering outgoing chat messages to the recipient server without the server being able to record the message metadata. 63 | 64 | ### Possible candidates 65 | 66 | **XMPP** 67 | 68 | XMPP provides a solid foundation for federated chat. After a decade, the libraries for XMPP are starting to actually mature. The fatal flaw of XMPP is the huge number of possible extensions to the protocol, which makes it difficult to ever achieve smooth compatibility between any two clients or servers. If Newchat were to use XMPP, it should be modified in the following manner: 69 | 70 | * A Newchat compatible client and server should only support a very specific subset of the available XMPP extensions. 71 | * Most XMPP extensions that are allowed should also be required, such as offline message support. 72 | * All transport connections should be required to be encrypted using TLS with PFS ciphers. 73 | * The content of every message should be encrypted using Newchat Message Encryption. 74 | * For mobile devices, the client should not keep an open TCP connection at all times. Instead, the device should establish a new connection after it has received a push notification that new content is available. 75 | * Newchat should not support continual presence notification. A traditional XMPP system is designed so that every user receives regular updates regarding the online status of their contacts. For security and performance reasons, Newchat should allow presence information only as a response to a specific query for it. 76 | * Newchat should include additional extensions not part of existing XMPP protocol, such as the ability for a sender to request that the recipient client disable message logging. 77 | 78 | Although XMPP does not support secure routing that protects metadata, an XMPP based protocol could include extensions for it. 79 | 80 | **TextSecure** 81 | 82 | Whispersystems TextSecure mobile application uses a client-server architecture that currently operates as a "closed federation". There is nothing that prevents this protocol and software from being modified to support an open federation with username@domain identifiers. 83 | 84 | Attractive properties of the TextSecure transport protocol: 85 | 86 | * It is modern protocol designed for mobile devices, using a REST API and push notifications, rather than the ancient always-open TCP connection using XML found in XMPP. 87 | * The reference server implementation is well written, fast and stable. 88 | 89 | ## Message Encryption 90 | 91 | The Message Encryption protocol specifies how each message is encrypted, and how a conversation is validated. It is orthogonal to whatever routing mechanism is used. For Newchat, the message encryption should include the following properties: 92 | 93 | * confidentiality: attacker should not be able to intercept a message and read it. 94 | * authenticity: the receiver should be assured the message has not been modified after being sent. 95 | * optional non-repudiation: a message sender should have the option of providing proof that the message came from them or not. 96 | * perfect forward secrecy: attacker who obtains a shared ephemeral key should not be able to read prior messages. 97 | * unlinkable: the message encryption should into leak information that can be used to correlate traffic (mostly, this is the responsibility of the routing protocol, but the message encryption also needs to make it hard to map who is communicating with whom). 98 | * sequence integrity: an attacker should not be able to drop messages or replay messages without participants noticing. 99 | 100 | Additionally, the protocol should have these features: 101 | 102 | * Is able to communicate securely in multi-user chats with a predetermined access list (e.g. groups). This might be simulated groups, with some method of transcript consistency. 103 | * Is able to send and receive secure messages asynchronously (when the recipient is not online). 104 | 105 | ### Possible candidates 106 | 107 | **OTR** 108 | 109 | OTR is the current gold standard for chats with PFS, but it does not support asynchronous messages. Group support (mpOTR) is highly experimental and necessarily slow. 110 | 111 | **OpenPGP** 112 | 113 | OpenPGP is not often used for chat and it does not support PFS. However, if used with a long lived signing key and very short lived encryption keys that are disposed, OpenPGP can offer some degree of forward secrecy (albeit with a much larger session window than other schemes). OpenPGP has the advantage of supporting groups and offline messages. 114 | 115 | **SCIMP** 116 | 117 | SCIMP is the protocol used by SilentCircle chat. SCIMP has some improvements over OTR, but is more brittle than Axolotl. Current SCIMP specification leaks information that can be used to correlate traffic. There are no free or open source implementations of SCIMP. It does not support groups. 118 | 119 | **Axolotl** 120 | 121 | Axolotl is a new protocol from Trevor Perrin and Moxie Marlinspike. It has a key ratchet system that offers resilient PFS and can be made to work with asynchronous messages (fully PFS on the first message if the client publishes in advance a pool of ephemeral ECC public keys). 122 | 123 | The current TextSecure implementation of Axolotl simulates groups by maintaining many 1:1 chat sessions. The chat transcripts are not yet validated to confirm that every user saw the same chat conversation, nor is there a way to manage the membership in a group. 124 | 125 | **Other** 126 | 127 | There are several other schemes for end-to-end XMPP message encryption, including Encrypted Session Negotiation (ESession) and XMPP Transport Layer Security (XTLS). In addition to not being used by anyone, they don't support both asynchronous and forward secret messages at the same time. 128 | 129 | 130 | ## Key Discovery and Validation 131 | 132 | In many ways, proper validation of public keys is bedrock precondition for any message security: you cannot ensure confidentiality or integrity without confirming the authenticity of the other party. Unfortunately, current schemes for validating the authenticity of a user's public key have fallen out of favor as insecure, too difficult, or for leaking metadata (e.g. Certificate Authorities, the Web of Trust). Many so called "secure" chat systems, like Telegram or Skype, don't have any key validation at all, resulting in a system with no actual confidentiality (Telegram recently added manual fingerprint validation for some chats, but it is clumsy and optional). 133 | 134 | Almost all the new "easy" security tools approach key validation by using Trust on First Use (TOFU), where keys are assumed to be valid when they are first seen. TOFU is much better than no validation, but has many limitations (although schemes that use TOFU can be considerably strengthened by layering additional checks, such as network perspective or endorsement). 135 | 136 | Although there are many methods of solving the problem of binding a user identifier to a cryptographic key, none have emerged as a widely adopted standard. 137 | 138 | Requirements: 139 | 140 | * Auto discovery: The client application should be able to automatically discover the public keys associated with a particular identifier without user intervention. 141 | * Auto validation: The client application should be able to automatically validate the authenticity of public keys, securely binding an identifier to the public key, without user intervention. 142 | * Meta-data protection: The user should not need to leak to a third party what keys they are interested in. 143 | * No spam, please: The user identifiers should not be globally enumerable. 144 | * Global view: In contrast to the user identifiers, it is desirable to have a global view into all public user keys to ensure that any bogus authentications are made public. 145 | * Auditability: Authentications by authenticating parties should be externally auditable by anyone (in other words, it should not be up to the user to be the sole auditor of the authentications made for their keys). 146 | 147 | ### Possible candidates 148 | 149 | **DNSSEC with DANE** 150 | 151 | DANE is a key discovery protocol over DNS that uses DNSSEC to allow the provider to securely endorse the results. DANE is an open standard, but it is unused, is troublesome to implement, and leaks metadata to a network observer. 152 | 153 | **Nickym** 154 | 155 | Nicknym is an experimental, lightweight REST-based discovery and validation protocol designed for this very problem. It uses a combination of TOFU, provider endorsement, and network perspective. The primary limitation with Nicknym is that it does not provide a global view, so ultimately it relies on the user's nicknym agent to report any bogus keys signed for the user. See https://leap.se/nicknym for more information. 156 | 157 | **Namecoin variants** 158 | 159 | An experimental p2p message system called Twister has solved this binding problem in a totally decentralized way by using a global append only log (borrowed from Bitcoin and Namecoin). This approach is very promising, but perhaps too experimental, resource intensive, and untested to be considered for Newchat at this time. 160 | 161 | **Modified Certificate Transparency** 162 | 163 | Although CT is not designed for service providers to sign user keys, it could be modified to support this. For example, CT logs could consist of a hashed user identifier with the corresponding public key. There is a paper that proposes to extend CT to support user keys and add better support for revocation ([Enhanced Certificate Transparency and End-to-end Encrypted Email](http://www.internetsociety.org/doc/enhanced-certificate-transparency-and-end-end-encrypted-mail)). 164 | 165 | ## Media Linking 166 | 167 | Chat today is media rich. Participants need to be able to attach links, images, audio, video, and other files inline with their messages. 168 | 169 | Requirements: 170 | 171 | * Securely embed rich media in chat messages via external resource URLs that point to encrypted content. 172 | * Only participants of the chat session may decrypt the content. 173 | * A third party observer should not be able to identify who is participating in the chat by how the participants access the media associated with the chat. 174 | 175 | ### Candidates 176 | 177 | **Naive HTTP** 178 | 179 | As a first approximation, Newchat clients could simply embed an HTTP URL in the message and encrypt the content retrievable at that URL using the current session key. So long as all currently participants download the URL immediately, this will work fine and is easy to implement. 180 | 181 | There are several problems with this approach: 182 | 183 | * This approach is not particularly efficient. In each participant wants to retain the ability to access the media resource, they need to download and save a copy for themselves. 184 | * If every client fetches the media resource, this will leak to a network observer who is participating in the chat. This information is leaked both to the media server (by logging who requests a particular resource), and to a network observer (by tracking the size of HTTP response). 185 | 186 | **Federated Storage** 187 | 188 | A better long term approach would be to have a federated cloud storage system. In this model, when a user posts a media link, this link can be used to obtain read (or read/write) access rights to a resource. For example, if the system was based on Tahoe-LAFS, each participant would be given a resource identifier and a copy of the capabilities key. 189 | 190 | # Application Protocols 191 | 192 | In order to achieve the desired usability and security, all Newchat clients will need support in the following areas. 193 | 194 | * Secure authentication and signup 195 | * Key management 196 | * Data synchronization 197 | * Group management 198 | * Push notification 199 | 200 | These protocols, and the libraries for them, are not needed for client interoperability, but they are required in order for a client to provide the kind of user experience that Newchat promises. Each Newchat client could use different libraries and protocols for each of these features. 201 | 202 | ## Secure authentication and signup 203 | 204 | Traditional authentication systems based on username and password typically rely on the server having access to a cleartext copy of the password at some moment in time. Although this creates all sorts of security problems, username-plus-password is still by far the most easy and approachable method of user authentication. 205 | 206 | Newchat has two competing promises: 207 | 208 | 1. All user data is encrypted on the client device 209 | 2. Users can authenticate using the familiar method of username-plus-password 210 | 211 | The primary problem is that if the server is able to see the password in cleartext at any time in history, and this password is also used to unlock the keys needed for client-side encryption, then the user is back to essentially placing blind trust in the provider. 212 | 213 | Requirements: 214 | 215 | * Password authentication that does not leak the password to the service provider. 216 | * New user registration 217 | * User destruction 218 | * Session management 219 | * Support for smart-cards and other non-password methods of authentication 220 | 221 | ### Candidates 222 | 223 | **SRP-based systems** 224 | 225 | There is a class of cryptographic protocols called "zero-knowledge proofs" that will nicely solve this problem. By using a zero-knowledge proof, a user can authenticate themselves with the server without ever handing over a copy of their password for the server to hash (as is required in traditional username-plus-password authentication schemes). In particular, Secure Remote Password (SRP) is zero-knowledge system designed specifically to solve the username-plus-password authentication problem. 226 | 227 | LEAP's Bonafide is a simple REST api that allows for authentication via SRP, account registration and deletion. After authentication, the client is given a simple session token that can be used to for any number of different services. Bonafide includes a reference client implementation in python and javascript. Currently, Bonafide uses a couchdb backend, but could be written to work with any database. Bonafide does not yet support smart-cards. 228 | 229 | **Signature-based systems** 230 | 231 | An alternate approach to the same problem is for the client device to upload a public key at the moment of account creation. To authenticate, the user's device is presented with a challenge by the server composed of random characters. If the client device can send back this challenge signed with the private signing key, and the server verifies this signature using the initially uploaded public key, then the user is granted a session token. 232 | 233 | Sureshot includes a signature based registration and authentication scheme. The advantage of a signature scheme is that it is more resistant to offline brute force attempts to guess the password. The disadvantage is that the user must have access to their private key in order to authenticate. 234 | 235 | **KDF-based systems** 236 | 237 | For a suitable Key Derivation Function `kdf`, the client can generate two hashes from the password using `kdf(password, 1)` and `kdf(password, 2)`. The result of one can be used to authenticate with the server, and the result of the other can be used to unlock encrypted storage. 238 | 239 | This system is by far the most simple, but does not support some of the features that SRP has, such as the ability of the user to also authenticate the server and the derivation of an ephemeral shared secret. Also, if the record kept on the server of the user's hash is ever leaked, then an attacker can trivially authenticate as that user. 240 | 241 | ## Key management 242 | 243 | Any attempt to make public-key cryptography easy on the user will necessitate more advanced software logic to automate proper maintenance of keys. Key management is fairly straightforward, until something goes wrong. The tricky part of the key manager is deciding how to handle key revocation, resolving key conflicts, and replacing a key with a new version. 244 | 245 | Requirements: 246 | 247 | * Generate public/private key pairs. 248 | * Manage a database of discovered and validated public keys of other users. 249 | * Make keys securely available on multiple devices. 250 | * Implement client support for Key Discovery and Validation protocol. 251 | * Securely handle key revocation, key replacement, and key conflicts. 252 | 253 | ### Candidates 254 | 255 | **LEAP's Key Manager** 256 | 257 | The key manager in the Bitmask application works as a "nickagent" and uses the Nicknym protocol and OpenPGP keyservers. It currently supports most of these features, but does not handle revocation, key replacement, key conflicts, or validation via network perspective (planned, but not implemented). 258 | 259 | ## Data synchronization 260 | 261 | Users today demand "data availability," the ability to access their data on multiple devices and to have piece of mind that there data will not be lost forever if they lose a device. For chat applications, data synchronization is needed for ensuring the availability of keys, contact rosters, media files, and chat history. 262 | 263 | There are several proprietary synchronization services offered by companies like Apple, Google, Dropbox, Microsoft, and Amazon. These services are insecure and designed to lock the user into continued use of a particular data provider. For Newchat, clients will need something much better. 264 | 265 | Requirements: 266 | 267 | * Data should be efficiently synchronized with all the user's devices 268 | * Data should be backed up in cloud storage in case a user loses their devices. 269 | * Data should be client-encrypted at all times (when stored locally, and when backed up to the cloud). 270 | * Some data should be synchronized only when requested (such as large files). 271 | 272 | ### Candidates 273 | 274 | **LEAP's Soledad** 275 | 276 | Soledad is a client-encrypted synchronized document database, with the ability to index fields and query structured documents. The data is kept synchronized with a server, and among the user's devices. It currently only works in Python. It currently uses HTTP, but this has proved to be very limiting and future development will focus on a more efficient synchronization transport. 277 | 278 | **Mozilla's Firefox Sync** 279 | 280 | Firefox Sync supports client-encrypted synchronization, but does not include a facility for search or secure local storage. To date, I don't think anyone other software besides Firefox uses Firefox Sync. 281 | 282 | **Spideroak's Crypton** 283 | 284 | Crypton currently works only in the web browser. Crypton has been heavily audited by third parties, and could be adopted outside the browser. 285 | 286 | ## Group management 287 | 288 | XMPP has a concept of a private group chat, but the user must entirely trust the provider to properly maintain the list of group members. For secure group chat, Newchat will require an API for managing groups securely. 289 | 290 | In the short term, it is probably sufficient define groups by simple consensus: Once a group is created, if any member of this group adds someone, then all the other participants accept this change. The only way to remove someone is if they decide to leave. 291 | 292 | In the long term, this simple model is not sufficient to achieve the full functionality of groups found in popular chat applications. 293 | 294 | Requirements: 295 | 296 | * Ability to create and destroy groups. 297 | * Ability to add and remove users from a group. 298 | * Ensure all group members get updates to the group membership list. 299 | * Ensure that only authorized member may modify the group membership list. 300 | * Ensure the server cannot replay an old membership list. 301 | 302 | Candidates: 303 | 304 | * None, new development needed. 305 | 306 | ## Efficient push notifications 307 | 308 | Typically, XMPP works by keeping a TCP connection open at all times. This works for desktop clients, but does not perform well on mobile devices or where network service is spotty. We need a library that can create an abstraction of the different push notification systems, including the proprietary ones native to android and IOs, as well as the open source alternatives. 309 | 310 | In the short term, a solution in this area may not be necessary. Many mobile chat applications get away with very inefficient polling without driving away their users. In the long term, this is an important problem that needs to be solved. 311 | 312 | ### Candidates 313 | 314 | **TextSecure** 315 | 316 | The TextSecure server has support for push notification via WebSockets, as well as using the Google Cloud Messaging (GCM) and Apple Push Notification Service (APN). 317 | 318 | -------------------------------------------------------------------------------- /threat-models.md: -------------------------------------------------------------------------------- 1 | # Threat models 2 | 3 | Thread models for end-to-end encrypted chat. 4 | 5 | Adapted from: https://gist.github.com/Geal/8228049 6 | 7 | ## Threat model goals 8 | 9 | In the short term, the goal with Newchat is to be resistant to the following attacks: 10 | 11 | * attacker reads messages on the wire 12 | * attacker modifies messages on the wire 13 | * attacker drops messages going to other participants 14 | * attacker drops messages coming from other participants 15 | * attacker sends messages to a conversation (not a participant) 16 | * attacker obtains the encryption key for one message 17 | * attacker obtains the encryption key(s) for multiple messages 18 | * attacker obtains a shared session key of two participants 19 | * attacker obtains all the previous session keys of two participants at a certain point 20 | * attacker obtains all the previous session keys of all participants at a certain point 21 | * attacker sends a message on behalf of a user 22 | * attacker replays a message 23 | * attacker sends different messages to different participants 24 | * attacker asks for a rekeying 25 | * attacker adds multiple users 26 | * attacker adds a lot of bogus users 27 | * attacker connects to the conversation, and tries to impersonate a previous participant 28 | 29 | In the long term: 30 | 31 | * attacker discovers one or more participants in a conversation 32 | * attacker splits the conversation in two or more sets of participants 33 | 34 | ## Threats that are out of scope 35 | 36 | These attacks might be too difficult to address, except in the long term: 37 | 38 | * attacker observes message size on the wire 39 | * attacker delays messages to other participants 40 | * attacker delays messages from other participants 41 | * attacker prevents a participant from joining a conversation 42 | * attacker prevents a participant from following the conversation 43 | * attacker prevents multiple participants from following the conversation 44 | * attacker abruptly disconnects participants 45 | * attacker sends a lot of bogus messages 46 | * attacker sends a lot of valid messages (ex: replays? attacker is a participant?) 47 | * participant attacker asks for a rekeying 48 | * participant attacker floods the channel 49 | --------------------------------------------------------------------------------