1 00:00:00,000 --> 00:00:16,720 Translated by Juho Halttunen (ITKST56 course assignment at JYU.FI) 2 00:00:16,720 --> 00:00:19,670 Hei, kaikki ja tervetuloa esitykseeni, joka on Bluetooth 3 00:00:19,670 --> 00:00:25,470 altistusilmoituksen turvasta. Tämän esityksen voi vetää yhteen: 4 00:00:25,470 --> 00:00:30,720 ensiksi altistumisilmoitukset Goolen/ Applen API:ssa ovat todella turvalliset ja 5 00:00:30,720 --> 00:00:36,190 patteri ystävälliset. Ja käyttää vain Korona varoitussovellusta. 6 00:00:36,190 --> 00:00:39,420 Tämä voi olla sekavaa monille teistä, jotka kuuntelavat sillä olen 7 00:00:39,420 --> 00:00:43,710 työskennellyt Bluetooth hyväksikäytön kanssa jo aikaisemmin ja aina 8 00:00:43,710 --> 00:00:47,710 opettanut, että Bluetooth ei ole turvallinen. Joten saatatte miettiä 9 00:00:47,710 --> 00:00:53,127 kuinka tämä käy järkeen. Miksi olen täällä nyt kertomassa, että ilmoitukset ovat turvallisia? 10 00:00:53,127 --> 00:00:59,860 Koska nyt on pandemia ja sen sijaan, että kritisoitaisiin ratkaisuja, meidän tulisi 11 00:00:59,860 --> 00:01:06,170 etsiä ratkaisuja, jotka toimivat. Joten sen sijaan, että paasaisin, teen jotain 12 00:01:06,170 --> 00:01:14,190 mikä auttaa kaikkia. Ensimmäinen kysymys, jota useat kysyvät on, että tarvisemmeko 13 00:01:14,190 --> 00:01:21,750 edes älypuhelin applikaatiota pandemiaa vastaan? No mitä voimme sanoa, on joulukuu 14 00:01:21,750 --> 00:01:26,063 ja altistumisilmoitukset esiteltiin kesäkuussa ja meillä on vielä korona. 15 00:01:26,063 --> 00:01:35,379 Joten se ei auttanut täysin ja se ei todennäköisesti pysäytä koronaa. Mutta 16 00:01:35,379 --> 00:01:41,340 katsotaan asiaa toisesta kulmasta. Ensiksi mikäli sinulla appi ja saat 17 00:01:41,340 --> 00:01:45,859 varoituksia, voimme tehdä tarkempia testejä ja se on erittäin tärkeää, koska 18 00:01:45,859 --> 00:01:50,820 jopa nyt olemme alhaisissa testilukemissa. Emme voi testata kaikkia. Testaamme vain 19 00:01:50,820 --> 00:01:56,840 ihmiset, joilla on oireita. Ja se on ongelma, sillä ihmiset voivat tartuttaa 20 00:01:56,840 --> 00:02:01,789 muita ennen oireita ja voivat tartuttaa oireettomina. 21 00:02:01,789 --> 00:02:07,569 Nämä kaikki voidaan löytää korona varoitus sovelluksella. Ja se myös voi 22 00:02:07,569 --> 00:02:11,470 rohkaista manuaalista jäljitystä, koska terveysviranomaiset eivät voi kontaktoida 23 00:02:11,470 --> 00:02:17,310 manuaalisesti enää jokaista. 24 00:02:17,310 --> 00:02:22,860 Joten sinun täytyy kysyä ystävältäsi jos sovelluksesi muuttuu punaiseksi ja siten 25 00:02:22,860 --> 00:02:28,280 voit löytää tapauksia vaikka he unohtaisivat kertoa. Tämä ei tietenkään 26 00:02:28,280 --> 00:02:33,790 korvaa käsienpesua, maskin käyttöä, etäisyyden pitämistä ja niin edelleen. 27 00:02:33,790 --> 00:02:39,970 Joten tietenkin nämä täytyy tehdä. Mutta mikäli edes ilmoitat muutamalle 28 00:02:39,970 --> 00:02:44,739 ihmiselle, voi jokainen estetty infektio pelastaa elämiä. Joten se on erittäin 29 00:02:44,739 --> 00:02:53,070 tärkeää, että on tälläinen appi. Ja seuraava kysymys on, että onko 30 00:02:53,070 --> 00:02:57,110 jotain parempaa kuin Bluetooth? Jos haluamme etsiä ratkaisua sovelluksen 31 00:02:57,110 --> 00:03:03,410 rakentamisesta, joka tukee altistumis- ilmoituksia ja estää tartuntoja. Kuinka 32 00:03:03,410 --> 00:03:09,730 voisimme rakentaa sellaisen? Tarvitsemme jotain, joka mittaa lähistöä tai lokaa- 33 00:03:09,730 --> 00:03:13,940 tiota ja kännykässä meillä on useita teknologioita, jotka tukevat tätä. On 34 00:03:13,940 --> 00:03:19,571 GPS, Bluetooth, LTE ja 5G, Wi-Fi, Ultra- wideband, josta et ehkä ole kuullut 35 00:03:19,571 --> 00:03:23,620 on audiota, on kameraa. 36 00:03:23,620 --> 00:03:31,260 Voisit käyttää jokaista näistä. Ja syy miksi voit mitata näillä etäisyyttä tai 37 00:03:31,260 --> 00:03:36,980 suuntaa on se, että fyysisellä tasolla sinulla on aaltomuoto. Ja tämä aalto- 38 00:03:36,980 --> 00:03:41,540 muodolla on ensinnäkin amplituudi ja etäisyyden kasvaessa se pienenee. 39 00:03:41,540 --> 00:03:45,230 Jolloin tämä tarkoittaa, että signaalin voimakkuus on heikompi ja sinulla on 40 00:03:45,230 --> 00:03:49,651 vaihe joka vaihtuu etäisyyden kanssa. Joten nämä ovat ominaisuudet, jotka 41 00:03:49,651 --> 00:03:54,120 voit mitata fyysisellä tasolla, raa'assa aaltomuodossa. Ja osa tästä tiedosta 42 00:03:54,120 --> 00:04:00,070 lähetetään ylemmille tasoilla. Ja ilmeisin näistä on signaalin voimakkuus, joten 43 00:04:00,070 --> 00:04:04,260 se on fyysisen tason ominaisuus, jonka voi mitata. Se myös lähetetään ylemmille 44 00:04:04,260 --> 00:04:10,320 tasoille useimmissa protokollissa yksin- kertaisiin asioihin kuten Wi-Fi signaalin 45 00:04:10,320 --> 00:04:14,540 voimakkuuden arvioimiseen, jotta laite voi määrittää voimakkaimman Wi-Fi aseman 46 00:04:14,540 --> 00:04:19,139 ja niin edelleen. Joten signaalin voi- makkuus on erittäin olennainen ja se 47 00:04:19,139 --> 00:04:25,479 lähetetään ylemmille tasoille useimmissa protokollissa. Voit itseasiassa tehdä 48 00:04:25,479 --> 00:04:30,240 erittäin tarkkaa mittausta mutta tarvitset raakaa aaltomuotoa ja tätä ei ole tuettu. 49 00:04:30,240 --> 00:04:34,460 Jotkin piirit voivat tätä tehdä. Tarkkaan mittaamiseen sinun täytyy lähettää 50 00:04:34,460 --> 00:04:39,080 signaali ja lähettää takaisin ja mitata edestakainen aika signaalista. 51 00:04:39,080 --> 00:04:43,800 Ja tätä esimerkiksi tehdään siinä, kun päätetään voiko Applen kello 52 00:04:43,800 --> 00:04:49,289 aukaista MacBookin. Ja kolmas vaihtoehto on se, että voit mitata 53 00:04:49,289 --> 00:04:53,939 signaalin suunnan. Tämä tarvitsee itse- asiassa useampaa antennia, jotta kolmio- 54 00:04:53,939 --> 00:04:59,460 mittaus voidaan tehdä signaalille. Tätä ei tueta useimmissa piireissä, sillä 55 00:04:59,460 --> 00:05:03,930 pelkästään piirin tukea ei tarvita, vaan myös useampaa antennia. Tämän avulla 56 00:05:03,930 --> 00:05:09,199 voit esimerkiksi iPhonella saada AirDrop suunnan toiselle iPhonelle ja niin 57 00:05:09,199 --> 00:05:14,349 edelleen ja voit nähdä signaalin suunnan omasta laitteestasi. 58 00:05:14,349 --> 00:05:21,770 Mitä tulee lokaatioon niin ilmeisin valinta monille on GPS. 59 00:05:21,770 --> 00:05:27,120 GPS:ssä signaalit lähetetään satelliiteilla. 60 00:05:27,120 --> 00:05:32,300 Nämä kiertävät yli 20 000 km päässä ja ovet todennäköisesti erittäin kaukaisia. 61 00:05:32,300 --> 00:05:36,680 Ja ennen kuin signaali saapuu puhelimeen siinä on paljon vaimennusta. 62 00:05:36,680 --> 00:05:42,360 Joten vaikka siinä olisi vain muutama rakennus tai olisit sisällä 63 00:05:42,360 --> 00:05:45,960 mutta jo muutama rakennus ovat tehokkaita estämään 64 00:05:45,960 --> 00:05:52,099 paikantamisen ja sisätiloissa ei se toimi lainkaan. Sisätiloissa meillä 65 00:05:52,099 --> 00:06:01,360 on suurin riski tartunnoille, joten GPS ei ole hyödyllinen tässä. Seuraava 66 00:06:01,360 --> 00:06:08,979 vaihtoehto signaaleille olisi LTE, 5G ja niin edelleen. Tässä on siis lähettäjiä ja 67 00:06:08,979 --> 00:06:13,590 voit oikeasti vaihtaa soluja puhelimessa. Joten tässä meillä on yksi solu ja kun 68 00:06:13,590 --> 00:06:18,889 liikumme liikut toiseen soluun ja tämä on liikettä mitä teet ja solujen vaihtelua 69 00:06:18,889 --> 00:06:25,020 voidaan mitata. Tätä on oikeasti käytetty puhelimien toimittajien toimesta Saksassa 70 00:06:25,020 --> 00:06:30,300 kuinka tehokkaita sulkutoimenpiteet ovat. Tämän avulla voit nähdä, sitä 71 00:06:30,300 --> 00:06:36,931 liikkuuko ihmiset enemmän vai vähemmän kuin ennen pandemiaa. 72 00:06:36,931 --> 00:06:41,400 Kuinka tehokkaita nämä säännöt ovat ja niin edelleen. Nämä eivät ole tarkkaa sta- 73 00:06:41,400 --> 00:06:49,650 tistiikkaa mutta on hyvä olla laaja- alaista statistiikkaa ihmisistä mutta 74 00:06:49,650 --> 00:06:59,969 se ei ole hyödyllistä siinä ketä tapasit. Toinen vaihtoehto on Wi-Fi mutta 75 00:06:59,969 --> 00:07:05,309 siinä on toinen ongelma. Wi-Fi on riippuvainen tukiasemista ja niin edelleen 76 00:07:05,309 --> 00:07:09,559 Voit skannata tukiasemia ja tottakai puhelimet tukevat, että teet oman 77 00:07:09,559 --> 00:07:13,759 tukiaseman ja sitten skannaisit sitä 78 00:07:13,759 --> 00:07:18,259 mutta silloin, et kuitenkaan käyttäisi omaa Wi-Fiä sillä voit liittyä Wi-Fii tai 79 00:07:18,259 --> 00:07:24,309 luoda sellaisen. Tämä ei oikeastaan toimi. On olemassa valmistaja spesifisiä 80 00:07:24,309 --> 00:07:28,469 lisäyksiä, jotka mahdollistavat etäi- syyskien mittaamisen mutta niitä ei 81 00:07:28,469 --> 00:07:33,999 ole useimmissa laitteissa, eikä se ole saatavilla APIen kautta. Joten ei voida 82 00:07:33,999 --> 00:07:41,169 käyttää Wi-Fiä, sen toiminnallisuuden vuoksi ja kuinka se on rakennettu puhelimiin. 83 00:07:41,169 --> 00:07:45,439 Paras tapa tarkkaan mittaukseen on audio, koska vaikka ei olisi pääsyä piirille tai 84 00:07:45,439 --> 00:07:52,949 APIin, niin se mitä on on lähettäjä tai puhujantapainen ja mikrofoni 85 00:07:52,949 --> 00:07:58,879 ja ne lähettävät aaltoja ja niitä voidaan mitata. 86 00:07:58,879 --> 00:08:04,479 Ja vaikka ilman alemman tason pääsyä sovellustasolle jollekkin piirille sinulla 87 00:08:04,479 --> 00:08:09,379 voi olla tarkka mittaus. Mutta tässä ongelmana on se, että tarvitaan 88 00:08:09,379 --> 00:08:13,960 pääsyä mikrofonille. Joten appin pitäisi olla ajossa etualalla koko ajan mikrofonin 89 00:08:13,960 --> 00:08:18,069 kanssa. Tämä kuluttaa akkua ja mikä pahinta, se tarkoittaa että sinulla on 90 00:08:18,069 --> 00:08:21,770 pysyvä vakoilija taskussasi. Sinulla olisi valtiollinen appi, joka kuuntelisi 91 00:08:21,770 --> 00:08:28,409 mikrofoniasi kaiken aikaa. Ja kovin moni ei tätä halua. Sitten vielä on 92 00:08:28,409 --> 00:08:31,770 sellainen mistä et ole todennäköisesti kuullut. Ultra-wideband, joka on 93 00:08:31,770 --> 00:08:36,450 tulossa uuden generaation iPhoneen ja tähän mennessä sitä ei ole käytetty 94 00:08:36,450 --> 00:08:40,850 kauhean monessa. Se on jotain, joka voi myös selvittää signaalin suunnan 95 00:08:40,850 --> 00:08:46,040 antennien avulla ja se voi näyttää missä suunnassa toinen laite 96 00:08:46,040 --> 00:08:51,180 sijaitsee. Mutta koska se on vain muutamassa laitteessa niin se ei 97 00:08:51,180 --> 00:08:56,440 ole hyödyllinen yleisesti. Se on kiva feature mutta olemme pari vuotta 98 00:08:56,440 --> 00:09:03,190 liian aikaisessa. Ja tietenkin voisit käyttää kameraa samalla tavalla kuin 99 00:09:03,190 --> 00:09:08,060 mikrofonia mutta tallentaa kaikki kameralla mutta se ei ole todennäköisesti se mitä 100 00:09:08,060 --> 00:09:13,880 halutaan. Joten todennäköisesti voisit käyttää sitä paikkoihin lukittaumiseen. 101 00:09:13,880 --> 00:09:19,140 Voisit skannata QR koodin ja sen jälkeen rekisteröidä ravintolaan tai 102 00:09:19,140 --> 00:09:23,710 että tapaat ystävisiä. Tämä olisi ideaali käyttö kameralle ja olisi hyvä 103 00:09:23,710 --> 00:09:31,580 lisä varoitus appeihin. Ja mitä on jäljellä niin on Bluetooth. 104 00:09:31,580 --> 00:09:38,380 Bluetooth itseasiassa lähettää signaalit 2.4 GHz kuten Wi-Fi ja 2.4 GHz on iso 105 00:09:38,380 --> 00:09:44,600 ongelma, sillä siihen vaikuttaa vesi ja ihmiset ovat 60% vettä. 106 00:09:44,600 --> 00:09:51,590 Tämän vuoksi mitaukset ovat hieman epätarkkoja mutta 40% ihmisistä on 107 00:09:51,590 --> 00:09:55,910 tyhmyyttä. On myös ongelma, että ihmiset eivät käytä ollenkaan 108 00:09:55,910 --> 00:10:02,910 Korona varoitus appia. Se on vielä pahempaa. Ja mitä muuta on? 109 00:10:02,910 --> 00:10:08,160 Seuraava ongelma on, että sirut ja antenni positiot vaihtelevat. Eli 110 00:10:08,160 --> 00:10:12,780 oikeastaan sinulla on ongelma, että mittaukset eivät joka mallilla sama. 111 00:10:12,780 --> 00:10:18,820 Se saattaa olla sama signaali, mutta eri tulokset. Meillä on tähän ongelmaan 112 00:10:18,820 --> 00:10:23,090 mittauksien tulosten vaihteluun jotain. APIin on valmiiksi rakennettu 113 00:10:23,090 --> 00:10:29,240 virallisiin Google/Apple APIn, että ne lisäävät lähetystehon laiteperusteisesti 114 00:10:29,240 --> 00:10:37,380 ja niin edelleen, joka on hienoinen riski yksityisyydelle. Mutta kaiken kaikkiaan 115 00:10:37,380 --> 00:10:44,880 sillä on hyvä kompensaatio. Se on parempi käyttää mutta on hieman vähemmän 116 00:10:44,880 --> 00:10:49,120 yksityisyyttä. Jotain muuta mitä voidaan käyttää on aktiivinen datayhteys 117 00:10:49,120 --> 00:10:54,854 tietyssä ajassa mitattaakseen signaalin voimakkuutta. Mutta se on huonompi 118 00:10:54,854 --> 00:10:58,570 sillä aktiivinen datayhteys tarkoittaa, että dataa vaihdetaan kahden 119 00:10:58,570 --> 00:11:05,790 laitteen välillä mikä altistaa hyväksikäyttö riskeille. Hyväksikäyttö tarvitsee 120 00:11:05,790 --> 00:11:11,900 jotain datan vaihtoa ja tämä olisi riski turvallisuudelle. Ja yksi toinen asia 121 00:11:11,900 --> 00:11:17,060 on se, että voitaisiin lisätä kiihtyvyys- mittari. Riippuen siitä miten pidät 122 00:11:17,060 --> 00:11:19,971 puhelinta voidaan määritellä kiihtivyys- mittarin avulla onko se kädessä 123 00:11:19,971 --> 00:11:24,990 taskussa vai missä ja sen jälkeen kompensoida mittauksissa. Mutta 124 00:11:24,990 --> 00:11:30,864 ongelma on, että se voi myös määritellä mikäli juokset, kävelet tai kuinka monta 125 00:11:30,864 --> 00:11:35,590 askelta otat. Se on suuri riski yksityisyydelle. 126 00:11:35,590 --> 00:11:42,920 Viimeisimpänä on saapumisen kulma ja se on jotain mikä on 127 00:11:42,920 --> 00:11:47,940 ollut tuettuna Bluetooth 5.1 asti mutta se on optionaalinen feature 128 00:11:47,940 --> 00:11:52,060 bluetoothin spekseissä, joten missään puhelimessa ei sitä vielä ole. Joten 129 00:11:52,060 --> 00:11:59,100 ei voida tehdä tarkkoja mittauksia toisen laitteen kulmasta. Se on 130 00:11:59,100 --> 00:12:05,120 melko surullista. Joten kaikki mikä parantaa mittauksia Bluetoothilla 131 00:12:05,120 --> 00:12:12,240 on aina yksityisyyden, turvallisuuden ja akun iän kustannuksella. 132 00:12:12,240 --> 00:12:19,030 Joten jos mietitään kuinka se on tällä hetkellä tehty APIssa niin se on hyvin. 133 00:12:19,030 --> 00:12:23,670 Ja summatakseni paasausta technologiasta. Vaikka Bluetooth ei ole täydellinen, 134 00:12:23,670 --> 00:12:27,620 Bluetooth low energy on paras teknologia, mikä meillä on kaikissa puhelimissa tai 135 00:12:27,620 --> 00:12:34,261 viimeaikaisssa puhelimissa. Ja sen avulla voidaan tehdä altistus ilmoituksia. Joten 136 00:12:34,261 --> 00:12:41,870 vaikka Bluetooth ei olisi optimaalinen on se silti voittaja. Tiedän, tiedän Bluetooth 137 00:12:41,870 --> 00:12:47,394 on vaarallinen ja niin edelleen, joten keskustellaan siitä hieman. 138 00:12:47,394 --> 00:12:52,520 Oikeastaan vuoden 2020 aikana moni sanomalehti yritti ottaa yhteyttä ja 139 00:12:52,520 --> 00:12:56,530 sanoa "Hei, Jiska, olet ollut Bluetoothin tietoturvan kanssa tekemisissä, joten 140 00:12:56,530 --> 00:13:01,190 kerro meille on nykyinen kunto kuinka huono" Olin heille, että en halua tätä 141 00:13:01,190 --> 00:13:05,500 kertoa mutta Bluetooth on langaton proto- kolla, joka lähettää langattomasti dataa 142 00:13:05,500 --> 00:13:11,660 ja siinä on tiettyjä riskejä mutta niin on kaikessa muussakin. Ja tämän vuoksi 143 00:13:11,660 --> 00:13:15,300 he eivät sitä julkaisseet. Onhan se hieno otsikko julkaista: 144 00:13:15,300 --> 00:13:21,154 "Bluetooth on langaton protokolla datan lähettämiseen" Sitten he olivat: "Tiedätkö 145 00:13:21,154 --> 00:13:25,970 mitä en käytä altistumisilmoituksia sillä käytän vanhentunutta puhelinta, joka 146 00:13:25,970 --> 00:13:30,670 ei saa enää tietoturvapäivityksiä" Sen jälkeen olin vain, huh. 147 00:13:30,670 --> 00:13:35,010 Eli ei tietoturvapäivityksiä. Tuo ei ole Bluetooth ongelma. 148 00:13:35,010 --> 00:13:39,180 Tuo on ongelma kaikkeen, sillä mikäli selailet yksisarvisen kuvia 149 00:13:39,180 --> 00:13:45,920 internetistä tai saat sähköpostia. Ehkä pitäisi hommata uusi puhelin, jos 150 00:13:45,920 --> 00:13:50,570 on huolissaan puhelimen datasta. Ja toinen asia mitä ei kannata tehdä 151 00:13:50,570 --> 00:13:55,330 journalistille on kun he kysyvät niin kertoa "Sinulla on vanhentunut puhelin? 152 00:13:55,330 --> 00:13:59,390 Soitatko vain puhelinnumeroon, joka kuuluu puhelimelle?" Joten älkää keskustelko 153 00:13:59,390 --> 00:14:07,400 tälläistä sillä se on yleinen ongelma, eikä Bluetooth spesifinen. 154 00:14:07,400 --> 00:14:14,050 Toinen mikä on enenmmän spesifinen Bluetoothille on se, että voit tehdä 155 00:14:14,050 --> 00:14:20,241 matoja. Joten laite voi olla isäntä tai orja Bluetooth terminologiassa. 156 00:14:20,241 --> 00:14:27,140 Ja isäntä voi yhdistyä orjiin 157 00:14:27,140 --> 00:14:32,490 ja puhelin voi vaihtaa rooleja, mikä tarkoittaa, että se voi saada 158 00:14:32,490 --> 00:14:36,050 madon ja tulla isännäksi ja lähettää sen muihin orjiin ja orja tulee jälleen 159 00:14:36,050 --> 00:14:41,950 isännäksi ja niin edelleen. Joten se on levittyjä. Mutta jotta olisi hyvä mato 160 00:14:41,950 --> 00:14:46,727 pitää olla, jokin exploit, joka suoriutuu uusimmalla iOS ja uusimmalla 161 00:14:46,727 --> 00:14:52,600 Android versiolla ja oltava erittäin luotettava. Sen pitäisi olla erittäin 162 00:14:52,600 --> 00:14:57,790 exploit kaikilla järjestelmillä. Ja mikäli jollain tälläinen olisi, niin se ei ajaisi 163 00:14:57,790 --> 00:15:02,870 sitä tuhoamaan altistumisilmoituksia vaan myisivät hyvällä hinnalla. 164 00:15:02,870 --> 00:15:06,910 Korkeimmalla hinnalla tietysti, koska 165 00:15:06,910 --> 00:15:13,440 sinulla ei ole kauhean monia eettisiä huolia raportoinnin sijaan. Mutta tuo 166 00:15:13,440 --> 00:15:19,950 olisi skenaario tässä. Ihmiset myös sanovat, että "Laitan Bluetoothini 167 00:15:19,950 --> 00:15:24,230 pois päältä sillä se kuluttaa akkua" Mutta tiedätkö mitä, Bluetooth ei kuluta 168 00:15:24,230 --> 00:15:28,420 paljoa akkua, varsinkaan Bluetooth low energy. Joten Bluetooth Low Energy on 169 00:15:28,420 --> 00:15:36,120 teknologia, joka voi antaa virtaa jopa näin pienille laitteille. Joten jos sinulla 170 00:15:36,120 --> 00:15:41,510 on patteri, tämänkokoinen nappi- paristo ja sitten voi olla näin iso laite 171 00:15:41,510 --> 00:15:46,590 hieman suurempi kuin Bluetooth etsin, joka on tämän kokoinen voivat 172 00:15:46,590 --> 00:15:51,190 toimia tämän pariston avulla vuoden. Ja lataat puhelinta päivittäin ja sinun 173 00:15:51,190 --> 00:15:57,280 puhelimessa on paljon enemmän akku- kapasitettia kuin yhdessä nappiparistossa. 174 00:15:57,280 --> 00:16:01,540 Joten oikeastaan se ei kulutua akkua koska sinulla on yhteisiä siruja ja mikäli on 175 00:16:01,540 --> 00:16:08,150 Wi-Fi enabloitu silloin Bluetooth ei oikeastaan lisää tähän juurikaan. Toinen 176 00:16:08,150 --> 00:16:12,681 argumentti voi olla, että Google sekä Apple varastavat dataasi aina ja 177 00:16:12,681 --> 00:16:17,750 mikäli ne nyt tekevät jäljitystä se tarkoittaa, että ne varastavat 178 00:16:17,750 --> 00:16:22,900 dataa jo. Mutta oikeastaan altistumis API nimettiin uudelleen koska se on vain 179 00:16:22,900 --> 00:16:28,150 altistumisilmoituksille. Se ei ole tapaamislokia. Ja tämä tarkoittaa ,että 180 00:16:28,150 --> 00:16:34,970 API ei kerää dataa tapaamistarkoituksessa ja se on hyvä sekä paha siinä, että 181 00:16:34,970 --> 00:16:39,710 estävät keskitetyn keräyksen. Ei pelkästään terveysviranomaisilta 182 00:16:39,710 --> 00:16:43,750 vaan myös kaikilta heidät mukaan lukien. 183 00:16:43,750 --> 00:16:52,799 Joten siellä ei ole mitään datan keräystä. Joten siitä ei voi valittaa. Tämän sanomisen 184 00:16:52,799 --> 00:16:58,730 jälkeen voit ehkä kysyä, että sanoinko juuri että Bluetooth ei ole ollenkaan 185 00:16:58,730 --> 00:17:03,960 vaarallinen. Mutta tiedätkö mitä, Bluetooth on silti langaton protokolla 186 00:17:03,960 --> 00:17:14,669 joka lähettää dataa. Joten ehkä se on jotakuinkin vaarallinen. Joten 187 00:17:14,669 --> 00:17:20,949 mikäli katsotaan Applen ekosysteemiä, mitä siellä on kutsutaan jatkuvaksi frameworkiksi 188 00:17:20,949 --> 00:17:26,120 ja se tekee paljon asioita kuten, copy-paste AirDrop hand-off ja niin. 189 00:17:26,120 --> 00:17:32,929 Joten siinä on paljon dataa vaihdossa. Ja kaikki se jatkuva osio tässä, se kaikki 190 00:17:32,929 --> 00:17:40,580 toimii BLE mainostuksella ja sitten Wi-Fi tai AWDL datan vaihtoon. Joten 191 00:17:40,580 --> 00:17:45,990 on paljon BLE mainostusta menossa, mikäli käytät iOS ja muita Applen 192 00:17:45,990 --> 00:17:51,440 laitteita. Ja altistumisilmoitukset ovat vain pieni lisäosa siihen. 193 00:17:51,440 --> 00:17:55,419 Joten se on vain yksi feature joka pohjautuu BLE mianostukseen. 194 00:17:55,419 --> 00:18:03,759 Siinä ei ole juurikaan mitään. Ja toinen asia on se, että altistumis- 195 00:18:03,759 --> 00:18:07,919 ilmoitukset eivät sisällä juurikaan logiikkaa, vaan saat ne, etkä vastaa 196 00:18:07,919 --> 00:18:12,720 niihin ollenkaan. Joten se on melko harmiton feature verratuna toisiin 197 00:18:12,720 --> 00:18:19,360 verrattuna. Katsotaanpa Androidia esimerkiksi, jolla on viimeaikainen 198 00:18:19,360 --> 00:18:26,029 Bluetooth exploit. Joten tälläisiä bugeja on eikä se ole Android spesifinen juttu, 199 00:18:26,029 --> 00:18:31,019 vaan se voi olla myös iOS:lla ja se ei ole Bluetooth ongelma sillä, meillä 200 00:18:31,019 --> 00:18:36,110 on bugeja kaiken aikaa. Joten mikäli käytät ohjelmaa ja mikäli et päivitä 201 00:18:36,110 --> 00:18:40,340 sitä niin siinä saattaa olla bugeja ja siinä voi olla bugeja joita ei olla 202 00:18:40,340 --> 00:18:46,820 nähty hetkeen. Vaikkakin ne pitäisi olla korjattu jo aikoja sitten. Joten tämä 203 00:18:46,820 --> 00:18:52,450 on olemassa mikäli käytät ohjelmia. Ja usein nämä bugit usein riippuvat 204 00:18:52,450 --> 00:18:57,320 tarkoista laite ja ohjelmisto versioista. Joten esimerkiksi tämä exploit toimii 205 00:18:57,320 --> 00:19:02,940 vain Android 9 ja vanhemmilla koska se tarvitsee erittäin tarkan implementaation 206 00:19:02,940 --> 00:19:08,080 muistikopiosta, koska muistikopio on kutsuttu argumentti pituudella -2 ja 207 00:19:08,080 --> 00:19:14,330 sillä on toisenlainen käyttäytyminen eri järjestelmissä. Ja eikä vähäisempänä 208 00:19:14,330 --> 00:19:19,929 tämä exploit tarvitsee 2 minuuttia ajaakseen koska sen tarvitsee päästä ASLR ohi 209 00:19:19,929 --> 00:19:25,081 ilmassa. Joten täytyy olla haavoittuvan laitteen lähellä jonkin aikaa mikäli 210 00:19:25,081 --> 00:19:32,210 on hyökkääjä. Ja nyt ihmiset sanovat: "Joo, mutta se on spesiaali, sillä tälläinen 211 00:19:32,210 --> 00:19:36,309 on matomainen". Joo kyllä se pitää paikkaansa. Sinäkin voisit rakentaa 212 00:19:36,309 --> 00:19:41,380 Bluetooth madon tämän avulla, mutta miltä näyttää? Ensinnäkin laitteet 213 00:19:41,380 --> 00:19:46,570 menettävät yhteyskiä siellä täällä ja 214 00:19:46,570 --> 00:19:51,390 mato on leviämässä jossain ja niin edelleen. Mutta hyökkääjä 215 00:19:51,390 --> 00:19:54,520 tarvitsee oikeastaan jonkinlaisen komento- palvelimen. Joten aivan sama 216 00:19:54,520 --> 00:20:00,840 mitä hyökkääjä haluaa saavuttaa, kuten varastaa dataa tai bitcoin kaivausta 217 00:20:00,840 --> 00:20:07,049 loppujen lopuksi sinulla pitää olla jokin palaute ja komentopalvelin internetissä 218 00:20:07,049 --> 00:20:11,210 kommunikointiin tai jos jotain menee pieleen tai exploit lakkaa toimimasta tai 219 00:20:11,210 --> 00:20:15,750 jotain. Tarvitset varakanavan siitäkin huolimatta, että on langaton kanava 220 00:20:15,750 --> 00:20:20,568 koska se ei ole pysyvä. Ja seuraava haaste on se, että exploit täytyy olla 221 00:20:20,568 --> 00:20:28,740 erittäin luotettava, tarkoittaen että mikäli tulee kaatuminen 222 00:20:28,740 --> 00:20:32,419 ja se on matomainen, joka leviää erittäin nopeasti ja paljon, on ongelmana 223 00:20:32,419 --> 00:20:37,220 se että mikäli se ei ole 100% luotettava ja saat kaatumisia ja ne raportoidaan 224 00:20:37,220 --> 00:20:44,330 Applelle tai Googlelle. Se on suuri ongelma koska kun bugi havaitaan 225 00:20:44,330 --> 00:20:48,450 se tarkoittaa, että Apple ja Google päivittävät käyttöjärjestelmät ja 226 00:20:48,450 --> 00:20:54,049 bugi on poissa. Joten kaikki haittaohjelman kehitys on poissa ja turhaan. 227 00:20:54,049 --> 00:21:00,179 Exploittisi on poissa. Ja tämä tarkoittaa itseasiassa sitä, että mikäli hyökkääjä 228 00:21:00,179 --> 00:21:06,202 rakentaa madon he käyttäisivät todennäköisesti vanhentunutta bugia. Ja kuten 229 00:21:06,202 --> 00:21:12,380 sanoin bugit ovat yleensä kuukausista vuosiin hieman riippuen. Sinulla 230 00:21:12,380 --> 00:21:18,639 olisi bugi, joka toimii matona ja tällöin hyökkääjällä ei olisi riskiä 231 00:21:18,639 --> 00:21:26,330 menettää uniikkia bugia, joka on rahallisesti arvokas, jos he 232 00:21:26,330 --> 00:21:30,029 voisivat käyttää vanhaa. Mutta se tarkoittaa myös, että kaikki päivitetyt 233 00:21:30,029 --> 00:21:36,344 laitteet ovat turvassa tältä. Joten se riippuu siitä mitä hyökkääjä haluaa. 234 00:21:36,344 --> 00:21:40,810 Mitä minä mietin on enemmänkin, madon rakentamisen sijaan - mitkä 235 00:21:40,810 --> 00:21:45,830 ovat hyökkäysskenaariot? Jos ajatellaan Bluetooth exploitteja, mato tarvitsee paljon 236 00:21:45,830 --> 00:21:52,238 luotettavuutta. Ja sinulla on riski, että menetät exploitin. Joten luultavasti 237 00:21:52,238 --> 00:21:56,470 hyökkääjät ovat valikoivia ja haluavat fyysisen läheisyyden kohteeseen. 238 00:21:56,470 --> 00:22:02,320 Joten realistisesti ajateltuna tälläisiä paikkoja voisi olla lentokentän 239 00:22:02,320 --> 00:22:08,259 turvatarkastus tai, että hyökkääjä on lähellä tiettyä rakennusta, 240 00:22:08,259 --> 00:22:12,309 kuten yrityksen rakennusta tai sinun kotiasi tai jotain, jotta voivat varastaa 241 00:22:12,309 --> 00:22:16,919 tiettyjä salaisuuksia tai valtion puolelta jos on protesteja ja valtio haluaa 242 00:22:16,919 --> 00:22:23,580 henkilöllisyyden protestoijilta tai jotain. Tämä on vaihtoehtona. 243 00:22:23,580 --> 00:22:35,059 Mutta mato, kuten sanoin, ei niin mahdollinen. 244 00:22:35,059 --> 00:22:41,940 Ja seurava asia on exploit kehittäminen, joka tarkoittaa that jos haluat kehittää 245 00:22:41,940 --> 00:22:49,780 exploitin viimeaikaiselle iOS ja Androidille, niin se on paljon työtä ja vihollisellasi 246 00:22:49,780 --> 00:22:55,139 voi olla varaa siihen. Ja tässä tapauksessa he voivat käyttää sitä monta kertaa, 247 00:22:55,139 --> 00:22:59,529 kunhan bugi ei vuoda jonnekkin ja sitä ei korjata he voivat käyttää sitä uudelleen. 248 00:22:59,529 --> 00:23:05,440 Joten se on ainutkertainen kustannus. Mutta jos mietitään, että on tämänkaltaisia 249 00:23:05,440 --> 00:23:09,150 vihollisia silloin ehkä kannattaa käyttää toista erillistä puhelinta alistumisilmoituksiin 250 00:23:09,150 --> 00:23:14,820 ja pitää puhelin päivitettynä ja niin edelleen. Tai mikäli olet erittäin huolissasi hyökkäysistä 251 00:23:14,820 --> 00:23:18,720 ehkä älä käytä puhelinta ollenkaan koska Bluetooth ei ole ainut tapa kaapata 252 00:23:18,720 --> 00:23:24,149 puhelintasi. Hyökkäys voi tapahtua messen- gerin avulla, selaimen tai 253 00:23:24,149 --> 00:23:28,659 jonkun muun langattoman tekniikan avulla, kuten LTE ja niin edelleen. 254 00:23:28,659 --> 00:23:34,460 Joten se on vain riski, joka sinulla on. Eikä se ole spesifinen Bluetoothiin. 255 00:23:34,460 --> 00:23:43,230 Kuitekin katsotaan pari implementointia spesifistä yksityiskohtaa. Mikäli haluat 256 00:23:43,230 --> 00:23:47,830 ymmärtää hyökkäyksen taustaa ja miksi minä uskon, että Bluetooth 257 00:23:47,830 --> 00:23:55,299 altistumisilmoitus API on erittäin turvallinen. Ensiksi API tekee Bluetooth osoitteelle 258 00:23:55,299 --> 00:24:00,690 randomisaatiota, joka tarkoittaa että nämä osoitteet ovat satunnaisia ja 259 00:24:00,690 --> 00:24:06,450 niihin ei voi yhdistää ja et voi yhdistää niihin hyökkääjänä. Ja myös 260 00:24:06,450 --> 00:24:11,349 siellä ei ole palautekanavaa tämän ei yhdis- tettävä ominaisuuden takia. Ja 261 00:24:11,349 --> 00:24:16,802 se, tarkoittaa yleensä, että puhelimesi on konfiguroitu siten, että se ei 262 00:24:16,802 --> 00:24:22,559 kaiuta mitään yhdistettävää osoitetta, ja sillä on vain nämä satunnaiset osoitteet. 263 00:24:22,559 --> 00:24:26,470 Ja tämä on erittäin vaikeaa hyväksikäytölle. Joten sinun täytyy tietää puhelimen 264 00:24:26,470 --> 00:24:32,169 oikea osoite, jonne lähettää exploit. Ja sitä ei lähetetä ilmassa. Joten sinun 265 00:24:32,169 --> 00:24:36,470 täytyy dekoodata paketit, esimerkiksi, jos olet rinnakkaiskuuntelussa musiikkiin tai 266 00:24:36,470 --> 00:24:43,360 jotain voisit saada osoitteen siitä mutta se on erittäin vaikea saavuttaa. Ja toinen 267 00:24:43,360 --> 00:24:47,639 asia on, että varsinkin Apple erityisesti rajoittaa Bluetooth käyttöliittymiä. 268 00:24:47,639 --> 00:24:55,320 Joten puhelin ei voi käyttää Bluetoothia mielivaltaiseen featureihin, jotka ovat 269 00:24:55,320 --> 00:25:02,989 Bluetooth spesifikaatiossa. Ja tämä tarkoittaa, että se on hyvä 270 00:25:02,989 --> 00:25:08,650 yksityisyydelle. Joten on vaikeaa tehdä esimerkiksi vakoilija taskuusi 271 00:25:08,650 --> 00:25:16,450 iOS:lla koska on vaikeaa ajaa appia taustalla, joka tekee 272 00:25:16,450 --> 00:25:22,200 seuraamista Bluetoothilla ja niin edelleen. Ja toisinpäin on se, että 273 00:25:22,200 --> 00:25:26,309 jos on appi, joka tekee alistumis- ilmoituksia tai tapaamis jäljitystä ja 274 00:25:26,309 --> 00:25:33,600 ne eivät käytä virallista APIa, niin nämä ovat hyväksikäytettävissä 275 00:25:33,600 --> 00:25:40,779 koska ne käyttävät aktiivisia yhteyksiä. Ne ajavat edustalla. Ne oikeasti 276 00:25:40,779 --> 00:25:45,499 lokittavat, jotain mitä ei pitäisi. Joten älä tee tätä ja älä luota näihin 277 00:25:45,499 --> 00:25:53,554 appeihin, jotka eivät käytä APIa. Toinen ongelma voi olla yksityisyys. 278 00:25:53,554 --> 00:25:58,809 Ensinnäkin siellä on satunnainen tunniste, joka pysyy samana jonkin aikaa mutta 279 00:25:58,809 --> 00:26:02,600 kuten sanoin iOS:lla sinulla on jatkuvuus framework ja se tekee samaa. Joten vähintään 280 00:26:02,600 --> 00:26:07,199 Applen laitteissa tämä ei tee suurtakaan eroa. Ja jos ajatellaan hieman laajemmin 281 00:26:07,199 --> 00:26:11,270 kuin Apple. Siellä on signaalin voimakkuus ja mikäli vertaat tätä muihin 282 00:26:11,270 --> 00:26:16,789 teknologioihin, jotka ovat langattomia, kuten Wi-Fi ja LTE näissä on myös 283 00:26:16,789 --> 00:26:21,669 signaalin voimakkuus ja osoitteiden vaihto ja niin edelleen. 284 00:26:21,669 --> 00:26:28,380 Voit aina kolmiomitata signaaleja. Joten jos et halua tulla seuratuksi 285 00:26:28,380 --> 00:26:38,029 sinun täytyy disabloida Wi-Fi ja LTE. Ja toinen tärkeä osa turvallisuus 286 00:26:38,029 --> 00:26:42,019 oletuksissa on palvelin infrastruktuuri. Siellä on kaksi eri palvelin infrastruktuuria 287 00:26:42,019 --> 00:26:46,629 ja ensinnäkin sinulla on keskitetty lähestyminen, 288 00:26:46,629 --> 00:26:50,410 joka myös tunnetaan kontakti jäljityksenä. Ja tässä keskitetyssä lähestymisessä 289 00:26:50,410 --> 00:26:55,309 palvelin tietää kaiken. Joten palvelin tietää kuka oli kenenkin kanssa kontaktissa ja 290 00:26:55,309 --> 00:27:00,430 kuinka kauan. Esimerkiksi Alice tapasi Bobia 15 minuuttia mutta Alice tapasi 10 muuta 291 00:27:00,430 --> 00:27:09,409 tiistaina tai jotain. Joten heillä on lokit, kuka tapasi ketä. Ja nyt palvelin 292 00:27:09,409 --> 00:27:13,509 pystyy kertomaan tietyille ihmisille kun joku on saanut positiivisen testin 293 00:27:13,509 --> 00:27:20,170 ja kuinka kauan sitten tämä oli. Palvelin pystyy sensuroimaan, jotain informaatiota 294 00:27:20,170 --> 00:27:26,570 jonka se lähettää tietyille henkilöille mutta sillä on paljon tietoa sisäisesti. 295 00:27:26,570 --> 00:27:31,049 Joten tämä tarkoittaa, että mikäli palvelinta ajaa joku terveysviranomainen ja sitä, 296 00:27:31,049 --> 00:27:39,459 että kaikien täytyy luottaa tähän heidän kontakti historiallaan. Ja toinen lähestyminen 297 00:27:39,459 --> 00:27:44,820 ovat hajautetut altistumisilmoitukset. Eli palvelimella on lista pseudonyymeistä 298 00:27:44,820 --> 00:27:51,509 ja positiivisesti testatuista käyttäjistä mutta nämä ovat vain pseudonyymeja 299 00:27:51,509 --> 00:27:56,230 eivät tarkkoja aikoja tai altistumisia. Ja jokainen voi ladata tämän listan ja 300 00:27:56,230 --> 00:28:00,330 verrata sitä lokaaliin listaan. Joten sinulla on vain lokaali lista puhelimessa 301 00:28:00,330 --> 00:28:06,038 ketä olet tavannut ja vertaat sitä listaan pseudonyymeista, jotka ovat palvelimella. 302 00:28:06,038 --> 00:28:11,659 Ja jokainen voi vetäytyä julkaisemasta näitä pseudonyymeja. Ja etkä jaa omaa 303 00:28:11,659 --> 00:28:19,240 listaasi kellekkään. Joten miksi tämä hyvä tai huono? Terveysviranomaiset eivät 304 00:28:19,240 --> 00:28:23,640 saa mitään kontakti seurausinfoa hajaute- tussa mallissa ja tämä saattaa olla ongelma 305 00:28:23,640 --> 00:28:28,409 sillä valtiolla ei ole mitään statistiikkaa näistä leviämisistä ja sovelluksen 306 00:28:28,409 --> 00:28:31,806 toimivuudesta. He eivät voi mitata 307 00:28:31,806 --> 00:28:36,580 kuinka paljon appi oikeasti auttoi. He eivät voi mitata kuinka monta tartuntaa 308 00:28:36,580 --> 00:28:41,009 estettiin sillä, että kerrottiin ihmisen karanteenista tai että käy testattavana. 309 00:28:41,009 --> 00:28:48,590 Toisaalta se tarkoittaa että kukaan ei saa dataa. Eli ei Apple tai Goole eikä 310 00:28:48,590 --> 00:28:53,470 hallinto. Kukaan ei saa dataa ja eikä ole mitään hyötyä hyökätä 311 00:28:53,470 --> 00:28:57,989 palvelinta kohtaan sillä siellä ei ole mitään sensitiivistä tietoa. 312 00:28:57,989 --> 00:29:03,399 Eikä appin käytöllä ole mitään impaktia yksityisyydelle. Ja loppujen lopuksi 313 00:29:03,399 --> 00:29:07,999 jos saat positiivisen tuloksen myös silloin voit olla jakamatta tuloksia, jos 314 00:29:07,999 --> 00:29:13,919 koet pseudonyymi jaon olevan ongelma. Ja mielestäni monien pitäisi jakaa tulokset 315 00:29:13,919 --> 00:29:23,240 mutta sinun ei täydy. Ja haluan näyttää muutaman hyökkäyksen altistumisilmoituksia 316 00:29:23,240 --> 00:29:26,630 vastaan koska jotkut ihmiset sanovat, että altistumisilmoitukset ovat erittäin 317 00:29:26,630 --> 00:29:33,249 epäturvallisia. Joten tarkastellaan hyökkäysiä, joista on julkisesti puhuttu altistumisilmoituksia 318 00:29:33,249 --> 00:29:38,239 kohtaan kuten ne ovat nyt implementoitu. Ja huomioikaa se, että monikaan hyökkäys 319 00:29:38,239 --> 00:29:42,619 ei ole spesifinen Bluetoothille mutta ne ovat spesifisiä kaikelle, jotka 320 00:29:42,619 --> 00:29:48,880 ovat jollain tavalla langattomia ja notifikaatioita. Joten tarkastellaan. 321 00:29:48,880 --> 00:29:54,340 Eli aikakonehyökkäys. Tämä on melko mielen- kiintoinen. Olettamus tässä on, että 322 00:29:54,340 --> 00:29:58,990 joku voi vaihtaa aikaa sinun puhelimellasi ja sen jälkeen 323 00:29:58,990 --> 00:30:06,940 toistaa vanhentuneet tokenit, jotta tavallaan tapaisit pseudonyymit menneisyydessä 324 00:30:06,940 --> 00:30:10,960 jotka on jo testattu positiiviseksi ja koska puhelimesi on myös menneisyydessä 325 00:30:10,960 --> 00:30:15,981 se hyväksyisi nuo tokenit ja lokittaisi ne ja jos vertaat niitä palvelimeen 326 00:30:15,981 --> 00:30:21,659 myöhemmin luulet, että olit positiivinen, kontaktissa positiiviseen käyttäjään ja 327 00:30:21,659 --> 00:30:26,659 niin edelleen. Mutta huomioikaa, että ajan spooffaus on erittäin vaikeaa. 328 00:30:26,659 --> 00:30:31,570 Jos joku voi spooffata aikaa, se tarkoit- taa että he voivat murtaa myös muita 329 00:30:31,570 --> 00:30:36,360 asioita kuten TLS. Ja jos minulla olisi aikakone niin matkustaisin ajassa 330 00:30:36,360 --> 00:30:43,799 ennen vuotta 2020 tai jotain sen sijaan että väärentäisin muutaman altistumisilmoituksen. 331 00:30:43,799 --> 00:30:50,980 Seuraava hyökkäys on madonreikähyökkäys. Kuvittele, että tämä on sellainen kauppakeskus, 332 00:30:50,980 --> 00:30:54,710 sitten toinen kauppakeskus ja ehkä siellä poliisiasema tai jotain. 333 00:30:54,710 --> 00:31:00,429 Kuinka se toimisi? No, jos madonreittiäisit ne ja laittaisit ne yhteen se, että 334 00:31:00,429 --> 00:31:08,090 tulisi positiivinen altistumisilmoitus lopuksi on erittäin korkea. 335 00:31:08,090 --> 00:31:17,478 joten nostaisit mahdollisuutta saada positiivisen ilmoituksen. Ja tämä 336 00:31:17,478 --> 00:31:23,809 ilmoitus ei tietenkään olisi aito. Eli se on forwardoidu altistuminen. Ja tämän 337 00:31:23,809 --> 00:31:28,270 seurauksena pahimassa tapauksessa tekisit enemmän fyysistä etäisyyttä, 338 00:31:28,270 --> 00:31:33,580 enemmän testauksia, ehkä alat epäluottamaan appiin vähän mutta 339 00:31:33,580 --> 00:31:38,220 se ei haittaa koko systeemiä. Joten määrä positiivisissa tuloksissa ei 340 00:31:38,220 --> 00:31:43,559 kasva koska ainoastaan todennetut positiiviset tapaukset ladataan pseu- 341 00:31:43,559 --> 00:31:48,749 donyymi listalle ja ketkä vain ovat täällä ja saavat notifikaation eivätkä uploadaa. 342 00:31:48,749 --> 00:31:52,950 Ja että on tälläinen madonreikä ja että madonreikä, joka skaalautuu 343 00:31:52,950 --> 00:31:58,750 tarvitset paljon laitteita, jotka forwardoivat notifikaatioita ja julkisessa tilassa 344 00:31:58,750 --> 00:32:06,190 se ei ole helppoa implementoida. Viimeinen hyökkäys on identiteetin 345 00:32:06,190 --> 00:32:10,350 jäljityshyökkäys. Joten sanotaan, että sinulla on nuo pseudonyymit. Pseudonyymit 346 00:32:10,350 --> 00:32:14,809 vaihtuvat ajan kanssa ja liikut kaupungilla ja siellä on useita laitteita, jotka 347 00:32:14,809 --> 00:32:20,039 tarkastelevat pseudonyymien vaihtelua. Tottakai voit alkaa jäljittää käyttäjiä. 348 00:32:20,039 --> 00:32:26,200 Tämä vaatii jälleen todella skaalautuvan systeemin ja ongelma on 349 00:32:26,200 --> 00:32:30,979 että mikäli pelkäät tälläistä hyökkäystä sinun tulisi disabloida 350 00:32:30,979 --> 00:32:35,427 myös Wi-Fi ja LTE ja niin edelleen koska voit kolmia mitata aina nämä 351 00:32:35,427 --> 00:32:42,259 signaalit. Eli ideaalisesti mikäli et halua tulla jäljitetyksi. Laita langattomat 352 00:32:42,259 --> 00:32:49,149 tekniikat pois päältä. Tämä ei ole pelkästään Bluetooth spesifinen. 353 00:32:49,149 --> 00:32:55,919 Kaikki nämä hyökkäyset ovat valideja mutta niiden hyväksikäyttöön, jotta voisit saada 354 00:32:55,919 --> 00:33:02,970 altistumisilmoituksia, jotka voisit toistaa aikamatkustuksella tai madonreiällä tai 355 00:33:02,970 --> 00:33:06,909 jäljittää ID:tä tarvitset erittäin laaja skaalautuvan asennuksen kuten Raspberry piit 356 00:33:06,909 --> 00:33:12,906 läpi kaupungin ja useita useita laitteita. Joten tämä toimisi myös muissa langattomissa 357 00:33:12,906 --> 00:33:18,489 ekosysteemeissä. Mutta OK, jos haluat tehdä tuollaisen 358 00:33:18,489 --> 00:33:23,220 asennuksen voisit yhtä hyvin tehdä jotain vastaavaa kuten, 359 00:33:23,220 --> 00:33:28,935 paljon laitteita, joissa on mikrofonit tai kamerat ja Wi-Fi ja niin edelleen ja 360 00:33:28,935 --> 00:33:34,299 jäljittää paljon muitakin asioita. Tämän täytyy tapahtua julkisessa paikassa kuten 361 00:33:34,299 --> 00:33:39,689 bussiasemalla, kauppakeskuksessa ja niin edelleen. Ja jos sinulla on 362 00:33:39,689 --> 00:33:45,580 sellainen installaatio sillon vain bluetooth altistumisilmoitusten 363 00:33:45,580 --> 00:33:51,429 muokkaus ei ole isoin huolenaihe. Surullinen todellisuus voisi olla se, että 364 00:33:51,429 --> 00:33:56,334 meillä on jo valmiiksi seurantaa joka paikassa. Meillä on paljon kameroita 365 00:33:56,334 --> 00:34:01,639 julkisissa paikoissa. Joten tämä ei ole huolenaihe. Tarkoitan, että olisin 366 00:34:01,639 --> 00:34:10,119 huolissani julkisesta vakoilusta mutta en Bluetooth seurannasta. Joten 367 00:34:10,119 --> 00:34:14,440 päättääkseni puheeni. BLE mainostus on paras teknologia, joka voidaan 368 00:34:14,440 --> 00:34:17,570 implementoida altistumisilmoituksiin ja 369 00:34:17,570 --> 00:34:23,980 ne ovat saatavilla uusissa puhelimissa iOSlla ja Androidilla. 370 00:34:23,980 --> 00:34:29,179 Ne ovat erittäin turvallisia, yksityisyyden pitäviä, akku ystävällisiä ja laajautuvia. 371 00:34:29,179 --> 00:34:33,139 Ja pitäkää mielessä, että jokainen estetty infektio pelastaa elämiä ja 372 00:34:33,139 --> 00:34:41,579 estää pitkäaikaisia sairauksia. Joten tämä on käytettävä juttu, vaikka se ei 373 00:34:41,579 --> 00:34:46,689 toimi 100%. Ja tämän jälkeen aloitetaan Q&A ja keskustellaan mistä haluatte, 374 00:34:46,689 --> 00:34:54,519 Bluetooth madoista ja niin edelleen. Kiitokset kuuntelusta. Herald: Kiitos Jiska 375 00:34:54,519 --> 00:34:59,299 puheestasi. Toivon, että meillä on aikaa Q&A:lle. 376 00:34:59,299 --> 00:35:05,829 J: Aloitetan H: Hienoa 377 00:35:05,829 --> 00:35:11,719 J: Luulen, että tämä oli Ollien internetyhteys? Joten ehkä 378 00:35:11,719 --> 00:35:15,470 päätän itsekseni kunnes hän reconnectaa. Ah täällä olet! 379 00:35:15,470 --> 00:35:21,110 H: Anteeksi. Kysymys oli, että miksi saapumiskulma on hyökkääjälle 380 00:35:21,110 --> 00:35:26,230 kiintoisa tai J: Ei hyökkääjälle mutta teknologian 381 00:35:26,230 --> 00:35:31,680 puolesta olisi mielenkiintoista, että se olisi bluetoothissa koska silloin 382 00:35:31,680 --> 00:35:37,030 voidaan tehdä suunta arvioita. Ja mikäli ihmiset liikkuvat voisit saada myös 383 00:35:37,030 --> 00:35:43,471 suunnan ja ehkä lokaation tämän avulla tai auttaa siinä. Mutta tarkoitan että 384 00:35:43,471 --> 00:35:47,810 se ei ole vielä missään chipeillä kuin evaluaatio kiteillä. 385 00:35:47,810 --> 00:35:55,010 H: Alright. Kiitos. Onko olemassa tutkimuksia jotka todistavat tai 386 00:35:55,010 --> 00:35:59,520 eivät todista kotankti seurantasovelluksien tehokkuutta yleisesti? Kuten use caseja? 387 00:35:59,520 --> 00:36:06,289 J: Tarkoitan, että ongelma on siinä, että meillä on altistumisilmoitus 388 00:36:06,289 --> 00:36:11,970 framework ja meillä ei ole statistiikkaa. joten hyvät ja huonot puolet yksityisyydestä 389 00:36:11,970 --> 00:36:17,609 on asia mistä meillä ei voi olla tutkimusta muuten kuin, jos ihmiset toimittavat dataa. 390 00:36:17,609 --> 00:36:21,980 En tiedä kyselyitä tai jotain. Mutta tiedän ainakin ihmisiä, joita on 391 00:36:21,980 --> 00:36:26,324 varoitettu appilla ja saatu testi ja niin edelleen. Joten se näyttää 392 00:36:26,324 --> 00:36:33,289 toimivan joillain. Ja jokainen pelastettu elämä lasketaan lopuksi. Joten 393 00:36:33,289 --> 00:36:39,890 mikään ei ole täydellistä? H: Totta. Kiitos vastauksista. 394 00:36:39,890 --> 00:36:44,989 Mutta käyttäjä triplefive haluaisi tietää "Miksi luulet että kiihtyvyysmittari 395 00:36:44,989 --> 00:36:49,950 voisi olla yksityisyydelle ongelma. Eikös se riipu siitä miten data prosessoidaan 396 00:36:49,950 --> 00:36:54,430 esimerkiksi pysyy laitteella, ei ole tallennettu ja niin edelleen" 397 00:36:54,430 --> 00:36:58,670 J: Tottakai. Mutta kun annat luvan applikaatiolle sinun tulee luottaa 398 00:36:58,670 --> 00:37:02,960 siihen, mikä on ensinnäkin kaikki binaarit mitä lataat. Tarkoitan ehkä se on 399 00:37:02,960 --> 00:37:07,390 avointakoodia kuten meidän Saksan sovellus on mutta ei sitä tiedä. Ja sitten 400 00:37:07,390 --> 00:37:11,810 se voisi prosessoida tätä dataa. Ja kiihtyvyysmittarista on tutkimuksia, 401 00:37:11,810 --> 00:37:16,670 että et voi tehdä askelmittausta mutta se että joku kääntyy vasemmalle tai 402 00:37:16,670 --> 00:37:20,040 oikealle ja tämänkaltaiset. Jos sinulla on overlay kartta voit 403 00:37:20,040 --> 00:37:24,660 uudelleen luoda polun mitä liikuit kaupungin läpi esimerkiksi. Joten 404 00:37:24,660 --> 00:37:32,920 se on iso ongelma. H: Alright. Kiitos. Vielä on yksi kysymys. 405 00:37:32,920 --> 00:37:38,869 Onko yksikään teoreettisista tai mahdollisista hyväksikäytöistä yritetty 406 00:37:38,869 --> 00:37:42,312 käytännössä? Sinun parhaan tiedon perusteella? 407 00:37:42,312 --> 00:37:47,970 J: Minun tietääkseni ei. Tarkoitan se olisi näkyvissä ainoastaan kerran 408 00:37:47,970 --> 00:37:53,309 jos joku tekee sellaisen hyökkäyksen. Laajassa skaalassa ja heillä täytyisi olla 409 00:37:53,309 --> 00:38:02,980 iso käyttönotto ilman kiinnijäämistä. Joten kukaan ei ole tehnyt tätä vielä. 410 00:38:02,980 --> 00:38:11,000 H: OK tuo käy järkeen. Ja oli yksi henkilö kenellä oli kommentti. He huomauttivat 411 00:38:11,000 --> 00:38:15,210 että on avoin implementaatio frameworkille ja mikäli käyttäjä haluaa mennä ulos ilman 412 00:38:15,210 --> 00:38:20,380 Googlea tai Applea ja silti osallistua altistumisilmoituksiin. Se taitaa olla 413 00:38:20,380 --> 00:38:24,030 aikaisessa kehityksessä. J: kyllä. Minulla oli jo kalvot valmiina 414 00:38:24,030 --> 00:38:29,049 kun se tuli ulos. JOten se on F-Droid varastossa ja se käyttää avoimen 415 00:38:29,049 --> 00:38:33,690 lähdekoodin implementaatiota. Joten voit käytää sitä jopa 416 00:38:33,690 --> 00:38:43,260 Lineage puhelimessa esimerkiksi. H: OK, kiitos. 417 00:38:43,260 --> 00:38:47,920 J: OK, muita kysymyksiä? H: Kyllä, vielä viimeinen johon törmäsin 418 00:38:47,920 --> 00:38:54,119 täällä. Onko kukaan yrittänyt murtaa varmistuspalvelinta väsytyshyökkäysellä? 419 00:38:54,119 --> 00:39:01,140 Kysyjä teki kirjekuorilaskennalla akoinaan. 420 00:39:01,140 --> 00:39:06,700 JA se näyttää siltä, että olisi mahdoll- ista kokeilla kaikki Tele-TANit jossain 421 00:39:06,700 --> 00:39:11,490 vaiheessa. J: Kaikki mahdolliset Tele-TANit. Se olisi tosiaan väsysytyshyökkäys jonka 422 00:39:11,490 --> 00:39:16,252 näkee back-endissa vai mitä? Joten siinä ei voida rate limittiä käyttää. 423 00:39:16,252 --> 00:39:19,480 Ja se on varmaan ainut asia minkä voi väsytyshyökätä koska kaikki vertailu 424 00:39:19,480 --> 00:39:25,660 tehdään lokaalisti puhelimessa. Joten TANit olisivat ainoat heikkoudet 425 00:39:25,660 --> 00:39:30,740 systeemissä. Ja mikäli joku yrittää väsytyshyökätä kaikki TANit 426 00:39:30,740 --> 00:39:36,530 se olisi ilmiselvä hyökkäys. H: Käy järkeen. Alright 427 00:39:36,530 --> 00:39:39,849 Kiitos paljon puheesta. Kiitos kärsivällisyydestä kysymyksien 428 00:39:39,849 --> 00:39:46,230 vastailuun. Luulen että tämä on meidän aikaraja tarkalleen. Ja 429 00:39:46,230 --> 00:39:51,720 sen myötä annan uutisille Dubliniin. Kiitos paljon. 430 00:39:51,720 --> 00:39:57,100 Loppumusiikki. 431 00:39:57,100 --> 00:40:32,000 Translated by Juho Halttunen (ITKST56 course assignment at JYU.FI)