├── .gitignore ├── 2018_talk_brussels_oct_20 ├── talk.css ├── Makefile ├── img │ └── delta-scan.png └── talk.rst ├── 2018_talk_lausanne_jan_17 ├── Makefile ├── img │ └── merlinux-klein.png └── talk.rst ├── images ├── join_verified_group.jpg ├── secure_channel_foto.jpg ├── no_gossip.seq ├── dkim.seq ├── gossip.seq ├── contact.seq ├── no_gossip.svg ├── dkim.svg ├── gossip.svg └── contact.svg ├── source ├── img │ ├── join_verified_group.jpg │ └── nextleap_logo_transp_1004x538.png ├── _templates │ ├── sidebarintro.html │ ├── searchbox.html │ └── globaltoc.html ├── _static │ ├── staging.css │ └── custom.css ├── index.rst ├── gen_attack_table.py ├── drafts │ ├── sync-cc-capabilities.rst │ └── inband-cc.rst ├── dkim.rst ├── gossip.rst ├── conf.py ├── summary.rst ├── claimchains.rst └── new.rst ├── CHANGELOG.rst ├── README.md └── Makefile /.gitignore: -------------------------------------------------------------------------------- 1 | build/* 2 | images/*.pdf 3 | -------------------------------------------------------------------------------- /2018_talk_brussels_oct_20/talk.css: -------------------------------------------------------------------------------- 1 | li { 2 | line-height: 2; 3 | font-size: larger; 4 | } 5 | -------------------------------------------------------------------------------- /2018_talk_brussels_oct_20/Makefile: -------------------------------------------------------------------------------- 1 | 2 | doc: 3 | hovercraft talk.rst html 4 | 5 | export: 6 | hover 7 | -------------------------------------------------------------------------------- /2018_talk_lausanne_jan_17/Makefile: -------------------------------------------------------------------------------- 1 | 2 | doc: 3 | hovercraft talk.rst html 4 | 5 | export: 6 | hover 7 | -------------------------------------------------------------------------------- /images/join_verified_group.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nextleap-project/countermitm/HEAD/images/join_verified_group.jpg -------------------------------------------------------------------------------- /images/secure_channel_foto.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nextleap-project/countermitm/HEAD/images/secure_channel_foto.jpg -------------------------------------------------------------------------------- /source/img/join_verified_group.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nextleap-project/countermitm/HEAD/source/img/join_verified_group.jpg -------------------------------------------------------------------------------- /2018_talk_brussels_oct_20/img/delta-scan.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nextleap-project/countermitm/HEAD/2018_talk_brussels_oct_20/img/delta-scan.png -------------------------------------------------------------------------------- /source/img/nextleap_logo_transp_1004x538.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nextleap-project/countermitm/HEAD/source/img/nextleap_logo_transp_1004x538.png -------------------------------------------------------------------------------- /2018_talk_lausanne_jan_17/img/merlinux-klein.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nextleap-project/countermitm/HEAD/2018_talk_lausanne_jan_17/img/merlinux-klein.png -------------------------------------------------------------------------------- /source/_templates/sidebarintro.html: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /images/no_gossip.seq: -------------------------------------------------------------------------------- 1 | # This is a sequence diagram for the dkim section 2 | # I used https://bramp.github.io/js-sequence-diagrams/ 3 | # to render it to svg and then save it in images folder 4 | 5 | participant Alice as Ua 6 | participant Attacker as At 7 | participant Bob as Ub 8 | participant Claire as Uc 9 | 10 | Ua --> At: (1) a 11 | At --> Ub: (2) a' 12 | Ub --> At: (3) b(a') 13 | At --> Ua: (4) b'(a) 14 | Ua -> Uc: (5) a 15 | Uc -> Ua: (6) c(a) 16 | Ub -> Uc: (7) b 17 | Uc -> Ub: (8) c(b) 18 | 19 | -------------------------------------------------------------------------------- /source/_static/staging.css: -------------------------------------------------------------------------------- 1 | body:before { 2 | content: "THIS IS A DRAFT! please refer to https://autocrypt.org/ for the current Autocrypt website"; 3 | display: block; 4 | position: fixed; 5 | top: 0px; 6 | left: 0px; 7 | padding: 1em; 8 | color: black; 9 | font-weight: bold; 10 | font-size: 150%; 11 | min-height: 2em; 12 | z-index: 10; 13 | background-color: rgba(255,0,0,0.1); 14 | text-shadow: 5px 5px 2px rgba(0,0,0,0.2); 15 | text-align: center; 16 | } 17 | .document { 18 | padding-top: 4em; 19 | } 20 | -------------------------------------------------------------------------------- /source/index.rst: -------------------------------------------------------------------------------- 1 | .. Counter Mitm documentation master file, created by 2 | sphinx-quickstart on Fri Jan 12 14:21:14 2018. 3 | You can adapt this file completely to your liking, but it should at least 4 | contain the root `toctree` directive. 5 | 6 | Detecting and preventing active attacks against Autocrypt 7 | ========================================================= 8 | 9 | .. toctree:: 10 | :maxdepth: 2 11 | :numbered: 12 | 13 | summary.rst 14 | new.rst 15 | claimchains.rst 16 | gossip.rst 17 | dkim.rst 18 | -------------------------------------------------------------------------------- /source/_templates/searchbox.html: -------------------------------------------------------------------------------- 1 | {%- if pagename != "search" and builder != "singlehtml" %} 2 | 10 | 11 | {%- endif %} 12 | -------------------------------------------------------------------------------- /images/dkim.seq: -------------------------------------------------------------------------------- 1 | # This is a sequence diagram for the dkim section 2 | # I used https://bramp.github.io/js-sequence-diagrams/ 3 | # to render it to svg and then save it in images folder 4 | 5 | participant Alice as Ua 6 | participant Alice Provider as Pa 7 | participant Bob Provider as Pb 8 | participant Bob as Ub 9 | 10 | 11 | Ua -> Pa: (1) a 12 | Pa -> Pb: (2) DKIM_ap(a) 13 | Pb ->> Pa: (3) get ap 14 | Pa ->> Pb: (4) ap 15 | Note over Pb: (5) Verify_ap(DKIM_ap(a)) 16 | Pb -> Ub: (6) DKIM_ap(a) 17 | Ub ->> Pa: (7) get ap 18 | Pa ->> Ub: (8) ap 19 | Note over Ub: (9) Verify_ap(DKIM_ap(a)) 20 | -------------------------------------------------------------------------------- /images/gossip.seq: -------------------------------------------------------------------------------- 1 | # This is a sequence diagram for the dkim section 2 | # I used https://bramp.github.io/js-sequence-diagrams/ 3 | # to render it to svg and then save it in images folder 4 | 5 | participant Alice as Ua 6 | participant Attacker as At 7 | participant Bob as Ub 8 | participant Claire as Uc 9 | 10 | Ua --> At: (1) a(b',c) 11 | At --> Ub: (2) a'(b,c) 12 | Ua -> Uc: (3) a(b',c) 13 | Note over Uc: (4) C's client sees other key b' for B 14 | Ub --> At: (5) b(a',c) 15 | At --> Ua: (6) b'(a,c) 16 | Ub -> Uc: (7) b(a',c) 17 | Note over Uc: (8) C's client sees other key a' for A 18 | Uc -> Ua: (9) c(a,b) 19 | Uc -> Ub: (10) c(a,b) 20 | -------------------------------------------------------------------------------- /source/_templates/globaltoc.html: -------------------------------------------------------------------------------- 1 | 2 | 3 |

countermitm-{{ release }}

4 | 5 |
6 |
7 | 15 |
16 |
17 | -------------------------------------------------------------------------------- /CHANGELOG.rst: -------------------------------------------------------------------------------- 1 | 0.10.0 (Incorporating feedback and finalizing) 2 | ---------------------------------------------- 3 | 4 | - include feedback received after sharing countermitm 5 | with the messaging@moderncrypto.org mailing list: 6 | 7 | - build verified group and history verification 8 | based on contact verification. 9 | 10 | - prevent replay attacks 11 | 12 | - improve readability and clarity in the entire document. 13 | (Wouter Lueks) 14 | 15 | - refine and document the interaction of encryption 16 | with verified and opportunistic Autocrypt keys. 17 | 18 | - address device loss in a verified group scenario. 19 | 20 | - add presentation slides for OpenPGP Summit 2018 in Brussels. 21 | 22 | 23 | 0.9.1 (typo/word/format-fixing) 24 | ------------------------------- 25 | 26 | - enable html numbering 27 | 28 | - fix title of dkim section, and several typos 29 | 30 | - streamline wording in claimchain, fix typos 31 | 32 | 0.9.0 33 | ----- 34 | 35 | - initial public release 36 | -------------------------------------------------------------------------------- /images/contact.seq: -------------------------------------------------------------------------------- 1 | # This is a sequence diagram for the dkim section 2 | # I used https://bramp.github.io/js-sequence-diagrams/ 3 | # to render it to svg and then save it in images folder 4 | 5 | participant Alice as A 6 | participant Bob as B 7 | 8 | A --> B: 1.a) bootstrap code 9 | Note over A: 1.b) track bootstrap per INVITENUMBER 10 | Note over B: 2.a) check for exising key 11 | B ->> A: 2.b) vc-request message with INVITENUMBER 12 | Note over A: 3.a) look up bootstrap by INVITENUMBER 13 | Note over A: 3.b) abort if invite expired 14 | Note over A: 3.c) process AC header 15 | A -> B: 3.d) vc-auth-required message with AC header 16 | Note over B: 4.a) abort if key does not match FP from bootstrap 17 | B -> A: 4.b) vc-request-with-auth with Bob_FP and AUTH 18 | Note over A: 5.a) verify AUTH and key 19 | Note over A: 5.b) on failure alert user and abort 20 | Note over A: 6.a) signal success to user 21 | A -> B: 6.b) vc-contact-confirm message 22 | Note over A: 6.c) clear bootstrap data for INVITENUMBER 23 | Note over B: 7. signal success to user 24 | 25 | -------------------------------------------------------------------------------- /source/gen_attack_table.py: -------------------------------------------------------------------------------- 1 | 2 | from __future__ import print_function 3 | from math import factorial as fac 4 | 5 | def print_headers(verifications): 6 | print("{0:>5} {1:>7} {2:>10}".format("size", "edges", "mitm"), end=" ") 7 | for v in verifications: 8 | print ("{0:>5}".format("v=" + str(v)), end=" ") 9 | print() 10 | 11 | def print_row(size, mitm, verifications): 12 | edges = int(size * (size - 1) / 2) 13 | print("{0:>5} {1:>7} {2:>10}".format(size, edges, mitm), end=" ") 14 | for v in verifications: 15 | a = mitm 16 | g = edges - mitm 17 | c = edges 18 | if edges > (mitm + v): 19 | not_noticed = ((fac(g) * fac(c - v)) / 20 | (fac(c) * fac(g - v))) 21 | else: 22 | not_noticed = 0 23 | detect_prob = 1 - not_noticed 24 | print ("{0:>6}".format("{0:02.1%}".format(detect_prob)), end=" ") 25 | print() 26 | 27 | if __name__ == "__main__": 28 | 29 | sizes = range(3, 18) 30 | verifications = range(1, 10) 31 | 32 | print_headers(verifications) 33 | 34 | print_row(size=4, mitm=1, verifications=verifications) 35 | print_row(size=4, mitm=2, verifications=verifications) 36 | print_row(size=4, mitm=3, verifications=verifications) 37 | print_row(size=8, mitm=1, verifications=verifications) 38 | print_row(size=8, mitm=2, verifications=verifications) 39 | print_row(size=8, mitm=3, verifications=verifications) 40 | 41 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # countermitm (reversing the panopticon) 2 | 3 | Evolving research on new protocols and approaches to counter 4 | mitm-attacks on Autocrypt E-Mail encryption. 5 | 6 | The work on the initial 0.9 release has been contributed 7 | by NEXTLEAP researchers, an project on privacy and decentralized messaging, 8 | funded through the EU Horizon 2020 programme. 9 | 10 | During the remainder of 2018 we'd like to incorporate 11 | feedback, comments and contributions, 12 | before publishing a "1.0" version of this paper. 13 | Contributors will be listed with the final release. 14 | 15 | If you want to do Pull Requests please note that we are using 16 | [Semantic Linefeeds](http://rhodesmill.org/brandon/2012/one-sentence-per-line/). 17 | It means that the source code of this document should be 18 | broken down to a "one-line-per-phrase" format, 19 | as to make reviewing diffs easier. 20 | 21 | ## The document uses RestructuredText 22 | 23 | While this readme uses Markdown syntax, the actual document 24 | uses the richer RestructuredText format and in particular 25 | the "Sphinx Document Generators". You can probably get 26 | around by just mimicking the syntax and "tricks" 27 | of the existing text. You may also look at this 28 | [reStructuredText Primer](http://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html) for some basic editing advise. 29 | 30 | 31 | ## Building the pdf 32 | 33 | For the images we use inkscape to convert them from svg to pdf. 34 | 35 | In order to create the documents you will need make, sphinx and inkscape installed 36 | on your system. On a debian based system you can achieve this with 37 | 38 | ```sh 39 | sudo apt install python-sphinx inkscape 40 | ``` 41 | 42 | From there on creating the pdf should be a matter of running 43 | 44 | ```sh 45 | make images 46 | make latexpdf 47 | ``` 48 | 49 | ## Build Results 50 | 51 | Once the build is completed there will be a CounterMitm.pdf file in the 52 | build/latex directory. This contains the different approaches. 53 | 54 | ## Modifying the Images 55 | 56 | The sources for the images are stored in .seq files. 57 | We used https://bramp.github.io/js-sequence-diagrams/ to turn them into 58 | svgs that live in the images directory. 59 | 60 | We have not found a good way to automate this yet. 61 | -------------------------------------------------------------------------------- /source/drafts/sync-cc-capabilities.rst: -------------------------------------------------------------------------------- 1 | Synchronizing CC capabilities accross devices 2 | ============================================== 3 | 4 | There's two different approaches to creating claim chain blocks: 5 | a) The one described in the paper including capabilities 6 | in the block. 7 | b) One where the capabilities are left out of the block 8 | and privided in addition to the block whenever the block owner 9 | wants to reveal the corresponding fact. 10 | 11 | In the former scenario blocks encode both 12 | our knowledge about the world 13 | and who we share it with. 14 | In the latter scenario these two aspects are separated 15 | 16 | 17 | Tracking capabilities 18 | --------------------- 19 | 20 | In scenario b) peers would loose access to all claims 21 | when a new block is created. 22 | 23 | This makes it hard to detect changes that occured between blocks 24 | and therefor opens the possibility of equivocating 25 | by sending different blocks to different peers. 26 | 27 | Therefor we need to send each peer proofs of inclusion 28 | for their key for all blocks we commit. 29 | 30 | At the same time tracking and syncing state across devices 31 | that may be used offline 32 | is hard and error prone. 33 | 34 | 35 | Multi device usage and offline mail composition 36 | ---------------------------------- 37 | 38 | When composing emails people are not neccessarily online. 39 | In addition they are using multiple devices. 40 | So they may be composing mail on a device 41 | that does not know the latest state of their claim chain. 42 | 43 | Sending emails at some point requires online connectivity. 44 | However delaying claim chain opperations until the mail is send 45 | breaks current MUA designs. 46 | 47 | Composing an email that introduces peers to each other 48 | the MUA should be able to perform the required CC operations 49 | even when operating on an outdated state. 50 | 51 | Updates to the chain on two devices that cannot sync 52 | will necessarily involve a branching in the CC history. 53 | Therefor we will have to merge them when uploading the blocks. 54 | 55 | 56 | Merging Claim Chains 57 | -------------------- 58 | 59 | A lot of concurrent changes can be merged without conflicts. 60 | In order to achieve this the MUA has to consider 61 | the changes in the chain rather than there latest state: 62 | If one chain contains a key for an email address 63 | and the other does not 64 | this may indicate an addition in the former 65 | or a removal in the latter chain. 66 | 67 | Unresolvable conflicts include different keys added 68 | for the same email address. 69 | This probably also is an error case 70 | we want to draw the users attention to. 71 | We can derive a deterministic solution for which 72 | key to continue using if we store the effective date 73 | we received the claim at inside the claim chain. 74 | -------------------------------------------------------------------------------- /2018_talk_brussels_oct_20/talk.rst: -------------------------------------------------------------------------------- 1 | :css: talk.css 2 | 3 | .. title: Securing Autocrypt against active attacks 4 | 5 | 6 | ---- 7 | 8 | Securing Autocrypt against active attacks 9 | ========================================= 10 | 11 | presented at OpenPGP Summit Brussels 2018 12 | by azul@merlinux.eu 13 | 14 | 15 | ---- 16 | 17 | CounterMitM 18 | =========== 19 | 20 | - developed as part of NEXTLEAP research 21 | 22 | - based on Autocrypt Level 1 23 | 24 | - Here: Focus on OpenPGP based ideas 25 | 26 | ---- 27 | 28 | Autocrypt Level 1 29 | ================= 30 | 31 | - prevent passive collection of email content 32 | 33 | - usability centered 34 | 35 | - replace clear text mail 36 | 37 | - Autocrypt gossip to make encrypted reply to all easy. 38 | 39 | ---- 40 | 41 | Active Attacks against Autocrypt Level 1 42 | ======================================== 43 | 44 | - Machine in the middle attack (MitM) 45 | 46 | - In band key transfer = easier for MitM 47 | 48 | - replace Autocrypt headers with MitM keys 49 | 50 | - continuously reencrypt 51 | 52 | - end attack by reencrypting without replacing headers 53 | 54 | ---- 55 | 56 | Verify Contacts based on QR codes 57 | ================================== 58 | 59 | .. image:: img/delta-scan.png 60 | 61 | - one person shows the QR code, other person scans. 62 | 63 | - works with laptop & mobile 64 | 65 | ---- 66 | 67 | Underlying mechanism 68 | ==================== 69 | 70 | - similar to fingerprint printouts 71 | with secret to authenticate recipient 72 | 73 | - requires confidentiallity of QR code 74 | 75 | - system messages 76 | 77 | - currently using Autocrypt headers for key retrieval 78 | 79 | could use: keyserver, wkd, etc. 80 | 81 | ---- 82 | 83 | Securing Group Communication 84 | ============================ 85 | 86 | - pairwise verification does not scale 87 | 88 | - web of trust leaks the social graph 89 | 90 | - gossip consistency: 91 | error cases instead of use cases 92 | 93 | ---- 94 | 95 | Verified groups 96 | =============== 97 | 98 | - use cases: 99 | - join group 100 | - add member to group 101 | 102 | - flow: 103 | - verify contact 104 | - send introduction message 105 | 106 | ---- 107 | 108 | Verified groups: Properties 109 | =========================== 110 | 111 | - fully connected verification graph 112 | 113 | - can replace gossip 114 | 115 | ---- 116 | 117 | Verified groups: Considerations 118 | =============================== 119 | 120 | - Reuse verifications accross groups? 121 | 122 | - + easier to create new groups 123 | 124 | - + faster recovery from lost device 125 | 126 | - - combined attack of provider and verified contact 127 | 128 | - - less incentitive to verify contacts 129 | 130 | 131 | ---- 132 | 133 | Verified groups: Infiltrator attack 134 | =================================== 135 | 136 | - Alice, Bob and Egon 137 | 138 | - Egon verified Alice and Bob, started the group 139 | 140 | - Egon collaborates with MitM attacker and introduced MitM keys 141 | 142 | - Attacker can MitM mails between Alice and Bob 143 | 144 | - Evidence of Egons involvement in signed messages 145 | 146 | ---- 147 | 148 | 149 | History verification 150 | ==================== 151 | 152 | - use case: 153 | Verifying existing contact 154 | 155 | - flow: 156 | - verify contact 157 | - exchange message-key log 158 | 159 | - goal: detect previous MitM attacks 160 | 161 | ---- 162 | 163 | More 164 | ==== 165 | 166 | - Claimchains: 167 | Privacy-preserving decentralized public key distribution based on 168 | cross-referencing hash chains. 169 | https://claimchain.github.io/ 170 | 171 | - Gossip consistency 172 | 173 | - Using DKIM to verify Autocrypt headers 174 | 175 | - https://github.com/nextleap-project/countermitm 176 | -------------------------------------------------------------------------------- /images/no_gossip.svg: -------------------------------------------------------------------------------- 1 | # This is a sequence diagram for the dkim section 2 | # I used https://bramp.github.io/js-sequence-diagrams/ 3 | # to render it to svg and then save it in images folder 4 | 5 | participant Alice as Ua 6 | participant Attacker as At 7 | participant Bob as Ub 8 | participant Claire as Uc 9 | 10 | Ua --> At: (1) a 11 | At --> Ub: (2) a' 12 | Ub --> At: (3) b(a') 13 | At --> Ua: (4) b'(a) 14 | Ua -> Uc: (5) a 15 | Uc -> Ua: (6) c(a) 16 | Ub -> Uc: (7) b 17 | Uc -> Ub: (8) c(b) 18 | AliceAliceAttackerAttackerBobBobClaireClaire(1) a(2) a'(3) b(a')(4) b'(a)(5) a(6) c(a)(7) b(8) c(b) -------------------------------------------------------------------------------- /images/dkim.svg: -------------------------------------------------------------------------------- 1 | # This is a sequence diagram for the dkim section 2 | # I used https://bramp.github.io/js-sequence-diagrams/ 3 | # to render it to svg and then save it in images folder 4 | 5 | participant Alice as Ua 6 | participant Alice Provider as Pa 7 | participant Bob Provider as Pb 8 | participant Bob as Ub 9 | 10 | 11 | Ua -> Pa: (1) a 12 | Pa -> Pb: (2) DKIM_ap(a) 13 | Pb ->> Pa: (3) get ap 14 | Pa ->> Pb: (4) ap 15 | Note over Pb: (5) Verify_ap(DKIM_ap(a)) 16 | Pb -> Ub: (6) DKIM_ap(a) 17 | Ub ->> Pa: (7) get ap 18 | Pa ->> Ub: (8) ap 19 | Note over Ub: (9) Verify_ap(DKIM_ap(a)) 20 | AliceAliceAlice ProviderAlice ProviderBob ProviderBob ProviderBobBob(1) a(2) DKIM_ap(a)(3) get ap(4) ap(5) Verify_ap(DKIM_ap(a))(6) DKIM_ap(a)(7) get ap(8) ap(9) Verify_ap(DKIM_ap(a)) -------------------------------------------------------------------------------- /2018_talk_lausanne_jan_17/talk.rst: -------------------------------------------------------------------------------- 1 | 2 | Securing Autocrypt against active attacks 3 | ============================================= 4 | 5 | - What is Autocrypt Level 1? Why E-Mail? 6 | 7 | - DKIM and Autocrypt gossip as verifications 8 | 9 | - ClaimChains and keeping histories 10 | 11 | - Prioritized Out-of-Band verification 12 | 13 | ---- 14 | 15 | Why "E-Mail"? 16 | ===================== 17 | 18 | - largest socially federated messaging network 19 | 20 | - organizations need it 21 | 22 | - new mail clients change social use 23 | 24 | ---- 25 | 26 | Delta.chat (Android) 27 | ========================== 28 | 29 | - codewise: Telegram UI + E-mail/Autocrypt backend 30 | 31 | - shows: convenient messaging over e-mail possible! 32 | 33 | - freeing users from "in-app-only" messenging 34 | (``ETOOMANYMESSENGERS``) 35 | 36 | ---- 37 | 38 | Autocrypt Level 1 39 | ======================================== 40 | 41 | **Autocrypt Level 1 for users**: 42 | 43 | - one click encryption 44 | 45 | - allowing for encrypted group replies 46 | 47 | - support for setting up multiple device 48 | 49 | design UX note: 50 | 51 | **never ask users about keys, ever!** 52 | 53 | ---- 54 | 55 | Autocrypt gossip 56 | ================ 57 | 58 | - recipients's keys are in encrypted group-messages 59 | 60 | - allows recipients to reply encrypted to all 61 | 62 | - complicates attacks from message transport layer 63 | (peers can track inconsistencies) 64 | 65 | ---- 66 | 67 | DKIM signing of Autocrypt headers 68 | ================================= 69 | 70 | - providers starting to regularly sign Autocrypt headers 71 | (Posteo.de, others upcoming) 72 | 73 | - if only one out of two providers in an e-mail transactions 74 | performs MITM attack, peers can notice DKIM verification 75 | failures 76 | 77 | ---- 78 | 79 | ClaimChains 80 | ================== 81 | 82 | - framework for decentralized key consistency 83 | 84 | - peers maintain key-related claims in "chains" 85 | 86 | - peers can exchange chain entries or head hashes 87 | in "online" and "offline" variants 88 | 89 | ---- 90 | 91 | ClaimChain "Key consistency" 92 | ================================= 93 | 94 | - CONIKS: highly online-system to maintain 95 | key consistency/transparency 96 | (nobody deployed it yet) 97 | 98 | - ClaimChain (CC): can work offline/decentralized, 99 | thus avoiding turning providers into CAs -- they 100 | rather become accountable for not manipulating 101 | headers. 102 | 103 | ---- 104 | 105 | Decentralized "offline" ClaimChain 106 | ================================== 107 | 108 | - "in-band" CC does not depend on online services 109 | 110 | - CC can integrate "gossip" keys and facts about 111 | DKIM verification (and used keys) 112 | 113 | - if needed, special claimchain-related headers 114 | can be added to regular encrypted messages 115 | 116 | ---- 117 | 118 | ClaimChain and out-of-band verification 119 | --------------------------------------- 120 | 121 | design approach: 122 | 123 | - users trigger their MUAs to compare 124 | key **histories** (own and common contacts) 125 | 126 | - peers communicate claim chain contents 127 | through an "out-of-band" verified channel 128 | 129 | Usability goal: 130 | 131 | **provide users with conclusive evidence for 132 | MITM attacks, distinguished from common 133 | 'new device setup' events** 134 | 135 | ---- 136 | 137 | Comparing key histories 138 | ----------------------- 139 | 140 | - MUAs exchange "peer chains" which contains 141 | message flows between the two respective peers 142 | 143 | - can determine if a message was modified during 144 | time ranges contained in both peer's histories 145 | ("shared history") 146 | 147 | - a modified Autocrypt header in a message contained 148 | in shared history provides conclusive evidence 149 | for MITM attack (disambiguates from "lost device") 150 | 151 | ---- 152 | 153 | out-of-band verification 154 | ========================= 155 | 156 | two techno-social flows to consider: 157 | 158 | (1) have two MUAs initiate a secured connection 159 | in e.g. the local WLAN and exchange further 160 | messages there. 161 | 162 | (2) have to MUAs verify fingerprints+emailaddress 163 | and then send a regular looking message with extra 164 | information in the encrypted content. 165 | 166 | notes: 167 | 168 | - (2) can serve as fallback to (1) 169 | 170 | - in either case we have an "out-of-band" channel 171 | where additional messages can be exchanged. 172 | 173 | ---- 174 | 175 | Usability ideas related to OOB/chains 176 | ------------------------------------- 177 | 178 | - offer a prioritized list (per-group and/or global) 179 | of which peers to oob-verify with. 180 | 181 | - key inconsistencies (from gossip or device change) 182 | raise priority of getting new oob-verification 183 | 184 | - oob-verification gossip can also be sent along 185 | regular messages (in headers or attachments 186 | of encrypted message parts) 187 | 188 | 189 | ---- 190 | 191 | new UX: Verified Groups 192 | ========================================== 193 | 194 | - OOB-verify and join a group in one step 195 | 196 | - gossip new oob-verified member+key to group 197 | 198 | - lost key requires new OOB verification 199 | 200 | **security practise for activists?** 201 | 202 | ---- 203 | 204 | Ongoing work 2018 205 | ---------------------------- 206 | 207 | - R&D with Carmela Troncoso/EPFL and 208 | NEXTLEAP partners 209 | 210 | - https://muacrypt.readthedocs.io for exploring 211 | chain and oob implementations, to be used in 212 | "expert" mail setups and from mailing list software 213 | 214 | - https://delta.chat to implement QR-based OOB 215 | verification 216 | 217 | 218 | 219 | Open issues 220 | ------------------------------------- 221 | 222 | - precise definition of PeerChain, KeyChain 223 | and OOB-verification Chains 224 | 225 | - algorithm/design to have two peers verify 226 | "shared contacts" in a "contact privacy-preserving" 227 | way (i.e. my peer should not know when or maybe even 228 | if i oob-verified a shared contact). 229 | 230 | - design UI flows for OOB "prioritization" 231 | and for performing verifications. 232 | 233 | - ongoing OTF proposal to perform Delta.Chat 234 | user-testing with activists in repressive contexts 235 | 236 | - feedback into development of next-level 237 | Autocrypt specifications 238 | -------------------------------------------------------------------------------- /images/gossip.svg: -------------------------------------------------------------------------------- 1 | # This is a sequence diagram for the dkim section 2 | # I used https://bramp.github.io/js-sequence-diagrams/ 3 | # to render it to svg and then save it in images folder 4 | 5 | participant Alice as Ua 6 | participant Attacker as At 7 | participant Bob as Ub 8 | participant Claire as Uc 9 | 10 | Ua --> At: (1) a(b',c) 11 | At --> Ub: (2) a'(b,c) 12 | Ua -> Uc: (3) a(b',c) 13 | Note over Uc: (4) C's client sees other key b' for B 14 | Ub --> At: (5) b(a',c) 15 | At --> Ua: (6) b'(a,c) 16 | Ub -> Uc: (7) b(a',c) 17 | Note over Uc: (8) C's client sees other key a' for A 18 | Uc -> Ua: (9) c(a,b) 19 | Uc -> Ub: (10) c(a,b)AliceAliceAttackerAttackerBobBobClaireClaire(1) a(b',c)(2) a'(b,c)(3) a(b',c)(4) C's client sees other key b' for B(5) b(a',c)(6) b'(a,c)(7) b(a',c)(8) C's client sees other key a' for A(9) c(a,b)(10) c(a,b) -------------------------------------------------------------------------------- /source/dkim.rst: -------------------------------------------------------------------------------- 1 | .. raw:: latex 2 | 3 | \newpage 4 | 5 | Using DKIM signature checks to guide key verification 6 | ======================================================= 7 | 8 | With `DomainKeys Identified Mail (DKIM) `_, 9 | a mail transfer agent (MTA) signals to other MTAs that a particular message passed through one of its machines. In particular, a MTA signs outoing mail from their 10 | users with a public key that is stored with DNS, the internet domain 11 | name system. The MTA adds a ``DKIM-Signature`` header which is then verified 12 | by the next MTA which in turns may add an `Authentication-Results header 13 | `_. 14 | After one or more MTAs have seen and potentially DKIM-signed 15 | the message, it finally arrives at Mail User Agents (MUAs). MUAs then 16 | can not reliably verify all DKIM-signatures because the intermediate 17 | MTAs may have mangled the original message, a common practise with 18 | mailing lists and virus-checker software. 19 | 20 | In :ref:`dkim-autocrypt` and following we discuss how DKIM-signatures can help 21 | protect the Autocrypt key material from tampering between the senders MTA and the 22 | recipients MUA. 23 | 24 | .. _`dkim-autocrypt`: 25 | 26 | DKIM Signatures on Autocrypt Headers 27 | ------------------------------------ 28 | 29 | .. figure:: ../images/dkim.* 30 | :alt: Sequence diagram of Autocrypt key exchange with DKIM Signatures 31 | 32 | Sequence diagram of Autocrypt key exchange with DKIM Signatures 33 | 34 | Alice sends a mail to Bob including an Autocrypt header with her key(a). 35 | First, Alice's Provider authenticates Alice, and upon receiving her message (1), it adds a DKIM signature header and then passes it on to Bobs provider (2). When Bob's provider receives the message it retrieves the public DKIM key from Alice's provider (3,4) and verifies Alice's provider DKIM signature (5). 36 | 37 | This is the default DKIM procedure and serves primarily to detect and prevent spam email. If the DKIM signature matches (and other spam tests pass) Bob's provider relays the message to Bob (6). 38 | 39 | In the current established practice Bob's MUA will simply present the 40 | message to Bob without any further verification. This means that Bob's provider is in a position to modify the message before it is presented to Alice. This can be avoided if Bob's MUA also retrieves the DKIM key (7,8) and verifies the signature (9, making sure that the headers and content have not been altered after leaving the Alice's provider. In other words, a valid DKIM signature on the mail headers, including the Autocrypt header, indicates that the recipient's provider has not altered the key included in the header. 41 | 42 | It must be noted that since some providers do not use DKIM signatures at 43 | all, a missing signature by itself does not indicate a MITM attack. 44 | Also, some providers alter incoming mails to attach mail headers or add 45 | footers to the message body. Therefore even a broken signature can have 46 | a number of causes. 47 | 48 | The DKIM header includes a field ``bh`` with the hash of the email body 49 | that was used to calculate the full signature. If the DKIM signature is 50 | broken it may still be possible to verify the Autocrypt header based 51 | on the body hash and the signed headers. 52 | 53 | Device loss and MITM attacks 54 | ---------------------------- 55 | 56 | Autocrypt specifies to happily accept new keys send in Autocrypt headers 57 | even if a different key was received before. This is meant to prevent 58 | unreadable mail, but also offers a larger attack surface for MITM 59 | attacks. 60 | 61 | The Autocrypt spec explicitely states that it does not provide 62 | protection against active attacks. However combined with DKIM signatures 63 | at least a basic level of protection can be achieved: 64 | 65 | A new key distributed in a mail header with a valid DKIM signature 66 | signals that the key was not altered after the mail left the sender's 67 | provider. Yet, the following threats remain: 68 | 69 | - the sender's device was compromised 70 | - the sender's email account was compromised 71 | - the transport layer encryption between the sender and their provider 72 | was broken 73 | - the sender's provider is malicious 74 | - the sender's provider was compromised 75 | 76 | This attack vector is shared by any other key distribution scheme that rely on the provider to certify or distribute the user's keys. 77 | 78 | One malicious provider out of two 79 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 80 | 81 | In order to carry out a successful transparent MITM attack on a 82 | conversation the attacker needs to replace both parties keys and 83 | intercept all mails. While it's easy for either one of the providers to 84 | intercept all emails replacing the keys in the headers and the 85 | signatures in the body will lead to broken DKIM signatures in one 86 | direction. 87 | 88 | Same provider or two malicious providers 89 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 90 | 91 | If both providers cooperate on the attack or both users use the same 92 | provider it's easy for the attacker to replace the keys and pgp 93 | signatures on the mails before DKIM signing them. However, with 94 | their DKIM-signatures they would have signed Autocrypt headers 95 | that were never sent by the users's MUAs. 96 | 97 | Key updates in suspicious mails 98 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 99 | 100 | If a MUA has seen an Autocrypt header with a valid DKIM 101 | signature from the sender before and receives a new key in a mail 102 | without a signature or with a broken signature that may indicate a MITM 103 | attack. 104 | 105 | 106 | Open Questions 107 | -------------- 108 | 109 | Reliability of DKIM signatures 110 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 111 | 112 | Key update notifications suffer from a high number of false positives. 113 | Most of the time the key holder just lost their device and reset the 114 | key. How likely is it that for a given sender and recipient DKIM 115 | signatures that used to be valid when receiving the emails stop being 116 | valid? How likely is this to occure with the introduction of a new 117 | key? Intuitively both events occuring at the same time seems highly 118 | unlikely. However an attacker could also first start breaking DKIM 119 | signatures and insert a new key after some mails. In order to estimate 120 | the usefulness of this approach more experiences with MUA side 121 | validation of DKIM signatures would be helpful. 122 | 123 | Provider support 124 | ~~~~~~~~~~~~~~~~ 125 | 126 | In December 2017 the provider posteo.de announced that they will DKIM 127 | sign Autocrypt headers of outgoing mail. 128 | 129 | What can providers do? 130 | 131 | - DKIM-sign Autocrypt headers in outgoing mails 132 | - preserve DKIM signed headers in incoming mails 133 | - add an ``Authentication-Results`` header which indicates 134 | success in DKIM validation. 135 | 136 | Maybe they can indicate both these properties in a way that can be 137 | checked by the recipients MUA? 138 | -------------------------------------------------------------------------------- /images/contact.svg: -------------------------------------------------------------------------------- 1 | participant Alice as A 2 | participant Bob as B 3 | 4 | A --> B: 1.a) bootstrap code 5 | Note over A: 1.b) track bootstrap per INVITENUMBER 6 | Note over B: 2.a) check for exising key 7 | B ->> A: 2.b) vc-request message with INVITENUMBER 8 | Note over A: 3.a) look up bootstrap by INVITENUMBER 9 | Note over A: 3.b) abort if invite expired 10 | Note over A: 3.c) process AC header 11 | A -> B: 3.d) vc-auth-required message with AC header 12 | Note over B: 4.a) abort if key does not match FP from bootstrap 13 | B -> A: 4.b) vc-request-with-auth with Bob_FP and AUTH 14 | Note over A: 5.a) verify AUTH and key 15 | Note over A: 5.b) on failure alert user and abort 16 | Note over A: 6.a) signal success to user 17 | A -> B: 6.b) vc-contact-confirm message 18 | Note over A: 6.c) clear bootstrap data for INVITENUMBER 19 | Note over B: 7. signal success to user 20 | AliceAliceBobBob1.a) bootstrap code1.b) track bootstrap per INVITENUMBER2.a) check for exising key2.b) vc-request message with INVITENUMBER3.a) look up bootstrap by INVITENUMBER3.b) abort if invite expired3.c) process AC header3.d) vc-auth-required message with AC header4.a) abort if key does not match FP from bootstrap4.b) vc-request-with-auth with Bob_FP and AUTH5.a) verify AUTH and key5.b) on failure alert user and abort6.a) signal success to user6.b) vc-contact-confirm message6.c) clear bootstrap data for INVITENUMBER7. signal success to user -------------------------------------------------------------------------------- /source/_static/custom.css: -------------------------------------------------------------------------------- 1 | html, body { 2 | width: 100%; 3 | min-height: 100%; 4 | } 5 | 6 | body { 7 | padding: 0 !important; 8 | font-family: Verdana, Arial, Helvetica, sans-serif !important; 9 | font-size: 15px; 10 | line-height: 1.5em; 11 | color: #000; 12 | background-color: #ffffff, #ccedf5; 13 | background-position: 0px 0px; 14 | background-image: linear-gradient( 15 | to bottom, 16 | #ffffff 0px, 17 | #ffffff 280px, 18 | #005FA9 2000px, 19 | #005FA9 100% 20 | ); 21 | } 22 | 23 | div.document { 24 | width: 1000px; 25 | margin-top: 0px !important; 26 | } 27 | 28 | 29 | /* -- Sidebar -- */ 30 | 31 | div.sphinxsidebar { 32 | width: 250px; 33 | margin-bottom: 4em; 34 | } 35 | 36 | div.bodywrapper { 37 | margin: 0 0 0 250px; 38 | } 39 | 40 | .sidebar-logo > img { 41 | width: 80%; 42 | padding: 0 !important; 43 | } 44 | 45 | div.sphinxsidebarwrapper { 46 | padding: 2em; 47 | text-align: right; 48 | } 49 | 50 | div.mainnav { 51 | margin: 3em 0; 52 | } 53 | 54 | div.mainnav li { 55 | font-weight: bold; 56 | font-size: 1.1em; 57 | } 58 | 59 | div.sidebar { 60 | width: 100%; 61 | float: inherit; 62 | padding: 0; 63 | border: none; 64 | margin: 0; 65 | background: none; 66 | text-align: right; 67 | } 68 | 69 | div.subnav { 70 | margin-bottom: 4em; 71 | } 72 | 73 | div.subnav ul > li { 74 | margin: 7px 0; 75 | } 76 | 77 | div.body a, div.sphinxsidebar a { 78 | font-family: Verdana, Arial, Helvetica, sans-serif !important; 79 | color: #005FA9 !important; 80 | border-bottom: 0 !important; 81 | transition: color linear 0.2s; 82 | text-decoration: none; 83 | } 84 | 85 | div.body a:hover, div.sphinxsidebar a:hover { 86 | color: #008AC1 !important; 87 | text-decoration: none; 88 | } 89 | 90 | div.sphinxsidebar a[href="#"] { 91 | color: #000 !important; 92 | font-weight: bold; 93 | } 94 | 95 | /* -- Index -- */ 96 | 97 | .body-header { 98 | width: 100%; 99 | margin: 0 !important; 100 | text-align: center; 101 | } 102 | 103 | .body-header img { 104 | width: 250px; 105 | margin-top: 1.5em; 106 | } 107 | 108 | .body-header-fill { 109 | width: 100%; 110 | /*background-color: #B1D5E9; */ 111 | /*border: 1px solid #B1D5E9; */ 112 | border-radius: 5px; 113 | text-align: center; 114 | padding: 10px 0 ; 115 | } 116 | 117 | .body-header h1 { 118 | /* color: #005FA9 !important; */ 119 | font-size: 1.6em !important; 120 | font-weight: 400 !important; 121 | } 122 | 123 | .body-masthead { 124 | display: flex; 125 | flex-direction: row; 126 | margin: 3.5em 0 2em; 127 | } 128 | 129 | .body-masthead-box { 130 | flex: 1; 131 | padding: 10px; 132 | /* background-color: #B1D5E9; */ 133 | border: 1px solid #B1D5E9; 134 | margin: 0 1em; 135 | border-radius: 5px; 136 | } 137 | 138 | .body-masthead-box:first-child { 139 | margin-left: 0; 140 | } 141 | 142 | .body-masthead-box:last-child { 143 | margin-right: 0; 144 | } 145 | 146 | .body-masthead-box-img { 147 | text-align: center; 148 | height: 100px; 149 | } 150 | 151 | .body-masthead-box-img2 img { 152 | margin-top: 15px; 153 | } 154 | 155 | 156 | /* 157 | .body-masthead-box-img img { 158 | height: 300px; 159 | } 160 | */ 161 | 162 | div.body-masthead-copy h2 { 163 | text-align: center; 164 | font-size: 1.4em; 165 | font-weight: 400 !important; 166 | margin-top: 1.2em !important; 167 | /*color: #005FA9 !important;*/ 168 | } 169 | 170 | /* -- Body -- */ 171 | 172 | div.body { 173 | color: #000; 174 | background-color: #FFF !important; 175 | padding-bottom: 2em; 176 | padding-top: 2em !important; 177 | overflow: auto; 178 | min-height: 800px; 179 | } 180 | 181 | div.footer { 182 | color: #ffffff; 183 | } 184 | 185 | div.footer a { 186 | color: #ffffff; 187 | text-decoration: none; 188 | } 189 | 190 | #searchbox, #searchbox form { 191 | display: block; 192 | float: right; 193 | } 194 | 195 | #searchbox input { 196 | font-family: Verdana, Arial, Helvetica, sans-serif !important; 197 | float: right; 198 | } 199 | 200 | #searchbox input[type="text"] { 201 | padding: 0 0.5em; 202 | } 203 | 204 | #searchbox input[type="submit"] { 205 | background: none; 206 | color: #005FA9; 207 | border: none; 208 | padding: 0; 209 | margin: 10px 0 0 0; 210 | } 211 | 212 | #searchbox p { 213 | float: right; 214 | } 215 | 216 | #searchbox a { 217 | font-family: Verdana, Arial, Helvetica, sans-serif !important; 218 | border: none; 219 | color: #005FA9; 220 | font-size: 0.8em; 221 | } 222 | 223 | h1, h2, h3, h4, h5, h6 { 224 | font-family: Verdana, Arial, Helvetica, sans-serif !important; 225 | line-height: 1.5em; 226 | color: #000 !important; 227 | font-weight: bold !important; 228 | margin: 1.5em 0 0 0 !important; 229 | } 230 | h1:first-child, h2:first-child, h3:first-child, h4:first-child { 231 | margin-top: 0 !important; 232 | } 233 | 234 | h1 a.toc-backref, h2 a.toc-backref, h3 a.toc-backref, h4 a.toc-backref, h5 a.toc-backref, h6 a.toc-backref { 235 | color: #000 !important; 236 | } 237 | 238 | div.body p { 239 | line-height: 1.5em; 240 | margin: 1em 0; 241 | } 242 | 243 | h1 { 244 | font-size: 2em !important; 245 | } 246 | 247 | h2 { 248 | font-size: 1.6em !important; 249 | } 250 | 251 | h3 { 252 | font-size: 1.3em !important; 253 | } 254 | 255 | h4 { 256 | font-size: 1.2em !important; 257 | } 258 | 259 | p.admonition-title { 260 | font-family: Verdana, Arial, Helvetica, sans-serif !important; 261 | font-weight: bold !important; 262 | margin: 0 !important; 263 | font-size: 1.3em !important; 264 | line-height: 1.5em !important; 265 | } 266 | 267 | div.admonition, div.note, div.contents { 268 | padding: 1em; 269 | margin: 0px; 270 | } 271 | 272 | div.highlight pre { 273 | padding: 10px 1em; 274 | } 275 | 276 | /* -- Table -- */ 277 | 278 | table { 279 | display: block; 280 | width: 100%; 281 | max-width: 650px; 282 | overflow: auto; 283 | } 284 | 285 | table tbody td { 286 | vertical-align: middle; 287 | } 288 | 289 | table tbody td > img, 290 | table tbody td > img.first { 291 | display: inline-block; 292 | float: left; 293 | height: 25px; 294 | margin-top: 15px !important; 295 | margin-right: 5px; 296 | } 297 | 298 | /* -- Buttons -- */ 299 | 300 | div.body a.primary-action { 301 | display: inline-block; 302 | margin: 2em 0px 1em; 303 | padding: 7px 15px; 304 | border-radius: 5px; 305 | font-size: 1.2em; 306 | font-weight: bold; 307 | text-transform: uppercase; 308 | color: #FFF !important; 309 | background-image: linear-gradient( 310 | 74deg, 311 | #1b64b8 0px, 312 | #1b64b8 66%, 313 | #5782cb 66%, 314 | #5782cb 100% 315 | ); 316 | } 317 | 318 | div.body a.primary-action:hover { 319 | background-image: linear-gradient( 320 | 74deg, 321 | #007eab 0px, 322 | #007eab 66%, 323 | #3497bc 66%, 324 | #3497bc 100% 325 | ); 326 | } 327 | 328 | /* -- Mobile -- */ 329 | 330 | @media screen and (max-width: 875px) { 331 | body { 332 | background: none; 333 | } 334 | 335 | div.document { 336 | width: 100%; 337 | } 338 | 339 | div.documentwrapper { 340 | width: 100%; 341 | } 342 | 343 | div.bodywrapper { 344 | margin: 0 !important; 345 | padding: 20px; 346 | overflow: hidden; 347 | } 348 | 349 | .body-masthead { 350 | flex-direction: column; 351 | margin: 2em 0; 352 | } 353 | 354 | .body-masthead-box { 355 | margin: 1em 0; 356 | } 357 | 358 | div.sphinxsidebar { 359 | margin: 0 0 3em 0 !important; 360 | padding: 0 !important; 361 | width: 100%; 362 | background: none; 363 | font-size: 1.4em; 364 | text-align: center; 365 | } 366 | 367 | div.sidebar { 368 | text-align: center; 369 | line-height: 2em; 370 | } 371 | 372 | .sidebar-logo > img { 373 | display: none; 374 | } 375 | 376 | #searchbox, #searchbox form { 377 | width: 100%; 378 | display: block; 379 | float: left; 380 | } 381 | 382 | #searchbox input[type="text"] { 383 | width: 100% !important; 384 | line-height: 2em; 385 | } 386 | 387 | #searchbox input[type="submit"] { 388 | width: 100%; 389 | text-align: center; 390 | } 391 | } 392 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | IMAGES = $(shell ls images/*.svg | sed -e 's/svg/pdf/') 2 | 3 | # Makefile for Sphinx documentation 4 | # 5 | 6 | # You can set these variables from the command line. 7 | SPHINXOPTS = 8 | SPHINXBUILD = sphinx-build 9 | PAPER = 10 | BUILDDIR = build 11 | RELEASE = $(shell python source/conf.py) 12 | 13 | # User-friendly check for sphinx-build 14 | ifeq ($(shell which $(SPHINXBUILD) >/dev/null 2>&1; echo $$?), 1) 15 | $(error The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed, then set the SPHINXBUILD environment variable to point to the full path of the '$(SPHINXBUILD)' executable. Alternatively you can add the directory with the executable to your PATH. If you don't have Sphinx installed, grab it from http://sphinx-doc.org/) 16 | endif 17 | 18 | # Internal variables. 19 | PAPEROPT_a4 = -D latex_paper_size=a4 20 | PAPEROPT_letter = -D latex_paper_size=letter 21 | ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) source 22 | # the i18n builder cannot share the environment and doctrees with the others 23 | I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) source 24 | 25 | .PHONY: help 26 | help: 27 | @echo "Please use \`make ' where is one of" 28 | @echo " html to make standalone HTML files" 29 | @echo " dirhtml to make HTML files named index.html in directories" 30 | @echo " singlehtml to make a single large HTML file" 31 | @echo " pickle to make pickle files" 32 | @echo " json to make JSON files" 33 | @echo " htmlhelp to make HTML files and a HTML help project" 34 | @echo " qthelp to make HTML files and a qthelp project" 35 | @echo " applehelp to make an Apple Help Book" 36 | @echo " devhelp to make HTML files and a Devhelp project" 37 | @echo " epub to make an epub" 38 | @echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter" 39 | @echo " latexpdf to make LaTeX files and run them through pdflatex" 40 | @echo " latexpdfja to make LaTeX files and run them through platex/dvipdfmx" 41 | @echo " text to make text files" 42 | @echo " man to make manual pages" 43 | @echo " texinfo to make Texinfo files" 44 | @echo " info to make Texinfo files and run them through makeinfo" 45 | @echo " gettext to make PO message catalogs" 46 | @echo " changes to make an overview of all changed/added/deprecated items" 47 | @echo " xml to make Docutils-native XML files" 48 | @echo " pseudoxml to make pseudoxml-XML files for display purposes" 49 | @echo " linkcheck to check all external links for integrity" 50 | @echo " doctest to run all doctests embedded in the documentation (if enabled)" 51 | @echo " coverage to run coverage check of the documentation (if enabled)" 52 | 53 | .PHONY: images 54 | images: $(IMAGES) 55 | 56 | images/%.pdf: images/%.svg 57 | inkscape -D -z --file=$< --export-pdf=$@ 58 | 59 | 60 | .PHONY: clean 61 | clean: 62 | rm -rf $(BUILDDIR)/* 63 | 64 | .PHONY: html 65 | html: 66 | $(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html 67 | @echo 68 | @echo "Build finished. The HTML pages are in $(BUILDDIR)/html." 69 | 70 | .PHONY: dirhtml 71 | dirhtml: 72 | $(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml 73 | @echo 74 | @echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml." 75 | 76 | .PHONY: singlehtml 77 | singlehtml: 78 | $(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml 79 | @echo 80 | @echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml." 81 | 82 | .PHONY: pickle 83 | pickle: 84 | $(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle 85 | @echo 86 | @echo "Build finished; now you can process the pickle files." 87 | 88 | .PHONY: json 89 | json: 90 | $(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json 91 | @echo 92 | @echo "Build finished; now you can process the JSON files." 93 | 94 | .PHONY: htmlhelp 95 | htmlhelp: 96 | $(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp 97 | @echo 98 | @echo "Build finished; now you can run HTML Help Workshop with the" \ 99 | ".hhp project file in $(BUILDDIR)/htmlhelp." 100 | 101 | .PHONY: qthelp 102 | qthelp: 103 | $(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp 104 | @echo 105 | @echo "Build finished; now you can run "qcollectiongenerator" with the" \ 106 | ".qhcp project file in $(BUILDDIR)/qthelp, like this:" 107 | @echo "# qcollectiongenerator $(BUILDDIR)/qthelp/CounterMitm.qhcp" 108 | @echo "To view the help file:" 109 | @echo "# assistant -collectionFile $(BUILDDIR)/qthelp/CounterMitm.qhc" 110 | 111 | .PHONY: applehelp 112 | applehelp: 113 | $(SPHINXBUILD) -b applehelp $(ALLSPHINXOPTS) $(BUILDDIR)/applehelp 114 | @echo 115 | @echo "Build finished. The help book is in $(BUILDDIR)/applehelp." 116 | @echo "N.B. You won't be able to view it unless you put it in" \ 117 | "~/Library/Documentation/Help or install it in your application" \ 118 | "bundle." 119 | 120 | .PHONY: devhelp 121 | devhelp: 122 | $(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp 123 | @echo 124 | @echo "Build finished." 125 | @echo "To view the help file:" 126 | @echo "# mkdir -p $$HOME/.local/share/devhelp/CounterMitm" 127 | @echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/CounterMitm" 128 | @echo "# devhelp" 129 | 130 | .PHONY: epub 131 | epub: 132 | $(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub 133 | @echo 134 | @echo "Build finished. The epub file is in $(BUILDDIR)/epub." 135 | 136 | .PHONY: latex 137 | latex: 138 | $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex 139 | @echo 140 | @echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex." 141 | @echo "Run \`make' in that directory to run these through (pdf)latex" \ 142 | "(use \`make latexpdf' here to do that automatically)." 143 | 144 | .PHONY: latexpdf 145 | latexpdf: 146 | $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex 147 | @echo "Running LaTeX files through pdflatex..." 148 | $(MAKE) -C $(BUILDDIR)/latex all-pdf 149 | @echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex." 150 | cp $(BUILDDIR)/latex/CounterMitm.pdf countermitm-$(RELEASE).pdf 151 | 152 | .PHONY: latexpdfja 153 | latexpdfja: 154 | $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex 155 | @echo "Running LaTeX files through platex and dvipdfmx..." 156 | $(MAKE) -C $(BUILDDIR)/latex all-pdf-ja 157 | @echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex." 158 | 159 | .PHONY: text 160 | text: 161 | $(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text 162 | @echo 163 | @echo "Build finished. The text files are in $(BUILDDIR)/text." 164 | 165 | .PHONY: man 166 | man: 167 | $(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man 168 | @echo 169 | @echo "Build finished. The manual pages are in $(BUILDDIR)/man." 170 | 171 | .PHONY: texinfo 172 | texinfo: 173 | $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo 174 | @echo 175 | @echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo." 176 | @echo "Run \`make' in that directory to run these through makeinfo" \ 177 | "(use \`make info' here to do that automatically)." 178 | 179 | .PHONY: info 180 | info: 181 | $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo 182 | @echo "Running Texinfo files through makeinfo..." 183 | make -C $(BUILDDIR)/texinfo info 184 | @echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo." 185 | 186 | .PHONY: gettext 187 | gettext: 188 | $(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale 189 | @echo 190 | @echo "Build finished. The message catalogs are in $(BUILDDIR)/locale." 191 | 192 | .PHONY: changes 193 | changes: 194 | $(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes 195 | @echo 196 | @echo "The overview file is in $(BUILDDIR)/changes." 197 | 198 | .PHONY: linkcheck 199 | linkcheck: 200 | $(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck 201 | @echo 202 | @echo "Link check complete; look for any errors in the above output " \ 203 | "or in $(BUILDDIR)/linkcheck/output.txt." 204 | 205 | .PHONY: doctest 206 | doctest: 207 | $(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest 208 | @echo "Testing of doctests in the sources finished, look at the " \ 209 | "results in $(BUILDDIR)/doctest/output.txt." 210 | 211 | .PHONY: coverage 212 | coverage: 213 | $(SPHINXBUILD) -b coverage $(ALLSPHINXOPTS) $(BUILDDIR)/coverage 214 | @echo "Testing of coverage in the sources finished, look at the " \ 215 | "results in $(BUILDDIR)/coverage/python.txt." 216 | 217 | .PHONY: xml 218 | xml: 219 | $(SPHINXBUILD) -b xml $(ALLSPHINXOPTS) $(BUILDDIR)/xml 220 | @echo 221 | @echo "Build finished. The XML files are in $(BUILDDIR)/xml." 222 | 223 | .PHONY: pseudoxml 224 | pseudoxml: 225 | $(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml 226 | @echo 227 | @echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml." 228 | -------------------------------------------------------------------------------- /source/drafts/inband-cc.rst: -------------------------------------------------------------------------------- 1 | Inband Claim Chains For Gossip 2 | ============================== 3 | 4 | Introduction 5 | ------------ 6 | 7 | Autocrypt gossip includes all recipient keys 8 | in messages with multiple recipients. 9 | This allows the recipients to encrypt replies 10 | to all of the initial recipients. 11 | At the same time it introduces an attack surface 12 | for injecting keys into other peoples Autocrypt peer state. 13 | 14 | The attack surface is limited by the fact 15 | that directly received keys will be chosen over gossip keys. 16 | 17 | However in an initial introduction message MITM keys could be seeded. 18 | This attack is particularly relevant when performed 19 | by a provider that already performs MITM attacks 20 | on the sender of the introductory message. 21 | In this position the attacker can tell 22 | from the message content the follow up messages might be interesting. 23 | 24 | In order to mitigate this attack 25 | and increase the trust in gossip keys 26 | we introduce a distributed key transperancy scheme 27 | that prevents equivocation in Autocrypt gossip. 28 | At the same time the scheme preserves 29 | the privacy of the participants 30 | to the same extend messages with only Autocrypt gossip would. 31 | 32 | The consistency checks the scheme introduces 33 | lead to error cases that can be used 34 | to recommend out of band verification 35 | with parties that have been detected to be equivocating. 36 | 37 | Inclusion in Messages 38 | --------------------- 39 | 40 | Every mail has the Autocrypt header as usual. 41 | 42 | Autocrypt: addr="..." 43 | keydata="..." 44 | 45 | In addition we include a header for the latest CC block 46 | in the encrypted and signed part of the message: 47 | 48 | GossipClaims: imprint= 49 | 50 | A gossip header includes these additional non-critical attributes: 51 | 52 | Autocrypt-Gossip: addr="..." 53 | keydata="..." 54 | _ccsecret= 55 | _ccdata= 56 | _ccproof= 57 | _cchead= 58 | 59 | - _ccsecret: allows deriving the index of the claim in the chain 60 | and decryption of _ccdata. 61 | - _ccdata: encrypted blob as included in the claim chain. 62 | Can be decrypted with H_2(_ccsecret). 63 | The entry itself contains: 64 | * the fingerprint of the peers public key included in the gossip. 65 | ( Linking the gossip to the head imprint ) 66 | * If the peer also uses claim chains, 67 | the imprint of the last block seen from that peer 68 | when constructing this block. 69 | ( Effectively a cross chain signature ) 70 | - _ccproof: allows veryfying the inclusion of the claim 71 | in the block and its content 72 | - _cchead: If the peer also uses claim chains, 73 | the imprint of the last block seen from that peer 74 | when composing the email 75 | 76 | 77 | If one of the peers has not seen 78 | the latest block from the sender yet 79 | the sender will also proof to them 80 | that they did not equivocate in the meantime. 81 | 82 | They do this by sending a system message 83 | including the same data 84 | as added to the gossip header 85 | but for all the blocks the user was missing. 86 | That is since the last head imprint 87 | that user had seen from them 88 | according to the mails they received 89 | If it looks like the peer has not seen any of their 90 | claim chain they include the heads 91 | since the claim about that user was added. 92 | 93 | TODO: figure out if this can be exploited by lying 94 | about the first block. Fall back to proofs for the full chain 95 | if that is the case. 96 | 97 | This data should be included 98 | in a way that is encrypted only to the corresponding user 99 | and at the same time does not cause confusion 100 | for the other users. (system message for now) 101 | 102 | 103 | Constructing New Blocks 104 | ----------------------- 105 | 106 | It is possible to equivocate by presenting different blocks to different 107 | users. 108 | Therefore we try to minimize the times new blocks need to be created 109 | and proof to everyone we did not equivocate about their key 110 | if they missed some blocks. 111 | If blocks stay stable for a longer time 112 | more people will observe the same block with the same head imprint 113 | and therefore we will need to add less proofs. 114 | 115 | Whenever the client adds gossip headers to an outgoing message 116 | it checks for a claim with the corresponding fingerprint in the last block. 117 | If it exists for all gossip headers the client can reuse the last block. 118 | 119 | If the client has seen newer blocks 120 | from the corresponding peers 121 | it will indicate this in the _cchead attribute 122 | rather than by creating a new block. 123 | 124 | If a claim is missing 125 | or references the wrong key in the last block 126 | a new block needs to be created. 127 | 128 | When creating a new block 129 | the client will include claims for all contacts with keys 130 | that could be used for gossip. 131 | Due to the privacy preserving nature of claim chains 132 | these keys will not be revealed to anyone 133 | until they actually are used in gossip. 134 | They are included never the less 135 | to ensure the block can be used as long as possible. 136 | 137 | New blocks SHOULD also include the latest peer head imprints 138 | in all claims. 139 | 140 | 141 | Using the chain to track keys 142 | ----------------------------- 143 | 144 | The chain can also be used to track the peer keys. 145 | In this scenario the next block is constructed 146 | continuously when receiving keys. 147 | When receiving the first key that is not in the latest block 148 | a new block is created 149 | based on the data of the last block. 150 | New keys are added to this block 151 | whenever they are received. 152 | 153 | The block captures the state of all peer keys on this device. 154 | When the MUA gossips a key that did not exist in the previous block 155 | it 'commits' the new keys and starts sending the new block 156 | 157 | 158 | Multi device usage 159 | ------------------ 160 | 161 | In addition we will need a mechanism to synchormize state 162 | between different devices. 163 | 164 | We can assume that we already shared the private keys 165 | between the devices. 166 | That is the private key for the email encryption 167 | but also the private key for the VRF. 168 | 169 | Therefor both devices can update their internal state in parallel. 170 | 171 | Whenever a block is commited we send a message to ourselves 172 | including the entire block. 173 | This way other devices can stay in sync. 174 | 175 | If they have observed additional keys 176 | that are not included in the block they receive 177 | these will be added 'on top' as uncommited claims. 178 | 179 | If two devices happen to commit new blocks 180 | before synchronizing 181 | we have two branches of the chain. 182 | 183 | The first device to recognize such a situation 184 | will create a merge block. 185 | 186 | 187 | Goals 188 | ----- 189 | 190 | - if i see a new block for a contact, i can verify it references a chain i already know about a contact 191 | 192 | - Cross-referenced chains allow for keeping consistency across contacts cryptographic information, making (temporary) isolation attacks harder: 193 | 194 | -> if A and B know C's head imprint through D - a contact both share with C (but not each other)... they can verify that neither C nor C's provider equivocate on any gossiped email 195 | 196 | - ordered history of keys allows determining which is the later one of two available keys 197 | 198 | - on device loss key history could be recovered from claim chains through peers who serve as an entry point. (claims might remain unreadable though.) 199 | 200 | 201 | 202 | Open Questions 203 | -------------- 204 | 205 | could we signal/mark entries that have a OOB-verification? 206 | 207 | 208 | Problems noticed 209 | ---------------- 210 | 211 | 212 | - complex to specify interoperable wire format of Claimchains, 213 | "_cchead" and "_ccsecret" and all of the involved cryptographic algorithms 214 | 215 | - Autocrypt-gossip + DKIM already make it hard for providers to equivocate, 216 | CC don't add that much 217 | (especially in relation to the complexity they introduce) 218 | 219 | - D2.4 (encrypted messaging, updated identity) 220 | also discusses benefits of Autocrypt/gossip 221 | 222 | - lack of underlying implementation for different languages 223 | 224 | - Maybe semi-centralized online storage access 225 | (not so bad since we can postpone storage updates 226 | to the time we actually send mail) 227 | 228 | 229 | Mitigating Equivocation in different blocks 230 | ------------------------------------------- 231 | 232 | The easiest way to circumvent the non-equivocation property 233 | is to send different blocks to two different parties. 234 | 235 | We work around this by prooving to our peers 236 | that we did not equivocate in any of the blocks. 237 | 238 | The person who can best confirm the data in a block 239 | is the owner of the respective key. 240 | -------------------------------------------------------------------------------- /source/gossip.rst: -------------------------------------------------------------------------------- 1 | .. raw:: latex 2 | 3 | \newpage 4 | 5 | Using Autocrypt key gossip to guide key verification 6 | ===================================================================== 7 | 8 | Autocrypt Level 1 introduces `key gossip `_ 9 | where a sender adds ``Autocrypt-Gossip`` headers 10 | to the encrypted part of a multi-recipient message. 11 | This was introduced to ensure users are able to reply encrypted. 12 | Because according to the Autocrypt specification 13 | encrypted message parts are always signed, 14 | recipients may interpret the gossip keys 15 | as a form of third-party verification. 16 | 17 | In `gossip-attack`_ we look at how MUAs can check key consistency 18 | with respect to particular attacks. MUAs can flag possible 19 | machine-in-the-middle (mitm) attacks on one of the direct connections 20 | which in turn can be used for helping users 21 | with prioritizing :ref:`history-verification` with those peers. 22 | To mitigate, attackers may intercept 23 | multiple connections to split the recipients into mostly isolated 24 | groups. However, the need to attack multiple connections at once 25 | increases the chance of detecting the attack by even a small 26 | amount of Out-of-Band key verifications. 27 | 28 | The approaches described here are applicable to other asymmetric 29 | encryption schemes with multi recipient messages. They are independent of 30 | the key distribution mechanism - wether it is in-band such as in 31 | Autocrypt or based on a keyserver like architecture such as in Signal. 32 | 33 | 34 | .. _`gossip-attack`: 35 | 36 | Attack Scenarios 37 | ---------------- 38 | 39 | Attacking group communication on a single connection 40 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 41 | 42 | .. figure:: ../images/no_gossip.* 43 | :alt: Targetted attack on a single connection 44 | 45 | Targetted attack on a single connection 46 | 47 | 48 | The attacker intercepts the initial message from Alice to Bob (1) 49 | and replaces Alices key ``a`` with a mitm key ``a'`` (2). 50 | When Bob replies (3) 51 | the attacker decrypts the message, 52 | replaces Bobs key ``b`` with ``b'``, 53 | encrypts the message to ``a`` 54 | and passes it on to Alice (4). 55 | 56 | Both Bob and Alice also communicate with Claire (5,6,7,8). 57 | Even if the attacker chooses to not attack this communication 58 | the attack on a single connection poses a significant risk 59 | for group communication amongst the three. 60 | 61 | Since each group message goes out to everyone in the group 62 | the attacker can read the content of all messages sent by Alice or Bob. 63 | Even worse ... it's a common habit in a number of messaging systems 64 | to include quoted text from previous messages. 65 | So despite only targetting two participants 66 | the attack can provide access to a large part of the groups conversation. 67 | 68 | Therefore participants need to worry 69 | about the correctness of the encryption keys they use 70 | but also of those of everyone else in the group. 71 | 72 | Detecting mitm through gossip inconsistencies 73 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 74 | 75 | Some cryptographic systems such as OpenPGP leak the keys used for other 76 | recipients and schemes like Autocrypt even include the keys. This allows 77 | checking them for inconsistencies to improve the confidence in the 78 | confidentiality of group conversation. 79 | 80 | .. figure:: ../images/gossip.* 81 | :alt: Detecting mitm through gossip inconsistencies 82 | 83 | Detecting mitm through gossip inconsistencies 84 | 85 | In the scenario outlined above Alice knows about three keys (``a``, 86 | ``b'``, ``c``). Sending a message to both Bob and Clair she signs the 87 | message with her own key and includes the other two as gossip keys 88 | ``a[b',c]``. The message is intercepted (1) and Bob receives one signed 89 | with ``a'`` and including the keys ``b`` and ``c`` (2). Claire receives 90 | the original message (3) and since it was signed with ``a`` it cannot be 91 | altered. C's client can now detect that A is using a different key for B 92 | (4). This may have been caused by a key update due to device loss. 93 | However if B responds to the message (5,6,7) , C learns that B also uses 94 | a different key for A (8). At this point C's client can suggest to 95 | verify fingerprints with either A or B. In addition a reply by C (9, 10) 96 | will provide A and B with keys of each other through an independent 97 | signed and encrypted channel. Therefore checking gossip keys poses a 98 | significant risk for detection for the attacker. 99 | 100 | Attacks with split world views 101 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 102 | 103 | In order to prevent detection through inconsistencies an attacker may 104 | choose to try and attack in a way that leads to consistent world views 105 | for everyone involved. If the attacker in the example above also 106 | attacked the key exchange between A and C and replaced the gossip keys 107 | accordingly here's what everyone would see: 108 | 109 | :: 110 | 111 | A: a , b', c' 112 | B: a', b , c 113 | C: a', b , c 114 | 115 | Only B and C have been able to establish a secure communication channel. 116 | But from their point of view the key for A is a' consistently. Therefore 117 | there is no reason for them to be suspicious. 118 | 119 | Note however that the provider had to attack two key exchanges. This 120 | increases the risk of being detected through OOB-verification. 121 | 122 | Probability of detecting an attack through out of band verification 123 | ------------------------------------------------------------------- 124 | 125 | Attacks on key exchange to carry out mitm attacks that replace everyones 126 | keys would be detected by the first out-of-band verification and the 127 | detection could easily be reproduced by others. 128 | 129 | However if the attack was carried out on only a small part of all 130 | connections the likelyhood of detection would be far lower and error 131 | messages could easily be attributed to software errors or other quirks. 132 | So even an attacker with little knowledge about the population they are 133 | attacking can learn a significant part of the group communication 134 | without risking detection. 135 | 136 | In this section we will discuss the likelyhood of detecting mitm attacks 137 | on randomly selected members of a group. This probabilistic discussion 138 | assumes the likelyhood of a member being attacked as uniform and 139 | independent of the likelyhood of out-of-band verification. It therefore 140 | serves as a model of randomly spread broad scale attacks rather than 141 | targetted attacks. 142 | 143 | Calculating the likelyhood of detection 144 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 145 | 146 | A group with n members has :math:`c = n \times \frac{n-1}{2}` 147 | connections. 148 | 149 | Let's consider an attack on :math:`a` connections. This leaves 150 | :math:`g = c-a` good connections. The probability of the attack not 151 | being detected with 1 key verification therefore is :math:`\frac{g}{c}`. 152 | 153 | If the attack remains undetected c-1 unverified connections amongst 154 | which (g-1) are good remain. So the probability of the attack going 155 | unnoticed in v verification attempts is: 156 | 157 | :math:`\frac{g}{c} \times \frac{g-1}{c-1} ... \times \frac{g-(v-1)}{c-(v-1)}` 158 | :math:`= \frac{g (g-1) ... (g-(v-1))}{c (c-1) ... (c-(v-1))}` 159 | :math:`= \frac{ \frac{g!}{(g-v)!} }{ \frac{c!}{(c-v)!} }` 160 | :math:`= \frac{ g! (c-v)! }{ c! (g-v)! }` 161 | 162 | Single Attack 163 | ~~~~~~~~~~~~~ 164 | 165 | As said above without checking gossip an attacker can access a relevant 166 | part of the group conversation and all direct messages between two 167 | people by attacking their connection and nothing else. 168 | 169 | In order to detect the attack 170 | key verification needs to be performed on the right connection. 171 | In a group of 3 users there are 3 direct connections. 172 | Therefor the chance of a single key verificatoin for detecting 173 | the attack is :math:`\frac{1}{3}`. 174 | In a group of 10 the chances are even slimmer: `\frac{1}{45} \approx 2%` 175 | 176 | Isolation attack 177 | ~~~~~~~~~~~~~~~~ 178 | 179 | Isolating a user in a group of n people requires (n-1) interceptions. 180 | This is the smallest attack possible that still provides consistent 181 | world views for all group members. Even a single verification will 182 | detect an isolation attack with a probability > 20% in groups smaller 183 | than 10 people and > 10% in groups smaller than 20 people. 184 | 185 | Isolation attacks can be detected in all cases if every participant 186 | performs at least 1 OOB-verification. 187 | 188 | Isolating pairs 189 | ~~~~~~~~~~~~~~~ 190 | 191 | If each participant OOB-verifies at least one other key 192 | isolation attacks can be ruled out. The next least invasive attack would 193 | be trying to isolate pairs from the rest of the group. However this 194 | requires more interceptions and even 1 verification on average per user 195 | leads to a chance > 88% for detecting an attack on a random pair of 196 | users. 197 | 198 | Targeted isolation 199 | ~~~~~~~~~~~~~~~~~~ 200 | 201 | The probabilities listed in the table assume that the attacker has no 202 | information about the likelyhood of out of band verification between the 203 | users. If a group is known to require a single key verification per 204 | person and two members of the group are socially or geographically 205 | isolated chances are they will verify each others fingerprints and are 206 | less likely to verify fingerprints with anyone else. Including such 207 | information can significantly reduce the risk for an attacker. 208 | -------------------------------------------------------------------------------- /source/conf.py: -------------------------------------------------------------------------------- 1 | # -*- coding: utf-8 -*- 2 | # 3 | # Counter Mitm documentation build configuration file, created by 4 | # sphinx-quickstart on Fri Jan 12 14:21:14 2018. 5 | # 6 | # This file is execfile()d with the current directory set to its 7 | # containing dir. 8 | # 9 | # Note that not all possible configuration values are present in this 10 | # autogenerated file. 11 | # 12 | # All configuration values have a default; values that are commented out 13 | # serve to show the default. 14 | 15 | import sys 16 | import os 17 | 18 | # If extensions (or modules to document with autodoc) are in another directory, 19 | # add these directories to sys.path here. If the directory is relative to the 20 | # documentation root, use os.path.abspath to make it absolute, like shown here. 21 | #sys.path.insert(0, os.path.abspath('.')) 22 | 23 | # -- General configuration ------------------------------------------------ 24 | 25 | # If your documentation needs a minimal Sphinx version, state it here. 26 | #needs_sphinx = '1.0' 27 | 28 | # Add any Sphinx extension module names here, as strings. They can be 29 | # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom 30 | # ones. 31 | extensions = [ 32 | 'sphinx.ext.intersphinx', 33 | 'sphinx.ext.todo', 34 | 'sphinx.ext.mathjax', 35 | ] 36 | 37 | # Add any paths that contain templates here, relative to this directory. 38 | templates_path = ['_templates'] 39 | 40 | # The suffix(es) of source filenames. 41 | # You can specify multiple suffix as a list of string: 42 | # source_suffix = ['.rst', '.md'] 43 | source_suffix = '.rst' 44 | 45 | # The encoding of source files. 46 | #source_encoding = 'utf-8-sig' 47 | 48 | # The master toctree document. 49 | master_doc = 'index' 50 | 51 | # General information about the project. 52 | project = u'Counter Mitm' 53 | copyright = u'2018' 54 | author = u'NEXTLEAP researchers' 55 | 56 | # The version info for the project you're documenting, acts as replacement for 57 | # |version| and |release|, also used in various other places throughout the 58 | # built documents. 59 | # 60 | # The short X.Y version. 61 | version = u'0.10' 62 | # The full version, including alpha/beta/rc tags. 63 | release = u'0.10.0' 64 | 65 | # The language for content autogenerated by Sphinx. Refer to documentation 66 | # for a list of supported languages. 67 | # 68 | # This is also used if you do content translation via gettext catalogs. 69 | # Usually you set "language" from the command line for these cases. 70 | language = None 71 | 72 | # There are two options for replacing |today|: either, you set today to some 73 | # non-false value, then it is used: 74 | #today = '' 75 | # Else, today_fmt is used as the format for a strftime call. 76 | #today_fmt = '%B %d, %Y' 77 | 78 | # List of patterns, relative to source directory, that match files and 79 | # directories to ignore when looking for source files. 80 | exclude_patterns = ['drafts'] 81 | 82 | # The reST default role (used for this markup: `text`) to use for all 83 | # documents. 84 | #default_role = None 85 | 86 | # If true, '()' will be appended to :func: etc. cross-reference text. 87 | #add_function_parentheses = True 88 | 89 | # If true, the current module name will be prepended to all description 90 | # unit titles (such as .. function::). 91 | #add_module_names = True 92 | 93 | # If true, sectionauthor and moduleauthor directives will be shown in the 94 | # output. They are ignored by default. 95 | #show_authors = False 96 | 97 | # The name of the Pygments (syntax highlighting) style to use. 98 | pygments_style = 'sphinx' 99 | 100 | # A list of ignored prefixes for module index sorting. 101 | #modindex_common_prefix = [] 102 | 103 | # If true, keep warnings as "system message" paragraphs in the built documents. 104 | #keep_warnings = False 105 | 106 | # If true, `todo` and `todoList` produce output, else they produce nothing. 107 | todo_include_todos = False 108 | 109 | 110 | # -- Options for HTML output ---------------------------------------------- 111 | 112 | # The theme to use for HTML and HTML Help pages. See the documentation for 113 | # a list of builtin themes. 114 | html_theme = 'alabaster' 115 | 116 | # Theme options are theme-specific and customize the look and feel of a theme 117 | # further. For a list of options available for each theme, see the 118 | # documentation. 119 | #html_theme_options = {} 120 | 121 | # Add any paths that contain custom themes here, relative to this directory. 122 | #html_theme_path = [] 123 | 124 | # The name for this set of Sphinx documents. If None, it defaults to 125 | # " v documentation". 126 | #html_title = None 127 | 128 | # A shorter title for the navigation bar. Default is the same as html_title. 129 | #html_short_title = None 130 | 131 | # The name of an image file (relative to this directory) to place at the top 132 | # of the sidebar. 133 | html_logo = "img/nextleap_logo_transp_1004x538.png" 134 | 135 | # The name of an image file (relative to this directory) to use as a favicon of 136 | # the docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 137 | # pixels large. 138 | #html_favicon = None 139 | 140 | # Add any paths that contain custom static files (such as style sheets) here, 141 | # relative to this directory. They are copied after the builtin static files, 142 | # so a file named "default.css" will overwrite the builtin "default.css". 143 | html_static_path = ['_static'] 144 | 145 | # Add any extra paths that contain custom files (such as robots.txt or 146 | # .htaccess) here, relative to this directory. These files are copied 147 | # directly to the root of the documentation. 148 | #html_extra_path = [] 149 | 150 | # If not '', a 'Last updated on:' timestamp is inserted at every page bottom, 151 | # using the given strftime format. 152 | #html_last_updated_fmt = '%b %d, %Y' 153 | 154 | # If true, SmartyPants will be used to convert quotes and dashes to 155 | # typographically correct entities. 156 | #html_use_smartypants = True 157 | 158 | # Custom sidebar templates, maps document names to template names. 159 | #html_sidebars = {} 160 | html_sidebars = { 161 | 'index': [ 162 | 'sidebarintro.html', 163 | 'globaltoc.html', 164 | 'searchbox.html' 165 | ], 166 | '**': [ 167 | 'sidebarintro.html', 168 | 'globaltoc.html', 169 | 'relations.html', 170 | 'searchbox.html' 171 | ] 172 | } 173 | 174 | # Additional templates that should be rendered to pages, maps page names to 175 | # template names. 176 | #html_additional_pages = {} 177 | 178 | # If false, no module index is generated. 179 | #html_domain_indices = True 180 | 181 | # If false, no index is generated. 182 | #html_use_index = True 183 | 184 | # If true, the index is split into individual pages for each letter. 185 | #html_split_index = False 186 | 187 | # If true, links to the reST sources are added to the pages. 188 | #html_show_sourcelink = True 189 | 190 | # If true, "Created using Sphinx" is shown in the HTML footer. Default is True. 191 | #html_show_sphinx = True 192 | 193 | # If true, "(C) Copyright ..." is shown in the HTML footer. Default is True. 194 | #html_show_copyright = True 195 | 196 | # If true, an OpenSearch description file will be output, and all pages will 197 | # contain a tag referring to it. The value of this option must be the 198 | # base URL from which the finished HTML is served. 199 | #html_use_opensearch = '' 200 | 201 | # This is the file name suffix for HTML files (e.g. ".xhtml"). 202 | #html_file_suffix = None 203 | 204 | # Language to be used for generating the HTML full-text search index. 205 | # Sphinx supports the following languages: 206 | # 'da', 'de', 'en', 'es', 'fi', 'fr', 'hu', 'it', 'ja' 207 | # 'nl', 'no', 'pt', 'ro', 'ru', 'sv', 'tr' 208 | #html_search_language = 'en' 209 | 210 | # A dictionary with options for the search language support, empty by default. 211 | # Now only 'ja' uses this config value 212 | #html_search_options = {'type': 'default'} 213 | 214 | # The name of a javascript file (relative to the configuration directory) that 215 | # implements a search results scorer. If empty, the default will be used. 216 | #html_search_scorer = 'scorer.js' 217 | 218 | # Output file base name for HTML help builder. 219 | htmlhelp_basename = 'CounterMitmdoc' 220 | 221 | # -- Options for LaTeX output --------------------------------------------- 222 | 223 | latex_elements = { 224 | # The paper size ('letterpaper' or 'a4paper'). 225 | #'papersize': 'letterpaper', 226 | 227 | # The font size ('10pt', '11pt' or '12pt'). 228 | 'pointsize': '12pt', 229 | 'preamble': '''\\setcounter{secnumdepth}{3}''', 230 | 231 | # Additional stuff for the LaTeX preamble. 232 | #'preamble': '', 233 | 234 | 'preamble': ''' 235 | \\newcommand{\\countermitmrelease}{%s} 236 | \\setcounter{secnumdepth}{3} 237 | '''%(release,), 238 | 239 | # Latex figure (float) alignment 240 | #'figure_align': 'htbp', 241 | } 242 | 243 | # Grouping the document tree into LaTeX files. List of tuples 244 | # (source start file, target name, title, 245 | # author, documentclass [howto, manual, or own class]). 246 | latex_documents = [ 247 | (master_doc, 'CounterMitm.tex', 248 | u'Detecting and preventing active attacks against Autocrypt', 249 | u'NEXTLEAP researchers', 'howto'), 250 | ] 251 | 252 | # For "manual" documents, if this is true, then toplevel headings are parts, 253 | # not chapters. 254 | # 255 | latex_use_parts = False 256 | 257 | # If true, show page references after internal links. 258 | # 259 | latex_show_pagerefs = True 260 | 261 | # If true, show URL addresses after external links. 262 | # 263 | latex_show_urls = 'footnote' 264 | # latex_show_urls = True 265 | 266 | # Documents to append as an appendix to all manuals. 267 | # 268 | # latex_appendices = [] 269 | 270 | # It false, will not define \strong, \code, itleref, \crossref ... but only 271 | # \sphinxstrong, ..., \sphinxtitleref, ... To help avoid clash with user added 272 | # packages. 273 | # 274 | # latex_keep_old_macro_names = True 275 | 276 | # If false, no module index is generated. 277 | # 278 | latex_domain_indices = False 279 | 280 | # -- Options for manual page output --------------------------------------- 281 | 282 | # One entry per manual page. List of tuples 283 | # (source start file, name, description, authors, manual section). 284 | man_pages = [ 285 | (master_doc, 'countermitm', u'Detecting and preventing active attacks against Autocrypt', 286 | [author], 1) 287 | ] 288 | 289 | # If true, show URL addresses after external links. 290 | #man_show_urls = False 291 | 292 | 293 | # -- Options for Texinfo output ------------------------------------------- 294 | 295 | # Grouping the document tree into Texinfo files. List of tuples 296 | # (source start file, target name, title, author, 297 | # dir menu entry, description, category) 298 | texinfo_documents = [ 299 | (master_doc, 'CounterMitm', u'Counter Mitm Documentation', 300 | author, 'CounterMitm', 'One line description of project.', 301 | 'Miscellaneous'), 302 | ] 303 | 304 | # Documents to append as an appendix to all manuals. 305 | #texinfo_appendices = [] 306 | 307 | # If false, no module index is generated. 308 | #texinfo_domain_indices = True 309 | 310 | # How to display URL addresses: 'footnote', 'no', or 'inline'. 311 | #texinfo_show_urls = 'footnote' 312 | 313 | # If true, do not generate a @detailmenu in the "Top" node's menu. 314 | #texinfo_no_detailmenu = False 315 | 316 | 317 | # Example configuration for intersphinx: refer to the Python standard library. 318 | # intersphinx_mapping = {'https://docs.python.org/': None} 319 | # 320 | if __name__ == "__main__": 321 | print(release) 322 | -------------------------------------------------------------------------------- /source/summary.rst: -------------------------------------------------------------------------------- 1 | .. raw:: latex 2 | 3 | \pagestyle{plain} 4 | \cfoot{countermitm \countermitmrelease} 5 | 6 | Introduction 7 | ============ 8 | 9 | This document considers how 10 | to secure Autocrypt_-capable mail apps against active network attackers. 11 | Autocrypt aims to achieve convenient end-to-end encryption of e-mail. 12 | The Level 1 Autocrypt specification offers users opt-in e-mail encryption, 13 | but only considers passive adversaries. 14 | Active network adversaries, 15 | who could, for example, 16 | tamper with the Autocrypt header during e-mail message transport, 17 | are not considered in the Level 1 specification. 18 | Yet, 19 | such active attackers might undermine the security of Autocrypt. 20 | Therefore, 21 | we present and discuss new ways to prevent and detect active 22 | network attacks against Autocrypt_-capable mail apps. 23 | 24 | .. 25 | TODO: Very out of the blue paragraph 26 | 27 | We aim to help establish a *reverse panopticon*: 28 | a network adversary should not be able to determine whether peers 29 | discover malfeasant manipulations, 30 | or even whether they exchange information to investigate attacks. 31 | If designed and implemented successfully it means that those 32 | who (can) care for detecting malfeasance also help to secure the 33 | communications of others in the ecosystem. 34 | 35 | This document reflects current research of the NEXTLEAP EU project. 36 | The NEXTLEAP project aims to secure Autocrypt beyond Level 1. 37 | To this end, this document proposes new Autocrypt protocols that focus on 38 | securely exchanging and verifying keys. 39 | To design these protocols, 40 | we considered usability, cryptographic and implementation aspects 41 | simultaneously, 42 | because they constrain and complement each other. 43 | Some of the proposed protocols are already implemented; 44 | we link to the repositories in the appropriate places. 45 | 46 | 47 | Attack model and terminology 48 | ++++++++++++++++++++++++++++ 49 | 50 | We consider a *network adversary* that can read, modify, and create 51 | network messages. 52 | Examples of such an adversary are an ISP, an e-mail provider, an AS, 53 | or an eavesdropper on a wireless network. 54 | The goal of the adversary is to i) read the content of messages, ii) 55 | impersonate peers -- communication partners, and iii) to learn who communicates 56 | with whom. 57 | To achieve these goals, 58 | an active adversary might try, for example, 59 | to perform a machine-in-the-middle attack on the key exchange protocol 60 | between peers. 61 | We consider this approach effective against mass surveillance of 62 | the encrypted email content while preventing additional meta data leakage. 63 | 64 | To enable secure key-exchange and key-verification between peers, 65 | we assume that peers have access to a *out-of-band* 66 | communication channel that cannot be observed or manipulated by the adversary. 67 | More concretely we expect them to be able 68 | to transfer a small amount of data via a QR-code confidentially. 69 | 70 | Targeted attacks on end devices or the out-of-band channels 71 | can break our assumptions 72 | and therefore the security properties of the protocols described. 73 | In particular 74 | the ability to observe QR-codes in the scan process 75 | (for example through CCTV or by getting access to print outs) 76 | will allow impersonation attacks. 77 | Additional measures can 78 | relax the security requirements for the *out-of-band* channel 79 | to also work under a threat of observation. 80 | 81 | Passive attackers such as service providers can still learn who 82 | communicates with whom at what time and the approximate size of the messages. 83 | We recommend using additional meassures such as encrypting the subject 84 | to prevent further data leakage. 85 | This is beyond the scope of this document though. 86 | 87 | Because peers learn the content of the messages, 88 | we assume that all peers are honest. 89 | They do not collaborate with the adversary and follow the protocols described in this document. 90 | 91 | Problems of current key-verification techniques 92 | +++++++++++++++++++++++++++++++++++++++++++++++ 93 | 94 | An important aspect of secure end-to-end (e2e) encryption is the verification of 95 | a peer's key. 96 | In existing e2e-encrypting messengers, 97 | users perform key verification by triggering two fingerprint verification workflows: 98 | each of the two peers shows and reads the other's key fingerprint 99 | through a trusted channel (often a QR code show+scan). 100 | 101 | We observe the following issues with these schemes: 102 | 103 | - The schemes require that both peers start the verification workflow to assert 104 | that both of their encryption keys are not manipulated. 105 | Such double work has an impact on usability. 106 | 107 | - In the case of a group, every peer needs to verify keys with each group member to 108 | be able to assert that messages are coming from and are encrypted to the true keys of members. 109 | A peer that joins a group of size :math:`N` 110 | must perform :math:`N` verifications. 111 | Forming a group of size :math:`N` therefore requires 112 | :math:`N(N-1) / 2` verifications in total. 113 | Thus this approach is impractical even for moderately sized groups. 114 | 115 | - The verification of the fingerprint only checks the current keys. 116 | Since protocols do not store any historical information about keys, 117 | the verification can not detect if there was a past temporary 118 | MITM-exchange of keys (say the network adversary 119 | exchanged keys for a few weeks but changed back to the "correct" keys afterwards). 120 | 121 | - Users often fail to distinguish Lost/Reinstalled Device events from 122 | Machine-in-the-Middle (MITM) attacks, see for example `When Signal hits the Fan 123 | `_. 124 | 125 | 126 | Integrating key verification with general workflows 127 | +++++++++++++++++++++++++++++++++++++++++++++++++++ 128 | 129 | In :doc:`new` we describe new protocols that aim to resolve these issues, 130 | by integrating key verification into existing messaging use cases: 131 | 132 | - the :ref:`Setup Contact protocol ` allows a user, say Alice, 133 | to establish a verified contact with another user, say Bob. 134 | At the end of this protocol, 135 | Alice and Bob know each other's contact information and 136 | have verified each other's keys. 137 | To do so, 138 | Alice sends bootstrap data using the trusted out-of-band channel to Bob (for 139 | example, by showing QR code). 140 | The bootstrap data 141 | transfers not only the key fingerprint, 142 | but also contact information (e.g., email address). 143 | After receiving the out-of-band bootstrap data, Alice's and Bob's clients 144 | communicate via the regular channel to 1) exchange Bob's key and contact 145 | information and 2) to verify each other's keys. 146 | Note that this protocol only uses one out-of-band message requiring 147 | involvement of the user. All other messages are transparent. 148 | 149 | - the :ref:`Verified Group protocol ` enables a user to invite 150 | another user to join a verified group. 151 | The "joining" peer establishes verified contact with the inviter, 152 | and the inviter then announces the joiner as a new member. At the end of this 153 | protocol, the "joining" peer has learned the keys of all members of the group. 154 | This protocol builds on top of the previous protocol. 155 | But, this time, the bootstrap data functions as an invite code to the group. 156 | 157 | Any member may invite new members. 158 | By introducing members in this incremental way, 159 | a group of size :math:`N` requires only :math:`N-1` verifications overall 160 | to ensure that a network adversary can not compromise end-to-end encryption 161 | between group members. If one group member loses her key (e.g. through device loss), 162 | she must re-join the group via invitation of the remaining members of the verified group. 163 | 164 | - the :ref:`History verification protocol ` 165 | verifies the cryptograhic integrity of past messages and keys. 166 | It can precisely point to messages where 167 | cryptographic key information has been modified by the network. 168 | 169 | Moreover, in :doc:`new` we also discuss a privacy issue 170 | with the Autocrypt Key gossiping mechanism. 171 | The continuous gossipping of keys may enable an observer 172 | to infer who recently communicated with each other. 173 | We present an "onion-key-lookup" protocol which allows peers 174 | to verify keys without other peers learning who is querying a key from whom. 175 | Users may make onion key lookups 176 | to learn and verify key updates from group members: 177 | if a peer notices inconsistent key information for a peer 178 | it can send an onion-key query to resolve the inconsistency. 179 | 180 | Onion key lookups also act as cover traffic 181 | which make it harder for the network 182 | to know which user is actually communicating with whom. 183 | 184 | 185 | Supplementary key consistency through ClaimChains 186 | +++++++++++++++++++++++++++++++++++++++++++++++++ 187 | 188 | We discuss a variant of ClaimChain_, a distributed key consistency scheme, 189 | in which all cryptographic checks are performed on the end-point side. 190 | ClaimChains are self-authenticated hash chains whose blocks contain statements 191 | about key material of the ClaimChain owner and the key material of her contacts. 192 | The "head" of the ClaimChain, the latest block, 193 | represents a commitment to the current state, 194 | and the full history of past states. 195 | 196 | ClaimChain data structures track all claims about public keys 197 | and enable other peers to automatically verify the integrity of claims. 198 | ClaimChains include cryptographic mechanisms 199 | to ensure the *privacy of the claim it stores* 200 | and the *privacy of the user's social graph*. 201 | Only authorized users can access the key material and 202 | the cross-references being distributed. In other words, neither providers 203 | nor unauthorized users can learn anything about the key material 204 | in the ClaimChain and the social graph of users 205 | by just observing the data structure. 206 | 207 | Private claims could be used by malicious users (or a network adversary who 208 | impersonates users) to *equivocate*, i.e., 209 | present a different view of they keys they have seen to their peers. 210 | For example, 211 | Alice could try to equivocate by showing different versions of a cross-reference 212 | of Bob's key to Carol and Donald. 213 | Such equivocations would hinder the ability to 214 | resolve correct public keys. 215 | Therefore, ClaimChain prevents users (or a network adversaries) 216 | from *equivocating* to other users about their cross-references. 217 | 218 | .. 219 | TODO: why the details about Autocrypt headers and claimchain integration here? 220 | 221 | The implementation of ClaimChains considered in this document 222 | relies on a self-authenticating storage which, given a hash, 223 | replies with a matching data block. 224 | We suggest that providers provide a "dumb" block storage 225 | for their e-mail customers, 226 | re-using existing authentication techniques for guarding writes to the block storage. 227 | The head hashes that allow to verify a full chain are distributed 228 | along with Autocrypt Gossip headers. 229 | Given a head, peers can verify that a chain has not been tampered with and 230 | represents the latest belief of another peer. 231 | Peers can use the information in the chain to perform consistency checks. 232 | 233 | ClaimChain permits users to check the evolution of others' keys over time. 234 | If inspection of the Claimchains reveals inconsistencies in the keys of a peer 235 | -- for example, because an adversary tampered with the keys -- 236 | the AutoCrypt client can advice the user to run the :ref:`history-verification` 237 | with this inconsistent peer. This protocol will then reveal conclusive evidence 238 | of malfeasance. 239 | 240 | 241 | Detecting inconsistencies through Gossip and DKIM 242 | +++++++++++++++++++++++++++++++++++++++++++++++++ 243 | 244 | The protocols for key verification and key inconsistency 245 | aid to detect malfeasance. 246 | However, even if they were not added, 247 | mail apps can use existing Autocrypt Level 1 Key Gossip and DKIM signatures 248 | to detect key inconsistencies. 249 | 250 | Key inconsistencies or broken signatures found using these methods 251 | can not be interpreted unequivocally as proof of malfeasance. 252 | Yet, mail apps can track such events and provide recommendations to users 253 | about "Who is the most interesting peer to verify keys with?" 254 | so as to detect real attacks. 255 | 256 | We note that if the adversary isolates a user 257 | by consistently injecting MITM-keys on her communications, 258 | the adversary can avoid the "inconsistency detection" via Autocrypt's basic mechanisms. 259 | However, any out-of-band key-history verification of that user will result 260 | in conclusive evidence of malfeasance. 261 | 262 | 263 | .. _coniks: https://coniks.cs.princeton.edu/ 264 | .. _claimchain: https://claimchain.github.io/ 265 | .. _autocrypt: https://autocrypt.org 266 | -------------------------------------------------------------------------------- /source/claimchains.rst: -------------------------------------------------------------------------------- 1 | .. raw:: latex 2 | 3 | \newpage 4 | 5 | Key consistency with ClaimChains 6 | ================================ 7 | 8 | In this section we show how ClaimChains, 9 | a data structure 10 | that can be used to store users' key history in a secure and privacy-preserving way, 11 | can be used to support keyhistory verification; 12 | and can also be used to identify 13 | which contacts are best suited to perform in-person key verifications. 14 | 15 | We first provide a brief introduction to the ClaimChains structure and its properties. 16 | Then, we describe a concrete usage of ClaimChains in the Autocrypt context. 17 | 18 | 19 | High level overview of the ClaimChain design 20 | --------------------------------------------- 21 | 22 | ClaimChains store *claims* 23 | that users make about their keys and their view of others' keys. 24 | The chain is self-authenticating and encrypted. 25 | Cryptographic access control is implemented via capabilities. 26 | In our design, the chains are stored as linked blocks 27 | with a publicly accessible block storage service 28 | in a privacy-preserving way. 29 | 30 | Claims come in two forms: 31 | self-claims, 32 | in which a user shares information about her own key material, 33 | and cross-references, 34 | in which a user vouches for the key of a contact. 35 | 36 | A user may have one or multiple such ClaimChains, 37 | for example, 38 | associated with multiple devices or multiple pseudonyms. 39 | 40 | ClaimChains provide the following properties: 41 | 42 | - **Privacy of the claim it stores**, 43 | only authorized users can access 44 | the key material and cross-references being distributed. 45 | 46 | 47 | - **Privacy of the user's social graph**, 48 | nor providers nor unauthorized users can learn 49 | whose contacts a user has referenced in her ClaimChain. 50 | 51 | Additionally ClaimCains are designed to prevent *equivocation*. 52 | That is, 53 | given Alices ClaimChain, 54 | every other user must have the same view of the cross-references. 55 | In other words, 56 | it cannot be that Carol and Donald observe different versions of Bob's key. 57 | If such equivocation were possible, 58 | it would hinder the ability to resolve correct public keys. 59 | 60 | 61 | The ClaimChain Design 62 | ~~~~~~~~~~~~~~~~~~~~~ 63 | 64 | ClaimChains represent repositories of claims 65 | that users make about themselves or other users. 66 | To account for user beliefs evolving over time, 67 | ClaimChains are implemented as cryptographic hash chains of blocks. 68 | Each block of a ClaimChain includes all claims 69 | that its owner endorses at the point in time when the block is generated, 70 | and all data needed to authenticate the chain. 71 | In order to optimize space, 72 | it is possible to only put commitments to claims in the block, 73 | and offload the claims themselves onto a separate data structure. 74 | 75 | Other than containing claims, 76 | each block in the chain contains enough information 77 | to authenticate past blocks as being part of the chain, 78 | as well as validate future blocks as being valid updates. 79 | Thus, 80 | a user with access to a chain block 81 | that they believe provides correct information 82 | may both audit past states of the chain, 83 | and authenticate the validity of newer blocks. 84 | In particular, 85 | a user with access to the *head* of the chain can validate the full chain. 86 | 87 | We consider that a user stores three types of information in a ClaimChain: 88 | 89 | - **Self-claims**. 90 | Most importantly these include cryptographic encryption keys. 91 | There may also be other claims about the user herself 92 | such as identity information (screen name, real name, email or chat identifiers) 93 | or other cryptographic material needed for particular applications, 94 | like verification keys to support digital signatures. 95 | Claims about user's own data are initially self-asserted, 96 | and gain credibility by being cross-referenced in chains of other users. 97 | 98 | - **Cross-claims**. 99 | The primary claim about another user is endorsing other user's ClaimChain 100 | as being authoritative, 101 | i.e. indicate the belief 102 | that the key material found in the self-claims of those chains is correct. 103 | 104 | - **Cryptographic metadata**. 105 | ClaimChains must contain enough information to authenticate all past states, 106 | as well as future updates of the repository. 107 | For this purpose 108 | they include digital signatures and corresponding signing public keys. 109 | 110 | 111 | In order to enable efficient operations 112 | without the need for another party 113 | to have full visibility of all claims in the chain, 114 | ClaimChains also have cryptographic links to past states. 115 | Furthermore, 116 | blocks include roots of high-integrity data structures 117 | that enable fast proofs of inclusion of a claim in the ClaimChain. 118 | 119 | 120 | Any of the claims can be public(readable by anyone), or private. 121 | The readability of private claims on a chain 122 | is enforced using a cryptographic access control mechanism 123 | based on capabilities. 124 | Only users that are provided with a capability 125 | for reading a particular cross-reference in a ClaimChain 126 | can read such claim, 127 | or even learn about its existence. 128 | 129 | Other material needed for ensuring privacy and non-equivocation is also included, 130 | as described in detail at https://claimchain.github.io . 131 | 132 | Use and architecture 133 | -------------------- 134 | 135 | This section discusses how ClaimChains can be integrated into Autocrypt. 136 | It considers that: 137 | 138 | - ClaimChains themselves are retrieved and uploaded 139 | from an online storage 140 | whenever a message is sent or received, 141 | 142 | - ClaimChain heads are transferred using email headers. 143 | 144 | This version is being implemented at 145 | https://github.com/nextleap-project/muacryptcc . 146 | 147 | 148 | Inclusion in Messages 149 | ~~~~~~~~~~~~~~~~~~~~~ 150 | 151 | When Autocrypt gossip includes keys of other users in an email 152 | claims about these keys are included in the senders chain. 153 | The email will reference the senders chain as follows: 154 | 155 | The Autocrypt and gossip headers are the same as usual. 156 | In addition we include a single header 157 | that is used to transmit 158 | the sender head imprint (root hash of our latest CC block) 159 | in the encrypted and signed part of the message:: 160 | 161 | GossipClaims: 162 | 163 | Once a header is available, 164 | the corresponding ClaimChain block(s) can be retrieved 165 | from the block storage service. 166 | After retrieving the chain the recipients can verify 167 | that the other recipients keys are properly included in the chain. 168 | 169 | The block also contains pointers to previous blocks 170 | such that the chain can be efficiently traversed. 171 | 172 | Mitigating Equivocation in different blocks 173 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 174 | 175 | The easiest way to circumvent the non-equivocation property 176 | is to send different blocks to two different parties. 177 | 178 | We work around this by proving to our peers 179 | that we did not equivocate in any of the blocks. 180 | 181 | The person who can best confirm the data in a block 182 | is the owner of the respective key. 183 | 184 | Proofs of inclusion 185 | ~~~~~~~~~~~~~~~~~~~ 186 | 187 | Proofs of inclusion allow 188 | verifying the inclusion of claims in the chain 189 | without retrieving the entire block. 190 | 191 | The ClaimChain design suggests 192 | to include proofs of inclusion 193 | for the gossiped keys in the headers. 194 | This way the inclusion in the given block could be verified offline. 195 | 196 | However in order to prevent equivocation 197 | all blocks since the last one we know need to be checked. 198 | Therefore we would have to include proofs of inclusion 199 | for all recipients and for all blocks 200 | since they last saw the chain. 201 | This in turn would require tracking the state 202 | each peer last saw of our own chain. 203 | 204 | We decided against adding the complexity involved. 205 | Instead we require users to be online 206 | to verify the inclusion of their own keys 207 | in peers chains and the overall consistency 208 | of their peers claims. 209 | 210 | This fits nicely with the recommendation guidance workflow 211 | described below. 212 | 213 | 214 | Constructing New Blocks 215 | ~~~~~~~~~~~~~~~~~~~~~~~ 216 | 217 | The absence of a claim can not be distinguished 218 | from the lack of a capability for that claim. 219 | Therefore, to prove 220 | that a ClaimChain is not equivocating about keys gossiped in the past 221 | they need to include, 222 | in every block, 223 | claims corresponding to those keys, 224 | and grant access to all peers 225 | with whom the key was shared in the past. 226 | 227 | When constructing a new block 228 | we start by including all claims about keys present in the last block, 229 | and their corresponding capabilities. 230 | 231 | In addition the client will include claims 232 | with the fingerprints of new gossiped keys. 233 | For peers that also use ClaimChain 234 | the client will include a cross-reference, 235 | i.e., the root hash of the latest block 236 | they saw from that peer in the claim. 237 | 238 | Then, 239 | if they did not exist already, 240 | the client will grant capabilities 241 | to the recipients for the claims concerning those recipients. 242 | In other words, 243 | it will provide the recipients with enough information 244 | to learn each other keys and ClaimChain heads. 245 | 246 | Note that due to the privacy preserving nature of ClaimChain 247 | these keys will not be revealed to anyone else 248 | even if the block data is publically accessible. 249 | 250 | 251 | Evaluating ClaimChains to guide verification 252 | ---------------------------------------------- 253 | 254 | Verifying contacts requires meeting in person, 255 | or relying on another trusted channel. 256 | We aim at providing users with means to identify 257 | which contacts are the most relevant to validate 258 | in order to maintain the security of their communication. 259 | 260 | The first in-person verification is particularly important. 261 | Getting a good first verified contact prevents full isolation of the user, 262 | since at that point it is not possible anymore 263 | to perform MITM attacks on all of her connections. 264 | 265 | Due to the small world phenomenon in social networks 266 | few verifications per user will already lead to a large cluster 267 | of verified contacts in the social graph. 268 | In this scenario any MITM attack will lead to inconsistencies 269 | observed by both the attacked parties and their neighbours. 270 | We quantify the likelihood of an attack in :ref:`gossip-attack`. 271 | 272 | To detect inconsistencies clients can compare their own ClaimChains with those of peers. 273 | Inconsistencies appear as claims by one peer about another peer's key material 274 | that differ from ones own observation. 275 | 276 | Given inconsistency of a key it is not possible 277 | to identify unequivocally which connection is under attack: 278 | 279 | * It may be the connection between other peers 280 | that leads them to see MITM keys for each other, 281 | while the owner is actually observing the actual ones. 282 | 283 | * It may be that the owner is seeing MITM keys for one of them, 284 | while the other one is claiming the correct key. 285 | 286 | Verifying one of the contacts 287 | for whom an inconsistency has been detected 288 | will allow determining whether that particular connection is under attack. 289 | Therefore we suggest 290 | that the recommendation regarding the verification of contacts 291 | is based on the number of inconsistencies observed. 292 | 293 | Split world view attacks 294 | ~~~~~~~~~~~~~~~~~~~~~~~~ 295 | 296 | Note, however, 297 | that the fact that peers' claims are consistent does not imply 298 | that no attack is taking place. 299 | It only means 300 | that to get to this situation an attacker has to split the social graph 301 | into groups with consistent ideas about their peers keys. 302 | This is only possible 303 | if there are no verified connections between the different groups. 304 | It also requires mitm attacks on more connections 305 | possibly involving different providers. 306 | Therefore checking consistency makes the attack both harder and easier to detect. 307 | 308 | In the absence of inconsistencies 309 | we would therefore like to guide the user towards verifying contacts 310 | they have no (multi-hop) verified connection to. 311 | But since we want to preserve the privacy 312 | of who verified whom 313 | we cannot detect this property. 314 | The best guidance we can offer is to verify users 315 | who we do not share a verified group with yet. 316 | 317 | Inconsistencies between other peoples chains 318 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 319 | 320 | In addition to checking consistency with the own chain 321 | the clients could also compare claims 322 | across the ClaimChains of other people. 323 | However, inconsistencies between the chains of others 324 | are a lot harder to investigate. 325 | Therefore their use for guiding the user is very limited. 326 | Effectively the knowledge about conflicts 327 | between other peoples chains 328 | is not actionable for the user. 329 | They could verify with one of their peers 330 | - but even that would not lead to conclusive evidence. 331 | 332 | In addition our implementation stores claims 333 | about all keys in active use 334 | in its own claimchain. 335 | Therefore if the user communicates with the person in question 336 | at least one of the conflicting keys of peers 337 | will conflict with our own recorded key. 338 | We refrain from asking the user to verify people 339 | they do not communicate with. 340 | 341 | 342 | Problems noticed 343 | ~~~~~~~~~~~~~~~~ 344 | 345 | 346 | - complex to specify interoperable wire format of ClaimChains 347 | and all of the involved cryptographic algorithms 348 | 349 | - Autocrypt-gossip + DKIM already make it hard for providers to equivocate. 350 | CC don't add that much 351 | (especially in relation to the complexity they introduce) 352 | 353 | - lack of underlying implementation for different languages 354 | 355 | - Maybe semi-centralized online storage access 356 | (we can postpone storage updates to the time we actually send mail) 357 | 358 | 359 | -------------------------------------------------------------------------------- /source/new.rst: -------------------------------------------------------------------------------- 1 | .. raw:: latex 2 | 3 | \newpage 4 | 5 | Securing communications against network adversaries 6 | =================================================== 7 | 8 | To withstand network adversaries, 9 | peers must verify each other's keys 10 | to establish trustable e2e-encrypted communication. In this section we describe 11 | protocols to securely setup a contact, to securely add a user to a group, and 12 | to verify key history. 13 | 14 | Establishing a trustable e2e-encrypted communication channel is 15 | particularly difficult 16 | in group communications 17 | where more than two peers communicate with each other. 18 | Existing messaging systems usually require peers to verify keys with every other 19 | peer to assert that they have a trustable e2e-encrypted channel. 20 | This is highly unpractical. 21 | First, 22 | the number of verifications that a single peer must perform becomes 23 | too costly even for small groups. 24 | Second, a device loss will invalidate all prior verifications of a user. 25 | Rejoining the group with a new device (and a new key) 26 | requires redoing all the verification, 27 | a tedious and costly task. 28 | Finally, 29 | because key verification is not automatic -- 30 | it requires users' involvement -- 31 | in practice very few users consistently perform key verification. 32 | 33 | **Key consistency** schemes do not remove the need 34 | of key verification. 35 | It is possible 36 | to have a group of peers 37 | which each see consistent email-addr/key bindings from each other, 38 | yet a peer is consistently isolated 39 | by a network adversary performing a machine-in-the-middle attack. 40 | It follows 41 | that each peer needs to verify with at least one other peer 42 | to assure that there is no isolation attack. 43 | 44 | A known approach 45 | to reduce the number of neccessary key verifications 46 | is the web of trust. 47 | This approach requires a substantial learning effort for users 48 | to understand the underlying concepts, 49 | and is hardly used outside specialist circles. 50 | Moreover, when using OpenPGP, 51 | the web of trust is usually interacting with OpenPGP key servers. 52 | These servers make the signed keys widely available, 53 | effectively making the social "trust" graph public. 54 | Both key servers and the web of trust have reached very limited adoption. 55 | 56 | Autocrypt was designed 57 | to not rely on public key servers, 58 | nor on the web of trust. 59 | It thus provides a good basis 60 | to consider new key verification approaches. 61 | To avoid the difficulties around talking about keys with users, 62 | we suggest new protocols 63 | which perform key verification as part of other workflows, 64 | namely: 65 | 66 | - setting up a contact between two individuals who meet physically, and 67 | 68 | - setting up a group with people who you meet or have met physically. 69 | 70 | These new workflows require *administrative* messages 71 | to support the authentication and security of the key exchange process. 72 | These administrative messages are sent between devices, 73 | but are not shown to the user as regular messages. 74 | This is a challenge, 75 | because some e-mail apps display all messages 76 | (including machine-generated ones for rejected or non-delivered mails) 77 | without special rendering of the content. 78 | Only some messengers, 79 | such as `Delta-chat `_, 80 | already use administrative messages, e.g., for group member management. 81 | 82 | The additional advantage of using administrative messages is 83 | that they significantly improve usability by reducing the overall number of actions 84 | to by users. 85 | In the spirit of the strong UX focus of the Autocrypt specification, 86 | however, 87 | we suggest 88 | to only exchange administrative messages with peers 89 | when there there is confidence they will not be displayed "raw" to users, 90 | and at best only send them on explicit request of users. 91 | 92 | Note that automated processing of administrative messages 93 | opens up a new attack vector: 94 | malfeasant peers can try to inject adminstrative messages 95 | in order 96 | to impersonate another user or 97 | to learn if a particular user is online. 98 | 99 | All protocols that we introduce in this section are *decentralized*. 100 | They describe 101 | how peers (or their devices) can interact with each other, 102 | without having to rely on services from third parties. 103 | Our verification approach thus fits into the Autocrypt key distribution model 104 | which does not require extra services from third parties either. 105 | 106 | Autocrypt Level 1 focusses on passive attacks 107 | such as sniffing the mail content 108 | by a provider. 109 | Active attacks are outside of the scope 110 | and can be carried out automatically 111 | by replacing Autocrypt headers. 112 | 113 | Here we aim to increase the costs of active attacks 114 | by introducing a second channel 115 | and using it to verify the Autocrypt headers 116 | transmitted in-band. 117 | 118 | We consider targeted active attacks 119 | against these protections feasible. 120 | However they will require coordinated attacks 121 | based for example on infiltrators or real time CCTV footage. 122 | 123 | We believe 124 | that the ideas explained here 125 | make automated mass surveillance prohibitively expensive 126 | with a fairly low impact on usability. 127 | 128 | 129 | .. _`setup-contact`: 130 | 131 | Setup Contact protocol 132 | ----------------------------------------- 133 | 134 | The goal of the Setup Contact protocol is 135 | to allow two peers to conveniently establish secure contact: 136 | exchange both their e-mail addresses and cryptographic identities in a verified manner. 137 | This protocol is re-used 138 | as a building block 139 | for the `history-verification`_ and `verified-group`_ protocols. 140 | 141 | After running the Setup Contact protocol, 142 | both peers will learn the cryptographic identities (i.e., the keys) of each other 143 | or else both get an error message. 144 | The protocol is safe against active attackers that can modify, create and delete 145 | messages. 146 | 147 | .. figure:: ../images/secure_channel_foto.jpg 148 | :width: 200px 149 | 150 | Setup Contact protocol step 2 with https://delta.chat. 151 | 152 | The protocol follows a single simple UI workflow: 153 | A peer "shows" bootstrap data 154 | that is then "read" by the other peer through a second channel. 155 | This means that, 156 | as opposed to current fingerprint verification workflows, 157 | the protocol only runs once instead of twice, 158 | yet results in the two peers having verified keys of each other. 159 | 160 | Between mobile phones, 161 | showing and scanning a QR code 162 | constitutes a second channel, 163 | but transferring data via USB, Bluetooth, WLAN channels or phone calls 164 | is possible as well. 165 | 166 | Recall that 167 | we assume that 168 | our active attacker *cannot* observe or modify data transferred 169 | via the second channel. 170 | 171 | An attacker who can alter messages 172 | but has no way of reading or manipulating the second channel 173 | can prevent the verification protocol 174 | from completing successfully 175 | by droping or altering messages. 176 | 177 | An attacker who can compromise both channels 178 | can inject wrong key material 179 | and convince the peer to verify it. 180 | 181 | .. figure:: ../images/contact.* 182 | :alt: Sequence diagram of UI and administrative message flow 183 | 184 | UI and administrative message flow of contact setup 185 | 186 | Here is a conceptual step-by-step example 187 | of the proposed UI and administrative message workflow 188 | for establishing a secure contact between two contacts, 189 | Alice and Bob. 190 | 191 | 1. Alice sends a bootstrap code to Bob via the second channel. 192 | 193 | a) The bootstrap code consists of: 194 | 195 | - Alice's Openpgp4 public key fingerprint ``Alice_FP``, 196 | which acts as a commitment to the 197 | Alice's Autocrypt key, which she will send later in the protocol, 198 | 199 | - Alice's e-mail address (both name and routable address), 200 | 201 | - A type ``TYPE=vc-invite`` of the bootstrap code 202 | 203 | - a challenge ``INVITENUMBER`` of at least 8 bytes. 204 | This challenge is used by Bob's device in step 2b 205 | to prove to Alice's device 206 | that it is the device that the bootstrap code was shared with. 207 | Alice's device uses this information in step 3 208 | to automatically accept Bob's contact request. 209 | This is in contrast with most messaging apps 210 | where new contacts typically need to be manually confirmed. 211 | 212 | - a second challenge ``AUTH`` of at least 8 bytes 213 | which Bob's device uses in step 4 214 | to authenticate itself against Alice's device. 215 | 216 | - optionally add metadata such as ``INVITE-TO=groupname`` 217 | 218 | b) Per ``INVITENUMBER`` Alices device will keep track of: 219 | - the associated ``AUTH`` secret 220 | - the time the contact verification was initiated. 221 | - the metadata provided. 222 | 223 | 2. Bob receives the bootstrap code and 224 | 225 | a) If Bob's device already knows a key with the fingerprint ``Alice_FP`` 226 | that 227 | belongs to Alice's e-mail address the protocol continues with 4b) 228 | 229 | b) otherwise Bob's device sends 230 | a cleartext "vc-request" message to Alice's e-mail address, 231 | adding the ``INVITENUMBER`` from step 1 to the message. 232 | Bob's device automatically includes Bob's AutoCrypt key in the message. 233 | 234 | 3. Alice's device receives the "vc-request" message. 235 | 236 | a) She looks up the bootstrap data for the ``INVITENUMBER``. 237 | If the ``INVITENUMBER`` does not match 238 | then Alice terminates the protocol. 239 | 240 | b) If she recognizes the ``INVITENUMBER`` from step 1 241 | she checks that the invite has not expired. 242 | If the timestamp associated with the ``INVITENUMBER`` 243 | is longer ago than a given time 244 | Alice terminates the protocol. 245 | 246 | c) She then processes Bob's Autocrypt key. 247 | 248 | d) She uses this key 249 | to create an encrypted "vc-auth-required" message 250 | containing her own Autocrypt key, which she sends to Bob. 251 | 252 | 4. Bob receive the "vc-auth-required" message, 253 | decrypts it, 254 | and verifies that Alice's Autocrypt key matches ``Alice_FP``. 255 | 256 | a) If verification fails, 257 | Bob gets a screen message 258 | "Error: Could not setup a secure connection to Alice" 259 | and the protocol terminates. 260 | 261 | b) Otherwise Bob's device sends back 262 | a 'vc-request-with-auth' encrypted message 263 | whose encrypted part contains 264 | Bob's own key fingerprint ``Bob_FP`` 265 | and the second challenge ``AUTH`` from step 1. 266 | 267 | 5. Alice decrypts Bob's 'vc-request-with-auth' message 268 | 269 | a) and verifies that Bob's Autocrypt key matches ``Bob_FP`` 270 | that the invite has not expired 271 | and that the transferred ``AUTH`` matches the one from step 1. 272 | 273 | b) If any verification fails, 274 | Alice's device signals 275 | "Could not establish secure connection to Bob" 276 | and the protocol terminates. 277 | 278 | 6. If the verification succeeds on Alice's device 279 | 280 | a) shows "Secure contact with Bob established". 281 | 282 | b) sends Bob a "vc-contact-confirm" message. 283 | 284 | c) also removes the data associated with ``INVITENUMBER``. 285 | 286 | 7. Bob's device receives "vc-contact-confirm" and shows 287 | "Secure contact with Alice established". 288 | 289 | 290 | At the end of this protocol, 291 | Alice has learned and validated the contact information and Autocrypt key of Bob, 292 | the person to whom she sent the bootstrap code. 293 | Moreover, 294 | Bob has learned and validated the contact information and Autocrypt key of Alice, 295 | the person who sent the bootstrap code to Bob. 296 | 297 | Requirements for the underlying encryption scheme 298 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 299 | 300 | The Setup Contact protocol requires that 301 | the underlying encryption scheme is non-malleable. 302 | Malleability means the encrypted content can be changed in a deterministic way. 303 | Therefore with a malleable scheme an attacker could impersonate Bob: 304 | They would add a different autocrypt key in Bob's vc-request message ( step 2.b ) 305 | and send the message along without other changes. 306 | In step 4.b they could then modify the encrypted content to include 307 | their own keys fingerprint rather than ``Bob_FP``. 308 | 309 | .. 310 | TODO: In case of such an attack 311 | the OpenPGP signature on the message body 312 | would be with Bob's original key. 313 | We could check the signature is made with the right key 314 | rather than adding the additional, somewhat redundant Bob_FP. 315 | 316 | In the case of OpenPGP non-malleability is achieved 317 | with Modification Detection Codes (MDC - see section 5.13 and 5.14 of RFC 4880). 318 | Implementers need to make sure 319 | to verify these 320 | and treat invalid or missing MDCs as an error. 321 | Using an authenticated encryption scheme prevents these issues 322 | and is therefore recommended if possible. 323 | 324 | An active attacker cannot break the security of the Setup Contact protocol 325 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 326 | 327 | .. 328 | TODO: Network adversaries *can* learn who is authenticating with whom 329 | 330 | Recall that an active attacker can 331 | read, modify, and create messages 332 | that are sent via a regular channel. 333 | The attacker cannot observe or modify the bootstrap code 334 | that Alice sends via the second channel. 335 | We argue that such an attacker cannot 336 | break the security of the Setup Contact protocol, 337 | that is, the attacker cannot 338 | impersonate Alice to Bob, or Bob to Alice. 339 | 340 | Assume, 341 | for a worst-case scenario, 342 | that the adversary knows the public Autocrypt keys of Alice and Bob. 343 | At all steps except step 1, 344 | the adversary can drop messages. 345 | Whenever the adversary drops a message, 346 | the protocol fails to complete. 347 | Therefore, 348 | we do not consider dropping of messages further. 349 | 350 | 1. The adversary cannot impersonate Alice to Bob, 351 | that is, 352 | it cannot replace Alice's key with a key Alice-MITM known to the adversary. 353 | Alice sends her key to Bob in the encrypted "vc-auth-required" message 354 | (step 3). 355 | The attacker can replace this message with a new "vc-auth-required" message, 356 | again encrypted against Bob's real key, 357 | containing a fake Alice-MITM key. 358 | However, Bob will detect this modification step 4a, 359 | because the fake Alice-MITM key does not match 360 | the fingerprint ``Alice_FP`` 361 | that Alice sent to Bob in the bootstrap code. 362 | (Recall that the bootstrap code is transmitted 363 | via the second channel 364 | the adversary cannot modify.) 365 | 366 | 2. The adversary also cannot impersonate Bob to Alice, 367 | that is, 368 | it cannot replace Bob's key with a key Bob-MITM known to the adversary. 369 | The cleartext "vc-request" message, sent from Bob to Alice in step 2, 370 | contains Bob's key. 371 | To impersonate Bob, 372 | the adversary must substitute this key with 373 | the fake Bob-MITM key. 374 | 375 | In step 3, 376 | Alice cannot distinguish the fake key Bob-MITM inserted by the adversary 377 | from Bob's real key, 378 | since she has not seen Bob's key in the past. 379 | Thus, she will follow the protocol 380 | and send the reply "vc-auth-required" encrypted with the key provided by the 381 | adversary. 382 | 383 | We saw in the previous part that 384 | if the adversary modifies Alice's key in the "vc-auth-required" message, 385 | then this is detected by Bob. 386 | Therefore, 387 | it forwards the "vc-auth-required" message unmodified to Bob. 388 | 389 | Since ``Alice_FP`` matches the key in "vc-auth-required", 390 | Bob will in step 4b 391 | send the "vc-request-with-auth" message encrypted to Alice's true key. 392 | This message contains 393 | Bob's fingerprint ``Bob_FP`` and the challenge ``AUTH``. 394 | 395 | Since the message is encrypted to Alice's true key, 396 | the adversary cannot decrypt the message 397 | to read its content. 398 | There are now three possibilities for the attacker: 399 | 400 | * The adversary modifies 401 | the "vc-request-with-auth" message 402 | to replace ``Bob_FP`` (which it knows) with the fingerprint of the fake 403 | Bob-MITM key. 404 | However, 405 | the encryption scheme is non-malleable, 406 | therefore, 407 | the adversary cannot modify the message, without being detected by Alice. 408 | 409 | * The adversary drops Bob's message and 410 | create a new fake message containing 411 | the finger print of the fake key Bob-MITM and 412 | a guess for the challenge ``AUTH``. 413 | The adversary cannot learn the challenge ``AUTH``: 414 | it cannot observe the bootstrap code 415 | transmitted via the second channel in step 1, 416 | and it cannot decrypt the message "vc-request-with-auth". 417 | Therefore, 418 | this guess will only be correct with probability :math:`2^{-64}`. 419 | Thus, with overwhelming probability 420 | Alice will detect the forgery in step 5, 421 | and the protocol terminates without success. 422 | 423 | * The adversary forwards Bob's original message to Alice. 424 | Since this message contains Bob's key fingerprint ``Bob_FP``, 425 | Alice will detect in step 5 426 | that Bob's "vc-request" from step 3 had the wrong key (Bob-MITM) 427 | and the protocol terminates with failure. 428 | 429 | 430 | Replay attacks and conflicts 431 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 432 | 433 | Alices device records the time a contact verification was initiated. 434 | It also verifies it has not expired and clears the data after 435 | completion. 436 | This prevents replay attacks. 437 | Replay attacks could be used to make Alices device switch back 438 | to an old compromised key of Bob. 439 | 440 | Limiting an invite to a single use 441 | reduces the impact of a QR-code 442 | being exposed to an attacker: 443 | If the attacker manages to authenticate faster than Bob 444 | they can impersonate Bob to Alice. 445 | However Bob will see an error message. 446 | If the QR-code could be reused 447 | the attacker could successfully authenticate. 448 | Alice would have two verified contacts 449 | and Bob would not see any difference to a successful 450 | connection attempt. 451 | 452 | Furthermore a compromise of Bob's device 453 | would allow registering other email addresses 454 | as verified contacts with Alice. 455 | 456 | 457 | Business Cards 458 | ~~~~~~~~~~~~~~ 459 | 460 | QR-codes similar to the ones used for verified contact 461 | could be used to print on business cards. 462 | 463 | Since business cards are usually not treated as confidential 464 | they can only serve 465 | to authenticate the issuer of the business card (Alice) 466 | and not the recipient (Bob). 467 | 468 | However as `discussed on the messaging@moderncrypto mailing list`_ 469 | the verification of a short code at the end of the protocol 470 | can extend it to also protect against leakage of the QR-code. 471 | This may also be desirable 472 | for users who face active surveillance in real life 473 | and therefor cannot assume 474 | that scanning the QR-code is confidential. 475 | 476 | .. _`discussed on the messaging@moderncrypto mailing list`: https://moderncrypto.org/mail-archive/messaging/2018/002544.html 477 | 478 | Open Questions 479 | ~~~~~~~~~~~~~~ 480 | 481 | - (how) can messengers such as Delta.chat 482 | make "verified" and "opportunistic" contact requests 483 | be indistinguishable from the network layer? 484 | 485 | - (how) could other mail apps such as K-9 Mail / OpenKeychain learn 486 | to speak the "setup contact" protocol? 487 | 488 | .. _`verified-group`: 489 | 490 | Verified Group protocol 491 | ----------------------- 492 | 493 | We introduce a new secure **verified group** that enables secure 494 | communication among the members of the group. 495 | Verified groups provide these simple to understand properties: 496 | 497 | .. 498 | TODO: Does autocrypt also protect against modification of group messages? 499 | 500 | 1. All messages in a verified group are end-to-end encrypted 501 | and secure against active attackers. 502 | In particular, 503 | neither a passive eavesdropper, 504 | nor an attactive network attacker 505 | (e.g., capable of man-in-the-middle attacks) 506 | can read or modify messages. 507 | 508 | 2. There are never any warnings about changed keys (like in Signal) 509 | that could be clicked away or cause worry. 510 | Rather, if a group member loses her device or her key, 511 | then she also looses the ability 512 | to read from or write 513 | to the verified group. 514 | To regain access, 515 | this user must join the group again 516 | by finding one group member and perform a "secure-join" as described below. 517 | 518 | 519 | Verifying a contact to prepare joining a group 520 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 521 | 522 | The goal of the secure-join protocol is 523 | to let Alice make Bob a member (i.e., let Bob join) a verified group 524 | of which Alice is a member. 525 | Alice may have created the group 526 | or become a member prior to the addition of Bob. 527 | 528 | In order to add Bob to the group 529 | Alice has to verify him as a contact 530 | if she has not done so yet. 531 | We use this message exchange 532 | to also ask Bob wether he agrees to becoming part of the group. 533 | 534 | The protocol re-uses the first five steps of the `setup-contact`_ protocol 535 | so that Alice and Bob verify each other's keys. 536 | To ask for Bob's explicit consent we 537 | indicate that the messages are part of the verified group protocol, 538 | and include the group's identifier 539 | in the metadata part of the bootstrap code. 540 | 541 | More precisely: 542 | 543 | - in step 1 Alice adds the metadata 544 | ``INVITE=``. 545 | Where ```` is the name of the group ``GROUP``. 546 | 547 | - in step 2 Bob manually confirms he wants to join ``GROUP`` 548 | before his device sends the ``vc-request`` message. 549 | If Bob declines processing aborts. 550 | 551 | - in step 5 Alice looks up the metadata 552 | associated with the ``INVITENUMBER``. 553 | If Alice sees the ``INVITE=`` 554 | but is not part of the group anymore 555 | she aborts the joining process 556 | (without sending another message). 557 | 558 | If no failure occurred up to this point, 559 | Alice and Bob have verified each other's keys, 560 | and Alice knows that Bob wants to join the group ``GROUP``. 561 | 562 | The protocol then continues as described in the following section 563 | (steps 6 and 7 of the `setup-contact`_ are not used). 564 | 565 | Joining a verified group ("secure-join") 566 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 567 | 568 | In order to add Bob to a group Alice first needs to make sure 569 | she has a verified key for Bob. 570 | This is the case if Bob already was a verified contact 571 | or Alice performed the steps described in the previous section. 572 | 573 | Now she needs to inform the group that Bob should be added. 574 | Bob needs to confirm everything worked: 575 | 576 | a. Alice broadcasts an encrypted "vg-member-setup" message to all members of 577 | ``GROUP`` (including Bob), 578 | gossiping the Autocrypt keys of all members (including Bob). 579 | 580 | b. Bob receives the encrypted "vg-member-setup" message. 581 | Bob's device verifies: 582 | 583 | * The encryption and Alices signature are intact. 584 | 585 | * Alice may invite Bob to a verified group. 586 | That is she is a verified contact of Bob. 587 | 588 | If any of the checks fail processing aborts. 589 | Otherwise the device learns 590 | all the keys and e-mail addresses of group members. 591 | Bob's device sends 592 | a final "vg-member-setup-received" message to Alice's device. 593 | Bob's device shows 594 | "You successfully joined the verified group ``GROUP``". 595 | 596 | c. Any other group member that receives the encrypted "vg-member-setup" message 597 | will process the gossiped key through autocrypt gossip mechanisms. 598 | In addition they verify: 599 | 600 | * The encryption and Alices signature are intact. 601 | 602 | * They are themselves a member of ``GROUP``. 603 | 604 | * Alice is a member of ``GROUP``. 605 | 606 | If any of the checks fail processing aborts. 607 | Otherwise they will add Bob to their list of group members 608 | and mark the gossiped key as verified in the context of this group. 609 | 610 | d. Alice's device receives the "vg-member-setup-received" reply from Bob 611 | and shows a screen 612 | "Bob securely joined group ``GROUP``" 613 | 614 | Bob and Alice may now both invite and add more members 615 | which in turn can add more members. 616 | The described secure-join workflow guarantees 617 | that all members of the group have been verified with at least one member. 618 | The broadcasting of keys further ensures 619 | that all members are fully connected. 620 | 621 | .. figure:: ../images/join_verified_group.jpg 622 | :width: 200px 623 | 624 | Join-Group protocol at step 2 with https://delta.chat. 625 | 626 | Strategies for verification reuse 627 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 628 | 629 | Since we retrieve keys for verified groups from peers 630 | we have to choose wether we want to trust our peers 631 | to verify the keys correctly. 632 | 633 | One of the shortcomings of the web of trust 634 | is that it's mental model is hard to understand 635 | and make practical use of. 636 | We therefore do not ask the user questions 637 | about how much they trust their peers. 638 | 639 | Therefore two strategies remain 640 | that have different security implications: 641 | 642 | - **Restricting verification reuse accross groups** 643 | Since we share the content of the group 644 | with all group members 645 | we can also trust them 646 | to verify the keys used for the group. 647 | 648 | If they wanted to leak the content they could do so anyway. 649 | 650 | However if we want 651 | to reuse keys from one verified group 652 | to form a different one 653 | the peer who originally verified the key 654 | may not be part of the new group. 655 | 656 | If the verifier is "malicious" 657 | and colludes with an attacker in a MITM position, 658 | they can inject a MITM key as the verified key. 659 | Reusing the key in the context of another group 660 | would allow MITM attacks on that group. 661 | 662 | This can be prevented by restricting 663 | the invitation to verified groups 664 | to verified contacts 665 | and limiting the scope 666 | of keys from member-added messages 667 | to the corresponding group. 668 | 669 | - **Ignoring infiltrators, focusing on message transport attacks first** 670 | One may also choose to not consider advanced attacks 671 | in which an "infiltrator" peer collaborates with an evil provider 672 | to intercept/read messages. 673 | 674 | In this case keys can be reused accross verified groups. 675 | Active attacks from an adversary 676 | who can only modify messages in the first channel 677 | are still impossible. 678 | 679 | A malicious verified contact may inject MITM keys. 680 | Say Bob when adding Carol as a new member, 681 | sends a prepared MITM key. 682 | We refer to this as a Bob in the middle attack 683 | to illustrate that a peer is involved in the attack. 684 | 685 | We note, 686 | that Bob, will have to sign the message 687 | containing the gossip fake keys. 688 | In the following section 689 | we introduce `history verification` 690 | which will detect such attacks after the fact. 691 | Performing a history verification with Alice 692 | will inform Carol about the MITM key introduced by Bob. 693 | Bob's signature serves as evidence 694 | that Bob gossiped the wrong key for Alice. 695 | 696 | Trusting all peers to verify keys 697 | also allows faster recovery 698 | from device loss. 699 | Say Alice lost her device 700 | and Bob verified the new key. 701 | Once Bob announced the new key in a verified group including Carol 702 | Carol could send the key to further verified groups 703 | that Bob is not part of. 704 | 705 | Dealing with key loss and compromise 706 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 707 | 708 | If a user looses their device 709 | they can setup a new device 710 | and regain access to their inbox. 711 | However they may loose their secret key. 712 | 713 | They can generate a new key pair. 714 | Autocrypt will distribute their new public key 715 | in the Autocrypt headers 716 | and opportunistic encryption will switch to it automatically. 717 | 718 | Verified groups will remain unreadable 719 | until the user verifies a contact from that group. 720 | Then the contact can update the key used in the group. 721 | This happens by sending a "vg-member-setup" message 722 | to the group. 723 | Since the email address of that user remains the same 724 | the old key will be replaced by the new one. 725 | 726 | Implementers may decide 727 | wether the recipients of such key updates 728 | propagate them to other groups 729 | they share with the user in question. 730 | If they do this will speed up the recovery from device loss. 731 | However it also allows Bob-in-the-middle attacks 732 | that replace the originally verified keys. 733 | So the decision needs to be based on the threat model of the app 734 | and the strategy picked for verification reuse 735 | 736 | If a key is known or suspected to be compromised 737 | more care needs to be taken. 738 | Since network attackers can drop messages 739 | they can also drop the "vg-member-setup" message 740 | that was meant to replace a compromised key. 741 | A compromised key combined with a network attack 742 | breaks the security of both channels. 743 | Recovering from this situation needs careful consideration 744 | and goes beyond the scope of our current work. 745 | 746 | Notes on the verified group protocol 747 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 748 | 749 | - **More Asynchronous UI flow**: 750 | All steps after 2 (the sending of adminstrative messages) 751 | could happen asynchronously and in the background. 752 | This might be useful because e-mail providers often delay initial messages 753 | ("greylisting") as mitigation against spam. 754 | The eventual outcomes ("Could not establish verified connection" 755 | or "successful join") can be delivered in asynchronous notifications 756 | towards Alice and Bob. 757 | These can include a notification 758 | "verified join failed to complete" 759 | if messages do not arrive within a fixed time frame. 760 | In practise this means that secure joins can be concurrent. 761 | A member can show the "Secure Group invite" to a number of people. 762 | Each of these peers scans the message and launches the secure-join. 763 | As 'vc-request-with-auth' messages arrive to Alice, 764 | she will send the broadcast message 765 | that introduces every new peer to the rest of the group. 766 | After some time everybody will become a member of the group. 767 | 768 | - **Leaving attackers in the dark about verified groups**. 769 | It might be feasible to design 770 | the step 3 "secure-join-requested" message 771 | from Bob (the joiner) to Alice (the inviter) 772 | to be indistinguishable from other initial "contact request" messages 773 | that Bob sends to Alice to establish contact. 774 | This means 775 | that the provider would, 776 | when trying to substitute an Autocrypt key on a first message between two peers, 777 | run the risk of **immediate and conclusive detection of malfeasance**. 778 | The introduction of the verified group protocol would thus contribute to 779 | securing the e-mail encryption eco-system, 780 | rather than just securing the group at hand. 781 | 782 | - **Sending all messages through alternative channels**: 783 | instead of being relayed through the provider, 784 | all messages from step 2 onwards could be transferred via Bluetooth or WLAN. 785 | This way, 786 | the full invite/join protocol would be completed 787 | on a different channel. 788 | Besides increasing the security of the joining, 789 | an additional advantage is 790 | that the provider would not gain knowledge about verifications. 791 | 792 | - **Non-messenger e-mail apps**: 793 | instead of groups, traditional e-mail apps could possibly offer 794 | the techniques described here for "secure threads". 795 | 796 | 797 | Autocrypt and verified key state 798 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 799 | 800 | Verified key material 801 | |--| whether from verified contacts or verified groups |--| 802 | provides stronger security guarantees 803 | then keys discovered in Autocrypt headers. 804 | 805 | At the same time opportunistic usage 806 | of keys from autocrypt headers 807 | provides faster recovery from device loss. 808 | 809 | Therefore the address-to-key mappings obtained using the verification protocols 810 | should be stored separately 811 | and in addition to the data 812 | stored for the normal Autocrypt behaviour. 813 | 814 | Verified contacts and groups offer 815 | a separate communication channel 816 | from the opportunistic one. 817 | 818 | We separated the two concepts 819 | but they can both be presented to the user 820 | as 'Verified Groups'. 821 | In this case the verified contact is a verified group with two members. 822 | 823 | This allows the UI to feature 824 | a verified group 825 | and the 'normal' opportunistic encryption 826 | with the same contact. 827 | 828 | The verified group prevents key injection through Autocrypt headers. 829 | In the case of device loss 830 | the user can fall back to the non-verified contact 831 | to ensure availability of a communication channel 832 | even before the next verification has taken place. 833 | 834 | .. _`history-verification`: 835 | 836 | History-verification protocol 837 | --------------------------------- 838 | 839 | The two protocols we have described so far 840 | assure the user about the validity of 841 | the keys they verify and of the keys of their peers in groups they join. 842 | If the protocols detect an active attack 843 | (for example because keys are substituted) 844 | they immediately alert the user. 845 | Since users are involved in a verification process, 846 | this is the right time to alert users. 847 | By contrast, today's verification workflows alert the users when a 848 | previously key has changed. 849 | At that point users typically are not physically next to each other, 850 | and are rarely concerned with the key since they want 851 | to get a different job done, e.g., of sending or reading a message. 852 | 853 | However, 854 | our new verification protocols only verify the current keys. 855 | Historical interactions between peers may involve keys that have never been 856 | verified using these new verification protocols. 857 | So how can users determine the integrity of keys of historical messages? 858 | This is where the history-verification protocol comes in. 859 | This protocol, 860 | that again relies on a second channel, 861 | enables two peers 862 | to verify integrity, authenticity and confidentiality 863 | of their shared historic messages. 864 | After completion, users gain assurance 865 | that not only their current communication is safe 866 | but that their past communications have not been compromised. 867 | 868 | By verifying all keys in the shared history between peers, 869 | the history-verification protocol can detect 870 | temporary malfeasant substitutions of keys in messages. 871 | Such substitutions are not caught by current key-fingerprint verification 872 | workflows, because they only provide assurance about the current keys. 873 | They can detect substitutions 874 | that happened via gossip, Autocrypt headers 875 | and through verification reuse (Bob in the middle attacks). 876 | 877 | In the latter case they also point out and provide evidence 878 | who introduced the MITM key in a given group. 879 | Performing a history verification with that person 880 | will in turn show where they got the key from. 881 | This way the key can be tracked back to who originally created it. 882 | 883 | Like in the `setup-contact`_ protocol, 884 | we designed our history-verification protocol so that 885 | peers only perform only one "show" and "read" of bootstrap information 886 | (typically transmitted via showing QR codes and scanning them). 887 | 888 | The protocol re-uses the first five steps of the `setup-contact`_ protocol 889 | so that Alice and Bob verify each other's keys. 890 | We make one small modifications to indicate that 891 | the messages are part of the history-verification protocol: 892 | In step 1 Alice adds the metadata 893 | ``VERIFY=history``. 894 | 895 | If no failure occurred after step 5, 896 | Alice and Bob have again verified each other's keys. 897 | The protocol then continues as follows 898 | (steps 6 and 7 of the `setup-contact`_ are not used): 899 | 900 | 6. Alice and Bob have each others verified Autocrypt key. 901 | They use these keys to 902 | encrypt a message to the other party 903 | which contains a **message/keydata list**. 904 | For each message that they have exchanged in the past 905 | they add the following information: 906 | 907 | - The message id of that message 908 | - When this message was sent, i.e., the ``Date`` field. 909 | - A list of (email-address, key fingerprints) tuples 910 | which they sent or received in that particular message. 911 | 912 | 7. Alice and Bob independently perform 913 | the following history-verification algorithm: 914 | 915 | a) determine the start-date as the date of the earliest message (by ``Date``) 916 | for which both sides have records. 917 | 918 | b) verify the key fingerprints for each message since the start-date 919 | for which both sides have records of: 920 | if a key differs for any e-mail address, 921 | we consider this is strong evidence 922 | that there was an active attack. 923 | If such evidence is found, 924 | an error is shown to both Alice and Bob: 925 | "Message at from to has mangled encryption". 926 | 927 | 8. Alice and Bob are presented with a summary which lists: 928 | 929 | - time frame of verification 930 | - the number of messages successfully verified 931 | - the number of messages with mangled encryption 932 | - the number of dropped messages, i.e. sent by one party, 933 | but not received by the other, or vice versa 934 | 935 | If there are no dropped or mangled messages, signal to the user 936 | "history verification successfull". 937 | 938 | 939 | Device Loss 940 | ~~~~~~~~~~~ 941 | 942 | A typical scenario for a key change is device loss. 943 | The owner of the lost device loses 944 | access to his private key. 945 | We note that when this happens, 946 | in most cases 947 | the owner also loses access to 948 | his messages (because he can no longer decrypt them) 949 | and his key history. 950 | 951 | Thus, if Bob lost his device, it is likely 952 | that Alice will have a much longer history for him then he has himself. 953 | Bob can only compare keys for the timespan after the device loss. 954 | While this verification is certainly less useful, 955 | it would enable Alice and Bob 956 | to detect of attacks in that time after the device lossj. 957 | 958 | On the other hand, we can also envision 959 | users storing their history outside of their devices. 960 | The security requirements for such a backup are much lower 961 | than for backing up the private key. 962 | The backup only needs to be tamper proof, 963 | i.e., its integrity must be guaranteed |--| not its confidentiality. 964 | This is achievable even if the private key is lost. 965 | Users can verify the integrity of this backup even if 966 | they lose their private key. 967 | For example, Bob can cryptographically sign 968 | the key history using his current key. 969 | As long as Bob, and others, have access to Bob's public key, 970 | he can verify that the backup has not been tampered with. 971 | 972 | .. 973 | TODO: But how does bob know his public key if he lost his device? 974 | 975 | An alternative is to permit 976 | that Bob recovers his history from the message/keydata list 977 | that he receives from Alice. 978 | Then, he could validate such information 979 | with other people in subsequent verifications. 980 | However, this method is vulnerable to collusion attacks 981 | in which Bob's keys are replaced in all of his peers, 982 | including Alice. 983 | It may also lead to other error cases 984 | that are much harder to investigate. 985 | We therefore discourage such an approach. 986 | 987 | 988 | Keeping records of keys in messages 989 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 990 | 991 | The history verification described above 992 | requires all e-mail apps (MUAs) to record, 993 | 994 | - each e-mail address/key-fingerprint tuple it **ever** saw 995 | in an Autocrypt or an Autocrypt-Gossip header in incoming mails. 996 | This means not just the most recent one(s), 997 | but the full history. 998 | 999 | - each emailaddr/key association it ever sent out 1000 | in an Autocrypt or an Autocrypt Gossip header. 1001 | 1002 | It needs to associate these data with the corresponding message-id. 1003 | 1004 | .. 1005 | TODO: This seems incomplete. To verify the history, MUAs also need 1006 | all message-ids, even if those are deleted, or do not contain keys. 1007 | This information is not mentioned here.j 1008 | 1009 | 1010 | State tracking suggested implementation 1011 | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1012 | 1013 | We suggest MUAs could maintain an outgoing and incoming "message-log" 1014 | which keeps track of the information in all incoming and outgoing mails, 1015 | respectively. 1016 | A message with N recipients would cause N entries 1017 | in both the sender's outgoing 1018 | and each of the recipient's incoming message logs. 1019 | Both incoming and outgoing message-logs would contain these attributes: 1020 | 1021 | - ``message-id``: The message-id of the e-mail 1022 | 1023 | - ``date``: the parsed Date header as inserted by the sending MUA 1024 | 1025 | - ``from-addr``: the sender's routable e-mail address part of the From header. 1026 | 1027 | - ``from-fingerprint``: the sender's key fingerprint of the sent Autocrypt key 1028 | (NULL if no Autocrypt header was sent) 1029 | 1030 | - ``recipient-addr``: the routable e-mail address of a recipient 1031 | 1032 | - ``recipient-fingerprint``: the fingerprint of the key we sent or received 1033 | in a gossip header (NULL if not Autocrypt-Gossip header was sent) 1034 | 1035 | It is also possible 1036 | to serialize the list of recipient addresses and fingerprints into a single value, 1037 | which would result in only one entry 1038 | in the sender's outgoing and each recipient's incoming message log. 1039 | This implementation may be more efficient, 1040 | but it is also less flexible in terms of how 1041 | to share information. 1042 | 1043 | Usability question of "sticky" encryption and key loss 1044 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1045 | 1046 | Do we want to prevent 1047 | dropping back to not encrypting or encrypting with a different key 1048 | if a peer's autocrypt key state changes? 1049 | Key change or drop back to cleartext is opportunistically accepted 1050 | by the Autocrypt Level 1 key processing logic 1051 | and eases communication in cases of device or key loss. 1052 | The "setup-contact" also conveniently allows two peers 1053 | who have no address of each other to establish contact. 1054 | Ultimately, 1055 | it depends on the guarantees a mail app wants to provide 1056 | and how it represents cryptographic properties to the user. 1057 | 1058 | 1059 | 1060 | .. _`onion-verified-keys`: 1061 | 1062 | Verifying keys through onion-queries 1063 | ------------------------------------------ 1064 | 1065 | Up to this point this document has describe methods 1066 | to securely add contacts, form groups, and verify history 1067 | in an offline scenario where users can establish a second channel 1068 | to carry out the verification. 1069 | We now discuss how the use of Autocrypt headers can be used 1070 | to support continuous key verification in an online setting. 1071 | 1072 | A straightforward approach to ensure view consistency in a group is 1073 | to have all members of the group continuously broadcasting their belief 1074 | about other group member's keys. 1075 | Unless they are fully isolated by the adversary (see Section for an analysis). 1076 | This enables every member 1077 | to cross check their beliefs about others and find inconsistencies 1078 | that reveal an attack. 1079 | 1080 | However, this is problematic from a privacy perspective. 1081 | When Alice publishes her latest belief 1082 | about others' keys she is implicitly revealing 1083 | what is the last status she observed 1084 | which in turn allows 1085 | to infer when was the last time she had contact with them. 1086 | If such contact happened outside of the group 1087 | this is revealing information 1088 | that would not be available had keys not been gossiped. 1089 | 1090 | We now propose an alternative 1091 | in which group members do not need to broadcast information 1092 | in order to enable key verification. 1093 | The solution builds on the observation 1094 | that the best person to verify Alice's key is Alice herself. 1095 | Thus, 1096 | if Bob wants to verify her key, 1097 | it suffices to be able to create a secure channel between Bob and Alice 1098 | so that she can confirm his belief on her key. 1099 | 1100 | However, 1101 | Bob directly contacting Alice through the group channel 1102 | reveals immediately that he is interested on verifying her key 1103 | to the group members, 1104 | which again raises privacy concerns. 1105 | Instead, 1106 | we propose that Bob relies on other members 1107 | to rely the verifying message to Alice, 1108 | similarly to a typical anonymous communication network. 1109 | 1110 | The protocol works as follows: 1111 | 1112 | 1. Bob chooses :math:`n` members of the group as relying parties 1113 | to form the channel to Alice. 1114 | For simplicity let us take :math:`n=2` 1115 | and assume these members are Charlie, key :math:`k_C`, 1116 | and David, with key :math:`k_D` 1117 | (both :math:`k_C` and :math:`k_D` being the current belief 1118 | of Bob regarding Charlie and David's keys). 1119 | 1120 | 2. Bob encrypts a message of the form 1121 | (``Bob_ID``, ``Alice_ID`` , :math:`k_A`) 1122 | with David and Charlie's keys in an onion encryption: 1123 | 1124 | :math:`E_{k_C}` (``David_ID``, :math:`E_{k_D}` (``Alice_ID``,(``Bob_ID``, ``Alice_ID``, :math:`k_A` ))), 1125 | where :math:`E_{k_*}` indicates encrypted with key :math:`k_*` 1126 | 1127 | In this message ``Bob_ID`` and ``Alice_ID`` are the identifiers, 1128 | e.g., email addresses, that Alice and Bob use to identify each other. 1129 | The message effectively encodes the question 1130 | 'Bob asks: Alice, is your key :math:`k_A`?' 1131 | 1132 | 3. Bob sends the message to Charlie, 1133 | who decrypts the message to find that it has to be relayed to David. 1134 | 1135 | 4. David receives Charlie's message, 1136 | decrypts and relays the message to Alice. 1137 | 1138 | 5. Alice receives the message and replies to Bob 1139 | repeating steps 1 to 4 with other random :math:`n` members 1140 | and inverting the IDs in the message. 1141 | 1142 | From a security perspective, 1143 | i.e., in terms of resistance to adversaries, 1144 | this process has the same security properties as the broadcasting. 1145 | For the adversary to be able to intercept the queries 1146 | he must MITM all the keys between Bob and others. 1147 | 1148 | From a privacy perspective it improves over broadcasting 1149 | in the sense that not everyone learns each other status of belief. 1150 | Also, Charlie knows that Bob is trying a verification, 1151 | but not of whom. 1152 | However, David gets to learn 1153 | that Bob is trying to verify Alice's key, 1154 | thus his particular interest on her. 1155 | 1156 | This problem can be solved in two ways: 1157 | 1158 | A. All members of the group check each other continuously so as 1159 | to provide plausible deniability regarding real checks. 1160 | 1161 | B. Bob protects the message using secret sharing 1162 | so that only Alice can see the content once all shares are received. 1163 | Instead of sending (``Bob_ID``, ``Alice_ID`` , :math:`k_A`) directly, 1164 | Bob splits it into :math:`t` shares. 1165 | Each of this shares is sent to Alice through a *distinct* channel. 1166 | This means that Bob needs toe create :math:`t` channels, as in step 1. 1167 | 1168 | When Alice receives the :math:`t` shares 1169 | she can recover the message and respond to Bob in the same way. 1170 | In this version of the protocol, 1171 | David (or any of the last hops before Alice) only learns 1172 | that someone is verifying Alice, 1173 | but not whom, i.e., Bob's privacy is protected. 1174 | 1175 | 1176 | Open Questions about onion online verification 1177 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1178 | An open question is 1179 | how to choose contacts to rely onion verification messages. 1180 | This choice should not reveal new information about users' relationships 1181 | nor the current groups where they belong. 1182 | Thus, the most convenient is 1183 | to always choose members of the same group. 1184 | Other selection strategies need to be analyzed 1185 | with respect to their privacy properties. 1186 | 1187 | The other point to be discussed is bandwidth. 1188 | Having everyone publishing their status implies N*(N-1) messages. 1189 | The proposed solution employs 2*N*n*t messages. 1190 | For small groups the traffic can be higher. 1191 | Thus, there is a tradeoff privacy vs. overhead. 1192 | 1193 | .. |--| unicode:: U+2013 .. en dash 1194 | .. |---| unicode:: U+2014 .. em dash, trimming surrounding whitespace 1195 | :trim: 1196 | --------------------------------------------------------------------------------