"Security & privacy of Bluetooth-based contact tracing apps" by Jim Mussared, CSides June 2020

right which brings us to our final four I did get told on the slack that my microphone was a little bit like Sony creates the volume hopefully that's a little bit better but our final talk is a really topical talk tonight for a stronger as well it is looking at contact tracing and specifically that I'm talking the title that it has it in the abstract the claimants a cup and some of the vulnerabilities around that and it is why Jim Jim was around and Jean works in the microwave - project is one of the authors of what crowed pythons of Malloy Street implementation before that he worked at a high school computer science education at Brock learning distributed

systems in cloud storage at Google Australia and also industrial process control and monitoring systems that is free so let's give a virtual welcome to Jim and he cannot take enough hi Sylvia - thankfully thank you for the introduction and thank you to both of you Colleen Sylvia for the opportunity to present I'm based in Sydney so I'd like to acknowledge the gadigal people of the eora nation the traditional custodians of this land and pay my respects to their elders past and present so I'm gonna give a quick introduction to contact tracing apps and I'm sure most of you are very familiar with with codes often and the general problem here but I just sum up our goal here is to

detect potential exposures while maintaining user privacy to the maximum extent possible this has been a pretty interesting journey I don't have a security background I'm just interested in Bluetooth then this seemed like a fun opportunity of something to investigate this has taken me into investigating several countries contact tracing applications I've written Senate submission I've spoken to journalists I've been on the radio it's all very very surreal and on brand for 2020 so there many different ways to build a contact tracing app and every country has gone a different path through these options New Zealand for example have a manual app where you scan qr-code this functions more as a memory aid but it's great for privacy there's

different ways of doing proximity detection we're going to focus on Bluetooth here but the idea is that an identifier is distributed to and recorded by nearby phones on a regular interval and later if you use a test positive than any other user who has seen an identifier from that user must be notified these identifiers can either be downloaded regularly from a central authority server or they can be generated on device via a cryptographic scheme as is done in the Apple and Google notification API for a user to say that they have tested positive there may be some verification by a central authority code would say if you just type it in and get a verification SMS

but in Apple Google you can actually have full-on I got this test result with this with his ID attached to it and the main thing that made people mostly focus on is how is the encounter matching algorithm implemented is it done on the device or is it done on the server to be and usually analyzed by a human contact tracer and then finally who gets this notification is it just the user on their phone with a pop-up saying you should self isolate or is the is the central contact tracing Authority involved in tracking whether the user needed to be notified and is undergoing their isolation so specifically covert safe on first install the user provides

their name and phone number to the server in exchange they get an authentication token every two hours the app downloads a new temp ID and this is the idea that they distribute to two other phones nearby these temp IDs are encrypted by a key that's known only to the server and once decrypted they map back to that user's record in the database we imagine unfortunate the details of this encryption process are not known and this would be a really good thing to have access to and understand more about how the silents system works once a user test positive any temp ID recorded by that device uniquely identifies the positive contact a possible contact I should say so the

full database of recorded temp IDs is then uploaded to the server the server can then decrypt these temp IDs and turn them into name and foreign records this data set of name and phone encounters is analyzed by contact tracer in contrast the Apple Google exposure notification API which I'm just going to call the exposure notification API has a process where no initial registration process happens and no PII is collected from the user but every day the device cryptographically generates a temporary exposure key this is used throughout the day to generate further rolling proximity identifies them these are the things that are broadcast nearby devices but the key thing is that if you know the temporary exposure key you can

generate all of the rolling proximity identifiers that would be distributed by that phone in that day and so this is what happens when you test positive you upload to a central server the last 14 days of exposure keys and then the central server just distributes those two keys to other devices it doesn't analyze them in any way it just it just shares them and then of all devices are constantly downloading this set of keys and then they use that to check if any of the generated proximity identifies match records in their local database and then they show a notification optionally the user can then upload that notification to the server to initiate a or more hands-on contact processing so

the fundamental goal here is to do all that while not making any extra information to an attacker or an observer this is a difficult challenge of course because the whole goal here is to exchange contact information with other users so one simple example that we need to watch out for is can I identify the same device multiple times so in this case we have cat unicorn and frog and we observe them at some place in time location one time t1 and then some point later if we can identify the same ID again so this the unicorn is still broadcasting the same identifier we know that's the same phone so it's very important that nothing that you

leak from the from the protocol stays constant over longer periods of time and similarly if we go back to that original location at a time 3 a different time later and we don't see the unicorn in the cat we do see the frog and the still has the same identifier that we know who's home and who is not we can track when people come and go from this from this location additionally if you have more than one identifier that you leak even if they both have short life times they need to both change on the same intervals so in this case we've seen two different identifiers from this device a one and the a identifier in the

B identifier and if a change is well B stays the same then we can use BB to link a and vice-versa we can even do that with a single identifier over time because if we only see one user's ID change at a time then we hope we deduct we deduce that there were the one that changed and so we can we can link them together and then if we even have a weakly identifiable piece of information like maybe which phone model they're running then then we can probabilistically say well they both change at the same time but one was on an old phone and one was on a new phone and we can tell even that their IDs

changed it they're in fact still the same person so our goal is to avoid these sort of problems very quickly a overview of how Bluetooth works because it'll be relevant to the issues that were going to discuss in this F so Bluetooth Low Energy was introduced as part of the Bluetooth 4.0 specification it coexists with classic Bluetooth and shares the same 2.4 gigahertz osm frequency buts otherwise completely different from them from the radio up in ble the 2.4 gig band is broken up into 42 megahertz channels it uses G FSK modulation which is Gaussian frequency shift keying it's basically a digital equivalent to FM radio in fact this whole thing works just like having 40 FM

radio channels it's short range and devices are identified by their six map six by MAC address which is much like Ethernet and is this Bluetooth MAC address where we see the same see our first identifiers like Ethernet Bluetooth devices have fixed MAC addresses and these are assigned by a central authority this is known as the public or the identity address and this would be a disaster for privacy because we just see the same device by it same MAC address all the time but fortunately bluetooth has an alternate address that you can use called your random private resolvable address and this is cryptographically generated from your identity address using a key known as the IR K identity

resolving key and basically if you know the identity resolving key then you can turn a public address into a into a private dress and vice-versa and this process is what pairing and bonding is about so when I pair two devices together they exchange their resolving keys and then in the future any random address that I see from that device can be turned back into its identity address and so that's how my head phones remember my my phone or something like that what we see with with covert safe is that it's not it's not it doesn't do pairing in bonding it's just it's just a quick exchange of data with no intent of making a future connection so it

entirely operates with the random resolvable private address and so there's no long-term tracking here but it's important that the MAC address even though it is for a short amount of time it doesn't change is the same interval as as other identifiers as we'll see so it can actually be used to link those identifiers together in blue if there are four roles and devices act in some subset of these four available roles broadcasters and short undirected advertising payloads round-robin on three specially reserved channels observers constantly rotate between these three channels and listen for these payloads allowing them to discover other devices apps can do both of these roles while in the background on iOS and Android

however the app level API for the broadcaster role is severely restricted on iOS but only while backgrounded and so the unfortunately this prevents its use for contact tracing apps but the Apple Google and expression notification API gets around this because it's a system app and can use these roles entirely for exchanging of data and so that is healthy the Apple Google notification API exchanges data so then finally we have additional roles peripheral and central so peripheral is a device that can be connected to and advertises its presence via the broadcaster and central uses the observer role to discover other peripherals and then connects to a peripheral once connected you hop over the 37 remain channels and these two

roles are unrestricted on Android and iOS even while back rounded so once the connections been established between a peripheral and central they exchange data everything called the generic attribute profile which is a client server where the server exposes a set of services each containing characteristics with metadata in the descriptors think of a server is the way that the features of the device are exposed so for example a temperature sensor would have a environmental sensing service and it would have a temperature or humidity or wind direction characteristic and so it's via GATT that the non-apple Google contact tracing apps work they expect exchange data over a characteristic value so at this point that's about all on you I'm going to do this

professionally but but there's not much that much water Bluetooth mostly it's about figuring out how the API is working and using that in a useful way and so when Travis F was released I thought I'd take a look and figure out how the payloads work and things like that and so the only if you have one takeaway from this talk and you're interested in Bluetooth the tool that you need to install in your phone is called NRF connect it's from Nordic semiconductor who a big player in the chipset market for Bluetooth and so this app lets you scan for nearby devices so it's the the observer role looking for broadcasters and we see here I can see

four devices and it it knows by their MAC address what what because of the central authority what make they are but it's actually um for the top and the bottom device it doesn't know so that's why it's got the Bluetooth logo but there is it one of these devices I promise you is is a Android device running covert safe and we know it's running covert safe because normally Android devices are actually in to bluetooth they don't they don't advertise so already already our presence is being made or made made visible so I'm going to expand the the Android device here and so the MAC address five five three II and we can see it's advertising payload so the kind

of weird thing here is it's telling us that it's made by Withings who manufacture like smart scales and health and fitness devices and it's got this extra data attached to the to the manufacturer we'd leave hex three one three zero three three it's kind of all ascii hex 0.029 8f range it's kind of weird and then it also has this service unit and so the service identify is what gets service this server will expose when we connect to it and if you look up the specification b8 to a be etc is um is the covert safe service so we're going to connect to this device and we'll see the list of services that it supports

NRF connect doesn't know what this service is but it'll show its characteristics and then we can issue a read for this for this characteristic value i've somewhat obscured the data here don't think it's that important that you can't see my my trace ID but this is what the the payload that's exchange by covert safe looks like and so the first thing they jumped out to me here and unfortunately this is a newer version of the protocol and it doesn't have this anymore we got fixed but the first thing is i'm down to me was to see my phone model name in this in this payload and so the phone model name is important because I

mean I've got a pixel to it's not that uncommon but it's not that common but some people have really unique finds and so this is actually strongly identifying piece of information for example if if I on that site a building and I can identify the three different phones that are in there then at any point in the future I can tell you which of those three people are currently home or not home and and as we discussed earlier I can use this to link other identifiers together as well and but why is it here eventually tracked down the the specification from the Singapore app that this is based on and they use this to calibrate the radio

signal strength which they use to make a distance calculation estimation but unfortunately this just doesn't work the this method of calculating distance from from signal strength is is highly inaccurate and my own experiments show that I can just turn my phone upside down on the table and make it look as if I have jumped you know to the other side of the room but remember that the official documentation for koban save says that the threshold is 1.5 meters for 15 minutes but by having the phone differently in my pocket I could be either either side of that threshold despite sitting across the table from somebody so what we have here is is that the temp ID is this is the idea that

needs to change on a regular interval and the documentation said that this would change every two hours so let's test that so I work on micro Python in my day job and so that's the easiest bluetooth I know how to use because I'm familiar with it but it's quite easy to write a dual script to run on a on a dev board that they're constantly connected to it to my phone recorded that the the resolvable public address recorded that manufacturer data that we saw earlier and the device model and the temp ID payload so this is an old temp ID payload from them from the first version and so this is at 10:29 p.m. on the on

the night that covert safe was launched fun Sunday night and all good so we try again two minutes later as we expect the same the same information right but and again 10:44 10:59 and then very excited we're now two hours later one at one minute away from the from the expected rollover still the same payload ah still the same payload that's a problem this is obviously not rolling over on a two-hour interval as the as the specification said and it's worth noting that's two hours in Australia but the protocol actually says it's supposed to be 15 minutes for the obvious reason of keeping the identity identification interval as short as possible so again a bit later

at 114 and then again at 821 in the morning so something's clearly not working here and then the phone is Rio Tinto fireball so I rebooted the phone a bit later and as we see the identifier now changes and interestingly so does that manufacturer data so if we go back and forward both both pieces of data changed so yeah at this point it's like well there's something not cook something not right here but while we're also looking at in RF Connect earlier we saw in addition to the covert safe service there were these other services and one of the fields that you get out of these other services is the device name and so here it says pixel 2 which

is the same as the phone model but it turns out this is actually controlled by the user and so a lot of people have this set to for example Jim's pixel 2 or my awesome new phone because this is the identifier that shows up in your cast area or something like that and so it's worse than the phone model because it's actually potentially name identifying but it's also if the users set it to anything other than the device model then it is potentially completely unique and and fixed on iphone the story's a bit different and I encourage everybody if you haven't seen it to read this Apple ble research because iPhones do actually give away a lot of additional

information as well so let's look into what's why these identifiers are not changing it's clearly a bug here so at this stage the source code had not been released but the source code for the Singapore out that this is based on had been released so the first place to look is the manufacturer data why why are those three additional ascii looking bytes ask your hex looking bytes appended to the manufacturer payload and so i found the code that starts the advertising process amazingly that on the first line there is one of the only comments in this entire code base and this all looks fine every time we start advertising and I've checked in other places that this happens every few

minutes we generate a new data payload so first of all we generate some random data and that is those three bytes that we see it's a pretty strange way of generating three bytes of random data but it actually explains why there hex values because it's a random uard that's been converted to a string totally a string of hex values we take off a few bytes off the end of it and then we append that into the manufacturing data and this thousand and twenty three in the middle is is Withings as an effector ID I have no idea why they're using that so that'll that'll looks fine we should be getting a new identifier but instead

so I disassembled the Australian app and this is the exact same code this is actually the the when the open source was released instead but the disassembly showed the same thing but notice the difference is that where we used to just always generate data we now only do it if data is null I doubt if and data is a member of this class and that class lives for the last time lifetime of the app so this code has been changed somehow to always read you always use the same identifier I assume somebody thought this was an optimization or maybe this was fixed in the Singapore code after the Australian code was forked or something like that but but

that's what's going on and then the next thing is why is the temp ID not changing so this is the code that handles a read of that characteristic value so we get an incoming read request and we check that we have a valid temp ID which is the checking if the context is valid and then there's this map a read payload mouth of caches the payload by the address and this is pretty strange because what it actually does is completely recompute the payload and then try and get an entry from the cache and if it's not there at stores there's new value but if there is an entry then it throws away the new value that it's

just generated and you is the cash value instead and this cash is done by the device address and then finally when a right happens later when we write back our own temp ID to the to the device we call save data saved and then saved out of a removes this entry from the cache and so this is the hint is that although phones are always used they're resolvable random private address my little dev board running market Python is actually using a fixed address so almost completely by accident I found this and immediately if I change my device to use a random address then then the problem went away but an attacker can can can choose that and then use

whatever address they like so they can take advantage of this so the code was working in terms of fetching new temp IDs but but an attacker had a way to control it and make it always see the same one and it's worth noting that an attacker doesn't have to be one device an attacker can be you know a whole range of $5 devices all running blood hit scanners and spread out over a number of locations and they can all share the same MAC address if they want and they shouldn't but they attack I can do that so this is I guess where it got interesting I tried to figure out what to do about this

because because this felt important to me but with no previous background in security I didn't know where to start this was a difficult and frustrating process I started looking for official and unofficial contacts I must have written the same email about 10 times before I wrote a doc in Google Docs and started sharing that with anybody I could find anyone vaguely connected to government ité cybersecurity or the covert safe project friends of friends who I knew worked at at companies that were associated with this project and things like that and nothing like this was this was astounding like odo just even imagined to reply from the official addresses but just just nothing it took me seven days and in a very

direct contact with through someone who knew someone who worked at the senior of the DTA and I finally got an SMS and then you know I made them aware that I wanted to talk about these issues and whatever and then that evening I spoke to them on the phone and they still hadn't read the document but then the next day confirmed that their team had received the document several days earlier so it doesn't it didn't feel to me that I mean they had other priorities right they shipped an app in in three weeks or you know there's a small number of amount of time and then it must be very hard to triage reports on it and honor

after a launch to you know the target of several million Australians but it didn't feel to me like these issues were serious and unfortunately I was excited when when a an update was released later that night but it only changed the graphics and the status icon not a single fixed with a bit Bluetooth protocol or any security stuff and then finally these issues were fixed ten days later so several weeks after after launch this this needs to be better so for next time I'm sure everybody who's in this this meetup knows this already but they needed to be a security contact at launch they did later add a security contact but it was called support at and

so I think that was probably a little bit confusing but finally was changed to be security at private safe and the source code should have been released before the launch even for public analysis and these sort of bugs could have been found one of the most frustrating things for me over the past eight weeks has just been coordinating the bugs because I made a bit of a fuss at the start I became the person that people wrote to you so all sorts of random people have reached out to me to talk about bugs and covert safe and I've sort of been the one that's coordinated getting them investigated and getting to the bottom of the Bluetooth issues and

stuff like that and then and then using the content that I'd made at ETA to get them looked out there should be an SLA on responses like if you send an email to security yet you should get an email in 24 hours and they should start talking to you about disclosure and and although you know sensible things that happen in a in a security incident service there should be a bug grantee and then services like poke cry out or disclose or hacker one I think the other one is golden and from the start this app should have engaged with experts there are there are amazing people in Australia you know people over NASA Teague who you know are so you know

cryptography and security experts and things like that but also that other things like like forming a community and how to engage with open-source and stuff like that there are there are really great people they prepared that they could have spoken to and and people with budget experience people with a lot more Bluetooth experience than me who who could have made this a bit more a little bit there's things that you've never bought to test for and they and that would have been really good advice to have received so the phone model that I mentioned earlier that was part of the payload I wish I could say that was fixed by simply removing from the payload and this this took a little bit

longer to finally um you know in a much later update however instead they implemented a vastly more complicated payload encryption scheme they're not even going to try to explain because I'm not a cryptographer but I highly recommend that you look at Vanessa Teague's blog at the URL here and on a personal note I'd like to public knowledge how amazing it's been to work with her and her team she was one of the first people I reached out to at the beginning when I when I had exhausted all the obvious government contacts and stuff like that and being able to watch them analyze the encryption changes and just talk to them about the sort of stuff it's been absolutely wonderful and

Eleanor who we heard from earlier tonight was was one of those people which was really cool and related to this the this encryption change it unfortunately broke the iPhone app and so the iPhone app became unable to do one of the directions of the of the exchange so it only worked in central to peripheral not peripheral to central because of the way they changed the size of the payload and then and the MTU exchange was not done properly and related that there was this whole open question at the time about does the iPhone even work especially in the background and I'd like to shout out the excellent work by Richard Nelson and John Evershed here who did a lot of work

to figure out exactly didn't work and how to fix it and then it took an even longer for those fixes to get applied however I'm excited to say that as of the update that came out this morning version 1.6 it seems like the iPhone probably for the first time actually works well locked and in the background this has got nothing to do with being Apple's fault or problems with older models or antennas it just just needed a few fixes and some people did some really great work to get to go to the bottom of that on the topic of the iPhone just kind of on a lighter note well a serious bit but it's a bit a

serious issue is that while we were investigating the iPhone code we were looking at the the switch code that was released and and this was truly the single version - and I sent this line to Richard for a completely unrelated reason and he answered my question about what it was doing in video he also said well what if menu data is fewer than two bytes like it's trying to take a slice of a thing that it's is assumed to be at least two bytes long and turns out that manufacturer data can be anything you like you don't have to set a manufacturer ID and Rich's written about padded here and you should read that and

I don't think I have time to play the video but very within about 15 minutes of discovering this I had a little Bluetooth beacon that I had in my drawer and he pushed the button on that and any iPhones nearby immediately terminate the covert safe app and so became very easy to build a the covert safe blocker and so that actually got fixed really quickly haha they got a richard got a spot on on sunrise and on the TV on the telly and yeah they did respond a lot more to that and i think it was good that we already had established the contacts with the DTA through the other bugs but yeah it was good to leverage

that so through the a lot of a lot of new friends that I've made in this process and somebody introduced me to person named Alan - at the Australian National University and and he had independently discovered I think all of the issues that we've talked about so far but they said I'll you be interested in changing him and and he had this interesting thing that he just noticed and that between the two of us we then spent a large chunk of Linux for weeks investigating this further he's his works amazing is his yeah the discoveries that he's made have been absolutely fascinating so remember at the beginning I was talking about this this public address and private private

address and the resolving key that's used to convert between them and so once the pairing process happens you you can then permanently identify that device by its identity address so you need to make sure that you can't pair with covert safe and you may have noticed if you've installed a later version of covert safe that there's a message on the home screen that says covert safe does not send parry requests and so that's Alan's fault I guess so now this is what the CVE is all about so normally if you're familiar with how pairing works on a phone on a Bluetooth device you get a prompt saying please enter this code or is this the device

you're trying to connect to but if the user would have clicked yes to that then they've now expose their that are okay and their identity address and they become permanently trackable but what Alvin discovered is that you can make this happen silently on Android so this is a quick demo of how this works so from NRF connect I can initiate the pairing process to an app running to a phone running covert safe and covert safe pops up and says would you like to pair and so hopefully a user would not click on that but but they might and here's the iPhone equivalent it's pretty convincing in at the time the iPhone app had to be in the foreground to work so

that you know there might have worked but I realized that of course you can control the text on here which is why it says covert safe rather than you know anything else and then I realized that you can turn off what's the man in the middle attack protection which which is why there's the passcode shown here so we had a pretty convincing request and if the user clicks pair then it's then it's all over but our one figured out how to make it happen silently and so the way this works is rather than sending a pairing request what you do is you pretend that the read required more authentication so the attacker on the right connects to

the the phone on the Left running covert safe in central role and oh sorry sorry other way around the attacker says that it is running covert safe as a peripheral the central on the Left connects to and attempts to read the tracing characteristic and then the attacker says are you don't have permission to that characteristic and so the central says well I trust you because I I connected to you so I'd like to pair with you and then the peripheral says yep but but no passcode none of that nonsense and so the central says sure no worries he's my okay and then it's all over at that point you can now permanently identify that device but

what do you do with an eye okay like how do I use that to track the device in the future like what if they uninstall the app or whatever it turns out the phones will always respond to a ping on their identity address so once you know their I okay you've once off get their identity address and now you can result you can ping it so I can always I can always ask is this device currently near me which is enough to do all of the the attacks that we've talked about so far but what else can you do with an identity address and so it turns out somebody left a very very helpful two

star review in the Play Store two days after launch I'd love to know what they think a one star review deserves but yeah this CVE is it's called blue frag and it is a heat vulnerability in the system Bluetooth service on Android in the way that it does packet reassembly just like just like I Pete you do Bluetooth packet packet fragmentation and all you need to know is the identity address of the phone to initiate it we that that page that was linked to has a demo way to reproduce the exploit and as you can see it works so they don't publish the full exploit which has got a um a rope chain to code execution

in a system service but we were able to demonstrate that at least it worked for crashing the service but also there's a demo that allows you to leak data out of memory and things like that and that that all works fine so this affects only versions of Android up to 9.0 but that's still the vast majority of Android phones out there but then finally one more thing that you can do not just with the identity address but because we've successfully paired with the phone is that after you've done that exchange you can then tell Bluetooth oh by the way I'm a keyboard now and the phone will happily then allow you to be connected as a keyboard and send arbitrary key

presses and remote control of the phone and we've tested this with keyboards and also with headphones and sets and you can do that you can play pause the music and all that stuff extremely fortunately I it doesn't also let you access the call log or the contact list that will prop up another another pairing prompt but it's just another pairing prompt right in here so it's there's a social engineering side to that so this is pretty scary um and yeah maybe it's a maybe it's a fairly targeted attack fit but this this existed Inc I would say from-from launch and was fixed two weeks ago we in fact Alan and I weren't able to come up with

it with a fix for this but the the Cova save team didn't implement a fix using reflection basically on Android the the library that you link against the SDK that the talks the system services is itself written in Java so you can use reflection to modify its state and so they trick the Android SDK into thinking that the pairing has already happened silently and then it doesn't try and do it again if you think this sounds pretty dodgy yes it is but it's actually a really common thing that that outs do on Android and Google have a whole process for how to allow apps through the store even when they're doing these sorts of the answers got

great listing the fix seems to work which is really good and so that that was released in version 1.0 point 18 which was just over two weeks ago we do have unrelated to this particular issue we do have another way of getting the identity dress but we haven't released the details of that yet but it was actually it's um is actually fixed today so that's that's good so they won't go into the details of that it's really important to ensure that you get the updates to this app to get these fixes as several fixes we've talked about plus the functionality fixes to iPhone I should mention as well that Vanessa takes team looked at light into

encryption and there was a bug associated with the way that works on Android with concurrency and that could lead to corrupt IDs and and fairly de três and possibly makes the app stop working properly that was also fixed today however what we've discovered is that the app doesn't necessarily auto update and we think the reason for this might be something to do with the fact that it's running in the background but it's very very active and so in the same way that auto update won't happen on your podcast player while you're playing a podcast I think possibly that that Google Play services is not Auto updating covert save cuz it can't find a time to schedule the update so it's

extremely important that you manually check in the Play Store or an apple in the Apple App Store for any potential updates and install them manually so as of today the latest version of Android is one point 0.28 and for iPhone it's version 1.6 so check yourself but also encourage your friends and family to check too so that's it I think the best outcome here is that [Music] the phone name is still addressed in some way so there was a fixer to a couple of weeks ago whether he for new users only in registration they encourage the user to change the phone name to Android phone but they say something like please make this anonymous and I think that might in fact

trick people will confuse people into entering something that is unique in the end because it's because it's got a bit hard to explain what the what the actual goal of this is but unfortunately this change only applies to people who are new to the app and so they don't need the people who only installed in the last couple of weeks so for now your phone name is still very much exposed to anybody who can find you with this app additionally there are some something needs to be done about the auto updating on Android I know the DJ is aware of this and and can confirm what I was reporting and there are some open questions about how the encryption

scheme works in terms of the payload encryption in terms of whether or not additional information is leaked from there and I encourage you to follow along at Vanessa's blog github.com /bt slash contact tracing and finally of course we still have no idea what happens on the server how is this data collected how does the encryption scheme for temp IDs work who has access to the data there's beans in vague rumors around you know only state based contractor contact tracers can access state-based data and things but that doesn't appear to be aligned with the way though of what we've seen and so I would love to see the server side open sourced and and the community engaged on

making that better too but fundamentally the issue with covert safe is that it's based on this GATT server based exchange and Bluetooth Bluetooth frameworks on phones were never designed to be operated in a mode where they connected to any random device around that advertised the right service so it's kind of like a higher risk option for how to implement an app like this and my feeling is that in in chasing this sort of centralized model of a very you know hands-on contact tracing they've missed out on privacy and the basic functionality and reliability that the Apple Google notification would have would have provided and so I really feel that when the Apple Google hood Google API was announced at the very

start of April that that the sensible thing to done would have been to immediately jump on board with that and like Germany they would have an app available already that that is based on this API and works really well on on as many devices as possible so that's all I have we'd love to hear questions and please engage email and Twitter and on the slack afterwards well it's great yeah very good very very busy on the slack actually during your talk a lot of it was actually a lot of questions for a lot of like support and a lot of ongoing commentary yeah yeah a couple of questions I asked for questions everyone there was was very impressed with all

the work he did there was one question in particular I'm not quite sure if you you it's been answered but it's in it so the blue frog volubility all Android devices passed candy packs for this or their limitations on some devices that that can't updates in the latest Android channel or whatnot right now it's only patched in Android ten there's a if you read if you read the the details by the author there is something in Android nine but I think I think they found a workaround for that or something um yeah basically Android ten safe but Android 9 and below have issues here okay and then I was um I was just wondering commenting on how much time you spent

and and I think I think maybe added to that and said can you ask him if he sent DT an invoice for his hours as a lot of time then we're in curve in 1908 right like it's absolutely on touch racing is really important and absolutely kind of my frustration here is that I've had I've had some very interesting conversations of people over the last eight weeks people from all sorts of different areas and and I need to be really clear I like I'm a computer program who's interested in how radios work and I'm not an epidemiologist and I'm not a contact race or a politician or any of that right but from a purely

yeah and so there's a really good question so settlers are asked a really good question in a conversation piece about should we be letting Apple and Google set the policy for how we do contact tracing and yeah like no we didn't we didn't vote for Apple and Google we we you know for weather or sweet right at our government and and we should be letting them set the policy but unfortunately in this case the technical the technical side of this is really important to and the approach taken by crowded safe is not it's not the it's not the best and then and and we trade it off we trade it off having a thing that worked well for a thing that

didn't really work that well at all and we're very lucky in Australia because because because thanks to the amazing public health teams in the state based public health teams and a lot of very very dedicated and passionate people that the pandemic has been really well managed in Australia and so to a certain extent I'm happy to help right like I'm happy i I genuinely can walk away from this feeling that thanks to this work Cova tape works better it's not the disapp I would've designed and it's not the a pilot chosen but other people reached it in Jeff weary and John and Vanessa and and then countless others have done really good work here and it's

and so very very grateful to all of those people yeah it's true I've not done a lot of work in the last eight weeks there's one more question here from Casey who actually said when you got connected to DTA what was the appetite for future security feedback like were they happy encouraging or do they see more inconvenience not wanting feedback for future engagements I guess it's harder I mean I don't know these people and and so you know conversations over email and I know a bit tricky I did I did have a very very poor interaction very early on with somebody from one of the the third party firms who ordered the app and yeah you know I was told

something like you're not the only kid with a disassembled oh and they're too busy for polite emails you know yeah and but the DJ themselves yeah I think the thing I would love to see in the future is what I said earlier respond to emails quickly and acknowledge that the bugs exist and but more importantly encourage the discussion around what to do about these bugs so like I understand things take time to fix although although a lot of them were very small one line changes but engage on things like disclosure and what the responsibilities are and things like that I mean based on the earlier comment I would have really loved a bug bounty and not just because I want to

not because I want the money for it I it's because by establishing something like a bug bounty you are forced to think about what the process for how people report issues is so different thank you as well and appreciating the work that's being done yeah yeah and I assume it's Casey from background babies Casey and something like that is it's a streamline way to get that right without even you know just do the easy easy obvious thing yeah hope that answers question awesome and I think there's there's lots of people just sort of chatting now and agreeing with you in the in the in the chat probably if you have some time after the talk to head

over to the chat and talk to people I was a great presentation yesterday thank you very much it's a great way no no thank you thank you very much buddy to be fair me Oh Vicki thank you say