Decompiling Smittestop

Flot arbejde af Kim - og ganske interessant. En enkelt ting har vakt min nysgerrighed, nemlig at appen "Orientere bruger om, hvad hun skal gøre, hvis hun har været i nærheden af en smittet.", hvilket måske ikke er så harmløst som det lyder.

Er det muligt ud fra decompileringen at se, hvordan denne orientering skabes, f.eks.:

1) er det en standard information der ligger permanent i appen, eller

2) er det en information som først hentes når appen opdager et match, og

3) hvor hentes informationen og hvordan (efterlader hentningen en IP adresse hos myndighederne).

4) Hentes denne information altid ved et match, eller kun hvis brugeren har slået notifikation til.

Bedømt ud fra beskrivelsen af Smittestop's behandling af persondata (se: https://stps.dk/da/om-os/data-og-privatlivspolitik/smitteapp-privatliv/ ), kunne det tyde på at informationen hentes af telefonen når appen opdager et match. Der er formuleret således: Afsnit 2.3: "Den information, du modtager i notifikationen, vil følge de til enhver tid gældende anbefalinger for, .... "

Jeg hæfter mig ved formuleringen "til enhver tid gældende" - det er vel kun muligt ved enten at hente den aktuelt, eller ved at pushe ny information til samtlige apps hver gang informationen opdateres.

Hvis den hentes individuelt, så rejser det selvfølgelig spørgsmålet om hvorvidt appens IP-adresse (som er en personfølsom oplysning) kan identificeres i forbindelse med et match?

Hvis IP-adressen er synlig for myndighederne i dette tilfælde, gør det en del af §1 i persondatadokumentet urigtig. Af den fremgår det:

"Når du bruger appen, kan andre borgere eller Styrelsen for Patientsikkerhed ikke se, hvem du er ....."

Styrelsen for Patientsikkerhed vil med IP-adressen kunne se hvem du er, hvis du har været i nærheden af en smittet.

.. som du selv er inde på, siger det eneste rigtige:

"It has nothing to do with privacy concerns. The idea that contact tracing can be done with an app, and not human health professionals, is just plain dumb."

Det kunne være interessant at sætte APP'en i isoleret miljø og sætte Wireshark på, for at se hvilke data/forbindelser den laver.

Jeg ved ikke nok om programmering, til at vide hvad MessageLink gør. Kan det undersøges om der laves en forbindelse til Netcompany.com, hver gang disse fejlbeskeder fremkommer? Så snart du har IP, kan du finde identiteten for ejeren af pågældende telefon.

Så længe kildekoden ikke er åben, stoler jeg ikke på APP'en. Det bliver et nej tak herfra ;)

Det kunne være interessant at sætte APP'en i isoleret miljø og sætte Wireshark på, for at se hvilke data/forbindelser den laver.

JA!! - Det kunne være interessant. I Android hedder Wireshark så f.eks. tPacketCapture - Den kan endda køre uden at telefonen rootes, og den fanger alt på bredbåndsinterfacet.

Andre muligheder er: zAnit, cSploit, DebugProxy, nMap, AndroidTcpdump, NetMonster

Nogle af dem kræver Root.

Kombineret med den decompilerede kode kan det sikkert give et ret præcist svar på hvad der reelt foregår - når nu vi ikke har adgang til kildekoden.

Jeg forstår heller ikke hvor driftsomkostningerne skulle komme fra ?

Hvis den ikke kom i udbud, så burde man måske have lavet en konkurrence mellem Aarhus Universitet, Københavns Universitet og DTU, og så ville man have fået noget ud i den anden ende som kunne driftes langt billigere.

Hvis IP-adressen er synlig for myndighederne i dette tilfælde, gør det en del af §1 i persondatadokumentet urigtig. Af den fremgår det:

IP-adressen vil være en rimelig vilkårlig adresse afhængig hvor du er henne, dvs. hvilken mobilmast eller WiFi du er koblet på, og rimelig svær at spore. Hvis mobilen er koblet på WiFi, mens app'en henter data vil det kun være routeren IP-adresse man finder, da mobilen vil have fået en lokal IP-adresse af WiFi access punktet, så den oplysning er heller ikke særlig anvendelig - det kan være hjemmeadressen, men også en vilkårlig anden.

IP adresse er dog ikke personfølsom men "bare" persondata

Ja, det er rigtigt - som udgangspunkt. Men hvis der foreligger anden information, f.eks. et login eller en NemID validering fra samme adresse er den (måske) personhenførbar. Se f.eks.: https://ecapacity.dk/derfor-kan-ip-adressen-faa-persondata-faelden-klapp...

Det er også korrekt, som @Andrew Rump skriver, at IP adressen kan skifte når man er på WiFi, og har du dynamisk IP adresse på din bredbåndsforbindelse. Det kræver så en henvendelse til teleselskabet for at få oplysningerne (hvilket kræver en dommerkendelse).

På mobilt bredbånd er det anderledes. Her benytes en kombination af statiske og dynamiske adresser - afhængig af teleselskab. Ude i selve mobilnettet benyttes IPv6 adresser, men de konverteres til puljede adresser i de gateways som forbinder core-nettet med Internettet. På den måde kan man sikre, at telefonen altid får en dansk IP adresse selv når den er roamet i udlandet. Min telefon får i øvrigt altid samme offentlige IPv4 adresse uanset hvor jeg bruger telefonen. Det er (formodentlig) en puljet adresse, men er trods alt uændret.

Uanset hvad, så er IP adressen meget interessant fordi den i Smittestop appen optræder samtidig med NemID validering.

Derfor vil det - ud fra et sikkerhedssynspunkt, være interessant at se hvad der rent faktisk ovberføres og hvornår.

"Fiddler som proxy" - Jeg kender ikke Fiddler, men tPacketCapture (Android app) kører også som proxy, og understøtter lokale nøgler, så du kan dekryptere hele transmissionen.

Det kunne være interessant at sætte APP'en i isoleret miljø og sætte Wireshark på, for at se hvilke data/forbindelser den laver.

Hvis man nu slår data forbindelsen fra, 4G eller hvad telefonen nu kører på, og lade alt kører gennem en trådløs router, så burde del være muligt at opætte en pc med wireshark.

Det kræver så en henvendelse til teleselskabet for at få oplysningerne (hvilket kræver en dommerkendelse).

Eller man skal bare sige man kommer fra "Rettigheds"alliancen, så åbnes godteposen ukritisk.

Jeg har skimmet googles exposure notifications api. 1. En app kan bede om at få de nøgler som har identificeret telefonen. Disse kan fås for de sidste 14 dage. Det sidste døgn forbeholdes specifikke apps. Før information returneres af api'et bliver brugeren promptet af Google Play services for at bede om lov at udlevere data til appen, tilladelsen gælder for 24 timer. 2. Match imod smittede, gøres ved at appen henter smittede id'er inklusiv smitte risikoen fra de forskellige id'er. Derefter kan man udlæse en rapport om sansynlighed for at borgeren er smittet. Jeg ser derfor ikke at api'et kan misbruges.

Men hvis man har hævede rettigheder på telefonen og derved kan få hele databasen ud er det selvfølgelig noget andet. Det er NSA/FE osv nok ret interreserede i. Mon ikke det er der man skal se på om man tør generere den deteljerede kontakt information.

Jeg har normalt meget stor respekt for Bruce Schneier, men jeg synes at han misser pointen her. Smitteopsporings app'en er et supplement til manuel smitteopsporing og absolut ingen blandt de danske myndigheder tror på den kan stå alene. Forhåbningen er at app'en kan finde nogen af de personer som en smittet har været tæt på, men ikke kender – fx i toget, til fodboldkampe eller på standen, og på den måde stoppe smittekæder som man ellers ikke kan finde. Mht. effekten af app’en har den effekt allerede ved en lav adoption se evt. https://www.technologyreview.com/2020/06/05/1002775/covid-apps-effective....

Før man registrer en kontakt i appen skal man have været inden for 1 meter i mindst 15 min af folk.

Hvis der virkelig skal 15 minutters tæt tilstedeværelse til før man har en nogen lunde risiko for at være smittet, hvorfor skal vi så holde så meget afstand? Hvis ikke, hvorfor siger appen ikke til for en kortere periode?

For mit vedkommende er det højest ganske få kolleger og min familie jeg er så tæt på i så lang tid. Appen giver slet ikke mening for mig.

Uanset hvad, så er IP adressen meget interessant fordi den i Smittestop appen optræder samtidig med NemID validering.

Hvorfor skulle en person der får en advarsel om kontakt være logget ind med NemID? Det bruges da først når man skal sige at man er testet positiv (og dermed allerede har mistet anonymiteten), eller har jeg misforstået?

Det er klart at hvis der på anden måde er mulighed for at sammenkæde IP adresse og NemID, så går det galt. En mulighed her er hvis man bestiller test, men så har man jo opgivet anonymiteten. Til gengæld kan de se hvor længe man har ventet mellem advarsel og bestilling.

En ting der kunne ske er at man kan se hvem der får en advarsel og IKKE beder om en test.

Men ja, det forekommer problematisk at der automatisk sendes en forespørgsel til en web adresse.

IP adresse er dog ikke personfølsom men "bare" persondata.

Det er nu ikke helt rigtigt: https://www.whitecase.com/publications/alert/court-confirms-ip-addresses...

I øvrigt er der ikke noget, der hedder 'personfølsom' ifølge GDPR. Alt hvad der kan udpege en person, er per definition personhenførbare oplysninger - eller ganske enkelt 'personoplysninger'. Måske tænker du på 'helbredsoplysninger'.

Før man registrer en kontakt i appen skal man have været inden for 1 meter i mindst 15 min af folk.

Hvilket appen på ingen måde kan måle (BLE egner sig ikke til præcis afstandsmåling - kommer aldrig til at virke)

Appen giver slet ikke mening for mig.

Heller ikke her ..

Databeskyttelsesforordningen opererer skam med begrebet følsom persondata. Her er hvad datatilsynet skriver om sagen:

Følsomme personoplysninger er udtrykkelig afgrænset i databeskyttelsesforordningen, og adgangen til at behandle sådanne oplysninger er snævrere end ved almindelige personoplysninger.

Følsomme oplysninger er oplysninger om:

• Race og etnisk oprindelse
• Politisk overbevisning
• Religiøs eller filosofisk overbevisning
• Fagforeningsmæssige tilhørsforhold
• Genetiske data
• Biometriske data med henblik på entydig identifikation
• Helbredsoplysninger
• Seksuelle forhold eller seksuel orientering.

Kun de oplysninger, der er nævnt ovenfor, er følsomme personoplysninger.

Databeskyttelsesforordningen opererer skam med begrebet følsom persondata. Her er hvad datatilsynet skriver om sagen

Det er faktisk ikke helt korrekt, selv om det er Datatilsynet der skriver det. Jeg tænker de skriver som de gør for at trække en tråd tilbage til den gamle persondatalov.

Hvis du vil vide hvad GDPR siger om det, bliver du nødt til at læse selve loven som den står i Databeskyttelsesforordningen (eller Persondataforordningen, som den tidligere blev kaldt). Der er der et helt afsnit (artikel 9) med overskriften 'Behandling af særlige kategorier af personoplysninger'. Men GDPR skelner altså ikke på samme måde som man gjorde før. I den gamle persondatalov så det lidt anderledes ud.

Essensen af det Datatilsynet skriver er rigtig nok, men GDPR bruger ikke den definition i forordningen (loven).

App'en kan køres i en android emulator (der er mange at vælge imellem). De fleste kører på VirtualBox som man kan bede om at logge al TCP kommunication til en fil. Det største problem bliver nok at dekryptere beskederne. Hvis det mod forventning er lavet ordentligt bliver man nok nødt til at stoppe processen og skanne for nøgler når man ser et SSL handshake til den anvendte server.

Appen giver slet ikke mening for mig.

Heller ikke her ..

Så er det godt, at det (stadig) er frivilligt, også i praksis. Og heldigvis behøver ingen have dårlig samvittighed over ikke at have en smartphone, eller have en, som er for "gammel" fordi:

Mht. effekten af app’en har den effekt allerede ved en lav adoption

Men nej, jeg tror heller ikke API'et kan misbruges

Jeg ser flere grundlæggende udfordringer, f.eks.:

• der er ingen kontrol med, om "smitte-ID" kun afsløres ved smitte. Det kan i princippet uploades kontinuerligt, og så falder alle garantier om manglende sporbarhed til jorden. Eller ved dommerkendelse/edition, whatever. Beskyttelsen er baseret på den, som bruger API opfører sig pænt.
• at rulle "smitte-ID" dagligt er en afvejning af effektivitet og af hvor meget sammenkædning, som er muligt, når ballonen går op, og og som alle afvejninger, så kan det diskuteres. Jeg synes personligt at et døgn er lang tid (bevares, det er justerbart i protokollen, men så vidt jeg ved ikke i API'et).
• der er så vidt jeg kan se, ikke nogen garantier imod passiv lytning, det være sig free-riders eller andre, som bare vil være med på en lytter. Det forudsætter selvfølgelig at smitte-ID afsløres ... se ovenfor.
• der er ingen beskyttelse imod replay (f.eks. kan en lille dims på f.eks. Nørreport opsnappe vilkårlige kontakt-IDs, og retransmitere dem i længere tid , selv efter at ophavsmanden for længst er kørt videre (i protokollen rulles de jævnligt, men samtidig anbefaler protokollen, at man ikke lægger alt for megen vægt på den implicitte tid - der tales om en tolerance på 2 timer, og det er nok til at dække det mest af myldretiden) - og det kan gøres endnu mere effektivt, hvis man er interesseret i at sprede panik og rædsel).

Og lidt mere eksotisk:

• den, som forvalter API har også nøglerne. Tør vi stole på at Google ikke føler sig fristet? Det er virkeligt mange lækre kontaktoplysninger, og de har allerede godt styr på, hvor vi er henne.
• den, som forvalter API, sidder også med sluk-knappen. Dermed falder argumentet om, at "så er vi klar til næste gang" i nogen grad til jorden, for Google hhv. Apple skal også være enige om, hvad som udgør "næste gang".

Men bevares, det er stadig lysår bedre end det "hjemmestrik", som man ellers var i gang med på nationalt plan, inklusive herhjemme til at starte med.

PS: Der, hvor nemid kommer ind i billedet er for ikke der ikke kan sendes falske smittemeldinger. Problemet med at verificere autentitet uden at afsløre identitet er forlængst løst. Men hvis man er en hammer, så ligner alt åbenbart et søm.

Men man kunne godt være anonym hele vejen igennem. Fx hvis hver testet person fik et id (fx en QR kode) samtidigt med de blev testet. Når man indtaster id'et på en hjemmeside, vil den fortælle om testen er positiv eller ej. Hvis testen er positiv melder man det i smittestop app'en og indtaster koden. Herefter kan den positive test bekræftes på backenden.

Absolut. Den tyske app bruger for eksempel en QR kode og jeg har også foreslået det som en mulighed i Danmark. Om ikke andet så til de udenlandske turister der tester positive og andre uden NemID. Specielt når man har fået taget sig sammen til at frigive appen til app stores uden for Danmark.

Hvorfor skulle en person der får en advarsel om kontakt være logget ind med NemID? Det bruges da først når man skal sige at man er testet positiv (og dermed allerede har mistet anonymiteten), eller har jeg misforstået?

Du har helt ret i forhold til Smitteappen. Men i forhold til NemID, så gemmer f.eks. Digitaliseringsstyrelsen bl.a. din IP adresse når du bruger nemid.nu - Noget tilsvarende gælder når du bruger NemID mod andre websteder, så "staten" kender formodentlig ret præcist din IP adresse. Hvad "staten" ikke ved er selvfølgelig hvilken enhed du logger på med, om du har dynamisk IP osv. så sikkerhedshullet er ikke altid åbent, men det er der.

Men man kunne godt være anonym hele vejen igennem. Fx hvis hver testet person fik et id (fx en QR kode) samtidigt med de blev testet.

Helt enig - det ville lukke sikkerhedshullet i forhold til NemID.

App'en kan køres i en android emulator (der er mange at vælge imellem). De fleste kører på VirtualBox som man kan bede om at logge al TCP kommunication til en fil. Det største problem bliver nok at dekryptere beskederne. Hvis det mod forventning er lavet ordentligt bliver man nok nødt til at stoppe processen og skanne for nøgler når man ser et SSL handshake til den anvendte server.

Der er mange forskellige måder at gøre det på. Den største udfordring jeg har med emulatorer er at få apps til at se mit netkort og min proxy som en mobil bredbåndsforbindelse.

De emulatorer som kan det, laver faktisk ikke nogen særlig god emulering, og ofte ser udfaldet anderledes ud, end når det eksekveres direkte i en Android enhed. Men det kan selvfølgelig være at jeg ikke har været grundig nok, eller bare ikke har fundet en emulator som er god nok.

Hvis man bruger tPacketCapture som jeg beskriver ovenfor, så er det ikke noget problem at dekryptere datastrømmen, fordi den proxy tPacketCapture sætter op, laver lokal authentikering både mod appen i telefonen og mod serveren (med forskellige nøgler). Imellem sidder tPacketCapture som den perfekte man-in-the-middle og giver dig pakkeindhold i klartekst, og afleverer det hele i en Wireshark fil. Selv NemID kan køre på den måde - og det kræver ikke roorting.

Når App'en kalder getTemporaryExposureKeyHistory() så vil brugeren skulle give tilladelse til at det sker.

Det er så API og ikke protokol. Jeg indrømmer gerne, at jeg ikke studeret API'et, men kun protokollen.

Hvordan tænker du man kan passivt lytte med?

Kontakt-ID broadcastes. Hvis A møder B, og A sender kontakt-ID jfr. protokollen, så kan B høre disse, men der er intet som tilsiger, at B behøver svare. Eller har jeg overset noget? Det kan godt være, at B ikke kan bruge API til det, men der er ingen der siger, at B behøver bruge API, endsige en smartphone.

Kontakt-ID kan så kopieres direkte eller gemmes. De bliver selvfølgelig først interessante, når man af en eller anden grund tvinges til at afsløre sit smitte-ID, men det kan der være mange grunde til (dommerkendelse?).

Så vidt jeg kan se, så er det medtænkt i protokollen

Ikke anonymiteten, så vidt jeg kan se. Her springer man i mål.

Eller man skal bare sige man kommer fra "Rettigheds"alliancen, så åbnes godteposen ukritisk.

Ikke i vores firma og formodentlig hellere ikke hos de to andre der er repræsenteret her. Det er i øvrigt nu ulovligt på grund af GDPR.

10 mio. alene for selve app'en - den er jo helt triviel, alt er implementeret af Google/Apple. Nogen der ved hvad andre landes tilsvarende apps har kostet? Kan ikke udelukkes jeg overser noget, men virker nærmest forbryderisk dyrt.

Bemærk i den forbindelse at grafik etc. jo er indeholdt i andre (store) poster. Samme med sikkerhedstest, jura etc. Så de 10 mio. er den "rå" udviklingspris. Tag også i betragtning at API'erne kun har været tilgængelige i godt en måned fra app'ens lancering. Der skal godt nok være smidt mange kodekarle og testere ind for at forbruge så mange timer på en måned - hvordan det kan lade sig gøre for en så triviel app er mig en gåde. Når man så tænker på at app'en skulle have været "pro bono" og dermed ikke er kommet i udbud, er frækheden så meget mere til at overse. Jeg håber virkelig at der kommer en undersøgelse af dette og hvem der har godkendt det. Der burde rulle minimum et par hoveder.

Hvor meget ligner koden det fra sample-appen?

Men det vil kræve et ret vildt setup, hvis du gerne vil tracke en eller flere brugere på denne måde.

Du har også læst protokollen, så lad os bruge de rigtige navne. Alene (uden TEK) er RPI rimeligt værdiløse. Der kan selvfølgelig laves noget korrelation hvis man ser samme RPI flere gange, men 10-20 minutter er i praksis ikke meget at løbe på (men sikkert nok til at kunne følge en person, f.eks. fra perron til perron). Eksotisk. Ikke interessant.

Men det hele falder fra hinanden, hvis du kender TEK. Det er også derfor at jeg kredser omkring scenarierne, hvor TEK fortabes, afsløres, franarres eller fratvinges. Der er ikke noget i protokollen, som giver sikkerhed her, selvom jeg gerne tror, at det er noget i implementationen lige nu, så i hvertfald forhindrer at man går igennem fordøren.

Og dommerkendelserne er selvfølgelig meget mere målrettede. Vi tror at du var sammen med X, lås lige din telefon op.

Anonymiteten er forsøgt håndteret med bluetooth id'er, som skifter hver 10-20 minut.

Ja, RPIer er rimeligt anonyme, sålænge du ikke kender TEK, men jeg kredsede omkring, at man insisterer på at knytte en samling TEKs sammen med et nemid. Hvorfor? Fordi at ikke alle enhver skal kunne melde sig smittede bare fordi at de har lyst. Men det behøver man altså ikke sammenknytningen til.

Det er muligt at lave protokoller, så man kan se, at smittemeldinger kommer fra en, som man har autoriseret til at kunne afgive smittemeldinger uden at man kan se, hvem af dem, som man har autoriseret, som melder sig smittet i det konkrete tilfælde. Her har Apple/Google sprunget i mål.

Du angav muligheden for replay attack

Hvad forhindrer mig i at gentage det RPI, som jeg har lige fået af dig, lige så mange gange, som jeg har lyst til? Det er for alle praktiske formål umuligt at forfalske RPIer, men der er ikke noget, som forhindrer dem i at blive kopieret og genbrugt.

Det sker selvfølgelig i håbet om, at du afgiver, taber, aftvinges etc. dit TEK, men pludselig kan du have "mødt" en masse, og været en masse steder, som du ikke troede.

Et egentlig håndslag på, at opfattelsen af nærhed var gensidig, ville styrke protokollen på dette punkt. Som det er i dag, så kan jeg sagtens have "mødt" dig, uden at du har "mødt" mig.

Det hele starter med, at du siger:

Men nej, jeg tror heller ikke API'et kan misbruges

...som svar til Jesper om, at han heller ikke tror det. Selvfølgelig kan det misbruges, uanset om vi snakker teori (dvs. protokol) eller praktisk implementation (dvs. API). Det er OK at mene, at muligheder er til at leve med, men det er også noget helt andet end at sige, at det ikke kan misbruges. Det skal "holdes rigtigt" for at virke.

Det er iøvrigt også derfor at jeg lader mig provokere af dem, som siger at "alt hjælper". Det er kun fordi, at man tager skyklapper på, og ignorer at der er en pris, og det kun er hvis man ikke vil forholde sig til det, at "alt hjælper" giver mening. Det kan sagtens være, at det er en god ide ved markant mindre problemer end at Mette lukkede landet ned, men på et tidspunkt må vi sige, at nu bliver ulemperne altså for store til, at vi skal fortsætte. Men det er en anden diskussion, som du svjv. har holdt dig ude af.

Implicit i min "det kan ikke misbruges" lå naturligvis et forbehold for, at en totalitær stat tvinger alle borgere til at udlevere deres TEKs hele tiden :-) Det er dog alt for besværligt i forhold til bare at bruge masteoplysninger, Tik Tok, WeChat eller bare tvinge sine undersåtter til at installere en tracking app...

Jeg er helt enig i den betragtning - specielt fordi appen jo ikke siger noget om hvorvidt du faktisk er blevet smittet, men blot at du (måske) har været tæt på en smittet, og fordi smittekilden er så relativt ligegyldig hvis det skulle blive afsløret hvem det er.

Jeg ser derimod en andne form for "misbrug" som kan blive langt værre, og som ligger "udenom" appen - at appen bliver en slags skudsmålsbog (se hvad det var: https://da.wikipedia.org/wiki/Skudsm%C3%A5lsbog ), f.eks:

• At forsikringsselskaber stiller krav om at du skal bruge appen for at kunne få en livs- eller rejseforsikring (eller få "rabat" på en sådan).

• At trafikselskaber kunne finde på noget tilsvarende, evt. koblet sammen med Rejsekortet, billetbestilling, Dankort (eksempel: Du kan ikke købe en billet med mindre du afleverer en "smittefri" log).

• At arbejdsgivere stiller krav til ansatte om at de skal bruge appen (for at beholde jobbet eller for at vise sig på arbejdspladsen).

• At indrapporterede data bruges af myndighederne imod de hensigter der gælder nu - jeg undrer mig f.eks. over hvorfor alle data skal kopieres til Rigsarkivet.

I dette dystopisk billede er nogle småting omkring snørklede sikkerhedsegenskaber i en app ret ligegyldige - selv om det selvfølgelig er nødvednigt også at diskutere deteljerne. Det bedste udgang må være, at alle kan overbevises om, at denne app ikke på nogen måde kan bruges til noget af det ovenstående, selv om det en gang imellem desværre virker lidt som om politikere og embedsværk tror noget andet.

Jeg synes, nok i modsætning til dig, at det er en fornuftig protokol og en god implementering af Google/Apple.

Nej, her er vi meget enige, i hvertfald i første del (jeg tror på at ting skal være sikre by-design, og det er de ikke, hvis for meget af magien afhænger af implementationen, og derfor har jeg ikke brugt tid på implementationen). Jeg fik sagt andetsteds, at protokollen fin, og lysår bedre end det hjemmestrik, som alle andre virkede til at have gang i.

Men der er nogle ting som undrer mig, og efterlader mig med samme indtryk, som med JavaScript. Det virker som om, at man var i gang med et rigtigt godt stykke arbejde, og var så godt som, men ikke helt færdige, da en leder stikker hovedet ind ad døren og siger "Time's up - release hvad I har", og alle kigger forfærdet på hinanden og siger, "jamen, vi er jo ikke færdige". Det er rigtigt meget godt, men der er noget, som virker som work-in-progress.

Mere om det i næste indlæg, men tillad mig først at være pernitten (når man snakker sikkerhed, så er det ikke nødvendigvis en dårlig ting):

Det kan du kun gøre inden for det timeslot en RPI er gyldig. Ellers vil protokollen dømme dine RPI'er for ugyldige. Timeslottet er ~10 minutter for protokollen.

Nej. Lad mig citere fra afsnittet "Value matching of positive users" i version 1.2 af protokollen:

A +/- two-hour tolerance window is allowed between when a Rolling Proximity Identifier derived from the Diagnosis Key was supposed to be broadcast, and the time at which it was scanned.

Og det skyldes en lavpraktisk forklaring om, at man aldrig må antage at to systemer er enige om, hvad klokken er slået. De kan drive overraskende langt fra hinanden.

Det gør også at tidsvinduet ikke er 10-20 minutter, men derimod noget som ligner 2 timer (hvis vi antager at den, som har lavet RPI og den, som skal snydes er rimeligt enige om tiden, hvad trods alt er det mest almindelige).

...og jeg kan se, at Torben har taget fat i det med at mindre end en totalitær stat kan gre det, så det vil jeg lade ligge.

Der er ting i protokollen, som undrer mig (og efterlader mig med et indtryk af, at man ikke helt er blevet færdig - og mon ikke at det går, som med JavaScript, hvor bordet fangede?).

TEKs genereres ved at lave kryptografisk sikre pseudo-tilfældige tal ud fra en ikke nærmere specificeret algoritme. Heraf afledes ikke en, men to nøgler med en velspecificeret algoritme, nemlig en RPI-key (RPIK) og en AEM-key (AEMK) . RPIK (som samme livcyklus som TEK) bruges til at lave RPIer med, ved at AES kryptere tiden (og nogle konstanter).

En given RPI bruges sammen med AEMK til at kryptere "additional metadata", men det er ikke klart for mig, hvilke data der er tale om, eller hvilken rolle de spiller.

Man kan aflede nøgler af mange grunde, men en af grundene kan være, at beskytte sig imod svagheder i den underliggende nøglegenerering. Selvom kravet er, at der bruges en CRNG til at lave TEKs med, så er den uspecificeret, og der kan være implementationsmæssige problemer som gør det muligt at korrellere TEKs. Derfor giver det god mening at holde TEK hemmelig, og offentliggøre RPIK i stedet. Men det er TEK, som offentliggøres ved smitte?

Det er almindeligt at antage at AES er known-plaintext sikker, så der er ikke nogle praktiske måder at komme fra RPI og til RPIK/TEK. Hvorfor så denne ekstra indirektion? Noget kunne tyde på, at det er artifakt fra version 1.0 af protokollen, hvor man havde en nøgle forever, og hvor det, som i senere versioner er den daglige TEK blev afledt udfra masternøglen og dagnummeret (det var disse daglige TEK ækvivalenter som blev offentliggjort ifm. smitte).

Og hvad laver AEM og AEMK i specifikationen? Hvad er det for metadata, som man påtænker at kode, og iom. at TEK offentliggøres, så ligger alle metadata tilgængeligt for alle, som har den fulde "bluetooth payload". Det er ikke noget, som kan bruges af de individuelle modtagere til noget på modtagelsestidspunktet, for de kender som udgangspunkt ikke TEK. Det tætteste, som jeg har kunnet komme på noget om det, er i BT specifikationen, hvor der skrives flg.:

Associated Encrypted Metadata (AEM) —A privacy preserving encrypted metadata that shall be used to carry protocol versioning and transmit (Tx) power for better distance approximation. The Associated Encrypted Metadata changes about every 15 minutes, at the same cadence as the Rolling Proximity Identifier, to prevent wireless tracking of the device.

Det lyder som meget besvær for noget, som virker ... ufærdigt. Og det bidrager til mit samlede indtryk af, at man har været i en god process, men aldrig fik lov til at gøre det færdigt, rydde op og binde sløjfer, fordi "NU skal det ud af døren!"

Jeg synes faktisk denne gennemgang af protokollen er god:

Ja, den er fin. Jeg kan se, at han også have overset 2 timers vinduet, og derfor tror at der kun er i omegnen af 10 minutter levetid - det burde ellers være et hint, at man ikke skifter hvert 10. minut on the spot, men derimod, når det lige passer indenfor et 10-20 minutters interval. Der vil i praksisk være nogle af de 144 daglige RPIer, som bliver sprunget over.

I BT-delen står der flg.:

On platforms supporting the Bluetooth Random Private Address with a randomized rotation timeout interval, the advertiser address rotation period shall be a random value that is greater than 10 minutes and less than 20 minutes.

...og hvad på platforme, som ikke understøtter "Bluetooth Random Private Address"? Det er en central del af sikkerheden, at der rulles jævnligt, så det forekommer overraskende meget uld-i-mund, at sige det på den måde.

Og så er han præcist lige som hand-wavy som alle andre på korrelation af RPI'er i forhold til tracking. Lad os tage flg. scenarie:

Vi kan lytte på RPIer, og vi modtager jævnligt RPI-1, RPI-2 og RPI-3. Efter et par minutter begynder vi så at modtage RPI-2, RPI-3 og RPI-4, men hører på det tidspunkt aldrig mere til RPI-1. Der, hvor vi stoppede med at høre RPI-1 og der hvor vi begyndte at høre RPI-4, ligger i nærheden af hinanden og begge langt fra indgang og udgang. Sandsynligheden er sikkert god nok til, at vi i praksis kan udlede at RPI-1 og RPI-4 er den samme telefon, og vi har lige fået fingeren på ham i 10-20 minutter mere.

...og her må du godt sige "upraktisk" og "det vil ikke virke hver gang", og du har helt ret, men husk at upraktisk ikke er det samme som sikker, og i høj grad afhænger af, hvor ihærdig man er. Jeg bliver stadig overrasket over, hvor ihærdig man er ... smart-TV som sladrer, reklamer som udsender uhørbare toner, så mikrofoner der lytter i nærheden kan ringe hjem om det.

Jeg synes, at det er en svaghed. Kan den udnyttes? Ja. Vil den blive det? Nok ikke. Men det er stadig en svaghed.

De emulatorer som kan det, laver faktisk ikke nogen særlig god emulering, og ofte ser udfaldet anderledes ud, end når det eksekveres direkte i en Android enhed. Men det kan selvfølgelig være at jeg ikke har været grundig nok, eller bare ikke har fundet en emulator som er god nok.

Jeg har reverse engineered flere app på LDPlayer (vha NPCAP). Det virker ganske godt.

Hvis man bruger tPacketCapture som jeg beskriver ovenfor, så er det ikke noget problem at dekryptere datastrømmen

Derfor skrev jeg også at det er "svært" hvis det er lavet ordentligt. MITM dur ikke hvis de ved hvad de laver mht certifikater. Så må nøglerne fiskes fra memory. Brug en proxy der delayer handshake. Stop emulator processen og find session keys i memory. (Ofte kan man søge på "PRIVATE KEY-----", det kan tage et par sekunder at finde)

Jeg har reverse engineered flere app på LDPlayer (vha NPCAP). Det virker ganske godt.

Jeg indrømmer gerne, at jeg ikke har vildt stor erfaring med Android emulering, og derfor ikke har nok hands-on til at bidrage. Men fedt at se, at vi har værktøjerne der skal til, og at de kan bringes til at virke.

Når jeg ikke har emuleret ret meget, er det fordi jeg har behov for radio APIet og et specielt Qualcomm chipset, til at bygge den måleapplikation jeg bl.a. bruger til kortlægning af mobildækning. Måleappen "kollapser" på en emulator.

Jeg scraper løbende deres API og har lagt alle "ExposureKey" online:

https://xn--sb-lka.org/smittestop/

Der skal ikke være tvivl om hvordan en kritisk, offentlig, sundhedsapp virker. Koden burde havde været åben og at man "sjkuler" ExposureKeys bag en web API med en statisk key virker fjollet.

Min konklusion på decompiling af app'en er også at vi har betalt 9,5M for hvad der allerede fandtes som en PoC plus en NemId integration.

Samt 1M for et cronjob (henting af data fra MiBa), wow.

Ikke i vores firma og formodentlig hellere ikke hos de to andre der er repræsenteret her.

Nu er det vel i bund og grund underordnet hvad i mener, da det er retten der afgører det?!

Når det så er sagt, så har retspraksis i mange år været at oplysningerne bare blev udleveret. Jeg antager dog at det har ændret sig siden Telia og Telenor tog kampen op.

Det er i øvrigt nu ulovligt på grund af GDPR.

Hvad er ulovligt? At udlevere oplysninger på baggrund af en kendelse?

...og hvad på platforme, som ikke understøtter "Bluetooth Random Private Address"? Det er en central del af sikkerheden, at der rulles jævnligt, så det forekommer overraskende meget uld-i-mund, at sige det på den måde

Kunne det tænkes at der her var en af grundene til hvilke OS versioner der er understøttede? Det har været muligt helt fra starten af LE at sætte en random adresse for advertising, tidlige BT versioner skulle bare gøre det fra hosten. Og 2015 kunne godt være deromkring hvor de begyndte at bekymre sig om privacy, så det er meget muligt at den randomising af adressen, som er vigtig her, kom med på det tidspunkt.

At forsikringsselskaber stiller krav om at du skal bruge appen for at kunne få en livs- eller rejseforsikring (eller få "rabat" på en sådan).

At trafikselskaber kunne finde på noget tilsvarende, evt. koblet sammen med Rejsekortet, billetbestilling, Dankort (eksempel: Du kan ikke købe en billet med mindre du afleverer en "smittefri" log).

At arbejdsgivere stiller krav til ansatte om at de skal bruge appen (for at beholde jobbet eller for at vise sig på arbejdspladsen).

Er det bare mig, der er underlig og synes det lyder som nogle fornuftige ideer?

Er der nogen, der kan/har dekompileret Danfoss Link app'en, så man kan simulere protokollen og aflæse og styre temperaturen fra hjemmeautomatikken?

Danfoss har kun åbnet for adgang via Alexa.

Er det bare mig, der er underlig og synes det lyder som nogle fornuftige ideer?

Der er millioner af mennesker som er underlagt noget lignende, og de får hele tiden at vide fra deres regeringer, at det er fornuftigt. De har så heller ingen mulighed for at sige fra, eller i det hele taget at sige noget, så, jo, de ideer stortrives skam.