Studente/i
Davide Taurisano
RelatoreVanni Galli
CorrelatoreVanni Galli
Committente Corso di laureaC10087
Modulo Anno2018/2019
Indice
1 Abstract 1 2 Introduzione 3 2.1 Descrizione progetto . . . 3 2.2 Compiti . . . 3 2.3 Requisiti . . . 4 3 Strumenti 5 3.1 Xamarin . . . 5 3.2 Ethereum . . . 6 3.2.1 Wallet . . . 8 3.3 Microsoft Azure AI . . . 10 4 Guida all’utilizzo 11 4.1 BioMetricWallet . . . 11 4.2 BioMetricServer . . . 16 5 Sviluppo 19 5.1 Struttura Client Server . . . 195.1.1 Schema Vending e Client . . . 20
5.1.2 Progettazione Client e Server . . . 21
5.2 Comunicazione Bluetooth . . . 23
5.2.1 Client Server prima versione . . . 25
5.2.2 BLE . . . 29
5.2.3 Client Server seconda versione . . . 31
5.3.4.1 Funzioni esposte . . . 47
5.3.4.2 Implementazione . . . 48
5.4 Transazione Ethereum . . . 52
5.4.1 Gas . . . 53
5.4.2 Schema transazione . . . 54
5.4.3 Wallet sul Client . . . 55
5.4.4 Nethereum API . . . 55
5.4.5 Etherscan API . . . 56
5.4.6 Notifica transazione . . . 57
6 Conclusione 61 6.1 Stato del lavoro . . . 61
6.2 Problemi riscontrati . . . 61
6.3 Considerazioni personali . . . 62
6.4 Sviluppi futuri . . . 62
Elenco delle figure
3.1 Etherscan explorer . . . 6
3.2 Esempio di wallet hardware ledger . . . 8
3.3 Metamask’s wallets . . . 9
3.4 Microsoft Servizi Cognitivi . . . 10
4.1 BioMetricWallet menu . . . 11
4.2 BioMetricWallet wallet . . . 12
4.3 BioMetricWallet wallet page . . . 13
4.4 BioMetricWallet homepage . . . 14
4.5 BioMetricWallet notification . . . 15
4.6 BioMetricServer homepage . . . 16
4.7 BioMetricServer connection page . . . 17
4.8 BioMetricServer products page . . . 17
4.9 BioMetricServer transaction confirmed . . . 18
5.1 Connessione client server . . . 20
5.2 Connessione bluetooth client server . . . 24
5.3 Client Server prima versione . . . 27
5.4 Bluetooth Low Energy . . . 29
5.5 Client Server seconda versione . . . 32
5.6 Scambio di messaggi tra dispositivi . . . 34
5.7 Fasi autenticazione . . . 40
5.8 Landmarks di un viso . . . 42
5.9 Orientamento del viso . . . 43
5.10 FaceRecognition.cs . . . 48
Capitolo 1
Abstract
Italiano
Al giorno d’oggi i nostri smartphone ci permettono di essere connessi con il mondo tec-nologico circostante, quello che si richiede a queste connessioni è che siano sicure e di facile utilizzo. Queste importanti caratteristiche sono tra loro contrastanti e quindi bisogna trovare un equilibro nel loro utilizzo. Questo progetto nasce dall’esigenza di sviluppare un sistema che riesca a bilanciare le caratteristiche sopracitate, garantendo una semplice user experience. Il progetto consiste nello sviluppo di un sistema che permette la comunicazione bluetooth tra due dispositivi android, uno è il telefono dell’utente che agisce da client mentre l’altro dispositivo è il server che permette la vendita di un prodotto. La comodità nell’utiliz-zo del progetto da parte dell’utente è assicurata dal fatto che lui interagisce con il server semplicemente avvicinandosi, potendo comodamente lasciare il suo telefono in tasca. La sicurezza è garantita dal sistema di autenticazione facciale implementato sul server, utiliz-zato per identificare l’utente. L’utente potrà selezionare ed acquistare un prodotto dal server grazie al client che effettuerà automaticamente l’operazione di pagamento. È stato scelto di utilizzare Xamarin Forms come piattaforma di sviluppo perché permette uno sviluppo Cross-Platform. Il sistema di riconoscimento facciale si appoggia alle API messe a disposizione da Microsoft Azure, che offrono un valido supporto per la manipolazione dei visi umani. Il paga-mento avviene utilizzando la piattaforma Ethereum e consiste nel trasferipaga-mento di Ether dal wallet del client al wallet del server. Il prototipo realizzato rispetta generalmente i requisiti iniziali ed è caratterizzato dall’equilibrio tra le caratteristiche sopracitate.
English
Nowadays our smartphones allow us to be connected to the technological world around us, and we expect that these connections are safe and easy to use. We need to find the balance in the using of these two important and conflicting aspects. This project was born by the need of a system that can balance the above aspects, guaranteeing a simple user experience.
The project consists in the development of a system that allows bluetooth communication between two Android devices, one is the user’s phone that acts as a client while the other device is the server that allows the selling of a product. The comfort in the use of the system by the user is assured by the fact that he interacts with the server simply by approaching it, being able to comfortably leave his phone in his pocket.
Security is guaranteed by the facial authentication system implemented on the server, used to identify the user. The user can select and purchase a product from the server thanks to the client that will automatically carry out the payment transaction. I decided to use Xamarin Forms as a development platform because it allows cross-platform development. The facial recognition system relies on the APIs made available by Microsoft Azure, which offer a valid support for the manipulation of human faces. Payment is made by using the Ethereum platform and consists in transferring Ether from the client wallet to the server wallet. The developed prototype generally respects the initial requirements and is characterized by the balance between the aforementioned characteristics.
Capitolo 2
Introduzione
2.1
Descrizione progetto
L’accesso e l’utilizzo di dispositivi e servizi digitali necessita di user experience sempre più semplici.
Questo progetto - legato a un brevetto depositato dalla SUPSI - vuole sviluppare un prototipo di un servizio digitale completamente automatico con relativa procedura di pagamento. Il servizio dovrà sfruttare un telefono in tasca dell’utilizzatore ma senza nessuna interazione dell’utente con il telefono stesso.
La comunicazione fra dispositivo e telefono dovrà avvenire tramite bluetooth.
Il pagamento dovrà avvenire da wallet a wallet di tipo blockchain, uno sul telefono e uno sul dispositivo.
2.2
Compiti
I compiti definiti inizialmente sono i seguenti:
• Definire il protocollo dell’intero flusso di comunicazione fra i 2 apparati • Agganciare la comunicazione Bluetooth fra dispositivo e telefono
• Gestire una comunicazione M2M (machine to machine) fra dispositivo e telefono • Ricevere e capire ordine vocale dell’utente tramite microfono sul dispositivo (voice to
text + semplice NLP)
2.3
Requisiti
Di seguito sono riportati i requisiti del progetto:
• Sviluppo dell’applicazione mobile sul telefono a scelta tra Android/Java e/o iOS/Swift • Sviluppo sul dispositivo Raspberry con C++ / Linux
• Voice to text / NLP (Comprensione del linguaggio parlato) • Comunicazione Bluetooth
• Utilizzo blockchain di test Ethereum per il pagamento
Capitolo 3
Strumenti
3.1
Xamarin
Xamarin.Forms è un toolkit multipiattaforma per Android, iOS, Mac e Windows che usa C # e .NET e consente di condividere il codice dell’interfaccia utente, nonché il codice della logica dell’app su tutte le piattaforme.
La scelta di questo strumento per lo sviluppo dell’applicazione mobile nasce da una pregres-sa conoscenza maturata dopo aver frequentato un corso il corso di sviluppo mobile tenuto dallo stesso relatore di questo progetto.
Lo sviluppo di questo progetto, al momento solo per la parte di Android, permette di avere una base per una futura estensione ad altre piattaforme, ad esempio iOS.
Il punto forte di questo strumento è quello di poter sviluppare gran parte del codice di logica ed UI nella zona di shared code, ovvero la parte condivisa dalle diverse piattaforme. Alcuni dei vantaggi di cui gode sono i seguenti:
• Wrapper che convertono codice C# in Java o Objective-D, quindi linguaggio nativo • Nessuna interpretazione di pagine web HTML 5, sulle quali si basano molti dei
fra-mework che permettono sviluppo multipiattaforma • Strumento Open Source
3.2
Ethereum
Ethereum è una piattaforma distribuita creata da Vitalik Buterin, open source, basata sulla blockchain. Al contrario delle altre blockchain, oltre al trasferimento di denaro tramite la sua criptovaluta nativa chiamata Ether (ETH), permette di creare delle applicazioni che, dal momento in cui vengono caricate rimarranno sempre in esecuzione.
Con criptovaluta si intende un mezzo di pagamento digitale, con le seguenti caratteristiche: • Crittografia che permetta la protezione dei dati attraverso la cifratura con funzioni hash
e firme digitali
• Blockchain che permette di gestire le operazioni e le transazioni senza avere un organo centrale, esempio una banca, ma permettendo ai partecipanti della rete di convalidarle
• Block mining è la ricerca della soluzione di problemi matematici in modo da po-ter sbloccare un nuovo blocco, che sia esso criptovaluta (la quantità di criptovaluta presente nella rete è definita a priori) oppure una convalida di una transazione
Blockchain
Con il termine Blockchain si indica un database pubblico (chain) che contiene informazioni digitali collegate tra loro (block). Un block è identificato da un codice univoco (hash) e contiene informazioni in merito alle transazioni che vengono effettuate sulla chain, data, possibile spostamento di denaro avvenuto, partecipanti alla transazione.
Alla chain è connessa una rete di nodi, in questo caso dei computer. Ogni singolo block che viene inserito nella chain, dovrà essere verificato e confermato da ogni singolo nodo appartenente alla rete. Ogni block inserito nella chain, sarà pubblico, e chiunque potrà risalire alle informazioni contenute in esso. Ad esempio, su Ethereum si può facilmente interrogare il database sul suo contenuto utilizzando il sito web Etherscan semplicemente inserendo il codice Hash dell’informazione desiderata. È la più grande ed attiva blockchain community del mondo. Non appartiene ad alcuna organizzazione o compagnia, di fatti sono grandi gruppi di persone che contribuiscono alla sua manutenzione ed innovazione.
Come detto precedentemente, ETH è la criptovaluta nativa di Ethereum, che può essere scambiata ed utilizzata all’interno delle applicazioni decentralizzate.
Figura 3.1: Etherscan explorer
La blockchain è sicura?
• Copia della chain su ogni nodo
• Ogni block viene aggiunto alla fine della blockchain
• Ogni block contiene il suo hash e quello del blocco precedente
• L’Hash è creato da una funzione matematica che prende in input l’informazione con-tenuta nel blocco e restituisce in forma di stringhe e numeri un valore univoco. Quindi per un certo input viene generato un output univoco.
• Concetto di chiave pubblica e privata
Cosa si intende con concetto di chiave pubblica e privata?
• Chiave Pubblica è quella da cui viene generato, tramite una funzione di hash, l’indiriz-zo del nostro wallet
• Chiave Privata è utilizzata per firmare una transazione, in modo da poter provare l’i-dentità di chi ha avviato la transazione. Mediante applicazione di determinate funzioni matematiche, dalla chiave privata viene generata la chiave pubblica. Dalla chiave pubblica è computazionalmente impossibile ottenere la chiave privata
Questo progetto si interfaccia alla rete di test Ethereum Ropsten, conosciuta come Ethe-reum Testnet. Utilizza gli stessi protocolli e funziona allo stesso modo della rete principale, viene utilizzata come piattaforma di testing durante lo sviluppo di dApps o come banco di prova per capire i meccanismi della Blockchain senza dover investire o potenzialmente perdere denaro reale.
3.2.1
Wallet
I wallet sono delle applicazioni che hanno la funzione di portafoglio virtuale. Permettono di conservare ed utilizzare i propri ETH.
Attualmente esistono diversi tipi di wallets:
• Smart Contract, sono wallets con dei controlli aggiuntivi, ad esempio whitelists and blacklists oppure autenticazione multifattore.
• Hardware, offrono il livello maggiore in termini di sicurezza quando si effettuano delle operazioni online, perché la chiave privata durante la firma delle transazioni non viene mai esposta.
• Mobile, garantiscono la possibilità di accedere ai propri fondi in qualunque luogo e momento, ma in termini di sicurezza è completamente dipendente dal device sul quale si trova.
• Desktop sono applicazioni per il sistema operativo, che diventano un metodo efficace per utilizzare i propri fondi quando permettono di essere utilizzate, quindi la creazione e la firma delle transazioni, sia offline che online.
• Web sono wallets che si trovano su un sito web
Figura 3.2: Esempio di wallet hardware ledger
Tipo di wallet utilizzato
I wallet creati ed utilizzati per questo progetto sono due: • Dispositivo (Vending Machine)
• Dispositivo mobile, in questo caso un telefono con sistema operativo Android.
Per la creazione è stato scelto di utilizzare MetaMask, un wallet Web, che permette di visi-tare la blockchain direttamente dal proprio browser.
In questo caso è stata utilizzata l’estensione disponibile per Google Chrome, che mette a disposizione un’intuitiva interfaccia grafica per gestire i propri profili sulle diverse reti ed effettuare transazioni in totale sicurezza.
3.3
Microsoft Azure AI
Microsoft Azure è un set in continua espansione di servizi cloud che aiuta le organizzazioni ad affrontare le sfide professionali.
Ti permette di creare, gestire e distribuire applicazioni su una rete globale di dimensioni elevate usando i tuoi strumenti e framework preferiti.
Azure espone dei servizi chiamati Servizi Cognitivi che permettono di utilizzare algoritmi di intelligenza artificiale per vedere, ascoltare, parlare, comprendere ed interpretare le esigen-ze degli utenti tramite metodi di comunicazione neurali.
In particolare, è stato utilizzato il servizio Face API del gruppo Vision APIs.
Gli algoritmi inclusi in questa API permettono di individuare, riconoscere ed analizzare i visi umani contenuti in un’immagine.
La descrizione più dettagliata sarà contenuta nel capitolo Sviluppo.
Figura 3.4: Microsoft Servizi Cognitivi
Capitolo 4
Guida all’utilizzo
4.1
BioMetricWallet
Configurazione Wallet:
1. Aprire il menù, scorrendo il con dito verso destra e selezionare la voce Wallet
2. Attivare lo switchModify Wallet Info, creare il proprio wallet tramite il bottone CREA-TE A NEW WALLET oppure inserire il proprio wallet address e la propria chiave
privata negli appositi spazi. Poi disattivare lo switch.
Figura 4.2: BioMetricWallet wallet
3. Premere CHECK YOUR BALANCE per ottenere l’attuale bilancio in Ether e GET TRANSACTIONS LIST per ottenere la lista delle transazioni associate al proprio
wallet
Avvio Comunicazione:
1. Schermata iniziale, nella parte superiore il proprio nome bluetooth, nella parte inferire lo switch per avviare la comunicazione
Figura 4.4: BioMetricWallet homepage
2. Notifica di transazione eseguita ma non confermata e notifica di transazione confer-mata
4.2
BioMetricServer
1. Premere il bottoneCHECK FOR AVAILABLE DEVICES
Figura 4.6: BioMetricServer homepage
2. Selezionare il dispositivo dell’utente e pagina di attesa mostrata durante registrazione o autenticazione
Figura 4.7: BioMetricServer connection page
4. Conferma transazione
Figura 4.9: BioMetricServer transaction confirmed
Capitolo 5
Sviluppo
5.1
Struttura Client Server
Il progetto si basa sulla comunicazione fra dispositivi dei quali uno funge da server e vende prodotti ad esempio un distributore automatico, mentre uno funge da client e rappresenta il dispositivo utilizzato dall’utente che desidera interagire con il server.
Nello schema iniziale del progetto era previsto che il server fosse realizzato con un Rasper-ry ed il client con un classico smartphone Android o iOS.
Successivamente questo schema è stato modificato, prevedendo l’utilizzo di uno smartpho-ne sia come client che come server.
Di seguito sono riportate le informazioni tecniche dei devices utilizzati:
Xiaomi MI A1 Sistema operativo Android 9.0 64 bits si RAM 4 GB Fotocamera 12 Mp 3968x2976 pixel Bluetooth 4.2
Samsung GALAXY ALPHA Sistema operativo Android 4.4.4 64 bits no RAM 4 GB Fotocamera 12 Mp 4608x2592 pixel Bluetooth 4.0 Tabella 5.1: Scheda tecnica devices
5.1.1
Schema Vending e Client
Lo schema seguente rappresenta le operazioni principali che dovranno essere eseguite dai dispositivi:
Figura 5.1: Connessione client server
5.1.2
Progettazione Client e Server
Client e Server sono stati progettati e sviluppati in due progetti Xamarin Forms separati poiché sono necessarie due diverse applicazioni che svolgano determinati compiti.
BioMetricWallet
BioMetricWallet è il progetto della parte client, un’applicazione per mobile che viene instal-lata dall’utente che desidera interagire con il server (Vending machine).
L’applicazione permette di gestire il proprio Wallet Ethereum e salvarne le informazioni in un database locale interno, e nel caso non si abbia già un wallet è possibile crearlo.
È possibile visualizzare il proprio bilancio di ether e la lista delle transazioni che hanno coin-volto il proprio indirizzo del wallet.
La sua funzione principale però, è quella di comunicare via bluetooth con l’altro dispositivo. Questo viene permesso attivando uno switch sulla pagina principale così abilitando la con-nessione tra il client ed i server.
Lo scopo di questo progetto è limitare l’interazione dell’utente con il proprio dispositivo durante la procedura di connessione, autenticazione e pagamento; di fatto l’utente dovrà utilizzare il proprio device solo nei seguenti casi:
• Avviare l’applicazione ed attivare lo switch
• Confermare il pin di sicurezza nella fase di primo accoppiamento con il server
• In qualunque momento si volesse verificare il proprio bilancio ether o la lista delle transazioni
Il pagamento viene effettuato automaticamente dall’applicazione previo scambio di specifici di messaggi e controlli con il server che autorizzano la transazione.
Tutte le operazioni come l’autenticazione attraverso riconoscimento facciale, registrazione nel caso del primo utilizzo o acquisto del prodotto, sono state delegate all’applicazione server.
BioMetricServer
BioMetricServer è il nome del progetto della parte server ed è anch’esso un’applicazione mobile che rappresenta un possibile distributore automatico, che si occupa di gestire la comunicazione con le applicazioni client.
Le sue funzioni sono le seguenti:
• Ricerca e connessione al client desiderato • Registrazione di un nuovo dispositivo
• Autenticazione di un dispositivo già conosciuto
• Aggiornare l’AI tramite l’inserimento di nuove foto dell’utente • Gestione degli acquisti dei prodotti
5.2
Comunicazione Bluetooth
La tecnologia utilizzata per gestire la comunicazione tra i dispositivi è quella Bluetooth. I vantaggi che derivano dall’utilizzo di una tecnologia di questo tipo, per la trasmissione dei dati, sono molteplici:
• Impostare una connessione bluetooth è facile e veloce, grazie anche all’ottimo sup-porto ed alla ricca documentazione delle APIs di Android
• Non è soggetta ad interferenze da altri dispositivi wireless
• In confronto ad una comunicazione Wi-Fi, il consumo energetico è nettamente inferio-re
• Gode di una buona distanza massima di trasmissione, in paragone ad una comunica-zione NFC che ha un range di circa 4 cm
• Sicurezza perché viene stabilita una connessione tra i dispositivi
• La connessione viene resa sicura dal pairing antecedente allo scambio di dati tra i due dispositivi
Bluetooth in Android
La piattaforma Android permette di accedere alla funzionalità Bluetooth del dispositivo at-traverso le Android Bluetooth APIs, le quali permettono di effettuare operazioni come lo scanning di nuovi dispositivi, ottenere i dispositivi già associati con il proprio dispositivo, sta-bilire un canale RFCOMM (simula una connessione cablata), connessione ad altri dispositivi dopo il discovery, trasferire dati e gestire connessioni multiple.
Per creare una connessione bluetooth tra due dispositivi, è stato necessario implementare un lato server ed un lato client, rispettivamente uno apre il server socket e l’altro avvia la connessione utilizzando l’indirizzo MAC del server.
Sia il server che il client ottengono un BluetoothSocket connesso sullo stesso canale RF-COMM, dal quale a loro volta ottengono uno stream di input ed uno di output in modo da poter iniziare la trasmissione dati.
Il server riceve il BluetoothSocket quando accetta una connessione in entrata, il client lo riceve quando apre un canale RFCOMM verso il server.
Nei prossimi paragrafi sarà spiegato chi tra i due progetti BioMetricWallet e BioMetricServer avrà il ruolo di Bluetooth server o Bluetooth Client.
Figura 5.2: Connessione bluetooth client server
5.2.1
Client Server prima versione
Nella prima versione dell’implementazione delle Bluetooth APIs è stato scelto di utilizzare BioMetricServer come bluetooth server e BioMetricWallet come bluetooth client.
Per rispettare l’obbiettivo di evitare l’interazione dell’utilizzatore con il proprio telefono, l’appli-cazione si occupa di ricercare ed eventualmente connettersi ad un server automaticamente.
BioMetricWallet, l’applicazione installata sul dispositivo dell’utente, necessita di un primo av-vio da parte dell’utente stesso per poi proseguire nell’esecuzione automatica delle seguenti operazioni:
1. Ricerca dei dispositivi disponibili
2. Connessione automatica al dispositivo con nome VENDOR _xxxx (Nome bluetooth che identifica un distributore automatico
3. Avvio transazione pagamento previe operazioni di Autorizzazione/Registrazione ed acquisto gestite dal server
4. Chiusura connessione 5. Ritorno allo step numero 1
Un’interazione con il proprio dispositivo sarà necessaria solamente in due casi:
• Nel caso in cui ci si voglia connettere con un nuovo dispositivo mai associato prima, sarà necessaria una piccola interazione con il proprio telefono per confermare il Pin di pairing. Questo garantisce la sicurezza che il proprio dispositivo si colleghi con il Server Reale e non ad un fantomatico dispositivo che potrebbe rubare i proprio dati sensibili quindi il proprio denaro.
• Nel caso in cui si voglia consultare il proprio bilancio o la lista delle transazioni del proprio Wallet
L’utente interagirà per tutta la durata delle operazioni con l’applicazione BioMetricServer, fino al termine dell’acquisto del prodotto. Il suo ciclo di vita è caratterizzato dalle seguenti fasi:
1. Attesa di connessione da parte del client
2. Se l’indirizzo bluetooth del client è già conosciuto si passa allo step tre altrimenti allo step 4
3. Autenticazione del dispositivo mediante riconoscimento facciale 4. Registrazione del dispositivo e del volto dell’utente
5. Operazione di acquisto del prodotto e ricezione conferma dal client 6. Chiusura connessione
7. Ritorno allo step numero 1
I processi di Autenticazione, Registrazione e Pagamento sono spiegati in dettaglio nel capi-tolo successivo.
Un’attenta analisi di questa prima soluzione ha portato in evidenza importanti e non trascu-rabili svantaggi:
• Sicurezza compromessa perché la connessione viene avviata dal client ed accettata
automaticamente dal server (sempre in ascolto).
Immaginando una probabile e comune situazione in cui si hanno diversi clients nei dintorni del server, si evince facilmente il problema che verrebbe causato.
Molteplici client tenterebbero di connettersi al server, quest’ultimo accetterebbe le connessioni senza rispettare un determinato criterio così costringendo l’utente che desidera utilizzare il distributore in una situazione di totale impotenza, siccome dal server risulterebbe impossibile scegliere con quale client iniziare la comunicazione. • Consumo energetico il dispositivo dell’utente, si trova sempre in una fase di ricerca
dei dispositivi attiva (Discovery mode), siccome si vuole automatizzare completamen-te la connessione al server senza l’incompletamen-terazione dell’ucompletamen-tencompletamen-te scompletamen-tesso.
Questa operazione risulta altamente dispendiosa in termini di consumo energetico, siccome al contrario del server che è collegato alla rete elettrica, il dispositivo dell’u-tente viene alimentato dalla batteria dello smartphone. Considerando al giorno d’oggi l’importanza di avere uno smartphone sempre funzionante e disponibile, risulta inac-cettabile che un’applicazione resti sempre attiva in background a consumare tutte le riserve energetiche.
La presenza di questi svantaggi porta alla ricerca di una nuova soluzione che possa appor-tare dei miglioramenti.
Per sopperire al problema dell’elevato consumo energetico, quindi del client in continua mo-dalità di ricerca, viene valutata la possibilità di non utilizzare il bluetooth classico, bensì il Bluetooth Low Energy (BLE).
5.2.2
BLE
Contrariamente al bluetooth classico, il Bluetooth Low Energy (BLE), è progetta per operare con un basso consumo energetico. Questo permette alle applicazioni Android di comunicare con dei dispositivi BLE senza necessità di avere capacità energetiche particolari.
A partire dalla versione 4.3 di Android (API livello 18) è stato introdotto il supporto BLE sui dispositivi e sono state rese disponibili le APIs per poter eseguire operazioni come ricerca di dispositivi e trasmissione dati.
Il vantaggio dal punto di vista energetico nell’utilizzo di questa tecnologia è evidente, nasce però un problema in fase di implementazione.
Il problema riscontrato è quello di non poter ricevere il nome dei dispositivi trovati durante la ricerca dei dispositivi ble disponibili, operazione diversa da quella effettuata con il bluetooth classico, bensì permettono di visualizzare e ricevere solamente il loro indirizzo bluetooth.
L’identificazione dei dispositivi server avviene tramite il nome assegnato al bluetooth ( VEN-DOR _xxxx ), se questo non viene reso disponibile in fase di discovery per motivi di sicurez-za di android, allora non è possibile conoscere quale dispositivo ha ruolo di server e quale no.
Nasce nuovamente l’esigenza di ricercare una nuova soluzione che permetta di risolvere i due svantaggi trovati precedentemente, bassa Sicurezza ed alto Consumo Energetico
5.2.3
Client Server seconda versione
Una nuova analisi porta alla progettazione della seconda versione di implementazione delle bluetooth APIs, quella attualmente in uso nel progetto.
Le necessità sono quelle di abbassare il consumo energetico dell’applicazione installata sul dispositivo dell’utente e garantire maggiore sicurezza nella fase di connessione tra i dispo-sitivi.
Ciò che causa il maggior dispendio energetico, come già detto in precedenza, è la fase di ricerca dei nuovi dispositivi.
Da qui nasce l’idea di invertire i ruoli scelti nella prima versione, quindi l’applicazione BioMe-tricWallet non sarà più il bluetoothclient, bensì il bluetooth server, mentre di conseguenza l’applicazione BioMetricServer diventerà il bluetoothclient.
Quali sono i vantaggi di questo nuovo approccio?
• Il server è connesso alla rete elettrica, quindi il dispendio energetico causato dalla fase di discovery non lo affligge
• Il client al quale connettersi verrà selezionato dall’utente sul server, sarà quindi lui ad assicurarsi di avviare la connessione sul proprio device
• L’applicazione client dell’utente, si comporterà da bluetoothserver; quindi non farà altro che aprire un socket ed aspettare che qualcuno si connetta, operazione energi-camente parlando efficiente
• Non si ha più alcun vincolo sul nome da assegnare al bluetooth del server (Distributore Automatico)
Alla fase attuale le applicazioni si comportano nel seguente modo:
• BioMetricServer, la Vending Machine, adesso permette di ricercare i dispositivi
intor-no a lei e permette la connessione a quello selezionato.
• BioMetricWallet, l’applicazione sul device dell’utente, è in attesa che qualcuno si
Di seguito viene mostrato lo schema di funzionamento della seconda ed attuale versione:
Figura 5.5: Client Server seconda versione
5.2.4
Protocollo flusso di comunicazione
Per gestire il flusso di messaggi che BioMetricServer e BioMetricWallet si scambieranno durante la loro esecuzione è stato definito un protocollo, che ne definisce ordine di in-vio/recezione e relativa risposta.
Una volta ottenuto il BluetoothSocket dopo aver stabilito la connessione tra i due dispositivi, è possibile ricevere lo stream di input per la ricezione dei dati (BluetoothSocket.InputStream) e lo stream di output per l’invio (BluetoothSocket.OutputStream).
I dati vengono inviati e ricevuti sotto forma di stringa, inseriti in un buffer di byte che viene trasportato dagli streams.
Le stringhe sono trasmesse con il formato:
MessageIdentificator _Content
MessageIdentificator è una stringa che specifica il tipo di messaggio che viene trasmesso: • ADDRESS è un messaggio che contiene un wallet address
• SHOP è un messaggio che contiene il prezzo di un prodotto o la conferma di una
Considerando l’Autenticazione/registrazione del dispositivo già avvenuta, si
rappre-senta lo scambio di messaggi sullo stream tra dispositivi con il seguente schema:
Figura 5.6: Scambio di messaggi tra dispositivi
5.3
Autenticazione
L’obbiettivo principale di questo progetto è quello di autenticare l’utente ed il relativo dispo-sitivo tramite un sistema di riconoscimento biometrico.
La pianificazione iniziale del progetto prevedeva l’implementazione di un riconoscimento vo-cale sia per l’autenticazione dell’utente sia per eseguire l’acquisto del prodotto.
L’utente si sarebbe registrato al servizio registrando la sua voce e pronunciando alcuni nu-meri.
Un primo ostacolo di questo sistema si presenta nel momento in cui il server si dovesse trovare in una zona affollata, ad esempio il classico distributore automatico in una scuola.
Campionare e registrare la voce di un utente dal server per la registrazione ad un servi-zio che permette lo scambio di denaro, in un ambiente non adatto e probabilmente caotico, non è una buona soluzione.
Durante l’implementazione del sistema si sono verificati dei problemi di sviluppo, dovuti anche alla piattaforma xamarin, che hanno portato al cambiamento del sistema di ricono-scimento biometrico.
Il nuovo sistema di autenticazione scelto è un sistema di riconoscimento facciale, implemen-tato utilizzando le API di Microsoft introdotte all’inizio del documento.
5.3.1
Riconoscimento Facciale
Il riconoscimento facciale è un sistema di autenticazione biometrico; ovvero viene utilizzata e misurata una parte del corpo, in questo caso il viso umano, e viene classificato in base a forma, struttura ed altri parametri.
Questi sistemi di riconoscimento possono accettare come input immagini 2D o 3D, anche se la maggior parte dei sistemi è si basa su input del primo tipo.
I punti di riferimento che vengono utilizzati in questi algoritmi sono generalmente naso, bocca e occhi, ne viene analizzata la forma, la distanza tra loro e la loro dimensione. Esistono degli step di base che un algoritmo deve eseguire:
• Riconoscimento della porzione di immagine che contiene un viso
• Elaborazione della porzione di immagine identificata in termini di ridimensionamento e rotazione, in modo da poter identificare la geometria del viso come distanza tra gli occhi, dimensione delle labbra, distanza tra le orecchie ecc.
• Una volta ottenuta la geometria del viso, viene generato un codice univoco che per-metta di identificare e comparare il viso
• Utilizzare un sistema di Deep Learning che contenga un dataset di immagini taggate di foto di visi umani
• Capacità di confrontare i visi e fornire un feedback sul matching positivo o negativo Le applicazioni di questo sistema sono molteplici, ad esempio sblocco dello smartphone (iPhone è stato il primo device ad implementarlo), controllo delle persone in transito negli aeroporti, social media che riconoscono le le persone presenti in una foto caricata.
5.3.2
Implementazione Fotocamera
Il primo approccio allo sviluppo del codice per sfruttare la fotocamera del dispositivo è sta-to quello di utilizzare le APIs di Android, le quali offrono controllo ed accesso complesta-to dell’hardware.
È stata eseguita l’implementazione sulla piattaforma Android che permette lo scatto ed il salvataggio della foto che verrà poi elaborata dall’algoritmo di riconoscimento facciale. Lo scopo per il quale è stato scelto Xamarin come piattaforma di sviluppo è quello di costrui-re una solida base per una futura estensione del progetto anche sulla piattaforma iOS, quin-di cercare quin-di implementate la maggior parte della logica del progetto nella parte quin-di coquin-dice condiviso dalle piattaforme.
La libreriaMediaPlugin viene in soccorso per rispettare questo principio; questa
permet-te di gestire l’hardware della fotocamera completamenpermet-te nella parpermet-te di shared code, così rendendo compatibile il codice sia per la piattaforma Android che per la futura piattaforma iOS.
Questa libreria è stata facilmente installata da Nuget, package manager di Visual Studio, e permette di scattare una fotografia utilizzando un’applicazione già esistente nel dispositivo, ad esempio quella di default, e di utilizzare il risultato in formato stream per i propri scopi.
5.3.3
Schema autenticazione
Quando il server decide di avviare la connessione verso uno dei dispositivi trovati, controlla tramite l’indirizzo bluetooth del dispositivo (univoco per ogni device) se è la prima volta che si stabilisce la connessione oppure no.
Il caso positivo viene avviata la procedura di registrazione dell’utente invece in caso nega-tivo si avvia la procedura di autenticazione, entrambe implementate nella parte di codice condiviso.
Registrazione
La procedura di registrazione è effettuata dal metodo RegisterNewAsync(address), che prende in input l’indirizzo MAC bluetooth del dispositivo dell’utente.
I passi che vengono effettuati sono i seguenti:
• La registrazione consiste nello scatto di 3 fotografie al viso dell’utente
• Elaborazione delle fotografie ed estrazione delle informazioni del viso per ogni singola foto
• Aggiunta delle informazioni elaborate ad un dataset identificato dall’indirizzo bluetooth dell’utente ricevuto come parametro
• Training dell’AI sul dataset appena creato • Attesa completamento del training
È stato scelto un numero di foto pari a tre per riuscire ad effettuare un iniziale e basilare training del dataset.
Autenticazione
La procedura di autenticazione effettuata dal metodo bool AuthentifyAsync(string address), che come per il metodo precedente prende in input l’indirizzo MAC bluetooth del dispositivo dell’utente e ritorna un valore booleano positivo in caso di riconoscimento.
I passi che vengono effettuati sono i seguenti: • Scatto di una fotografia al viso dell’utente
• Elaborazione della fotografia ed estrazione delle informazioni del viso
• Confronto della foto con quelle contenute nel dataset identificato dall’address ricevuto come parametro
• Ritorno esito positivo con relativo valore della probabilità o ritorno esito negativo
Aggiunta immagine al dataset
Una volta stabilita la connessione ed effettuata l’autenticazione del dispositivo, dal server è possibile scattare una nuova foto ed aggiungerla al dataset.
Questa operazione torna utile nel caso si voglia aggiungere una propria foto con o senza gli occhiali, con una nuova espressione ecc.
Una volta aggiunta la nuova foto, il dataset effettua l’operazione di training tramite le FaceA-PI.
Di seguito si rappresenta lo schema delle fasi di autenticazione:
Figura 5.7: Fasi autenticazione
5.3.4
Face API
Face API, è il servizio messo a disposizione da Microsoft Azure Servizi Cognitivi, che permette di elaborare le immagini di visi umani.
• Rileva e confronta i visi
• Permette di organizzare le immagini in gruppi
• Identifica i visi di persone, già precedentemente identificate, nelle immagini
• Gli algoritmi possono essere eseguiti in locale tramite l’SDK o utilizzando le API REST ed effettuando richieste Http al server Azure
Face detection
Con Face detection si intende l’operazione che permette di localizzare un viso umano in un’immagine e fornire dei dati relativi ad esso.
Ogni viso rilevato corrisponde ad un rettangolo nel quale può essere contenuto, il metodo per rilevare i visi ritornare una lista di risultati, dei quali il primo è il viso contenuto nel rettangolo più grande.
Ogni viso viene identificato univocamente da una stringa chiamata Face ID.
Nell’immagine seguente viene rappresentato un viso con i suoi 27 punti di riferimento pre-definiti, utilizzati dagli algoritmi del servizio per elaborare le immagini.
Figura 5.8: Landmarks di un viso
Quando una faccia viene rilevata è possibile ottenere una serie di attributi: • Age come un stima dell’età
• Blur come livello di sfocatura dell’immagine
• Emotion come tipo di emozione del viso identificato ad esempio felice, triste, neutro, arrabbiato ecc.
• Exposure come valore di esposizione
• Facial Hair come stima della quantità dei peli sul viso • Gender come stima del sesso
• Glasses per verificare la presenza ed il tipo di occhiali • Hair come colore e tipo di capelli
• Head pose intenso come l’orientamento del viso in uno spazio 3D, come mostrato nella seguente figura
Figura 5.9: Orientamento del viso
• Makeup per indicare la presenza o meno di makeup • Noise per un valore del rumore visivo
• Occlusion per indicare una parte del viso coperta da un ostacolo • Smile che indica con 0 l’assenza di sorriso e con 1 un evidente sorriso
Le immagini che vengono date in input agli algoritmi devono rispettare dei canoni per poter essere elaborate:
• I formati supportati sono JPEG, PNG, GIF (primo frame) e BMP • La dimensione massima del file deve essere 4 MB
• Il range della faccia per essere identificata e tra 36x36 e 4096x4096
• Una posizione frontale nella fotografia può solo migliorare l’accuratezza nei risultati
Face recognition
Face recognition è l’operazione che permette di confrontare due diverse facce e determinare quanto sono simili e se appartengono alla stessa persona.
Questa operazione utilizza una struttura dati ben precisa, gli oggetti utilizzati descritti nella lista seguente sono memorizzati sul cloud e sono identificati dalla loro stringa ID univoca.
• DetectedFace rappresenta la faccia generata dal metodo di rilevamento del volto,
dopo 24 ore dalla sua creazione viene eliminata dal cloud
• PersistedFace rappresenta una DetectedFace che viene aggiunta ad un gruppo, in
questo caso il salvataggio sul database è permanente e possono essere recuperate in qualsiasi momento
• FaceList rappresenta una lista di PersistedFace
• Person rappresenta un FaceList che appartiene ad una determinata persona,
carat-terizzata da un ID univoco ed un nome
• PersonGroup rappresenta una lista di Person, anche questo possiede un ID
univo-co. Deve essere sottoposto a training prima di essere utilizzato per operazioni di riconoscimento
Le operazioni di riconoscimento citate nell’ultimo punto dell’ultima lista sono le seguenti, ed utilizzano le strutture dati appena descritte:
• Verify prende in input un face ID generato dall’operazione di Face Detection o uno
ottenuto da una Persisted Face, ed un altro face ID o un oggetto di tipo Person o PersonGroup e determina se le facce appartengono alla stessa persona
• Find Similiar prende in input un face ID e ritorna una lista di facce simili
• PersonGroup prende in input una lista di face ID e la divide in gruppi che contengono
le facce simili tra loro
• Identify prende in input un face ID e ritorna una lista di Person, etichettati come oggetti
Candidate, ai quali questa faccia potrebbe appartenere
5.3.4.1 Funzioni esposte
Le funzioni esposte che Face API sono molteplici, ma di seguito sono elencate solamente quelle utilizzate ed implementate nel progetto.
• PersonGroup - Create permette la creazione di un nuovo person group con uno
spe-cifico personGroupId (in questo progetto uguale al bluetooth address del dispositivo dell’utente)
• PersonGroup Person - Create permette la creazione di un nuovo oggetto person in
uno specifico person group
• PersonGroup Person - Add Face permette di aggiungere un viso ad una persona
contenuta in un person group per future operazioni di identificazione o verifica • PersonGroup - Train permette di effettuare il training del person group, così
permet-tendo di utilizzare metodi su esso come Face - Identify
• PersonGroup - Get Training Status permette di verificare se il training del
person-group è stato completato oppure è ancora in esecuzione
• Face - Identify permette, dato un certo face Id in input, di verificare se la faccia
passata a parametro appartiene ad una persona contenuta in un person group, di cui l’Id viene passato anch’esso a parametro
• Face - Detect permette il rilevamento di un volto in un’immagine e ritorna un faceId
Come detto in precedenza, è possibile utilizzare queste funzioni sia scaricando il package della libreria nel proprio progetto sia utilizzando le API REST.
In entrambi i casi è necessario registrarsi al servizio Cloud in modo da ottenere la chiave privata da utilizzare durante il richiamo di questi metodi.
5.3.4.2 Implementazione
Per lo sviluppo di Face API nel progetto è stato scelto di utilizzare le API REST, quindi si accede ai metodi effettuando richieste tramite il protocollo HTTP.
BioMetricServer è l’applicazione incaricata di scattare le fotografie all’utente, quindi anche di gestirne la relativa autenticazione.
La classe nel quale è stata implementata la logica per l’utilizzo di questo servizio è FaceRe-cognition e si trova nella parte di codice condiviso.
Figura 5.10: FaceRecognition.cs
All’interno di ogni metodo viene effettuata una richiesta HTTP al cloud e si riceve una rispo-sta sotto forma di json.
Per effettuare queste chiamate viene utilizzata la classe HttpClient che permette facilmente di definire l’Uri, i parametri, gli headers con chiave e valore e di passare un json nel body. Di seguito viene riportato un esempio di implementazione del metodo CreatePersonGroup che esegue una richiesta HTTP di tipo PUT:
Il server gestisce tutta l’implementazione del bluetooth nativamente nella piattaforma An-droid, una volta eseguita la connessione con il device client viene eseguito il metodo per gestirne l’autenticazione.
Questo metodo è contenuto nella parte di codice condiviso e prende in input l’indirizzo blue-tooth del client.
Il personGroupId è il bluetooth address del device dell’utente, questa scelta, permette di avere un personGroupId univoco per ogni device.
Come avviene il controllo sulla già avvenuta registrazione del device sul server o meno?
Una volta stabilita la connessione tra dispositivi si richiama subito il metodo che permette la creazione di un Person Group che ritorna un errore di conflitto nel caso esista già un Person Group con id uguale al bluetooth address passato o risposta positiva in caso di creazione di uno nuovo.
Nel primo caso viene avviata la procedura di Autenticazione altrimenti viene avviata quella di Registrazione.
I passi principali dell’autenticazione sono stati rappresentati nello schema "Fasi Autenti-cazione" nella Figura 4.7. Di seguito viene riproposto lo stesso modello di schema, con una differenza, per ogni fase verrà specificato l’esatto metodo della classe FaceRecognition utilizzato.
5.4
Transazione Ethereum
La blockchain Ethereum è una rete, l’Ether (ETH) è la benzina per questa rete.
Quando vengono trasferiti degli ETH o comunque si ha un’interazione con la rete, si effettua una transazione e bisogna pagarne la computazione dei dati.
Questa tassa, il pagamento della computazione, viene calcolato in GAS, anch’esso pagato in ETH; serve per pagare i miners che si occupano di minare la transazione, inserirla nei blocchi ed inserirla con sicurezza nella blockchain.
Questa viene pagata indipendentemente dall’esito finale della transazione, cioè dal suo successo o dal suo fallimento.
Una transazione ha una struttura precisa: • Mittente, indirizzo di 20 byte di un wallet • Destinatario, indirizzo di 20 byte di un wallet
• Valore, somma che si desidera trasferire in wei (1 wei =1018ether) • Data input, utilizzato per attività relative ai contratti.
• Prezzo del gas e limite, sono entrambe relative alla tassa pagata per effettuare la transazione
5.4.1
Gas
Quando si parla di Gas nell’ambito Ethereum si parla di:
• Prezzo del Gas
• Limite del Gas
Il costo totale della tassa per una transazione è Prezzo del Gas * Limite del Gas. Un paragone utile per capire questo meccanismo è quello di un automobile.
Il prezzo del Gas è il costo del carburante al litro mentre il limite del Gas è la quantità di litri di carburante.
Con un prezzo di 2 franchi a litro ed un rifornimento di 10 litri, il costo totale sarebbe 20 franchi.
Questo funziona allo stesso modo per le transazioni Ethereum.
Impostando il limite di Gas della transazione a 21000 (valore di default quando questo non viene specificato), se il prezzo unitario è 20 GWEI, il totale della tassa da pagare è 0.00042 ETH
21000 è il valore utilizzato per il Limite del Gas all’interno del progetto.
Una transazione può fallire poiché non si investe abbastanza gas, quindi la quantità investita non è abbastanza per coprire le operazioni di computazioni dei miners.
In questo caso la transazione fallisce per Gas esaurito. La scelta del prezzo del Gas, cioè quanto pagare ogni singola unità di GAS influisce sulla velocità di esecuzione della propria transazione.
Normalmente, un prezzo del Gas di:
5.4.2
Schema transazione
Figura 5.13: Transazione Ethereum
5.4.3
Wallet sul Client
L’applicazione BioMetricWallet, tramite il menu, permette di accedere alla pagina Wallet. Questa pagina permette di:
• Creare un wallet dal sito www.myetherwallet.com
• Inserire la propria chiave privata ed il proprio indirizzo pubblico da utilizzare durante le transazioni
• Salvare chiave privata ed indirizzo in un database locale SqLite
• Visualizzare le informazioni sulle transazioni che hanno coinvolto il proprio wallet
5.4.4
Nethereum API
Nethereum API è la libreria che è stata utilizzata per gestire la comunicazione tra applica-zione e rete Ethereum.
È stata implementata nella classe NethereumImplementation in entrambi i progetti BioMe-tricWallet e BioMetricServer.
• Il metodo utilizzato in BioMetricServer è GetAccountBalance(string address), che per-mette di ricevere il bilancio Ethereum dell’indirizzo passato a parametro.
• In BioMetricWallet è utilizzato il metodo TransferEtherAsync(destinationAddress, eth), permette di trasferire una quantitàeth di Ethereum ad un indirizzo address
5.4.5
Etherscan API
Etherscan, famoso sito che permette di esplorare la rete Ethereum, permettendo la verifica dello stato della rete, delle transazioni, dei contratti e altro ancora.
Mette a disposizione delle API che permettono di interrogare la rete Ethereum
Nel progetto queste API sono state utilizzate per ottenere la lista delle transazioni che hanno coinvolto l’indirizzo wallet dell’utente.
Le API vengono chiamate con una richiesta HTTP REST di tipo Get, il metodo utilizzato si chiama GetTransactionList, che ritorna una lista di oggetti di tipo Transaction, successiva-mente aggiunta ad una lista visibile nell’interfaccia grafica.
La classe Transaction è strutturata nel seguente modo: • Hash, indirizzo hash che identifica la transazione • From, indirizzo del wallet del mittente
• To, indirizzo del wallet del destinatario • Age, data della transazione
• Value, somma trasferita
• Gas, commissione pagata per la transazione
5.4.6
Notifica transazione
Android permette di generare notifiche personalizzate direttamente dalla propria applicazio-ne.
Gli elementi che la compongono sono i seguenti:
Figura 5.14: Notifica Android
Questo sistema viene utilizzato in questo progetto per notificare l’utente quando la transa-zione effettuata durante l’operatransa-zione di acquisto dal server viene effettivamente confermata ed inserita nella blockchain.
La logica per gestire le notifiche è stata implementata interamente in BioMetricWallet, quindi sull’applicazione sul dispositivo dell’utente.
Durante l’operazione di pagamento, durante la connessione con il server, vengono eseguiti i seguenti passi:
1. Si esegue la transazione e si riceve il suo indirizzo hash (indirizzo univoco che identi-fica una transazione).
2. L’indirizzo ottenuto viene inserito in un database locale, che contiene tutte le transa-zioni eseguite dall’applicazione non ancora confermate.
Il Database, come detto in precedenza, contiene tutte le transazioni che sono state esegui-te ma non sono ancora staesegui-te inseriesegui-te nella blockchain. A questo punto è necessario poesegui-ter controllare lo stato di queste transazioni.
La soluzione è stata realizzata attraverso l’implementazione di un timer che ad ogni avvio dell’applicazione, ogni 10 secondi, controlla lo stato delle transazioni.
Il timer, implementato utilizzando la libreria AdvancedTimer, permette di definire una funzio-ne da eseguire ed ogni quanto eseguirla.
Le operazioni svolte dalla funzione contenuta nel timer sono le seguenti: 1. Recupero lista di transazioni dal database
2. Per ogni transazione, verificarne lo stato tramite l’utilizzo delle API di Etherscan 3. In caso di transazione completata, viene generata una notifica e viene rimossa la
transazione dal database
4. Dopo aver controllato tutte le transazioni si attende la ri-esecuzione delle operazioni da parte del timer
Il vantaggio è che, se dopo l’avvio di una transazione, l’applicazione dovesse essere chiusa o la connessione si dovesse perdere; al successivo avvio si effettuerà comunque il controllo nel database, quindi la notifica prima o poi sarà sicuramente generata.
Di seguito si riporta uno schema che rappresenta la logica appena descritta:
Capitolo 6
Conclusione
6.1
Stato del lavoro
Gli obbiettivi posti all’inizio del progetto sono stati generalmente raggiunti, anche se alcuni hanno dovuto subire dei cambiamenti, ad esempio l’utilizzo di due telefoni al posto di un telefono ed un raspberry oppure l’utilizzo di un sistema di image recognition al posto di un sistema di riconoscimento del linguaggio NLP..
È stato sviluppato un prototipo che gestisce una connessione bluetooth fra due dispositivi Android, che permette di effettuare un trasferimento di Ethereum tra i wallet dei due dispo-sitivi.
Questo trasferimento è effettuabile solo dopo che l’utente che desidera utilizzare il servizio viene identificato con tecnologia biometrica tramite un sistema di riconoscimento facciale. È possibile anche creare e gestire il proprio wallet direttamente dall’applicazione installata sul device dell’utente.
6.2
Problemi riscontrati
Alcune dei problemi riscontrati sono stati causati dall’utilizzo di Xamarin, durante l’imple-mentazione di alcune librerie e durante l’implel’imple-mentazione della logica di comunicazione tra piattaforma Android e zona di codice condiviso. Inizialmente sono stati evidenziati problemi di dispendio energetico dati dall’utilizzo del bluetooth, successivamente risolti.
Il problema attuale del progetto è che effettua richieste HTTP, utilizzando la rete, per effet-tuare l’autenticazione dell’utente; quindi la velocità di esecuzione delle procedure dipende dalla qualità della rete nel momento di utilizzo.
6.3
Considerazioni personali
Questo progetto affronta due tematiche molto attuali, lo sviluppo di applicazioni mobili e l’in-terazione con una blockchain. Ho avuto l’occasione di approfondire le mie conoscenze in questi due ambiti, creando un prodotto che ne congiunge le loro funzionalità. Sono soddi-sfatto di ciò che è stato realizzato pur essendo consapevole dei possibili miglioramenti che potrebbero essere apportati.
6.4
Sviluppi futuri
Il progetto potrebbe essere migliorato migrandolo anche sulla piattaforma iOS. La grafi-ca dell’interfaccia utente non è stato l’obbiettivo primario di questo prototipo, ma potrebbe essere migliorata e resa più accattivante. Si potrebbe implementare un sistema di ricono-scimento vocale da associare all’attuale sistema di riconoricono-scimento facciale. Infine l’utilizzo della rete di test di Ethereum è idoneo per una fase prototipale, ma per una versione di distribuzione sarebbe opportuno operare sulla rete principale.
