Implementarea Software a Conceptului Shadowkey Cheie Rf Controlata Prin Nfc

Cuprins

1 Introducere 4

1.1 Domenii de abordare și obiective generale 4

1.2 Contextul de realizare 5

1.3 Specificații generale 6

2 Sisteme de acces în automobile existente 7

3 Noțiuni generale despre NFC 10

3.1 Dispozitive NFC 10

3.2 Tehnologii NFC 11

3.3 Ciclul de detecție 12

3.4 Protocoale de comunicație NFC 13

3.5 Tehnologia NFC-A 15

3.5.1 Modulația semnalului purtător și codificarea biților 15

3.5.2 Structura cadrelor de date 16

3.5.3 Setul de comenzi și răspunsuri 18

3.6 Platforma Type 4A Tag 19

3.6.1 Setul de comenzi și răspunsuri 19

3.7 Mesaje NDEF (NFC Data Exchange Format) 20

3.8 Transferul de date cu platforma Type 4A Tag 22

3.8.1 Setul de comenzi și răspunsuri ISO-DEP 22

3.8.2 Gestionarea memoriei platformei Type 4A Tag 23

3.8.3 Procedura de detecție a unui mesaj NDEF 24

3.8.4 Procedura de citire a unui mesaj NDEF 27

3.8.5 Procedura de scriere a unui mesaj NDEF 27

4 Descrierea generală a conceptului Shadow Key 29

4.1 Comunicația între smartphone și cheia Shadow Key 29

4.2 Simulatorul PC AK3G 31

5 Cheia RF Shadow Key 32

5.1 Facilitățile microcontroller-ului Keylink 32

5.2 Sursele de alimentare ale cheii 33

5.3 Arhitectura SW generică RFKPOLAR 34

5.4 Implementarea emulării de card Type 4A 38

5.5 Implementarea protocolului de transmisie RF AK3G 42

6 Aplicația Shadow Key pentru Android 45

6.1 Componente ale unei aplicații Android 45

6.2 Mecanisme Android pentru transferul datelor prin NFC 47

6.2.1 Detecția unui card Type 4A și citirea mesajelor NDEF 48

6.2.2 Scrierea mesajelor NDEF pe un card Type 4A 49

6.3 Implementarea aplicației 50

7 Concluzii și perspective 56

7.1 Implementarea comunicației criptate la nivel NFC 56

7.2 Autentificarea utilizatorului în sistem 57

8 Referințe bibliografice 58

9 Anexa 1. Structura comenzilor și răspunsurilor definite de tehnologia NFC-A 59

10 Anexa 2. Structura comenzilor și răspunsurilor definite de platforma Type 4A Tag 62

Introducere

În industria automobilelor, marile companii rivale sunt într-o continuă competiție în a furniza soluții care să facă conducerea automobilelor o experiență mai plăcută, mai sigură, mai simplă și mai accesibilă unui segment de piață cât mai larg. Un element esențial îl constituie interfețele (HMI – Human Machine Interface) dintre automobil și utilizator, care se impun a fi cât mai simple și intuitive în condițiile creșterii accelerate a numărului de funcționalități care sunt puse la dispoziție de automobile.

De asemenea, în condițiile în care utilizatorul interacționează cu o multitudine de alte sisteme electronice (smartphone, smartwatch) în viața de zi cu zi, este de preferat ca interacțiunea dintre acesta și automobil să se facă pe cât posibil prin elemente încorporate în automobil (ex: Head Unit – sistem multimedia încorporat în consola centrală), la care să se adauge un număr minim de elemente pe care utilizatorul ar trebui să le poarte asupra sa.

Domenii de abordare și obiective generale

În domeniul sistemelor de acces în automobile, un factor determinant îl reprezintă securitatea. Sistemele actuale de acces se bazează, în principal, pe o comunicație radio între identificatorul utilizatorului (cheie) și mașină. Informația transferată este criptată și două acțiuni similare consecutive din partea utilizatorului (ex: intenția de a descuia mașina) nu vor produce informații transferate similare. Deci, dezideratul securității este asigurat de sistemele actuale, cu atât mai mult cu cât dezvoltarea lor se bazează pe o experiență de peste 10 ani.

În ceea ce privește factorul interfeței dintre utilizator și mașină, în contextul celor descrise mai sus, sistemele de acces actuale impun ca utilizatorul să poarte asupra sa, în permanență, elementul prin care se autentifică în sistem – cheia automobilului. Ar fi de preferat ca acest element de autentificare să fie încorporat în alt dispozitiv electronic la care utilizatorul are acces în permanență, de exemplu smartphone-ul.

Conceptul Shadow Key propune o cheie clasică având în plus capabilități de comunicație NFC, care este atașată în permanență smartphone-ului și controlată de acesta prin NFC. Cheia are ca și input comenzile recepționate prin NFC, care înlocuiesc butoanele necesare în cazul unei chei clasice. Interfața utilizatorului cu sistemul va fi o aplicație mobilă pe smartphone care gestionează comunicația NFC cu cheia.

Un studiu de piață arată că în 2015 există 1,7 miliarde posesori de smartphone-uri la nivel global și este preconizat ca până în anul 2018 această cifră să ajungă la valoarea de 2,7. Dintre smartphone-urile lansate pe piață în anul 2015, aproximativ 30% au capabilități NFC, dar și în acest caz este preconizat ca acest procent să atingă valoarea de 55% la finalul anului 2017.

Contextul de realizare

Conceptul Shadow Key a fost dezvoltat în cadrul departamentului „Interior Body and Security” al companiei Continental Automotive România. Scopul principal este de a simplifica accesul în automobile din perspectiva utilizatorului, prin încorporarea elementului de autentificare în sistem (cheia) în telefonul mobil. Momentan, conceptul este în stadiul de prototip funcțional cu scop demonstrativ.

La dezvoltarea acestui proiect au participat mai mulți angajați din cadrul departamentului, respectiv:

Un coordonator al proiectului

Pe disciplina hardware: un inginer care a proiectat schema plăcii la nivel hardware

Pe disciplina proiectare mecanică: un inginer care a proiectat carcasa și forma cheii

Pe disciplina software: autorul lucrării de față

Desfășurarea activităților autorului lucrării a fost realizată prin suportul Domnului Ș.l. dr. ing. Sebastian FUICU și a coordonatorului proiectului din cadrul companiei Continental, ing. Adrian RADU, responsabilul funcționalității de cheie în cadrul grupului software „Sisteme de Acces” din cadrul departamentului „Interior Body and Security”.

Specificații generale

Conceptul Shadow Key propune o cheie clasică având în plus capabilități de comunicație NFC, care este atașată în permanență smartphone-ului și controlată de acesta prin NFC. Cheia are ca și input comenzile recepționate prin NFC, care înlocuiesc butoanele necesare în cazul unei chei clasice. Interfața utilizatorului cu sistemul va fi o aplicație mobilă pe smartphone care gestionează comunicația NFC cu cheia.

Cazurile de utilizare din perspectiva utilizatorului sunt aceleași ca și în cazul unui sistem de acces clasic. Sistemul trebuie să pună la dispoziția utilizatorului funcționalități precum:

Descuie mașina

Încuie mașina

Deschide portbagajul

Aprinde luminile

Sisteme de acces în automobile existente

În momentul de față, există două categorii importante de sisteme de acces în automobile: sistemele de acces clasice bazate pe dispozitive de identificare a utilizatorului (chei) fizice și categoria mai nouă de sisteme de acces bazate pe chei virtuale.

Sistemele de acces clasice (vezi Figura 2-1, 2-2) sunt sistemele RKE/PASE bazate pe chei RF/LF.

Figura 2-1 Sistem de acces clasic RKE

RKE (Remote Keyless Entry) este scenariul în care utilizatorul execută o cerere către sistem prin apăsarea unui buton de pe cheie. Cheia va transmite un set (de dimensiune variabilă, în funcție de durata apăsării) de cadre de date prin RF către mașină, care la recepție va executa niște verificări asupra informației primite și dacă verificările trec va executa acțiunea intenționată de utilizator. Cazuri de utilizare posibile ale sistemelor RKE sunt: descuierea/încuierea mașinii, deschiderea portbagajului, coborârea/ridicarea geamurilor (la apăsări lungi), aprinderea farurilor, pornirea alarmei.

Figura 2-2 Sistem de acces PASE

PASE (PAssive Start and Entry) este un scenariu care, după cum sugerează și numele, este pasiv din punctul de vedere al utilizatorului. Utilizatorul face cereri către sistem, de exemplu, prin acționarea mânerului ușii când mașina este închisă. În acel moment are loc o autentificare rapidă (sub 100ms) între cheie și mașină. De această dată, mașina (dotată cu un set de antene LF) este cea care inițiază comunicația trimițând o comandă pe LF cheii. Aceasta răspunde prin LF/RF. Dacă autentificarea are succes, mașina se descuie până când utilizatorul acționează complet mânerul ușii. În continuare, mașina descuiată va testa periodic prezența cheii în apropierea sa iar atunci când cheia se îndepărtează, se va încuia automat. Alt caz de utilizare al sistemelor PASE este pornirea motorului prin apăsarea unui buton din mașină, fără a introduce cheia în contact.

Sistemele de acces clasice implică o procedură de învățare între cheie și mașină care se desfășoară la service, sub diagnoză. În timpul procedurii de învățare, are loc o comunicație între cheie și mașină în care mașina obține identificatorul unic al cheii ce urmează a fi învățată iar cheia obține din partea mașinii cheia de criptare care va fi folosită pentru criptarea comunicației începând din acest moment.

Prin urmare, sistemele clasice au avantajul securității, întreaga comunicație fiind criptată. În plus, două cereri consecutive similare ale utilizatorului către sistem nu vor produce informații similare transferate între componente, datorită faptului că în protocoalele de comunicație sunt prezente și elemente variabile (exemplu: contoare de apăsări la RKE) gestionate atât de cheie, cât și de mașină. De asemenea, sistemele de acces clasice se bazează pe o experiență în dezvoltare de peste 10 ani.

Dezavantajul acestor sisteme este necesitatea utilizatorului de a avea elementul de autentificare în sistem – cheia – asupra sa în permanență.

La capătul opus se situează sistemele de acces (încă în fază de prototip) bazate pe chei virtuale care elimină cheile fizice RF/LF. Utilizatorul folosește smartphone-ul pentru a face cereri către sistem. Cheile virtuale sunt generate pe un server după care sunt transmise fie către smartphone-ul utilizatorului, care le va trimite mai departe către mașină printr-un standard precum NFC/Bluetooth/Wi-Fi, fie direct către mașină în cazul în care aceasta este dotată cu o conexiune permanentă la internet.

Sistemele de acces bazate pe chei virtuale au avantajul că elimină necesitatea utilizatorului de a purta asupra sa elementul de autentificare (cheia fizică din sistemele clasice), fiind suficient să aibă asupra sa smartphone-ul personal cu o aplicație instalată.

Totuși, aceste sisteme au și dezavantaje, în principal prin prisma securității, întrucât cheile virtuale circulă prin internet, decriptarea acestora fiind doar o problemă de timp. În plus, tehnologia este relativ nouă, neputându-se baza pe anii de experiență în dezvoltarea sistemelor de acces clasice.

Noțiuni generale despre NFC

NFC (Near Field Communication) este un standard pentru transferul de date între dispozitive electronice, fără fir, pe distanțe mici, tipic sub 10 cm. Exemple de aplicații tipice pentru NFC sunt:

e-payment: soluțiile pentru plată electronică;

identificare personală: acces la transportul în comun sau în clădiri;

transfer de date: partajare de contacte, poze, video, alte fișiere;

inițierea de conexiuni pe alte standarde, cum ar fi Bluetooth sau Wi-Fi, cu interacțiune minimă din partea utilizatorului

Avantajele aplicațiilor bazate pe tehnologia NFC sunt:

interacțiunea redusă cu utilizatorul

posibilitatea implementării de dispozitive NFC fără sursă de alimentare proprie

securitatea datorată, în principal, distanței mici la care se efectuează comunicația între dispozitive

Specificațiile standardului NFC sunt dezvoltate de o organizație numită NFC-Forum, înființată în anul 2004 de către Nokia, NXP și Sony. În [13] se menționează: „Organizația NFC-Forum a fost înființată pentru a îndemna la folosirea tehnologiei NFC prin dezvoltarea de specificații, asigurarea interoperabilității între dispozitive și servicii și educarea pieței relativ la tehnologia NFC”.

Dispozitive NFC

NFC-Forum definește în mod generic un dispozitiv NFC în [2], ca fiind un dispozitiv prevăzut cu o antenă legată la un circuit electronic.

Figura 3-3-1Dispozitive NFC în modurile poll și listen (sursa: [2])

Comunicația între două dispozitive NFC presupune întotdeauna ca unul dintre cele două să fie în mod poll iar celălalt în mod listen. În timpul funcționării, un curent alternativ străbate bobina primară (antena dispozitivului în mod poll) și aceasta generează un câmp electromagnetic care induce un curent în bobina secundară (antena dispozitivului în mod listen). Dispozitivul în mod listen poate folosi câmpul generat de dispozitivul în mod poll pentru a se alimenta.

Energia RF transmisă de dispozitivul în mod poll activează sau trezește dispozitivul în mod listen și este folosită pentru a transmite date prin modularea semnalului purtător. Pentru a răspunde, dispozitivul în mod listen folosește tehnica denumită „load modulation”. Aceasta se bazează pe cuplajul electromagnetic dintre cele două dispozitive, similar cu transferul de putere și comunicația de la dispozitivul poll către dispozitivul listen. Dispozitivul în mod listen ajustează curentul din antena proprie iar această variație este detectată de dispozitivul în mod poll ca o mică variație a curentului din antena proprie.

Tehnologii NFC

Semnalul purtător în cazul dispozitivelor NFC are o frecvență de valoare fixa: 13,56 Mhz. NFC-Forum definește prin [3] trei tehnologii NFC având ca și particularități distinctive: tipul de modulație aplicat semnalului purtător, codificarea biților, mecanismele de prevenire a coliziunilor, structura cadrelor de date și setul de comenzi/răspunsuri necesare pentru detecția și/sau selecția eventualelor dispozitive prezente în raza de acțiune. Cele trei tehnologii sunt NFC-A, NFC-B și NFC-F iar particularitățile amintite sunt descrise în Tabelul 3-1. Dispozitivele NFC pot implementa una sau mai multe dintre aceste tehnologii.

Tabelul 3-3-1 Tehnologii NFC

Ciclul de detecție

Dispozitivele NFC se împart în două mari categorii: dispozitive active și dispozitive pasive.

Dispozitivele pasive sunt dispozitive fără sursă de alimentare proprie și, prin urmare, nu pot genera câmp electromagnetic. Exemple de astfel de dispozitive sunt card-urile NFC. Acestea implementează o singură tehnologie NFC dintre cele amintite mai sus și se află tot timpul în modul listen. Idealizat, pot fi privite ca fiind alcătuite din antena legată la un circuit digital responsabil cu interpretarea comenzilor recepționate și generarea răspunsurilor, acest circuit incluzând sau fiind conectat la o memorie nevolatilă (memoria card-ului). NFC-Forum definește la nivel de specificații, prin [5], [6], [7], [8] cinci tipuri de card-uri: Type 1 Tag, Type 2 Tag, Type 3 Tag, Type 4A Tag, Type 4B Tag, fiecare având particularități legate de tehnologia NFC pe care o implementează, structura memoriei, protocoalele de comunicație utilizate.

Dispozitivele active, pe de altă parte, sunt dispozitive prevăzute cu sursă de alimentare și pot genera câmp. Ca și exemple se pot considera smartphone-urile cu NFC (Samsung Galaxy S4, S5, S6, seria Nexus, etc.), cititoarele NFC din mijloacele de transport în comun sau de la intrările în anumite clădiri ș.a.m.d. Acestea pot implementa mai multe tehnologii iar modurile poll și listen sunt alternate în decursul procesului de detecție într-o buclă denumită „ciclul de detecție” (Figura 3-2).

Figura 3-3-2 Ciclul de detecție al dispozitivelor NFC active

În decursul fazelor de poll, dispozitivul activ trimite comenzile de detecție/selecție specifice fiecărei tehnologii pe care o implementează și așteaptă un răspuns din partea unui dispozitiv pasiv sau activ (aflat în faza de listen) care ar putea fi prezent în raza sa de acțiune.

În decursul fazei de listen, dispozitivul activ răspunde comenzilor de detecție/selecție corespunzătoare tehnologiilor pe care le implementează, trimise de către un alt dispozitiv activ (aflat într-o fază de poll), în raza de acțiune a căruia s-ar putea afla.

Durata ciclului de detecție are o valoare configurabilă, valoarea tipică folosită de cele mai multe dispozitive fiind 500ms.

Protocoale de comunicație NFC

Protocoalele de comunicație NFC nu sunt complexe, dar complexitatea rezultă din diversitatea lor (Tabelul 3-2). NFC-Forum definește o serie de activități în decursul comunicației, cum ar fi: prevenirea coliziunilor RF, detecția tehnologiilor NFC, activarea unui dispozitiv NFC, transferul de date utile între dispozitive și altele.

Selecția protocolului utilizat în comunicația NFC depinde de factori cum ar fi:

Activitatea în care se află comunicația

Tehnologia NFC utilizată pentru comunicație

Tipul dispozitivelor NFC care comunică

Tabelul 3-3-2 Activități și protocoale NFC utilizate

Ar mai fi de menționat faptul că dispozitivele active pot avea unul din următoarele roluri în comunicație:

Reader/Writer: dispozitivul activ aflat în mod poll se comportă precum un cititor de card wireless folosind comenzi dintr-un subset al unei tehnologii (ex: un subset al tehnologiei NFC-A îl constituie Platforma Type4A Tag + Protocolul ISO-DEP)

Peer to Peer: un dispozitiv activ aflat în mod poll comunică cu un dispozitiv activ aflat în mod listen la nivel de conexiune logică; dispozitivul aflat în mod poll poartă denumirea de initiator iar cel aflat în mod listen poartă denumirea de target

Card Emulator: dispozitivul activ aflat în mod listen se comportă precum un card standard, răspunzând la comenzi dintr-un subset al unei tehnologii

Prin urmare, Protocolul NFC-DEP se folosește pentru activarea și transferul de date între două dispozitive active, unul fiind în mod poll (initiator) iar celălalt în mod listen (target) pe una din tehnologiile NFC-A sau NFC-F. NFC-Forum definește și protocoale de nivel superior protocolului NFC-DEP (nivel Data-Link), cum ar fi:

LLCP (Logical Link Control Protocol): protocol de nivel Transport orientat pe conexiune logică; prevede mecanisme pentru segmentarea pachetelor de dimensiuni mari și garantează faptul că segmentele ajung la destinație în ordinea în care au fost transmise, folosind un mecanism de confirmări

Protocoale de nivel aplicație:

SNEP (Simple NDEF Exchange Protocol): transferul mesajelor NDEF (Nfc Data Exchange Format – structura de date definită în standard); mecanismul Android Beam este o implementare a protocolului SNEP

Connection Handover: transfer de date în vederea inițierii unei conexiuni între dispozitive pe un standard altul decât NFC (ex: Bluetooth,Wi-Fi)

Platformele Type <N> Tag sunt folosite în cazul activării de către un dispozitiv activ a unuia pasiv (card/dispozitiv activ aflat în rolul card emulator) și definesc un set de comenzi/răspunsuri pentru negocierea anumitor parametrii (dimensiunea maximă a cadrelor de date, rata de transfer).

Protocoalele Half-Duplex Type 1/2/3 Tag și ISO-DEP sunt folosite în cazul transferului de date între un dispozitiv activ și unul pasiv (card/dispozitiv activ aflat în rolul card emulator) și definesc un set de comenzi/răspunsuri care permit dispozitivului activ să citească sau să scrie memoria card-ului.

Tehnologia NFC-A

Acest capitol prezintă particularitățile tehnologiei NFC-A specificate de NFC-Forum prin [3].

Modulația semnalului purtător și codificarea biților

Dispozitivul aflat în mod poll aplică semnalului purtător o modulație ASK 100%, folosind codificarea Miller modificată.

Figura 3-3-3 Codificare Miller modificată cu ASK 100% (sursa: [3])

Codificarea biților de către dispozitivul aflat în mod poll se face după următoarele reguli:

Pentru biții cu valoare 1, dispozitivul va folosi tiparul X

Pentru biții cu valoare 0 izolați între biți cu valoare 1, dispozitivul va folosi tiparul Y

Pentru secvențe de biți cu valoare 0 consecutivi, dispozitivul va folosi:

Tiparul Y pentru primul bit 0

Tiparul Z pentru următorii biți 0

Dispozitivul aflat în mod listen aplică semnalului purtător modulație prin subpurtătoare OOK, folosind codificarea Manchester.

Figura 3-3-4 Codificare Manchester cu OOK (sursa: [3])

Codificarea biților de către dispozitivul aflat în mod listen se face după următoarele reguli:

Pentru biții cu valoare 1, dispozitivul va folosi tiparul D

Pentru biții cu valoare 0, dispozitivul va folosi tiparul E

Structura cadrelor de date

Tehnologia NFC-A definește trei tipuri de cadre de date:

Cadrul de date scurt

Cadrul de date standard

Cadrul de date SDD (Single Device Detection)

Cadrul de date scurt (Figura 3-5) este folosit pentru a iniția comunicația și este alcătuit din:

SoF bit (Start of Frame)

7 biți de date, primul fiind cel mai puțin semnificativ

EoF bit (End of Frame)

Figura 3-3-5 Structura cadrului de date scurt – Tehnologia NFC-A (sursa: [3])

Cadrul de date standard (Figura 3-6) este folosit pentru transferul de date și este alcătuit din:

SoF bit (Start of Frame)

N*(8 biți de date + bit de paritate); bitul de paritate trebuie setat astfel încât numărul de biți 1 din secvența formată din (8 biți de date + bitul de paritate) să fie impar

EoF bit (End of Frame)

Figura 3-3-6 Cadrul de date standard – Tehnologia NFC-A (sursa: [3])

Cadrul de date SDD (Figura 3-7) este folosit pentru rezolvarea coliziunilor și este, practic, un cadru de date standard cu lungime 8 octeți care este secționat în două. Secționarea se poate face după orice bit de date din cadrul standard.

Figura 3-3-7 Cadrul de date SDD – Tehnologia NFC-A (sursa: [3])

Biții SoF și EoF din cadrele de date definite de tehnologia NFC-A se codifică după următoarele reguli:

Dispozitivul în mod poll codifică SoF și EoF ca biți cu valoarea 0

Dispozitivul în mod listen codifică:

SoF ca bit cu valoarea ca bit cu valoarea 1

EoF nemodulând semnalul purtător pentru durata unui bit

Datele transferate folosind un cadru de date standard au structura prezentată în Figura 3-8, unde câmpul „Payload” conține comanda sau răspunsul NFC-A iar câmpul EoD este opțional (în funcție de conținutul câmpului „Payload”) și, dacă este prezent, conține o sumă de control calculată peste octeții din câmpul „Payload”.

Datele transferate folosind cadrele de date scurt sau SDD nu includ câmpul EoD.

Figura 3-3-8 Structura datelor transferate folosind un cadru standard NFC-A (sursa: [3])

Setul de comenzi și răspunsuri

Datele transferate între dispozitivele NFC constau în comenzi și răspunsuri. Tehnologia NFC-A definește un set de comenzi/răspunsuri care sunt folosite în procesul de detecție. Dispozitivul în mod poll trimite comenzi pentru a verifica dacă în raza sa de acțiune există dispozitive aflate în mod listen care implementează tehnologia NFC-A sau pentru a selecta unul din aceste dispozitive iar dispozitivele în mod listen răspund la comenzile recepționate de la dispozitivul în mod poll. În Tabelul 3-3 sunt prezentate comenzile definite de tehnologia NFC-A, răspunsurile corespunzătoare, tipul de cadre de date folosit pentru transferul acestora și necesitatea prezenței câmpului EoD prezentat în capitolul anterior.

Tabelul 3-3 Setul de comenzi/răspunsuri definit de Tehnologia NFC-A

Comenzile ALL_REQ și SENS_REQ sunt trimise de către dispozitivul aflat în mod poll pentru a verifica dacă în raza sa de acțiune există dispozitive NFC-A în mod listen. Dacă există, acestea răspund prin SENS_RES, răspunsul incluzând dimensiunea identificatorului unic al dispozitivului. Această dimensiune poate fi 4,7 sau 10 octeți.

Comanda SDD_REQ este trimisă de către dispozitivul aflat în mod poll pentru a obține identificatorul unic al dispozitivului aflat în mod listen și pentru a detecta dacă există mai multe dispozitive NFC-A în mod listen aflate în raza sa de acțiune. Răspunsul SDD_RES conține întregul identificator unic al dispozitivului în mod listen sau doar o porțiune din acesta.

Comanda SEL_REQ este trimisă de dispozitivul în mod poll pentru a selecta un dispozitiv în mod listen prin intermediul identificatorului unic al acestuia. Răspunsul SEL_RES indică capabilitățile dispozitivului în mod listen referitor la platformele/protocoalele NFC implementate: platforma Type 2 Tag și/sau platforma Type 4A Tag și/sau protocolul NFC-DEP.

Comanda SLP_REQ este trimisă de dispozitivul în mod poll pentru a pune dispozitivul în mod listen în starea SLEEP, ceea ce înseamnă că acesta va mai răspunde doar la comanda ALL_REQ. Nu este definit un răspuns la această comandă.

Structura comenzilor definite de tehnologia NFC-A este prezentată în detaliu în Anexa 1.

Platforma Type 4A Tag

Acest capitol prezintă particularitățile platformei Type 4A Tag specificate de NFC-Forum în [3].

Platforma Type 4A Tag este bazată pe tehnologia NFC-A. Modularea semnalului purtător și codificarea biților se face conform mecanismelor tehnologiei NFC-A, comenzile și răspunsurile sunt transferate în cadre de date standard NFC-A și este inclus câmpul EoD prezentat în capitolul anterior.

Setul de comenzi și răspunsuri

Platforma Type 4A Tag definește un set de comenzi/răspunsuri care sunt folosite în procesul de activare. Dispozitivul aflat în mod poll trimite comanda RATS pentru a negocia dimensiunea maximă a unui cadru de date și rata de transfer cu dispozitivul aflat în mod listen. Acesta răspunde cu răspunsul RATS. Structurile comenzii și răspunsului RATS sunt detaliate în Anexa 2.

Prin negocierea acestor parametri se încheie procesul de activare și poate începe transferul de date utile între dispozitive. Acesta se efectuează utilizând protocolul ISO-DEP(ISO 14443-4).

Mesaje NDEF (NFC Data Exchange Format)

Un mesaj NDEF este o structură de date definită de NFC-Forum în [4], care permite încapsularea unor date al căror tip este definit la nivel de aplicație. Fiecare mesaj NDEF este compus dintr-un tip (tipul datelor stocate), datele în sine și un identificator care este opțional. Informația de pe card-urile NFC poate fi organizată conform structurii de date NDEF.

Este prevăzut și un mecanism pentru segmentarea datelor, segmentele rezultate purtând denumirea de înregistrări NDEF. Un mesaj NDEF poate fi alcătuit din una sau mai multe înregistrări NDEF.

Înregistrările NDEF pot fi segmente formate din date de același tip sau pot fi înregistrări cu date de tipuri diferite. Structura generală a unei înregistrări NDEF este prezentată în Figura 3-9.

Figura 3-9 Structura unei înregistrări NDEF (sursa: [4])

Bit-ul MB (Message Begin) este folosit pentru a indica începutul unui mesaj NDEF. Acesta are valoarea 1 în prima înregistrare din mesaj și 0 în celelalte. Bit-ul ME (Message End) este folosit pentru a indica sfârșitul unui mesaj NDEF. Acesta are valoarea 1 în ultima înregistrare din mesaj și 0 în celelalte. Un mesaj NDEF alcătuit dintr-o singură înregistrare atribuie atât bit-ului MB cât și bit-ului ME valoarea 1.

Câmpul TYPE LENGTH este folosit pentru a stoca lungimea tipului datelor, adică lungimea informației din câmpul TYPE.

Câmpul PAYLOAD LENGTH este folosit pentru a stoca lungimea datelor în sine, adică lungimea informației din câmpul PAYLOAD.

Câmpul ID LENGTH este opțional și este folosit pentru a stoca lungimea informației din câmpul ID, de asemenea opțional.

Bit-ul CF (Chunk Flag) este folosit pentru segmentarea datelor de același tip. El are valoarea 0 în ultimul segment (înregistrare) și valoarea 1 în celelalte segmente. Primul segment trebuie să indice tipul datelor și, opțional, identificatorul, câmpurile TYPE și ID fiind omise din segmentele următoare. Segmentele următoare au câmpurile TYPE LENGTH și ID LENGTH setate la valoarea 0 și obligatoriu câmpul TNF setat la valoarea 6 (neschimbat).

Bit-ul SR (Short Record) semnalează eventuale înregistrări scurte. Dacă are valoarea 1, atunci lungimea datelor (câmpul PAYLOAD LENGTH) este reprezentată pe un singur octet iar dacă are valoarea 0, pe patru octeți.

Bit-ul IL (ID_LENGTH) semnalează prin valoarea 1 prezența câmpului ID LENGTH în înregistrare. Valoarea 0 indică faptul ca atât câmpul ID LENGTH cât și ID sunt omise.

Câmpul TNF (Tipe Name Format) indică structura tipului înregistrării iar valorile definite pentru acest câmp sunt prezentate în Figura 3-10.

Figura 3-10 Valori posibile ale câmpului TNF (sursa: [4])

Transferul de date cu platforma Type 4A Tag

În urma încheierii procesului de activare al platformei Type 4A Tag se poate proceda la transferul de date utile cu aceasta. În această fază modularea semnalului purtător și codificarea biților se face tot conform mecanismelor tehnologiei NFC-A iar comenzile și răspunsurile specifice protocolului ISO-DEP(ISO 14443-4) sunt transferate în cadre de date standard NFC-A. Protocolul ISO-DEP este prea complex pentru a fi prezentat în lucrarea de față și de aceea vor fi prezentate doar comenzile și răspunsurile, respectiv mecanismele necesare pentru citirea sau scrierea unui mesaj NDEF de pe un card Type 4A. Acestea sunt specificate de NFC-Forum prin [8].

Setul de comenzi și răspunsuri ISO-DEP

Structurile comenzilor specifice protocolului ISO-DEP, denumite C-APDU (Command Application Protocol Data Unit) și a răspunsurilor, denumite R-APDU (Response Application Protocol Data Unit) sunt descrise în Tabelul 3-4 și 3-5.

Tabelul 3-4 Structura comenzilor C-APDU

Tabelul 3-5 Structura răspunsurilor R-APDU

Comenzile utilizate pentru citirea sau scrierea unui card Type 4A sunt:

Select – folosită pentru selectarea de aplicații sau fișiere din structura card-ului

ReadBinary – folosită pentru citirea datelor dintr-un fișier

UpdateBinary – folosită pentru scrierea de date într-un fișier

Gestionarea memoriei platformei Type 4A Tag

Platforma Type 4A Tag prezintă un mecanism de gestionare a memoriei bazat pe aplicații, fiecare card Type 4A conținând cel puțin aplicația NDEF. Aplicația NDEF este organizată sub forma unei structuri de fișiere și conține un fișier denumit „Capability Container” și fișierul NDEF.

Pentru a detecta și accesa mesajul NDEF stocat pe un card de tip 4A, dispozitivul în mod poll trebuie să citească și să interpreteze informația conținută în fișierul „Capability Container” din aplicația NDEF. Structura fișierului este descrisă prin Tabelul 3-6.

Tabelul 3-6 Structura fișierului Capability Container

Ultimul câmp este o structură de date TLV (Tip-Lungime-Valoare):

Câmpul Tip (un octet) are în acest caz valoarea 04h

Câmpul Lungime (un octet) indică numărul octeților din câmpul Valoare, în acest caz 06h

Câmpul Valoare (6 octeți) specifică:

Identificatorul fișierului NDEF (2 octeți)

Dimensiunea maximă a fișierului NDEF (2 octeți) – nu semnifică dimensiunea mesajului NDEF conținut în fișier

Drepturi de citire asupra fișierului NDEF (1 octet) – 00h înseamnă ca citirea este permisă fără nici un fel de securitate

Drepturi de scriere asupra fișierului NDEF (1 octet) – 00h înseamnă că scrierea este permisă fără nici un fel de securitate

Fișierul NDEF conține mesajul NDEF stocat pe card. Structura sa este prezentată în Tabelul 3-7.

Tabelul 3-7 Structura fișierului NDEF

Procedura de detecție a unui mesaj NDEF

Pentru detecția unui mesaj NDEF pe un card Type 4A se execută următorii pași:

Se selectează aplicația NDEF:

Tabelul 3-8 C-APDU – Selectare aplicație NDEF

Tabelul 3-9 R-APDU – Selectare aplicație NDEF

Se selectează fișierul Capability Container:

Tabelul 3-10 C-APDU Selectare fișier Capability Container

Tabelul 3-11 R-APDU Selectare fișier Capability Container

Se citește fișierul Capability Container (dimensiunea fișierului este conținută în câmpul CCLEN), se stochează identificatorul fișierului NDEF și se verifică drepturile de citire/scriere asupra acestuia:

Tabelul 3-12 C-APDU Citire fișier Capability Container

Tabelul 3-13 R-APDU Citire fișier Capability Container

Se selectează fișierul NDEF; Identificatorul fișierului este cel preluat din câmpul NDEF File Control TLV al CC:

Tabelul 3-14 C-APDU Selectare fișier NDEF

Tabelul 3-15 R-APDU Selectare fișier NDEF

Se citește și se stochează câmpul NLEN din fișierul NDEF (primii 2 octeți) și se verifică ca acesta să satisfacă relația: 2<NLEN+2<=Max NDEF file (preluat din NDEF File Control TLV al CC)

Tabelul 3-16 C-APDU Citire NLEN

Tabelul 3-17 R-APDU Citire NLEN

Dacă toți pașii enumerați mai sus, împreună cu verificările aferente au fost executați cu succes, se consideră că mesajul NDEF este detectat.

Procedura de citire a unui mesaj NDEF

Dacă detecția mesajului NDEF se execută cu succes prin procedura descrisă în Capitolul 3.8.3, citirea informației care constituie mesajul NDEF se face folosind una sau mai multe comenzi ReadBinary, ținând cont de faptul că lungimea mesajului NDEF este specificată prin câmpul NLEN al fișierului NDEF care a fost reținut în procedura de detecție:

Tabelul 3-18 C-APDU Citire fișier NDEF

Tabelul 3-19 R-APDU Citire fișier NDEF

Procedura de scriere a unui mesaj NDEF

Dacă detecția mesajului NDEF se execută cu succes prin procedura descrisă în capitolul 3.8.3, scrierea informației care constituie mesajul NDEF se face folosind una sau mai multe comenzi UpdateBinary:

Tabelul 3-20 C-APDU Scriere fișier NDEF

Tabelul 3-21 R-APDU Scriere fișier NDEF

Se au în vedere următorii pași:

Dacă dimensiunea mesajului NDEF care se dorește să fie scris este mai mare decât Max NDEF file – 2 (stocat în procedura de detecție), procedura de scriere se anulează

Se scrie valoarea 0000h în câmpul NLEN al fișierului NDEF

Se scrie mesajul NDEF folosind una sau mai multe comenzi UpdateBinary, având în vedere faptul că dimensiunea câmpului Data nu trebuie sa depășească valoarea câmpului MLc din CC

Se calculează dimensiunea mesajului NDEF și se scrie în câmpul NLEN al fișierului NDEF folosind comanda UpdateBinary

Descrierea generală a conceptului Shadow Key

Sistemul de acces bazat pe cheia RF Shadow Key care face obiectul lucrării de față este un prototip cu scop pur demonstrativ și nu este proiectat să funcționeze cu o mașină reală. În scopul demonstrației, cheia va funcționa cu un simulator conectat la PC, pe care este instalată o aplicație prin care se redau vizual acțiunile cerute de utilizator.

În componența sistemului intră următoarele elemente:

Cheia RF ShadowKey

Smartphone cu sistem de operare Android și capabilități NFC, având instalată aplicația pentru Android Shadow Key

Simulator pentru PC AK3G

Cheia RF Shadow Key este o cheie RKE clasică, având în plus capabilități de comunicație NFC. Nu este prevăzută cu butoane întrucât input-ul provenit de la acestea este înlocuit prin comenzile NFC recepționate. Conceptul presupune atașarea cheii în permanență unui smartphone cu sistem de operare Android, pe care este instalată aplicația Shadow Key. Această aplicație, în fapt un widget care funcționează și din ecranul de blocare al telefonului, reprezintă interfața sistemului cu utilizatorul și are ca principal scop înlocuirea butoanelor unei chei clasice.

Comunicația între smartphone și cheia Shadow Key

Comunicația NFC dintre smartphone și cheia Shadow Key este bazată pe schimbul de mesaje NDEF. Cheia emulează un card Type 4A pe care telefonul îl scrie pentru a trimite comenzi și îl citește pentru a prelua status-ul ultimei comenzi trimise.

Scenariul uzual este ilustrat prin diagrama de secvență din Figura 4-1. Utilizatorul face o cerere către sistem prin apăsarea unui buton de pe interfața grafică a aplicației Shadow Key pentru Android. Aplicația activează o bară de progres prin care anunță utilizatorul asupra faptului că cererea sa este în curs de procesare. Apoi aplicația generează un mesaj NDEF care încapsulează comanda utilizatorului, pe care îl scrie pe card-ul emulat de cheie. La recepția completă a mesajului NDEF, cheia interpretează comanda încapsulată și comută alimentarea pentru a putea începe transmisia RF. Din acest moment emularea de card este dezactivată.

Transmisia RF se face utilizând protocolul AK3G implementat de simulatorul PC, cadrele de date fiind generate conform comenzii ce este încapsulată în mesajul NDEF recepționat de la telefon. La finalul transmisiei RF, cheia generează un alt mesaj NDEF în memoria card-ului emulat prin care furnizează telefonului status-ul ultimei comenzi. Apoi, comută alimentarea înapoi pe câmpul NFC furnizat de telefon, pornind din nou și emularea de card.

Card-ul este din nou detectat de telefon, care citește NDEF-ul de status, iar apoi oferă feedback utilizatorului oprind bara de progres, semn că cererea a fost executată de sistem.

Figura 4-1 Comunicația între componentele sistemului de acces bazat pe cheia Shadow Key

Structura mesajelor NDEF care încapsulează comenzile și status-ul utilizate în cadrul comunicației dintre telefon și cheie este prezentată în Tabelul 4-1.

Tabelul 4-1 Structura mesajelor NDEF comandă și status utilizate în sistem

Simulatorul PC AK3G

Simulatorul AK3G pentru PC are scopul redării vizuale a acțiunilor cerute de utilizator sistemului de acces bazat pe ShadowKey.

Simulatorul este alcătuit din următoarele componente:

Receptor RF cu interfață LIN

Convertor LIN/RS232

PC, având instalată aplicația AK3G

Receptorul RF se conectează prin intermediul convertorului la interfața serială a PC-ului. Responsabilitatea receptorului este de a recepționa cadrele de date trimise de cheie pe RF și de a le trimite PC-ului prin port-ul serial. Interpretarea semnificației cadrelor de date este realizată de aplicația AK3G instalată pe PC, aceasta oferind feedback vizual utilizatorului (Figura 4-2).

Figura 4-2 Aplicația pentru PC AK3G

Cheia RF Shadow Key

Cheia RF Shadow Key este bazată pe microcontroller-ul Keylink NCF2971 de la NXP. Schema bloc a plăcii este prezentată în Figura 5 – 1.

Figura 5-1 Schema bloc a cheii Shadow Key

Facilitățile microcontroller-ului Keylink

Principalele facilități care fac acest microcontroller potrivit pentru această aplicație sunt interfața ISO14443 și memoria EEPROM paralelă.

Interfața ISO14443 are o rată de transfer de 106kbps, asigurând compatibilitate cu tehnologia NFC-A. Interfața utilizează modularea prin absorbție a câmpului HF (13,56 MHz) pentru a transmite date dispozitivului cititor și poate recepționa date dacă dispozitivul cititor aplică purtătoarei o modulație ASK 100%.

Independent de modul de operare al microcontroller-ului, interfața ISO14443 este capabilă să detecteze prezența câmpului HF și să genereze un semnal de trezire sau un semnal de întrerupere. De asemenea, include un periferic CIU (Contactless Interface Unit) care permite citire/scriere tamponată către interfața HF.

Perifericul CIU este folosit în timpul emulării ISO14443. Aceasta este activată din rutina de boot sau printr-un apel sistem. Emularea gestionează și secvența de anticoliziune (detecția de tehnologii, Capitolul 3.5.3). După selecția dispozitivului de către cititor, controlul este pasat aplicației. Transmisia și recepția prin interfața CIU se vor face prin intermediul unor funcții de bibliotecă.

În afară de comunicația de date folosind interfața ISO14443, microcontroller-ul poate folosi câmpul HF ca sursă de alimentare.

A doua facilitate principală a microcontroller-ului este memoria EEPROM paralelă. Aceasta este recomandată pentru stocarea datelor persistente datorită timpului de citire/scriere redus. Este organizată în 64 pagini de câte 64 octeți și mapată în spațiul adreselor de date. Citirea sau scrierea se fac la nivel de octet sau cuvânt, prin intermediul unor apeluri sistem. Memoria EEPROM paralelă poate fi programată și în timp ce microcontroller-ul rulează pe sursa de alimentare furnizată de câmpul HF.

Sursele de alimentare ale cheii

S-a constatat experimental faptul că energia electrică extrasă din câmpul electromagnetic NFC este insuficientă pentru a alimenta transmițătorul RF pe durata unei transmisii. Soluția adoptată a fost utilizarea unor condensatori conectați pe de o parte la antena NFC și pe de altă parte la terminalul pentru alimentare de la baterie al microcontroller-ului și al transmițătorului RF. Aceștia înmagazinează energia electrică furnizată de câmpul NFC, care va fi folosită pentru transmisii RF. Sursele de alimentare ale cheii și tranzițiile între ele sunt sugerate în Figura 5-2.

Figura 5-2 Sursele de alimentare ale cheii Shadow Key

Inițial cheia este în modul NEALIMENTAT. În acest mod componentele nu sunt alimentate. La detecția de către microcontroller a câmpului NFC, cheia trece în modul ALIMENTARE_HF. Microcontroller-ul comută sursa de alimentare pe intrarea de la antena NFC (pin-ul VDDA) iar condensatorii se încarcă. La recepția unei comenzi de la telefon (utilizatorul a apăsat un buton din aplicație), cheia trece în modul ALIMENTARE_CONDENSATOR. Microcontroller-ul comută sursa de alimentare pe intrarea de la baterie (pin-ul VBAT) și comandă transmisia RF. În acest mod și transmițătorul RF este alimentat de la condensatori. După finalizarea transmisiei, se trece din nou în modul ALIMENTARE_HF. În cazul în care câmpul NFC dispare(telefonul este blocat), se trece înapoi în starea NEALIMENTAT.

Arhitectura SW generică RFKPOLAR

RFKPOLAR (RF Keys PRoduct Line ARchitecture) este o arhitectură generică definită pentru software-ul de chei RF. Figura 5-3 ilustrează cele mai importante module software din arhitectură.

Figura 5-3 Arhitectura software generică RFKPOLAR

Nivelul „Aplicație” se caracterizează prin faptul că modulele care îl compun trebuie rescrise pentru fiecare proiect în parte. Modulele sunt proiectate conform tiparului statemachine(automat cu stări finite). Aici se definește comportamentul pentru diferite cazuri de utilizare (exemplu: ce se întâmplă când se apasă un buton).

Nivelul „Generic” este compus din module care oferă servicii necesare modulelor din stratul „Aplicație”. Modulele sunt generice și nu trebuie rescrise pentru fiecare proiect în parte. Trebuie specificate totuși anumite configurații.

Nivelul „Driver” este alcătuit din drivere care oferă servicii pentru utilizarea perifericelor microcontroller-ului dar și a dispozitivelor externe (de exemplu „dfrantic” implementează protocolului de comunicație cu transmițătorul RF Frantic). Acest nivel are o structură variabilă a modulelor ce îl compun în sensul că acestea trebuie selectate în funcție de platforma hardware pe care rulează software-ul.

Nivelul „Core Software” este alcătuit din module furnizate, de obicei, de producătorul microcontroller-ului.

Blocul RFK OS implementează un sistem de operare în timp real. La acest nivel se definesc task-urile software (RFK OS implementează un task de background și unul periodic cu recurența 1ms), rutinele de tratare ale întreruperilor și se gestionează execuția software-ului. În acest sens, sistemul de operare are 3 module relevante :

Bosevtmng (manager-ul de evenimente)

Bossmmng (manager-ul de automate cu stări finite)

Bosvirtim (timer-e software)

Manager-ul de automate cu stări finite definește un tablou de pointer-i la funcții care indică către funcțiile automatelor și asociază fiecărui automat un index în tabloul respectiv.

Manager-ul de evenimente definește un tampon de tip structură având următoarele elemente: <identificator mesaj> (o constantă) și <identificator statemachine destinație> (o constantă – index în tabloul de pointer-i al manager-ului de automate). Oferă servicii pentru adăugarea de mesaje în această coadă:

void bosevtmng_PostMessage(T_UBYTE lub_StateMacineID, T_UBYTE lub_Msg);

În bucla infinită a sistemului de operare (executată din task-ul de background) se verifică dacă sunt mesaje nelivrate în coada manager-ului de evenimente și în caz afirmativ se livrează câte unul automatului cu stări finite căruia îi este destinat, adică se apelează funcția de la index-ul <identificator statemachine destinație> din tabloul manager-ului de automate cu parametrul <identificator mesaj>.

În Figura 5-3, dependințele între module cu notația <<calls>> presupun apeluri directe de funcții iar cele cu notația <<informs>> presupun postări de mesaje prin manager-ul de evenimente.

Figura 5-4 Funcționarea manager-ului de evenimente

Modulul Bosvirtim implementează un serviciu de timer-e software care atunci când expiră se livrează un anumit mesaj unui automat cu stări finite sau altei funcții configurată în modulul Bosvirtim. Oferă o interfață pentru pornirea unui timer:

void bosvirtim_StartNewVirtualTimer(T_UWORD luw_CountValue, T_UBYTE lub_SM_or_CallbackFctID, T_UBYTE lub_Msg);

Toate timer-ele pornite la un moment dat se decrementează în task-ul periodic de 1ms, prin urmare timer-ele au rezoluție de 1ms (luw_CountValue). După decrementarea fiecărui timer, se verifică dacă el a ajuns la valoarea 0 și în caz pozitiv se procedează precum descrie Figura 5-5.

Figura 5-5 Funcționare serviciului de timer-e virtuale

În caz că funcția destinație este un automat cu stări finite (bit 7 din identificator este 0) se postează mesajul prin manager-ul de evenimente, altfel funcția se execută pe loc direct din task-ul periodic.

Alte module relevante pentru aplicația de față din arhitectura RFKPOLAR (Figura 5-3) sunt:

Armanag

Akrke

Grftrans

Armanag este manager-ul de aplicație. El este responsabil pentru coordonarea execuției celorlalte automate cu stări finite din aplicație. Akrke este modulul care implementează protocolul de transmisie RF al cheii.

Grftrans este un modul generic care comunică direct cu driver-ul transmițătorului RF și oferă aplicației un set de servicii abstractizate pentru controlul transmisiei RF:

grftrans_PowerOn(const T_UBYTE *lp_RamBuffer, T_UBYTE lub_RegAddress, T_UBYTE lub_NrOfRegs);

Folosită pentru pornirea transmițătorului RF

Descrierea parametrilor

lp_RamBuffer – pointer către adresa zonei RAM de unde încep valorile care se doresc a fi scrise în regiștrii transmițătorului RF

lub_RegAddress – adresa de început al regiștrilor ce vor fi scriși; este utilizată în alcătuirea comenzii care va fi trimisă transmițătorului prin interfața serială

lub_NrOfRegs – numărul de regiștrii ce vor fi scriși

grftrans_PrepareTX(T_UBYTE lub_telegramIDX, T_UBYTE Freq, T_UBYTE Sync, T_UBYTE PA, T_UBYTE Manch, T_UBYTE Power);

folosită pentru a încărca telegrama ce se dorește a fi transmisă în tampoanele driver-ului de transmițător RF

Descrierea parametrilor:

lub_telegramIDX – index al telegramei (cadrului de date) ce se dorește a fi transmisă într-un tablou de tip structură care trebuie configurat în prealabil

Freq, Sync, PA, Manch, Power – parametrii de transmisie care vor fi trimiși transmițătorului RF prin interfața serială

grftrans_StartTX(void);

Folosită pentru pornirea transmisiei RF; datele și parametrii de transmisie au fost configurați prin apelul funcției grftrans_PrepareTX

grftrans_PowerOff(void);

Folosită pentru oprirea transmițătorului RF

Implementarea emulării de card Type 4A

După cum s-a precizat și în Capitolul 5.2, cheia se află în modul NEALIMENTAT atât timp cât microcontroller-ul nu detectează câmp NFC. În momentul în care acesta este prezent, microcontroller-ul comută sursa de alimentare pe intrarea corespunzătoare antenei NFC iar execuția software-ului începe de la vectorul HF WARM BOOT (Figura 5-6).

Figura 5-6 Vectorii de întrerupere ai microcontroller-ului Keylink

Aici este specificată adresa de început a unei rutine de boot care pornește emularea ISO 14443. Aceasta este furnizată într-o librărie de către producătorul microcontroller-ului, NXP. La finalul execuției rutinei de boot controlul este pasat aplicației.

Odată activată, emularea ISO14443 va trata autonom activitățile de detecție și anticoliziune specifice tehnologiei NFC-A, descrisă pe larg în Capitolul 3. Identificatorul unic al card-ului necesar în această etapă este preluat de la o adresă fixă din memoria ULPEEPROM a microcontroller-ului și are o valoare fixată (nu este configurabil de către programator).

Ca rezultat, aplicația va trebui să trateze activitățile de:

activare a platformei Type 4A Tag (comanda RATS pentru negocierea dimensiunii maxime a unui cadru de date și a ratei de transfer)

transfer de date, mai precis protocolul ISO-DEP, în vederea furnizării unor mijloace pentru citirea și scrierea mesajelor NDEF stocate pe card-ul emulat de cheie

În plus, va trebui să aloce și să gestioneze o zonă de memorie nevolatilă în care vor fi stocate fișierele CC, respectiv NDEF. Pentru aceasta, a fost aleasă memoria EEPROM paralelă a microcontroller-ului datorită timpilor de citire/scriere reduși.

Aceste elemente au fost implementate în modulul „type4tag” de pe nivelul „Driver” din Figura 5-3. Mecanismul de emulare ISO14443 tratează activitățile de detecție și anticoliziune și, odată ce card-ul emulat este selectat de către dispozitivul cititor, se generează o întrerupere pentru ca activitățile succesive să fie tratate de aplicație. Punctul principal de intrare în driver îl constituie rutina de tratare a acestei întreruperi din interiorul căreia se tratează comenzile succesive recepționate de la dispozitivul cititor.

void ISO14443_UserOS( void ) property(isr) {

T_UBYTE u8_NumRxBytes;

T_UBYTE u8_firstbyte;

T_BOOL is_first_cmd, b_ATS_done;

// enable parallel EEPROM

dnxpcsw_EEPROM_Enable( EE_RAM_AUT );

is_first_cmd = TRUE;

b_ATS_done = FALSE;

en_T4_SelectedFile = SELFILE_NONE;

u8_LastTxSize = 0;

while ( TRUE )

{

// clear receive buffer

memset( g_u8arr_RxBuffer, 0, ISO_RXTX_BUFFER_SIZE );

// receive command

iso14443_user_os_return_value = ReceiveIso14443Frame( g_u8arr_RxBuffer, ISO_RXTX_BUFFER_SIZE, &u8_NumRxBytes );

// in case of an error, exit this function

if ( iso14443_user_os_return_value != SUCCESS )

break;

u8_firstbyte = g_u8arr_RxBuffer[0];

/*– RATS command ––––––––––––––––––––––––*/

else if ( (u8_NumRxBytes==2) && ( u8_firstbyte == ISO_CMD_RATS ) && ( is_first_cmd ) )

{

T_UBYTE u8_FSDI = ( g_u8arr_RxBuffer[1] & 0xF0 ) >> 4;

// max Rx frame size

u16_FSD = FSDI_CONV_TABLE[ u8_FSDI ];

// connected device logical No

u8_CID = g_u8arr_RxBuffer[1] & 0x0F;

// max. transmit frame size is FSD or local buffer size, whichever is smaller

u8_MaxTxFrameSize = (T_UBYTE) MIN( u16_FSD, ISO_RXTX_BUFFER_SIZE );

// send ATS

phcaiKEyLLGenFunc_Ciu_InitCRC();

phcaiKEyLLGenFunc_Ciu_Transmit( ISO_RESP_ATS_LENGTH, 8, CIU_CRC, CIU_NOT_LAST_BYTE );

phcaiKEyLLGenFunc_Ciu_Transmit( ISO_RESP_ATS_FORMAT, 8, CIU_CRC, CIU_NOT_LAST_BYTE );

phcaiKEyLLGenFunc_Ciu_Transmit( ISO_RESP_ATS_TA1 , 8, CIU_CRC, CIU_NOT_LAST_BYTE );

phcaiKEyLLGenFunc_Ciu_Transmit( ISO_RESP_ATS_TB1 , 8, CIU_CRC, CIU_NOT_LAST_BYTE );

phcaiKEyLLGenFunc_Ciu_Transmit( ISO_RESP_ATS_TC1 , 8, CIU_CRC, CIU_LAST_BYTE );

b_ATS_done = TRUE;

}

/* I-Block : binary (000x xx1x) */

else if ( ( u8_firstbyte & 0xE2 ) == 0x02 )

{

// errors below here don't change iso14443_user_os_return_value

HandleCommandAPDU( u8_NumRxBytes-1, g_u8arr_RxBuffer );

}

else

{ /* All other commands */

iso14443_user_os_return_value = ERROR;

}

// in case of an (ISO comm.) error, exit this function

if ( iso14443_user_os_return_value != SUCCESS )

break;

is_first_cmd = FALSE;

}

dnxpcsw_EEPROM_Disable();

}

În funcția „HandleCommandAPDU” sunt tratate comenzile specifice procedurii de citire/scriere NDEF descrisă pe larg în Capitolul 3.8.4, 3.8.5. În acest sens, se alocă o zonă de memorie care va stoca conținutul fișierului CC și două zone pentru stocarea de fișiere NDEF. Fișierul CC este definit ca un tablou constant, alocat în memoria EROM întrucât conținutul acestuia este static.

const T_UBYTE u8_CC_FILE[] =

{

0x00, 0x0F, /* CCLEN (Hi/Low byte) */

0x20, /* Version 2.0 */

0x00, CC_MLE, /* MLe (bytes) */

0x00, CC_MLC, /* MLc (bytes) */

/*NDEF File Control TLV */

0x04, /* T */

0x06, /* L */

FILEID_NDEF_HI, /* */

FILEID_NDEF_LO, /* */

EE_NDEF_FILE_SIZE >> 8, /* max. NDEF file size (Hi byte) */

EE_NDEF_FILE_SIZE & 0x00FF,/* max. NDEF file size (Lo byte) */

0x00, /* read access condition */

0x00, /* write access condition: 00 = writeable, FF = read only */

};

Sunt necesare două fișiere NDEF întrucât unul este folosit pentru a stoca mesajul NDEF care codifică comanda transmisă cheii de către dispozitivul cititor iar celălalt este folosit pentru returnarea status-ului ultimei comenzi de către cheie. Acest lucru este complet transparent pentru dispozitivul cititor. După selecția fișierului NDEF conform procedurii descrise în Capitolul 3.8.3, în caz că se recepționează comenzi de citire (ReadBinary), răspunsul va conține date din fișierul NDEF care stochează status-ul iar în caz că se recepționează comenzi de scriere, datele încapsulate în comandă vor fi scrise în fișierul care stochează comanda. La finalul recepției complete a unui mesaj care codifică comanda de la dispozitivul cititor, driver-ul inițiază un reset software în vederea comutării sursei de alimentare pe intrarea de la baterie pentru începerea unei transmisii RF.

Fișierele NDEF sunt definite ca două tablouri, alocate prin configurații de linker la adresele de memorie F000h, respectiv F800h. Aceste adrese de început sunt utilizate pentru scrierea conținutului fișierelor în memoria EEPROM paralelă (mapată în spațiul adreselor de date peste o zonă care include zonele la care sunt alocate fișierele) prin intermediul funcției din modulul dnxpcsw.c:

T_WriteError dnxpcsw_EEPROM_ProgramWait(volatile T_UBYTE* const lub_addr, const T_UBYTE* const lub_data, const T_UWORD luw_len);

Parametrul lub_addr specifică adresa de start de unde se va începe scrierea, lub_data este un pointer către zona de memorie RAM unde se află datele ce urmează să fie scrise iar luw_len specifică lungimea datelor.

Pentru crearea fișierului NDEF de status în memoria EEPROM paralelă, driver-ul „type4tag” pune la dispoziția aplicației interfața:

T_ERROR NfcTag_CreateNdefMsg ( void );

Implementarea protocolului de transmisie RF AK3G

Protocolul AK3G este o variantă simplificată a protocolului de transmisie RF pentru Volvo, cu scop pur demonstrativ a anumitor funcționalități pe un PC conectat la un receptor RF. La nivel fizic, pentru transmiterea de date, purtătoarea este modulată FSK iar codificarea biților este Manchester inversat.

Figura 5-7 Protocolul de transmisie RF AK3G

Datele transmise nu sunt criptate iar transmisia se face pe două canale precum indică Figura 5-7. Diferența între cele două canale este frecvența semnalului purtător (868.05/868.55MHz). Cadrele de date simbolizate în figură cu verde sunt transmise de cheie iar cele albastre de către receptorul RF ca și confirmări. Din moment ce cheia Shadow Key nu are capabilități de recepție RF, acestea sunt ignorate. Prin urmare, sunt transmise cadrele de date aferente unui sub bloc din figură după care cheia așteaptă un interval de timp de:

Cadrele de date transmise de cheie (WUP1, RKE Frame #n) au în mare parte o structură statică. Elementele care diferă sunt câmpuri ale cadrelor de tip RKE Frame #n precum:

un câmp care indică canalul pe care se transmite

cei mai semnificativi 4 biți ai octetului 2

valori posibile: 1h sau 2h

un câmp care indică indexul cadrului de date (n)

cei mai puțin semnificativi 4 biți ai octetului 2

când s-a transmis cadrul de date cu index-ul 15, acest index pornește din nou de la valoarea 0

un câmp care codifică comanda transmisă

octetul 6

valori posibile: 10h-LOCK, 20h-UNLOCK, 80h-TRUNK, 8h-LIGHTS

Cheia transmite protocol RF, pe o durată de 150ms, la fiecare recepție de mesaj NDEF cu comandă de la dispozitivul cititor. Rezultă un număr de două sub blocuri transmise de cheie.

Implementarea protocolului RF este asigurată de către modulul „akrke” de pe nivelul aplicație. Acesta este proiectat ca un automat cu stări finite, având patru stări. Tranzițiile dintre acestea sunt sugerate în Figura 5-8.

Figura 5-8 Automatul cu stări finite „akrke”

Starea inițială este SM_RKE_STATE_INIT în care se așteaptă recepția unui mesaj NDEF cu comandă de la dispozitivul cititor. În momentul în care acesta este recepționat, se activează automatul cu stări finite „akrke” de către manager-ul de aplicație prin postarea către acesta a unui mesaj MSG_DEB_NEWBUTTON. În acest moment are loc tranziția în starea SM_RKE_STATE_PREPTX în care se citesc din memoria EEPROM valorile de configurare ale transmițătorului RF iar apoi automatul tranzitează în starea SM_RKE_ACTION și își postează un mesaj MSG_START_TX. La apelul automatului „akrke” cu parametrul MSG_START_TX, se pornește transmițătorul RF, se configurează parametrii de transmisie, se construiesc cadrele de date ce trebuie transmise în această iterație (un cadru WUP1 + un cadru RKE FRAME #n din Figura 5-7), se pornește transmisia și automatul tranzitează în starea SM_RKE_WAIT_TX_FINISH. În această stare se așteaptă confirmarea de terminare a transmisei RF de la driver-ul de transmisie. Când aceasta e primită (automatul este apelat cu parametrul MSG_GRFTRANS_FINISHED), se verifică dacă e necesară o nouă transmisie, caz în care se execută tranziția în starea SM_RKE_STATE_ACTION de unde se configurează noua transmisie. În caz negativ, automatul tranzitează înapoi în starea SM_RKE_STATE_INIT și își încheie execuția.

Un scenariu complet de transmisie RF din punctul de vedere al interacțiunii dintre principalele module software implicate este prezentat în Figura 5-9.

Figura 5-9 Interacțiunea modulelor din software-ul cheii Shadow Key

Aplicația Shadow Key pentru Android

Aplicația Shadow Key pentru Android are ca principal scop înlocuirea interfeței dintre utilizator și o cheie clasică. În cazul unei chei clasice, utilizatorul apasă un buton de pe cheie pentru a interacționa cu sistemul (pentru a descuia/încuia mașina, pentru a deschide portbagajul, etc.). Similar, aplicația pentru Android pune la dispoziția utilizatorului o interfață grafică asemănătoare cu silueta unei chei clasice, sub forma unui widget cu butoane echivalente ca și scop final cu cele ale unei chei clasice. Aplicația transmite comenzile indicate de utilizator (prin apăsarea butoanelor de pe widget) cheii Shadow Key prin NFC, aceste comenzi fiind încapsulate în structuri de date NDEF corespunzătoare.

Componente ale unei aplicații Android

Fiecare aplicație utilizator trebuie să definească un fișier manifest (AndroidManifest.xml) prezent în directorul rădăcină. Acest fișier definește:

Pachetul Java al aplicației; acesta se consideră ca un identificator unic al aplicației

Componentele aplicației: activități, servicii, broadcast receiver-e; specifică clasele care implementează fiecare componentă și capabilitățile fiecărei componente (de exemplu, ce Intent-uri pot trata)

Permisiunile pe care aplicația trebuie să le dețină pentru a accesa porțiuni protejate din API și pentru a interacționa cu alte aplicații

Versiunea minimă de Android API necesară aplicației

Librăriile la care aplicația face referiri

Activitățile sunt elemente de interfață grafică ale unei aplicații, împreună cu comportamentul specificat pentru aceste elemente. Elementele GUI se specifică într-un fișier *.xml iar comportamentul asociat lor într-o clasă derivată din clasa Activity. Ciclul de viață al unei activități este prezentat în Figura 6-1. Metodele ilustrate în figură au implementări implicite definite în clasa Activity, dar pot fi suprascrise polimorfic în clasele derivate din aceasta.

Figura 6-1 Ciclul de viață al unei activități Android (sursa: [9])

Intent-urile sunt descrieri abstractizate ale unor operații care se doresc a fi executate. Pot fi folosite pentru a porni activități sau pot fi trimise unor broadcast receiver-e care specifică faptul că sunt interesate de primirea intent-urilor de anumite tipuri. De asemenea, pot fi utilizate ca modalitate de comunicare între diferite aplicații. Practic, sunt structuri de date care conțin descrierea abstractizată a acțiunii ce se dorește executată.

Broadcast Receiver-ele sunt componente care permit interceptarea de Intent-uri, permițând în același timp o filtrare după tipul acestora. Comportamentul lor se specifică printr-o clasă derivată din clasa BroadcastReceiver suprascriind metoda onReceive() a acesteia. Ciclul de viață al unui Broadcast Receiver se poate considera încheiat la finalul apelului metodei onReceive().

Widget-urile sunt elemente de interfață grafică ale aplicațiilor care pot fi integrate în alte aplicații, spre exemplu în ecranul de pornire. Pentru a crea un widget, o aplicație trebuie să creeze două elemente:

Un fișier de resurse (xml) în care se definește structura grafică a widget-ului, frecvența de actualizare și clasa care implementează comportamentul acestuia

Clasa care implementează comportamentul widget-ului, derivată din clasa AppWidgetProvider (la rândul ei derivată din BroadcastReceiver); suprascriind metoda onUpdate() moștenită de la clasa AppWidgetProvider se vor putea intercepta evenimente corespunzătoare unor acțiuni precum: adăugare widget, ștergere widget, actualizare widget

În final, widget-ul trebuie specificat ca și componentă a aplicației în fișierul manifest.

Mecanisme Android pentru transferul datelor prin NFC

Telefoanele mobile cu NFC și sistem de operare Android sunt dispozitive NFC active și implementează, în general, toate cele trei tehnologii NFC: NFC-A, NFC-B, NFC-F. Comunicația NFC este activă doar atunci când telefonul este deblocat și, bineînțeles, NFC este activat din setările telefonului. În decursul comunicației NFC, pot avea unul din următoarele roluri:

Reader/Writer: permite citirea/scrierea card-urilor NFC

Peer to Peer: permite transferul de date cu alte dispozitive active

Opțional, Card Emulator: se comportă ca un card NFC specific

Aceste smartphone-uri implementează activitățile de poll, listen, detecție/selecție/activare de dispozitive NFC, prioritizare în cazul detecției de dispozitive multiple, prin diferite componente ale sistemului de operare, aplicațiile utilizator neavând la dispoziție mijloace prin care să poată extinde, modifica sau configura comportamentul deja implementat. Pentru transferul de date utile, sistemul de operare implementează, de asemenea, protocoalele specificate de standard, dar pentru specificarea datelor efective prevede diferite mecanisme, accesibile de aplicațiile utilizator prin API. Acestea diferă în funcție de tipul dispozitivului NFC cu care se comunică.

Există două cazuri de utilizare principale a mecanismelor puse la dispoziție de API:

Citirea/scrierea mesajelor NDEF pe/de pe card-uri NFC

Transferul mesajelor NDEF, în rolul Peer to Peer, cu un alt dispozitiv NFC activ prin mecanismul Android Beam (implementare a protocolului SNEP amintit în Capitolul 3.4)

Pentru lucrarea de față, prezintă un interes deosebit mecanismele pentru citirea și scrierea de mesaje NDEF pe card-uri Type 4A.

Detecția unui card Type 4A și citirea mesajelor NDEF

Toate activitățile necesare citirii unui mesaj NDEF de pe un card Type 4A sunt implementate de componente ale sistemului de operare. Acesta este capabil sa detecteze, selecteze și activeze card-ul. De asemenea, implementează protocolul ISO-DEP pentru transferul de date utile cu card-ul și va folosi procedurile de detecție și citire a unui mesaj NDEF de pe un card de tip 4A (descrisă în Capitolul 3.8.3, 3.8.4).

Dacă a fost detectat un mesaj NDEF, după citirea acetuia, sistemul de operare încapsulează tipul și payload-ul mesajului (prin obiecte NdefMessage), precum și informațiile despre card (prin obiecte Tag), într-un Intent. Aplicațiile pot sa se declare interesate de a primi notificări în momentul detecției de mesaje NDEF, specificând filtre de Intent după tipul mesajelor NDEF în fișierul manifest. Sistemul de operare va interpreta informația din câmpul tip al mesajului NDEF citit pentru a decide cărei aplicații îi va livra Intent-ul creat. În caz că există o aplicație care poate trata Intent-ul, sistemul de operare va specifica ACTION_NDEF_DISCOVERED ca și acțiune caracteristică Intent-ului și îl va livra aplicației.

Dacă nu există nicio aplicație care poate trata Intent-ul sau dacă un mesaj NDEF nu a fost detectat, sistemul de operare încapsulează doar informațiile despre card-ul detectat (prin obiecte Tag) într-un Intent. Și în acest caz, aplicațiile pot să specifice filtre de Intent, dar de această dată după tehnologii NFC. În caz că există o aplicație care poate trata Intent-ul, sistemul de operare va specifica ACTION_TECH_DISCOVERED ca și acțiune caracteristică Intent-ului și îl va livra aplicației

Dacă nici în acest caz nu exista aplicații care pot trata Intent-ul, sistemul de operare va specifica ACTION_TAG_DISCOVERED ca și acțiune caracteristică pentru Intent. Acest mecanism poartă denumirea de „Tag Dispatch System” și este prezentat în Figura 6-2.

Figura 6-2 Android Tag Dispatch System

Scrierea mesajelor NDEF pe un card Type 4A

Și în cazul scrierii mesajelor NDEF pe card-uri Type 4A, sistemul de operare va utiliza procedura de scriere NDEF (prezentată în Capitolul 3.8.5). Conținutul mesajului NDEF în sine trebuie să fie specificat din aplicații utilizator. În acest sens, principalele clase puse la dispoziție de API sunt NdefRecord, NdefMessage, Tag, Ndef, NdefFormatable.

Un obiect al clasei NdefRecord corespunde unei înregistrări NDEF din componența unui mesaj NDEF. Pentru crearea unei astfel de înregistrări, clasa NdefRecord este prevăzută cu constructor-ul:

public NdefRecord (short tnf, byte[] type, byte[] id, byte[] payload), unde:

Tnf – indică structura tipului înregistrării; valorile posibile sunt definite în Capitolul 3.7, Figura 3-10

Type – indică tipul înregistrării

Id – indică identificatorul înregistrării; este opțional în caz că nu se dorește prezența câmpului ID în înregistrare, se poate furniza null ca și argument

Payload – indică payload-ul înregistrării

Celelalte câmpuri din structura NDEF definită de Nfc-Forum precum lungimea tipului, lungimea payload-ului, informațiile de control, sunt calculate automat fie la crearea unui obiect NdefRecord (lungime tip, lungime payload, flag SR, flag IL) sau la crearea unui obiect NdefMessage din obiectele NdefRecord aferente (flag-urile MB,ME,CF).

Un obiect al clasei NdefMessage corespunde unui mesaj NDEF care poate fi alcătuit din una sau mai multe înregistrări NDEF. În acest sens, clasa NdefMessage este prevăzută cu constructorul:

public NdefMessage (NdefRecord[] records), unde: records reprezintă un tablou de obiecte NdefRecord (înregistrări NDEF) care vor intra în componența mesajului NDEF.

Un obiect al clasei Tag reprezintă starea inițială a unui card NFC din momentul detecției sale. Sistemul de operare încapsulează obiectele Tag în Intent-urile livrate către aplicații (vezi capitolul precedent).

Un obiect al clasei Ndef oferă acces la conținutul NDEF de pe un card. Poate fi obținut prin metoda statică:

public static Ndef get (Tag tag), unde tag este obiectul Tag corespunzător card-ului la care se dorește accesul la conținutul NDEF.

Alte metode utile din clasa Ndef:

public void connect ()

Activează operații de intrare/ieșire cu card-ul fizic

public boolean isWritable ()

Indică dacă card-ul permite scrierea

public int getMaxSize ()

Indică dimensiunea maximă a unui mesaj NDEF ce poate fi scris pe card; la Type 4A aceasta e specificată în NDEF File Control TLV din fișierul CC (Capitolul 3.8.2)

public void writeNdefMessage (NdefMessage msg)

Scrie mesajul NDEF furnizat ca parametru pe card-ul fizic; în cazul card-ului Type 4A telefonul va utiliza procedura descrisă în Capitolul 3.8.5

Implementarea aplicației

Aplicația Shadow Key pentru Android este alcătuită din două componente de bază: o activitate principală și un widget. Interfața cu utilizatorul este asigurată prin widget.

Figura 6-3 Widget-ul pentru Android Shadow Key

Elementele de grafică prezente în widget au fost realizate în aplicația de editare grafică Photoscape. Acesta este structurat conform unei așezări liniare cu orientare verticală și conține următoarele componente (de sus în jos):

Căsuță text, în care se tipărește ora și data ultimei comenzi trimise cu succes

Buton Încuiere

Buton Descuiere

Buton Lumini

Buton Portbagaj

Bară de progres

Butoanele sunt singurele elemente care sunt tratate de clasa ce implementează comportamentul widget-ului, aici atașându-se rutinele care tratează apăsările de butoane. Celelalte două componente (Căsuța de text și Bara de progres) sunt tratate din activitate. Bara de progres este vizibilă din momentul în care din aplicație s-a scris cu succes un NDEF comandă până în momentul în care se citește un NDEF status.

public class GatewayKeyAppWidgetProvider extends AppWidgetProvider {

public static String ACTION_WIDGET_LOCK="ActionReceiverLock";

public staticString ACTION_WIDGET_UNLOCK="ActionReceiverUnlock";

public static String ACTION_WIDGET_TRUNK="ActionReceiverTrunk";

public static String ACTION_WIDGET_LIGHTS="ActionReceiverLights";

public static String WIDGET_LOCKSCREEN="WidgetFromLockscreen";

public static String EXTRA_LOCKSCREEN="com.gatewayKey.appWidget.GatewayKeyAppWidgetProvider/lockscreen";

private Bundle myOptions;

private int category;

public void onUpdate(Context context, AppWidgetManager appWidgetManager, int[] appWidgetIds) {

final int N = appWidgetIds.length;

PendingIntent lockPendingIntent;

PendingIntent unlockPendingIntent;

PendingIntent lightsPendingIntent;

PendingIntent trunkPendingIntent;

// Perform this loop procedure for each App Widget that belongs to this provider

for (int i=0; i<N; i++) {

int appWidgetId = appWidgetIds[i];

myOptions = appWidgetManager.getAppWidgetOptions (appWidgetId);

category=myOptions.getInt(AppWidgetManager.OPTION_APPWIDGET_HOST_CATEGORY, -1);

// Create Intents to launch Activity

Intent lockIntent = new Intent(context, MainActivity.class);

lockIntent.setAction(ACTION_WIDGET_LOCK);

Intent unlockIntent = new Intent(context, MainActivity.class);

unlockIntent.setAction(ACTION_WIDGET_UNLOCK);

Intent lightsIntent = new Intent(context, MainActivity.class);

lightsIntent.setAction(ACTION_WIDGET_LIGHTS);

Intent trunkIntent = new Intent(context, MainActivity.class);

trunkIntent.setAction(ACTION_WIDGET_TRUNK);

if(category==AppWidgetProviderInfo.WIDGET_CATEGORY_KEYGUARD)

{

lockIntent.putExtra(EXTRA_LOCKSCREEN, WIDGET_LOCKSCREEN);

unlockIntent.putExtra(EXTRA_LOCKSCREEN, WIDGET_LOCKSCREEN);

lightsIntent.putExtra(EXTRA_LOCKSCREEN, WIDGET_LOCKSCREEN);

trunkIntent.putExtra(EXTRA_LOCKSCREEN, WIDGET_LOCKSCREEN)

}

lockPendingIntent = PendingIntent.getActivity(context, 1, lockIntent, PendingIntent.FLAG_UPDATE_CURRENT);

unlockPendingIntent = PendingIntent.getActivity(context, 1, unlockIntent, PendingIntent.FLAG_UPDATE_CURRENT);

lightsPendingIntent = PendingIntent.getActivity(context, 1, lightsIntent, PendingIntent.FLAG_UPDATE_CURRENT);

trunkPendingIntent = PendingIntent.getActivity(context, 1, trunkIntent, PendingIntent.FLAG_UPDATE_CURRENT);

// Get the layout for the App Widget and attach an on-click listener

// to the buttons

RemoteViews views = new RemoteViews(context.getPackageName(), R.layout.key_appwidget);

views.setOnClickPendingIntent(R.id.lock_button, lockPendingIntent);

views.setOnClickPendingIntent(R.id.unlock_button, unlockPendingIntent);

views.setOnClickPendingIntent(R.id.lights_button, lightsPendingIntent);

views.setOnClickPendingIntent(R.id.trunk_button, trunkPendingIntent);

// Tell the AppWidgetManager to perform an update on the current app widget

appWidgetManager.updateAppWidget(appWidgetId, views);

}

}

}

La apăsarea butoanelor se lansează intent-uri care specifică acțiuni corespunzătoare pentru a se lansa activitatea principală. Dacă widget-ul din care s-a apăsat butonul provine din ecranul de blocare (lockscreen), intent-urilor li se adaugă ca și extra un String pentru a informa activitatea principală de acest lucru, întrucât tratarea lor va fi diferită în acest caz (NFC-ul telefonului este inactiv când telefonul este blocat).

Activitatea principală este necesară pentru implementarea comunicației NFC, mai precis pentru a putea avea acces la Intent-urile lansate de „Tag Dispatch System” prezentat pe larg în Capitolul 6.2. Sistemul de operare livrează aceste intent-uri doar către activități care au specificate filtre corespunzătoare în fișierul manifest.

<activity android:label="@string/app_name"

android:screenOrientation="portrait"

android:name="com.gatewayKey.main.MainActivity"

android:theme="@android:style/Theme.Translucent.NoTitleBar">

<intent-filter>

<action android:name="android.nfc.action.NDEF_DISCOVERED" />

<category android:name="android.intent.category.DEFAULT" />

<data android:mimeType="akng/nfc" />

</intent-filter>

<intent-filter>

<action android:name="android.intent.action.MAIN" />

<category android:name="android.intent.category.LAUNCHER" />

</intent-filter>

</activity>

S-a optat, deci, pentru implementarea unei activități fără interfață grafică, care procesează Intent-urile lansate de „Tag Dispatch System” la detecția de mesaje NDEF cu tipul „akng/nfc”, respectiv cele lansate din widget la apăsarea butoanelor. Durata de viață a activității se limitează la timpul necesar procesării unui anumit eveniment (Intent prin care este pornită) după care activitatea își autoinvocă terminarea prin apelul metodei finish(), moștenită din clasa Activity. Prin urmare, existența activității este complet transparentă pentru utilizator, singura interfață a aplicației cu acesta fiind widget-ul.

La apăsarea unui buton de pe widget, activitatea scrie un NDEF comandă corespunzător acțiunii specificate de Intent-ul care a pornit-o. Metoda care scrie un mesaj NDEF pe un tag este prezentată în continuare.

public boolean writeTag(NdefMessage message, Tag tag) {

int size = message.toByteArray().length;

try {

Ndef ndef = Ndef.get(tag);

if (ndef != null) {

ndef.connect();

if (!ndef.isWritable()) {

toast("Tag is read-only.");

return false;

}

if (ndef.getMaxSize() < size) {

toast("Tag capacity is " + ndef.getMaxSize() + " bytes, message is " + size+ " bytes.");

return false;

}

try{

ndef.writeNdefMessage(message);

}

catch(IOException e){

Log.e("IOException", e+"");

}

ndef.close();

/*All OK – vibrate*/

Thread vibrateThread = new Thread(){

public void run(){

try {

sleep(1000);

} catch (InterruptedException e) {

}

Vibrator v = (Vibrator) activity.getSystemService(Context.VIBRATOR_SERVICE);

// Vibrate for 300 milliseconds

v.vibrate(300);

Thread.currentThread().interrupt();

}

};

vibrateThread.start();

// Get instance of Vibrator from current Context

return true;

} else {

NdefFormatable format = NdefFormatable.get(tag);

if (format != null) {

try {

format.connect();

format.format(message);

format.close();

return true;

} catch (IOException e) {

return false;

}

} else {

toast("Tag doesn't support NDEF.");

return false;

}

}

}

catch (Exception e) {

toast("Failed to write tag");

}

return false;

}

Se diferențiază totuși situația în care butonul apăsat aparține unui widget din ecranul de blocare (lockscreen) sau ecranul de pornire (homescreen) deoarece NFC-ul telefonului este inactiv cât timp telefonul este blocat. Activitatea controlează, de asemenea, căsuța de text (care afișează data și ora ultimei comenzi transmise cu succes) și bara de progres a widget-urilor. Funcționarea elementelor descrise este prezentată în următoarea diagramă de secvență:

Figura 6-4 Interacțiunea componentelor aplicației Shadow Key

Concluzii și perspective

Conceptul Shadow Key nu modifică conceptul sistemelor de acces clasice bazate pe chei RF, ci îl extinde, fiind la bază o cheie RF care are în plus capabilități de comunicație NFC. Astfel, se poate profita de securitatea bună a sistemelor de acces clasice, dobândită prin ani de experiență în dezvoltare. Introducerea comunicației NFC în sistem nu pune probleme de securitate în primul rând datorită distanței mici la care are loc.

Conceptul prevede atașarea în permanență a cheii la un telefon mobil cu capabilități NFC. Acesta înlocuiește interfața utilizatorului cu sistemul constituită de butoane, la cheile RF clasice, printr-o aplicație mobilă. Astfel, la un nivel abstract, se poate considera că atașarea cheii la telefonul mobil extinde funcționalitățile acestuia prin posibilitatea de a executa cereri sistemului de acces de pe mașină(încuie, descuie, etc.). În aceeași ordine de idei, ansamblul format din cele două dispozitive (smartphone și Shadow Key) poate fi privit din perspectiva utilizatorului ca un singur dispozitiv, astfel fiind suprimat dezavantajul sistemelor clasice în care utilizatorul trebuie să aibă în permanență elementul de autentificare în sistem (cheia) asupra sa.

Contribuția autorului lucrării de față în dezvoltarea conceptului a fost implementarea driver-ului „type4tag” și a protocolului de transmisie AK3G în software-ul pentru cheie, respectiv implementarea aplicației mobile „Shadow Key” pentru sistemul de operare Android.

Cât despre perspectivele acestui sistem, ar fi de menționat două mai notabile.

Implementarea comunicației criptate la nivel NFC

Deși securitatea comunicației NFC este sporită prin distanța redusă la care se comunică, ea nu poate fi garantată. În implementarea actuală, comunicația între telefon și cheie se realizează prin schimbul de mesaje NDEF, telefonul scriind, respectiv citind succesiv informația de pe card-ul emulat de cheie printr-o procedură definită în standard.

Alegerea implementării unei emulări de card Type 4A a fost făcută deoarece, alături de aplicația NDEF specificată în standard, se pot define aplicații proprietare. Prin această facilitate se poate defini un protocol de comunicație proprietar, în care comenzile și răspunsurile pe protocolul ISO-DEP să fie criptate.

Acest lucru este realizabil și din perspectiva aplicației mobile întrucât Android API pune la dispoziția dezvoltatorilor un mecanism prin care protocolul ISO-DEP se poate gestiona din aplicații utilizator.

Autentificarea utilizatorului în sistem

Se impune a fi luată în calcul și posibilitatea în care utilizatorului îi este furat telefonul mobil împreună cu cheia atașată.

Această problemă se poate soluționa printr-un sistem de autentificare al utilizatorului în sistem înainte sa îi fie permis să execute vreo cerere. Pentru a nu impune utilizatorului să se autentifice folosind parole sau coduri PIN, se poate lua în calcul varianta „Fingerprint Sensor API”, care va fi disponibilă începând cu versiunea M a sistemului de operare Android. Astfel, utilizatorului i se va putea cere să se autentifice folosind amprenta, operație mult mai puțin consumatoare de timp decât introducerea unui cod PIN sau a unei parole.

În plus, începând de la versiunea L a sistemului de operare Android, există o facilitate prin care telefonul nu se va bloca dacă descoperă că este în mișcare (prin intermediul accelerometrului). Cu alte cuvinte, nu va fi cerut utilizatorului să se autentifice (prin parolă, PIN, tipar) decât dacă telefonul a măsurat că a fost ținut pe loc un anumit interval de timp. În ideea că și „Fingerprint Sensor” va funcționa într-o manieră similară, utilizatorul nu va trebui să se autentifice de fiecare dată când vrea sa execute o cerere sistemului de acces prin aplicația Shadow Key.

Referințe bibliografice

Anexa 1. Structura comenzilor și răspunsurilor definite de tehnologia NFC-A

SENS_REQ: 26h

ALL_REQ: 52h

SENS_RES:

SDD_REQ:

SDD_RES:

BCC: XOR peste primii 4 octeți din răspuns

SEL_REQ:

SEL_RES:

Anexa 2. Structura comenzilor și răspunsurilor definite de platforma Type 4A Tag

Comanda RATS:

Răspunsul RATS: