Implicările ideii de contact-tracing prin Bluetooth Low Energy pentru COVID-19

Google împreună cu Apple au anunţat în 10 aprilie că vor lansa o fundaţie pentru infrastructura tehnologiei de contact-tracing prin Bluetooth Low Level ce ar avea ca scop să ţină evidenţa persoanelor infectate cu CODIV-19 şi a celor ce au intrat in contact cu ele.

Rădăcinile ideii

O astfel de idee îşi are originile undeva prin 2010-2011 la Cambridge University din uk. Era o aplicatie numită FluPhone, ce odata instalată în telefon ea rula în background dincolo de layer-ul vizibil şi se folosea de Bluetooth ca să comunice cu device-urile din proximitatea lui. Răspunsurile împreună cu datele colectate din proximitatea acelui device erau encriptate şi trimise spre un server unde puteau fi analizate.

Dificultăţile apărute

Ca şi probleme etice pe care le ridica acea idee atunci erau că ei nu puteau folosi funcţia gps din cauză că asta ar însemna să faca tracking-ul unei persoane şi să îl ţină pe un server aşa la ochii oricui, milioane de date, milioane de trasee şi persoane, astfel se violau mulţi termeni referitori la intimitatea persoanei. Ar fi fost cumva mai simplu pentru că aşa datele proximităţilor puteai fi lărgite puţin în termeni de geo localizare, nu aveau ca date doar ora şi data în care doua device-uri au făcut schimb de pachete ci şi direct zona în care s-a întâmplat asta. Partea proastă cu GPS-ul era ca pentru activităţile din interiorul locaţiilor nu prea înţelege exact ce se petrece acolo, aici bluetooth pe low energy cu algoritmi bazaţi pe poziţionarea din interiorul locaţiilor excelează.

O altă problema era că ideea funcţiona doar atunci când amândoua device-urile aveau funcţia BT pornită ceea ce ar fi dus la descarcărcarea bateriei prematur pentru că funcţia tot încerca să caute device-uri la un interval mic de timp. La Bluetooth-ul normal clasic de atunci consumul de energie era 30mA faţă de cel modern de acum BLE pe 15mA. Plus că cel clasic putea iniţia doar 7 conexiuni simultan, faţă de cel nou ce poate interacţiona cu ~20 device-uri în acelaşi timp. Ultima problema e foarte importantă pentru că în cazul unei infecţii în masă ideea trebuie să functioneze şi atunci cănd o persoană infectata intra într-un magazin de exemplu cu 20 persoane în proximitatea lui. Daca 7 doar pot schimba date cu device-ul celui infectat şi celelalte 13 nu primesc nimic, ideea nu e stabilă.

Un alt avantaj pe care îl are Bluetooth pe tehologia low energy e ca are 40 de canale fizice de comunicaţie în aria de bandă 2.4GHz despărţite fiecare de 2MHz. Are 2 tipuri de canale, pentru date şi pentru reclame. 37 fiind destinate pentru date şi 3 pentru advertising.

Ce elemente aduce Google pe partea de contact-tracing

Cei de la Google & Apple ziceau în articolul lor că lansează program-ul de contact tracing în două faze începând cu un API pe la jumătatea lui mai ce se va asigura că aplicaţiile iOS şi Android pot urmări utilizatorii indiferent de sistemul de operare pe care îl folosesc, dar o să fie accesul o să fie doar din app-urile oficiale. Practic ei testează puţin apele să vadă cum merge treaba şi cam câţi oameni se vor alătura programului.

În a doua fază ei se vor baza exclusiv pe sistemul de operare push-uind nişte update-uri de sistem şi pe Android si pe iOS care, cred eu, ca totuşi vor avea nevoie de aprobarea deţinătorului pentru că aşa mi se pare normal.

După cum am scris mai sus prin rădăcinile ideii de contact tracing ce se baza pe Bluetooth, aşa şi cei din Google vor să implementeze ceva bazat pe Bluetooth Low Energy. Ei nu se vor mai folosi de aplicaţii pentru a schimba chei între device-uri ci de magia Bluetooth-ului. Iar cum toate device-urile suporta BLE încă din 2011 asta ar fi cam cea mai bună soluţie.

În documentele tehnice ataşate de Google în anunţ se află şi primul ataşament ce e zic eu cel mai crucial şi anume ce implică tehnologia în raport cu intimitatea individului.

• va avea nevoie de acordul persoanei, probabil la nivel de instalare app în primă fază şi mai apoi în update-ul de sistem;
• nu ar colecta date personale despre celelealte persoane cu care ai intrat in contact, ori date geografice din zona respectiva
• lista cu persoane cu care ai intrat in contact nu părăseşte telefonul tău, cheile primite ar trebui să fie disponibile doar pentru cui i se dă acest drept

Pe partea tehnică a implementării tehnologiei de contact Tracing prin BLE :

Ca elemente a ceea ce înseamnă acest mecanism de contact tracing:

Contact Detection Service – un serviciu din modulul de Bluetooth LE necesar pentru a detecta proximitatea altui device.

Tracing Key – cheia unică a device-ului

     tracing key-ul se derivă astfel
      tk ← CRNG(32)
     *CRNG - generator de numere random criptografice

Daily Tracing Key – cheia regenerata o dată la 24h

    Pentru a afla tracing key-ul e nevoie sa fie definita ziua, derivata la 
    randul ei din timpul in format epoch unix pe numarul total de secunde 
    dintr-o zi.
    Day_Number = Epoch / (24*60*60)
  
    Cheia zilnica trece printr-o functie de derivare a cheilor 
    criptografice cu urmatorii parametrii:
     -> HKDF(Key, Salt, Info, OutputLength)
     
    dtki ← HKDF(tk , NULL, (UTF8("CT-DTK")||Di),16)

Funcția HKDF utilizează o cheie secretă, în acest caz, tracing key-ul, împreună cu funcția de hash SHA-256, pentru a crea un cod de autentificare a mesajelor (sau „HMAC”). Apoi extrage o cheie pseudorandom („PRK”) din HMAC și o concatenează la un număr Day_number ce indica ziua respectivă.

Ideea cu HDKF e că merge pe două etape, extracţie şi expandare. Extracţia se face prin: HKDF-Extract(salt, IKM) după manual, însă aici cei de la Google fac o şmecherie şi mută key-ul adică daily tracing key-ul ca prim parametru şi salt-ul următorul. Pentru ca poate dacă ar avea salt-ul primul fiind null sau ceva usor de dibuit, ar face treaba putin mai usoara la un bruteforce. Si prk-ul rezultat din prima etapa a extracţiei mergând pe ideea lor: HMAC-Hash(tk, salt)

Care mai apoi e parsat in expandare prin: HKDF-Expand(PRK, info, L) -> de unde rezultă cheia finală OKM prin mai multe cicluri succesive de concatenari asupra prk-ului extras din prima etapă. Truncată la 128biţi.

Identificatorul de proximitate

Un identificator privat derivat din cheile zilnice de urmărire şi din intervalul de timp în care a fost generat. Obţinut prin:

RPIi, j ← Truncate(HMAC(dkti , (UTF8("CT-RPI") || TINj)),16)

Unde TINj este valoarea timpului în care adresa BLE MAC se schimbă. 
Fiecare cheie de identificare trebuie să conţină o adresă diferită. 
dkti ar fi cheia zilnică ce se trimite împreună cu 
mesajul de autentificare ce e intervalul generarii acelei chei. 

Identificatorul e o cheie generata la fiecare 10 minute pe parcursul a 24 de ore. Un interval format din [0, 140]. Practic sunt pot fi 144 chei per zi. Foloseste hmac ca mecanism de autentificare utlizând funcţii de dispersie şi preia cheia generată prin hkdf, cheia zilnică ce e privată şi mai aplică pe ea concatenări cu timpul generării.

Ce se va intampla prin acest sistem e că se va face publicitate periodic asupra serviciului de urmărire a contactelor prin trimiterea datelor pe care alte dispozitive le pot asculta și păstra un log. Specificația pentru serviciul de urmărire a contactelor solicită trimiterea acestei reclame la fiecare 200-270 de milisecunde, sau de aproximativ 5 ori pe secundă. Aceste reclame vor fi difuzate la nesfârșit dacă serviciul e pornit. Pentru a face acest lucru în siguranță, se va crea un „Identificator de proximitate continuu” aproximativ la fiecare 10-15 minute cum am explicat în zona cheii identificatorului de proximitate și va pune acest identificator unic în load-ul datelor pe care le trimite prin Bluetooth.

*advertising-ul dintre dispozitive este tehnologia de transmitere a beacons-urilor printr-un dispozitiv ce funcţionează pe nişa undelor radio 2.4GHz. Spre exemplu când intrăm într-un magazin de haine cu serviciul BT pornit păţim de multe ori să primim o notificare pe telefon cu ceva ce are legătură directă cu acel magazin.

Când telefonul face publicitate de date cu privire la orice serviciu Bluetooth, trebuie să includă și o adresă pentru dispozitiv. Iar din acest motiv pentru a împiedica persoanele să asocieze adresa dispozitivului cu o listă de identificatori de proximitate, specificația de urmărire a contactului solicită ca adresa dispozitivului să fie aleatorie și să o schimbe la fiecare 15 minute în același timp, se schimbă identificatorul de proximitate. Am discutat mai sus despre TINj care solicită o noua adresă mac la fiecare 10-15min. Pentru a prelua identificatorii de proximitate, aproximativ la fiecare 5 minute, dispozitivul va scana serviciul Bluetooth și va înregistra toate identificatoarele pe care le descoperă. Acest log al proximității este stocat doar pe dispozitivul vostru. Cheile zilnice primite de la alte persoane sunt impachetate în acel identificator de proximitate care e trimis de cine e în jurul device-ului vostru.

Un reverse engineering aici e destul de dificil de făcut deoarece totul porneşte de la cheia zilnică generată, tk. Aceea nu pleacă niciodată din device. Ea e folosită pentru formarea cheilor zilnice. Cheia zilnică e mai apoi folosită în identificatorii de proximitate ce pot fi în jur de 144 pe zi.

Cheile de diagnoză.

Cheile de diagnoză sunt cheile zilnice ale unei persoane infectate care şi-a dat acordul ca acele chei să fie urcate pe un server. Povesteam mai sus despre cum se formează identificatorul de proximitate. E foarte important acel aspect deoarece şi cheile de diagnoză ce vor fi urcate după confirmarea unei infecţii sunt cheile din ultimele ~14zile care vor trece prin acelasi pas din momentul urcării lor pe server şi până la generarea identificatorilor de proximitate.

În momentul în care aplicaţia începe fetch-ul cheilor de diagnoză, ea foloseşte acelaşi algoritm de la identificatorul de proximitate pentru a genera toate hash-urile identificatorilor de proximitate generaţi împreuna cu intervalul lor. Odată generate acestea, aplicaţia se uită dacă printre hash-urile primite la voi în device există vreunul care sa se potrivească cu ce a reieşit din acele chei zilnice ale persoanei infectate. Daca se gaseste vreunul reiese că aţi fost în contact cu acea persoană(cheie) în ziua z. Eventual se poate extrage şi intervalul(ziua, ora) când s-a întâmplat ce contează foarte mult pentru urmărirea evoluţiei infecţiei de la acele chei de diagnoză, ce voi explica într-un alt articol.

Apple-and-Google-partner-covid-19-contact-tracing-technology