1 00:00:17,630 --> 00:00:23,729 okay do you hear me the drugging okay 2 00:00:20,970 --> 00:00:25,890 great so welcome to my talk I'm Dominic 3 00:00:23,730 --> 00:00:27,779 and this is joint work with two of my 4 00:00:25,890 --> 00:00:30,210 brightest master students Fabien and 5 00:00:27,779 --> 00:00:32,668 Gregoire and yes we are looking into 6 00:00:30,210 --> 00:00:35,399 that ATP it's a quite an old standard 7 00:00:32,668 --> 00:00:37,849 box tool it's used so we got a nice 8 00:00:35,399 --> 00:00:40,559 response from one of the authors of the 9 00:00:37,850 --> 00:00:42,899 standard on Twitter and yeah he's 10 00:00:40,559 --> 00:00:46,620 wondering if we can can learn something 11 00:00:42,899 --> 00:00:50,219 so let's learn something here um let's 12 00:00:46,620 --> 00:00:54,328 look at the current status of end-to-end 13 00:00:50,219 --> 00:00:57,570 security and voice calls so keep in mind 14 00:00:54,329 --> 00:01:00,239 end-to-end security not just client - - 15 00:00:57,570 --> 00:01:02,340 cloud provider so public switch 16 00:01:00,239 --> 00:01:05,128 telephone network what we have is not 17 00:01:02,340 --> 00:01:07,049 enter and secured pretty obvious then we 18 00:01:05,129 --> 00:01:10,560 have the session initiation protocol and 19 00:01:07,049 --> 00:01:13,619 like RTP and SFTP it's also not 20 00:01:10,560 --> 00:01:16,170 end-to-end secure by design okay let's 21 00:01:13,619 --> 00:01:19,530 go on then we have something that's 22 00:01:16,170 --> 00:01:23,610 called DTLS at the Datagram transport 23 00:01:19,530 --> 00:01:26,189 layer security used to exchange a secret 24 00:01:23,610 --> 00:01:29,520 for smtp that's end-to-end encryption 25 00:01:26,189 --> 00:01:32,820 and then we have end-to-end encryption 26 00:01:29,520 --> 00:01:37,110 and authentication that zip plus SATP 27 00:01:32,820 --> 00:01:39,539 plus let ftp and obviously for an evil 28 00:01:37,110 --> 00:01:45,049 operator it gets more difficult down the 29 00:01:39,540 --> 00:01:45,049 line so we are looking into this space 30 00:01:46,009 --> 00:01:55,320 so um first I wanted to introduce like 31 00:01:52,159 --> 00:01:57,600 what we did in the beginning so if we 32 00:01:55,320 --> 00:01:59,908 just have slipped with encryption olney 33 00:01:57,600 --> 00:02:02,369 or on or no encryption there is a 34 00:01:59,909 --> 00:02:04,469 similar setup like this this is a pretty 35 00:02:02,369 --> 00:02:06,869 simplified view with just one tip server 36 00:02:04,469 --> 00:02:09,090 but to get the point across 37 00:02:06,869 --> 00:02:12,510 yes Alice and Bob they're doing a call 38 00:02:09,090 --> 00:02:13,710 they're using a sip server and if you 39 00:02:12,510 --> 00:02:15,390 are an evil operator 40 00:02:13,710 --> 00:02:17,460 you can do some men in the middle here 41 00:02:15,390 --> 00:02:19,470 from East dropping it's very very simple 42 00:02:17,460 --> 00:02:23,700 we did an implementation for the server 43 00:02:19,470 --> 00:02:25,710 Camarillo and so we just rewriting some 44 00:02:23,700 --> 00:02:28,560 headers in the session initiation and 45 00:02:25,710 --> 00:02:30,090 redirecting the caller from Ella's to 46 00:02:28,560 --> 00:02:32,190 the special client that is running on 47 00:02:30,090 --> 00:02:35,490 the server for example the special 48 00:02:32,190 --> 00:02:38,130 client takes the call thus its own call 49 00:02:35,490 --> 00:02:40,590 to Bob and then connect those multimedia 50 00:02:38,130 --> 00:02:42,960 streams and you get your eavesdropping 51 00:02:40,590 --> 00:02:47,250 or via typing so very very simple it 52 00:02:42,960 --> 00:02:49,140 works are on Bob side is it says ellos 53 00:02:47,250 --> 00:02:53,760 and ellas at example.com 54 00:02:49,140 --> 00:02:57,989 so how to protect against this this is 55 00:02:53,760 --> 00:02:59,549 that Ltd the same setup are what the 56 00:02:57,990 --> 00:03:01,410 users are seeing is a little bit 57 00:02:59,550 --> 00:03:03,030 different there is something that is 58 00:03:01,410 --> 00:03:06,060 called and short of indication string 59 00:03:03,030 --> 00:03:08,580 here it's pretty small here story so 60 00:03:06,060 --> 00:03:10,620 it's just four characters that is shown 61 00:03:08,580 --> 00:03:12,270 on the screen and on the other side also 62 00:03:10,620 --> 00:03:14,160 four characters shown on the screen and 63 00:03:12,270 --> 00:03:16,350 Alice involved need to compare these 64 00:03:14,160 --> 00:03:18,450 strings and when they're different there 65 00:03:16,350 --> 00:03:20,730 is an attack so they are different there 66 00:03:18,450 --> 00:03:23,450 is an attack here this is how the ITP 67 00:03:20,730 --> 00:03:29,010 works from your user user's perspective 68 00:03:23,450 --> 00:03:30,959 okay what are we doing now so that a DB 69 00:03:29,010 --> 00:03:33,720 is a pretty complex protocol in my 70 00:03:30,960 --> 00:03:35,760 opinion and it basically boils down to 71 00:03:33,720 --> 00:03:38,190 in a DC Hellman key exchange there's 72 00:03:35,760 --> 00:03:42,239 authenticated using these short of a 73 00:03:38,190 --> 00:03:45,960 negating strings to keep this string 74 00:03:42,240 --> 00:03:47,910 short as the name suggests they are 75 00:03:45,960 --> 00:03:51,780 doing a hash commitment to constrain the 76 00:03:47,910 --> 00:03:53,460 tecar to just one try for call in this 77 00:03:51,780 --> 00:03:56,250 paper we are doing a real world 78 00:03:53,460 --> 00:03:58,890 a relation of real world implementations 79 00:03:56,250 --> 00:04:01,020 and we are explicitly not looking into 80 00:03:58,890 --> 00:04:04,500 closed networks we are excluding attacks 81 00:04:01,020 --> 00:04:06,690 where the you assume that the attacker 82 00:04:04,500 --> 00:04:10,260 do stuff some speechless entities we are 83 00:04:06,690 --> 00:04:11,430 not doing this we assume that the short 84 00:04:10,260 --> 00:04:16,858 authentication strings have been 85 00:04:11,430 --> 00:04:18,840 compared correctly okay so in the paper 86 00:04:16,858 --> 00:04:20,548 we looked into the following 87 00:04:18,839 --> 00:04:22,679 implementations there is a cure with 88 00:04:20,548 --> 00:04:24,719 soft form for IRSC sip simple for 89 00:04:22,680 --> 00:04:27,930 Android there's jitsi it's a 90 00:04:24,720 --> 00:04:31,710 cross-platform client we have lint sound 91 00:04:27,930 --> 00:04:34,260 and we have signal so in in the paper we 92 00:04:31,710 --> 00:04:36,810 are certain protocol tests and for non 93 00:04:34,260 --> 00:04:38,670 protocol test and in the presentation I 94 00:04:36,810 --> 00:04:40,910 will just show the interesting results 95 00:04:38,670 --> 00:04:44,940 and skip the rest 96 00:04:40,910 --> 00:04:49,140 okay so let's dive deep down into that 97 00:04:44,940 --> 00:04:52,560 FTP this is an extremely simplified view 98 00:04:49,140 --> 00:04:55,370 of that ATT so there see is much longer 99 00:04:52,560 --> 00:04:57,690 so if you if you look into it there is a 100 00:04:55,370 --> 00:04:59,700 on the left side we have the responder 101 00:04:57,690 --> 00:05:01,230 on the right side the initiator they're 102 00:04:59,700 --> 00:05:02,880 exchanging some hello messages and 103 00:05:01,230 --> 00:05:04,800 random values that's not that important 104 00:05:02,880 --> 00:05:08,670 what is important you can you can find 105 00:05:04,800 --> 00:05:10,380 the diffie-hellman here so P VI is the 106 00:05:08,670 --> 00:05:13,200 public value for diffie-hellman on the 107 00:05:10,380 --> 00:05:16,200 initiator slide that's up there then we 108 00:05:13,200 --> 00:05:18,890 have PV err it's the responder is public 109 00:05:16,200 --> 00:05:21,180 value and obviously they are doing a 110 00:05:18,890 --> 00:05:24,690 difficult key exchange so this is like 111 00:05:21,180 --> 00:05:26,610 the shared secret we get all of this on 112 00:05:24,690 --> 00:05:29,370 the initiators side and this is the one 113 00:05:26,610 --> 00:05:33,260 on the responder side so what's the 114 00:05:29,370 --> 00:05:36,000 trick here arm it's not sink it's not 115 00:05:33,260 --> 00:05:38,610 yeah it's not doing this at the same 116 00:05:36,000 --> 00:05:41,250 time they are doing a hash commitment so 117 00:05:38,610 --> 00:05:43,410 instead of directly are transmitting the 118 00:05:41,250 --> 00:05:46,230 public value or the initiator is 119 00:05:43,410 --> 00:05:47,850 transmitting a hash of the publicly so 120 00:05:46,230 --> 00:05:50,010 you're kind of committing to the public 121 00:05:47,850 --> 00:05:53,700 value without revealing it over the 122 00:05:50,010 --> 00:05:55,260 network and this kind of constraints the 123 00:05:53,700 --> 00:05:58,020 attacker to just won't try in the 124 00:05:55,260 --> 00:05:59,670 beginning so we don't have like an 125 00:05:58,020 --> 00:06:02,219 offline brute-force attack of edom 126 00:05:59,670 --> 00:06:05,040 instead we have an online attack of is 127 00:06:02,220 --> 00:06:06,540 just one file and in the end the 128 00:06:05,040 --> 00:06:09,510 shortest indication string is kind of a 129 00:06:06,540 --> 00:06:11,670 key duration of the shared secret the 130 00:06:09,510 --> 00:06:14,340 IDS of responder and initiator and the 131 00:06:11,670 --> 00:06:17,430 hash of all messages okay so first thing 132 00:06:14,340 --> 00:06:21,479 you need to notice you need this check 133 00:06:17,430 --> 00:06:23,970 so it's the hash that has been committed 134 00:06:21,480 --> 00:06:27,180 previously really the hash of the public 135 00:06:23,970 --> 00:06:30,470 value that you received so this is one 136 00:06:27,180 --> 00:06:33,540 of our test it's very obvious test and 137 00:06:30,470 --> 00:06:38,010 there's one implementation failing it so 138 00:06:33,540 --> 00:06:40,950 Lin phone didn't check this so we don't 139 00:06:38,010 --> 00:06:41,480 have to be constrained to one try taker 140 00:06:40,950 --> 00:06:45,170 in 141 00:06:41,480 --> 00:06:47,270 we have well I can not unlimited but we 142 00:06:45,170 --> 00:06:50,080 haven't attacker is much more ruthless 143 00:06:47,270 --> 00:06:53,229 capabilities and we implemented that and 144 00:06:50,080 --> 00:06:54,710 yeah it works so there are two kind of 145 00:06:53,230 --> 00:06:56,900 representations of the short 146 00:06:54,710 --> 00:06:59,450 authentication string one for 16-bit and 147 00:06:56,900 --> 00:07:00,109 one for 20 bits that's shown here and 148 00:06:59,450 --> 00:07:02,900 yeah 149 00:07:00,110 --> 00:07:05,930 not many tries or needed to crack this 150 00:07:02,900 --> 00:07:13,489 obviously this has been fixed and in 151 00:07:05,930 --> 00:07:15,320 phone okay so next attack so if you do 152 00:07:13,490 --> 00:07:18,290 this if you Hellman key exchange will 153 00:07:15,320 --> 00:07:20,300 set FTP and you press the confirm button 154 00:07:18,290 --> 00:07:21,080 that you're short authentication string 155 00:07:20,300 --> 00:07:26,270 is the right one 156 00:07:21,080 --> 00:07:27,680 let it be stores this inside a cache so 157 00:07:26,270 --> 00:07:30,169 the next time you do a call to the same 158 00:07:27,680 --> 00:07:31,880 person you no longer need to compare 159 00:07:30,170 --> 00:07:35,570 short authentication strings because you 160 00:07:31,880 --> 00:07:37,730 did in the first call this is stored 161 00:07:35,570 --> 00:07:41,450 inside the cache and next time they just 162 00:07:37,730 --> 00:07:44,890 use what is inside the cache duty 163 00:07:41,450 --> 00:07:48,620 duration on it so it's like similar - 164 00:07:44,890 --> 00:07:52,669 yeah like self-healing properties okay 165 00:07:48,620 --> 00:07:54,880 so um there is a special scenario here 166 00:07:52,670 --> 00:07:58,220 what is also written in the error see I 167 00:07:54,880 --> 00:08:00,740 just read result if either party can't 168 00:07:58,220 --> 00:08:03,620 discovers the cache mismatch the user 169 00:08:00,740 --> 00:08:05,180 agent who must who makes this discovery 170 00:08:03,620 --> 00:08:07,310 must treat this as a possible security 171 00:08:05,180 --> 00:08:09,680 then and must alert their own you know 172 00:08:07,310 --> 00:08:12,170 that there is a heightened risk of an 173 00:08:09,680 --> 00:08:17,540 end until attack so this means if I do 174 00:08:12,170 --> 00:08:23,150 LS does call - both are the dish secret 175 00:08:17,540 --> 00:08:27,560 is safe second call to Bob on and Alice 176 00:08:23,150 --> 00:08:30,890 looks into the cache and there is there 177 00:08:27,560 --> 00:08:34,820 is a cache miss mesh so this doesn't fit 178 00:08:30,890 --> 00:08:38,210 to the one that is used by Bob then 179 00:08:34,820 --> 00:08:41,599 there is maybe a security incident here 180 00:08:38,210 --> 00:08:43,430 and there is security warning in jitsi 181 00:08:41,599 --> 00:08:45,680 this is displayed here and expected 182 00:08:43,429 --> 00:08:47,689 retain shared secret is missing I don't 183 00:08:45,680 --> 00:08:50,420 think anybody and user would understand 184 00:08:47,690 --> 00:08:54,480 what is saying here but they implemented 185 00:08:50,420 --> 00:08:57,689 it at least it's a must in diversity 186 00:08:54,480 --> 00:09:01,030 so I think it's a questionable 187 00:08:57,690 --> 00:09:03,550 requirement because n Jesus maybe just 188 00:09:01,030 --> 00:09:06,220 dismiss it t sub simple and then phone 189 00:09:03,550 --> 00:09:10,560 do not implement this and while checking 190 00:09:06,220 --> 00:09:15,190 this out we found a bug in GT so 191 00:09:10,560 --> 00:09:19,479 actually they not just show this on a 192 00:09:15,190 --> 00:09:21,280 case in mismatch they also show this if 193 00:09:19,480 --> 00:09:24,760 there is just one entry inside the cache 194 00:09:21,280 --> 00:09:28,360 and they're creating a second entry they 195 00:09:24,760 --> 00:09:31,390 also show the flag because yeah there 196 00:09:28,360 --> 00:09:35,170 was one missing initiation of an object 197 00:09:31,390 --> 00:09:37,660 here so we fixed it so the security 198 00:09:35,170 --> 00:09:40,870 warning was raised for other 199 00:09:37,660 --> 00:09:42,300 participants new clients of Bob so and 200 00:09:40,870 --> 00:09:47,980 nobody complained sue 201 00:09:42,300 --> 00:09:50,620 okay let's just so lots of tech I won't 202 00:09:47,980 --> 00:09:51,940 present in the presentation that's what 203 00:09:50,620 --> 00:09:56,580 we call the shared men in the middle 204 00:09:51,940 --> 00:10:00,670 attack so let's consider the following 205 00:09:56,580 --> 00:10:03,780 like LS bought and Eve are friends they 206 00:10:00,670 --> 00:10:08,140 know each other they talk a lot on phone 207 00:10:03,780 --> 00:10:10,480 so an elephant is to a normal phone call 208 00:10:08,140 --> 00:10:11,800 they both confirm the shot of engagement 209 00:10:10,480 --> 00:10:14,290 ring 210 00:10:11,800 --> 00:10:18,069 the shared secret is stored inside the 211 00:10:14,290 --> 00:10:19,480 cache on both sides so very nice second 212 00:10:18,070 --> 00:10:21,820 time they don't need to confirm the 213 00:10:19,480 --> 00:10:24,100 short vacation string then there is a 214 00:10:21,820 --> 00:10:24,610 call between Ethan Bob same thing 215 00:10:24,100 --> 00:10:27,160 happens 216 00:10:24,610 --> 00:10:29,560 they both confirm the SAS everything is 217 00:10:27,160 --> 00:10:33,540 correct nice second call no need to 218 00:10:29,560 --> 00:10:36,520 check SAS and the third step arm 219 00:10:33,540 --> 00:10:37,630 each is no evil 220 00:10:36,520 --> 00:10:40,240 he was conducting a man-in-the-middle 221 00:10:37,630 --> 00:10:44,260 attack like we showed in the beginning 222 00:10:40,240 --> 00:10:46,150 like an evil operator and it's just 223 00:10:44,260 --> 00:10:49,090 placing herself in the middle between 224 00:10:46,150 --> 00:10:51,790 elephant Bob and yeah actually it works 225 00:10:49,090 --> 00:10:53,860 because there are shared secrets between 226 00:10:51,790 --> 00:10:57,270 elephant decent with leaves and Bob 227 00:10:53,860 --> 00:11:00,280 so no SAS confirmation required 228 00:10:57,270 --> 00:11:02,740 everything works and also the zip 229 00:11:00,280 --> 00:11:06,209 address is shown on the on Ellis own 230 00:11:02,740 --> 00:11:09,449 shows Bob at example.com anon box shown 231 00:11:06,209 --> 00:11:14,039 so what is missing here I mean very 232 00:11:09,449 --> 00:11:17,358 obvious attack why does this work so in 233 00:11:14,039 --> 00:11:19,829 that edit II there is no binding of the 234 00:11:17,359 --> 00:11:22,709 identity is used in 1080p to the order 235 00:11:19,829 --> 00:11:25,769 protocol so they explicitly designed the 236 00:11:22,709 --> 00:11:29,878 TTP to work independently of the session 237 00:11:25,769 --> 00:11:31,769 protocol so the the cache look up just 238 00:11:29,879 --> 00:11:35,999 uses the Zetas TP ID which is just a 239 00:11:31,769 --> 00:11:42,269 random ID it's not a good address so 240 00:11:35,999 --> 00:11:42,869 this just works um so in signal there is 241 00:11:42,269 --> 00:11:47,239 no cash 242 00:11:42,869 --> 00:11:49,829 you cannot confirm it so the secure 243 00:11:47,239 --> 00:11:51,839 accurate softphone they actually 244 00:11:49,829 --> 00:11:53,608 implement the RFC compliant protection 245 00:11:51,839 --> 00:11:57,119 again there are C knows about this 246 00:11:53,609 --> 00:12:01,169 somehow and you can actually enter a 247 00:11:57,119 --> 00:12:03,839 string for the participants and that is 248 00:12:01,169 --> 00:12:07,470 stored beside the Zetas TP ID inside the 249 00:12:03,839 --> 00:12:10,259 cache and if you do a second call this 250 00:12:07,470 --> 00:12:11,129 is like this it address its LS and this 251 00:12:10,259 --> 00:12:14,879 is the z TP 252 00:12:11,129 --> 00:12:17,209 ID so there is a mismatch here but I 253 00:12:14,879 --> 00:12:22,439 mean the user needs to see this right 254 00:12:17,209 --> 00:12:26,069 it's even I mean I don't think you I say 255 00:12:22,439 --> 00:12:28,169 if it would do usability study I'm not 256 00:12:26,069 --> 00:12:32,128 sure people will even get why they need 257 00:12:28,169 --> 00:12:33,929 to enter a name here so and the other 258 00:12:32,129 --> 00:12:38,659 implementations are insecure there is no 259 00:12:33,929 --> 00:12:42,419 way to to see which set a TP ID is used 260 00:12:38,659 --> 00:12:45,419 okay I have some time left right that's 261 00:12:42,419 --> 00:12:48,449 good so I will do a short quiz ok 262 00:12:45,419 --> 00:12:50,339 security indicators let also nice topic 263 00:12:48,449 --> 00:12:52,949 we just look briefly at security 264 00:12:50,339 --> 00:12:55,949 indicators and applications we did no 265 00:12:52,949 --> 00:13:00,179 user study but just we will do now a 266 00:12:55,949 --> 00:13:03,329 short you the study with you ok so what 267 00:13:00,179 --> 00:13:06,899 is n 2 n TQ left or right who's for left 268 00:13:03,329 --> 00:13:10,069 who's for right ok maybe through let's 269 00:13:06,899 --> 00:13:13,549 first left left-hander and up for left 270 00:13:10,069 --> 00:13:13,549 ok right ok 271 00:13:13,620 --> 00:13:17,490 okay this was easy the students enter 272 00:13:15,630 --> 00:13:20,160 into cute if the green lock I can write 273 00:13:17,490 --> 00:13:22,940 this is this is an open locks about it's 274 00:13:20,160 --> 00:13:28,110 red so okay that that is easy 275 00:13:22,940 --> 00:13:30,810 here's GT by the way okay this is more 276 00:13:28,110 --> 00:13:40,940 difficult okay which one is entering 277 00:13:30,810 --> 00:13:40,939 secure who is for left with four eyes 278 00:13:41,630 --> 00:13:48,030 okay a yeah you can see there is a cross 279 00:13:44,430 --> 00:13:50,459 inside the lock right on the top so this 280 00:13:48,030 --> 00:13:52,470 is insecure this is I mean even there is 281 00:13:50,460 --> 00:13:54,990 a green icon but that doesn't have to do 282 00:13:52,470 --> 00:13:57,900 anything with security so just the lock 283 00:13:54,990 --> 00:14:02,430 I mean it's a closed lock with the cross 284 00:13:57,900 --> 00:14:03,390 I don't know okay last one what is the 285 00:14:02,430 --> 00:14:08,790 key what is insecure 286 00:14:03,390 --> 00:14:18,540 who's for left who's for right okay what 287 00:14:08,790 --> 00:14:19,620 about this yes we will also quite 288 00:14:18,540 --> 00:14:22,589 confused and we couldn't really 289 00:14:19,620 --> 00:14:24,180 reproduce this but but we we asked the 290 00:14:22,590 --> 00:14:27,320 support about this and actually this 291 00:14:24,180 --> 00:14:29,910 says dead now it comes the following so 292 00:14:27,320 --> 00:14:32,460 we have that ATP for the voice 293 00:14:29,910 --> 00:14:36,030 communication and for the video it's 294 00:14:32,460 --> 00:14:38,910 clear it's not encrypted but there is no 295 00:14:36,030 --> 00:14:42,620 voice there is no like long click or 296 00:14:38,910 --> 00:14:47,719 information what is for what and yes 297 00:14:42,620 --> 00:14:52,800 it's really confusing okay so that's it 298 00:14:47,720 --> 00:14:56,490 come to my conclusion current status Lin 299 00:14:52,800 --> 00:14:58,709 phone has been fixed the back in GT we 300 00:14:56,490 --> 00:15:01,530 fix directly upstream that's what was 301 00:14:58,710 --> 00:15:04,710 very very easy signal long longer uses 302 00:15:01,530 --> 00:15:06,900 at ATP this is an independent decision 303 00:15:04,710 --> 00:15:09,120 of Moxie knob there's not not the 304 00:15:06,900 --> 00:15:13,810 influence for our research it's been 305 00:15:09,120 --> 00:15:16,300 done in parallel and yen for the future 306 00:15:13,810 --> 00:15:18,638 yeah most apps fall back to insecure 307 00:15:16,300 --> 00:15:20,439 mode if the data P say it and if you 308 00:15:18,639 --> 00:15:24,910 think about the security indicators I 309 00:15:20,439 --> 00:15:26,230 don't think you will notice Chapman in 310 00:15:24,910 --> 00:15:29,350 the middle tags needs to be discussed 311 00:15:26,230 --> 00:15:32,989 and that's it thanks 312 00:15:29,350 --> 00:15:32,989 [Applause]