tfm- seguretat en sistemes biotmètricsdeim.urv.cat/~francesc.serratosa/2017_05_21_axel_picon...tfm-...
TRANSCRIPT
AUTENTIFICACIÓ D’HUMANS A TRAVÉS DEL
RECONEIXEMENT DE LA SIGNATURA UTILITZANT
DISPOSITUS MÒBILS ANDROID
Màster Interuniversitari en Seguretat de les TIC
(MISTIC)
Memòria Final
Tutor: Francesc Serratosa Casanelles
Alumne: Axel Picón Magdalena
Data: Juny de 2017
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 2
“L’únic sistema segur és aquell que està apagat en l’interior d’un bloc d’hormigó
protegit en una habitació sellada rodejada per guardies armats”
Gene Spafford
Autor del projecte: Axel Picón Magdalena, 2017
Les imatges utilitzades en el projecte en tenen els drets els seu respectius propietaris i s’utilitzen seguint el dret de cita en l’àmbit
acadèmic i només per finalitats acadèmiques (article 32 de la Llei de la Propietat Intel·lectual)
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 3
Agraïments:
Amb aquest redactat es vol valorar i agrair, primerament l’ajuda del consultor i tutor
de la Universitat Rovira Virgili Francesc Serratosa Casanelles, que amb els seus
comentaris de les diferents situacions que s’han viscut en aquest projecte ha permès
que s’hagi completat el projecte i dissenyat una documentació final atractiva i
completa.
També en aquest apartat es vol fer un agraïment a la meva família que amb la seva
gran paciència i comprensió ha aportat a que durant la realització d’aquest projecte es
pogués dedicar el màxim de temps possible amb la finalitat de finalitzar aquest
projecte del màster MISTIC
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 4
Resum del projecte
Català:
En els mateixos casos, hi ha la necessitat d'autenticació si una persona ha signat un document.
En aquestes situacions, és habitual demanar-li a la persona que signi en un troç de full i una
persona autoritzada validi si la nova signatura és suficientment similar a la signatura del
document.
L'objectiu d'aquest projecte fi de màster és dissenyar i implementar un mètode per comparar
signatures fetes a mà a través d'un dispositiu mòbil. En primer lloc, la persona que ha de ser
autentificada signarà a la pantalla del mòbil. En segon lloc, la persona autoritzada, realitzarà
una fotografia a la signatura del document mitjançant el dispositiu mòbil. Finalment, s’haurà
de validar amb garantia el grau de similitud.
Castellà
En los mismos casos, existe la necesidad de autenticar si una persona ha firmado en un
documento. En estas situaciones, es habitual pedirle a la persona que firme en un trozo de
papel y una persona autorizada valide si la nueva firma es suficientmente similar a la firma del
documento.
El objetivo de este proyecto final de master es diseñar e implementar un método para
comparar firmas hechas a mano a través de un dispositivo móvil. Primero, la persona tiene que
ser autentificada firmando en la pantalla del móvil. En segundo lugar, la persona autoritzada
realizara una foto en la firma del documento mediante el dispositivo móvil. Finalmente, se
tendra que validar con garantia el grado de similitud
English
In same cases, there is the need of authenticating if a person has signed a document. In these
situations, it is usual to ask the person to sign in a piece of sheet and an authorised person
validates whether the new signature is similar enough to the document’s signature.
The aim of this Master thesis is to design and implement a method to compare hand-made
signatures through a mobile device. First, the person to be authenticated will sign at the
mobile screen. Second, the authorised person will take a picture at the document’s signature.
Finally, the device will output a similarity degree between both signatures.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 5
INDEX
1) Introducció...................................................................................................................8-12
1.1) Situació actual, contextualització del Projecte ....................................................8-11
1.2) Objectius i motivació per a la realització del projecte .....................................11-12
1.3) Plannificació del projecte .......................................................................................12
2) Estructura Android/Interacció entre components ...................................................13-18
2.1) Estructura a nivell de xarxa Android ......................................................................18
3) Estructura i funcionament del projecte ....................................................................19-36
3.1) Aplicatiu Android ..............................................................................................20-30
3.2) Api rest ..............................................................................................................31-35
3.3) Servidor base de dades Sql server (Vmware) ........................................................36
4) Resultats de l’aplicatiu extern i introducció a la llibreria opencv ...........................37- 64
4.1) SIFT (Scale-Invariant Feartures) .......................................................................38-47
4.1.1) Escala-espai de detecció extrema .....................................................38 -39
4.1.2) Localització de keypoints….. ....................................................................40
4.1.3) Orientació…………………………………………………………………..……………..………..40
4.1.4) Punt clau descriptor ................................................................................40
4.1.5) Matchs dels keypoints .............................................................................41
4.1.6) Proves amb l’algorisme SIFT en el laboratori………………………...……….41-47
4.2) SURF (Speeded-Up Robust Features) ..............................................................48-56
4.2.1) Proves amb l’algorisme SURFT en el laboratori………………….………..…50-56
4.3) ORB (Oriented Fast and Rotated Brief) ..........................................................57-64
4.3.1) Proves amb l’algorisme ORB en el laboratori i dipositiu mòbil………..58-64
4.3.2) Conclusions amb l’algorisme ORB en el laboratori……………………..……….64
5) Elements de seguretat d’Android..............................................................................65-68
5.1) Arxiu AndroidManifest.xml................................................................................65-66
5.2) Usuari Linux i accés a l’arxiu...................................................................................66
5.3) L’esquema de permisos en Android……………………………………………………..…………….66
5.4) Mencanisme de seguretat sandbox…………………………………………….………..……….66-67
5.5) Partició del sistema i mode segur…………………………………………………………………..……67
5.6) Sistema de xifratge…………………………………………………………………………………….……….67
5.7) Protecció per contrasenya……………………………………………………………………………...…67
5.8) Administració de dipositius……………………………………………………………………….…..……68
5.9) Millores de seguretat en l’administració de la memòria………………………….…….……68
5.10) Permisos de “root” en els dispositius…………………………………………………….………….68
5.11) Signatura de les aplicacions……………………………………………………………………….……..68
6) Tipus d’atacs als dispositius Android ……………………………………………………………….….68-74
6.1) Atacs des del dispositiu.....................................................................................69- 72
6.1.1) Atacs procedents de carpetes emails o altres aplicacions ......................69-70
6.1.2) Atacs basats en telèfon/SMS……………………………………………….…………………70-71
6.1.3) Atacs bastas en aplicacions de tercers……………………………………………………….71
6.1.4) Atacs basats en sistema operatiu……………………………………………………….…71-72
6.2) Atacs procedents des de la xarxa.......................................................................72-73
6.3) Atacs procedents des d’un centre de dades (web service o base de dades).....73-74
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 6
6.3.1) Webservices …………………………………………………………………………………….……73-74
6.3.2) Base de dades…………………………………………………………………….……………………….74
7) Politiques de configuración en seguretat del dipositiu móbil................................. 74-76
8) Guia de seguretat pel desenvolupament d’aplicacions Android............................ 76 -93
8.1) Augmentar la complexitat del codi i l’ús d’ofuscació en l’aplicatiu Android……76-77
8.2) Evitar lògica simple………………………………………………………………………………………..77-78
8.3) Utilització de biblioteques de tercers……………………………………………………………….…78
8.4) Aplicar tècniques de protección contra manipulacions……………………….…………78-79
8.5) Emmagatzemar de forma segura dades confidenciasl en la memòria RAM…………79
8.6) Comprovar Eliminació segura de dades………………………………………………….………79-80
8.7) Evitar la cadena de consulta de les dades sensibles……………………………………….……80
8.8) Implementar emmagatzamatge segur de dades…………………………………………….……81
8.9) S’ha d’utilitzar un entorn per a les cookies…………………………………………………….……81
8.10) Validar totalment SSL/TLS…………………………………………………………………….………81-82
8.11) Protegir atacs downgrade SSL……………………………………………………………………………82
8.12) Protecció del tractament geològiques……………………………………………………….………83
8.13) Insertar temporització de la sesisió local en l’aplicatiu………………………………………83
8.14) Implementar auntentificació Enhaced/Two-Factor………………………………………83-84
8.15) Protegir la configuración de l’aplicació………………………………………………………………84
8.16) Amagar números de compte i l’ús de tokens…………………………………………….………84
8.17) Validar els valor de dades entrats pels usuaris………………………………………….………85
8.18) Evitar l’emmagatzamatge de dades en l’aplicació de còpies de seguretat…………85
8.19) Evitar tenir els registres logs habilitats en l’aplicatiu…………………………………………85
8.20) Tenir un control de registres de depuració generats per l’aplicatiu………………85-86
8.21) S’ha de ser concient de la funcionalitat en Android………………………………………..…86
8.22) Implementació de intents amb un controls exhaustiu…………………………………86 -87
8.23) Verificar el correcte funcionament de les activitats disenyades…………….…….……87
8.24) Utilització de broadcast amb cura……………………………………………………….……….……88
8.25) Implementació de pendingintents amb cura……………………………………………….……88
8.26) Protegir els serveis d’aplicacions………………………………………………………………….……88
8.27) Realitzar bones practiques del webview en els aplicatius Android…………….………89
8.28) Evitar l’emmagatzematge d’imatges de la càmera en memoria cau…………….……89
8.29) Els desenvolupadors sempre han de signar els arxius APK…………………………………90
8.30) Funcions de seguretat integrades en el sistema operatiu Android…….…………90-91
8.31) Permisos en aplicacions Android……………………………………………………………….………91
8.32) Segureta en l’utilització de xarxa en aplicatiu Android……………………………..………92
8.33) Ús de criptografía en aplicatius Android……………………………………………………………92
8.34) Seguretat de càrrega dinàmica de codi en Android………………………………………92-93
8.35) Utilització de programari lliure per milllorar la seguretat……………………….…………93
9) Eines d’android incloses en el programari pe analitzar i desenvolupar aplicacions
Android amb seguretat..............................................................................................94-96
10) Eines externes per analitzar i protegir aplicacions Android…………………………….….96-102
11) Tècniques d’ofuscació de codi en Android…………………………………………………………102-105
12) Guia per seguritzar l’aplicatiu contra atacs de Sql injection………………………………106-110
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 7
12.1) Escapar els caràcters especials utilitzats en les consultes Sql………………………..…106
12.2) Verificar sempre les dades que introduiex l’usuari en l’aplicatiu……………………..107
12.3) Assignar mínims privilegis a l’usuari que connecta amb la base de dades des de
l’aplicatiu …………………………………………………………………………………………………………………107
12.4) Realitzar modificacions del codi per tenir una codificació correcta………….………107
12.5) Protegir els logs ………………………………………………………………………………………………108
12.6) Utilitzar Sql dinàmic només si és absolutament necessàri……………….………………108
12.7) Instal·lar pegats (patch) regularment………………………………………………………………108
12.8) Treure tota la funcionalitat que no s’utilitizi……………………………………………………108
12.9) Utilitzar eines de proves automatitzades per les injeccions Sql…………….…………109
12.10) No revelar ni informació ni les credencials amb privilegis d’administrador
(enginyeria social)……………….…………………………………………………………………………….…….109
12.11) Utilització de firewall (application firewalls) …………………………………………………109
12.12) Xifrar les dades sensibles en la base de dades…………………………………….…109-110
12.13) No mostrar més informació de la necessària…………………………………………………110
12.14) No emmagatzemar dades sensibles…………………………………………………………..….110
13) Com monotoritzar i mitigar un possible atac en l’aplicatiu………………..…………..…111-114
13.1) Passos per prevenir un possible atac…………………………………....…………………111-112
13.2) Passos per mitigar un possible atac……………………………………………….…………112-114
14) Conclusions i treballs futurs………………………….……………………………………..……………115-116
15) Referències…………………………………………………………………………………………………..……117-123
16) Annex 1 Manual laboratori de proves………………………………………………………………..124-125
17) Annex 2 Manuals de l’aplicació completa ……………………………………………………..…..126-129
18) Annex 3 Storeds i taules utilitzades en el servidor de base de dades……………….…130-134
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 8
1. INTRODUCCIÓ
1.1 Situació actual, contextualització del projecte
Els requisits de seguretat de la societat d'avui, tenen la biometria col·locada en el centre d'un
gran debat, ja que, s'està convertint en un aspecte clau en una multitud de sistemes. Aquest
concepte de biometria és el reconeixement individual basat en les característiques distintives
d'una persona. Mentre altres tècniques utilitzen la possessió d'un objecte físic (és a dir, targeta
d'identificació, ID targeta, etc.) o el coneixement d'alguna cosa (és a dir, una contrasenya, clau
de fase, etc.) per a realitzar el reconeixement personal, en els últims anys s’han estat
implementant noves tècniques biomètriques les quals ofereixen la possibilitat d'utilitzar les
característiques inherents de la persona per a la seva identificació en qualsevol sistema. Per
tant, els sistemes biomètric no pateixen les desavantatges de qualsevol dels enfocaments
basats en objectes físics, en els aquals els atributs poden ser perduts o robats, i la perspectiva
basada en el coneixement, els atributs es poden oblidar.
Un sistema biomètric pot o bé verificar o identificar. En la verificació el sistema biomètric
autentifica la identitat de la persona sobre la base de coneixement de la seva identitat
declarada. En canvi, en el procés d'identificació, s'estableix la identitat de la persona (entre els
inscrits en una base de dades) sense els subjectes que tenen per reclamar la seva identitat.
En funció de les característiques personals es consideren dos tipus de dades biomètriques les
quals poden definir trets fisiològic o de comportament. El primers es basen en el mesurament
de les característiques biològiques dels usuaris, com, per exemple, empremta digital, cara,
geometria de la mà, la retina i l'iris o la segona segons els trets de comportament que posseix
el propi usuari que vol tenir accés a un sistema.
Les signatures manuscrites ocupen un lloc molt especial en aquest ampli conjunt de trets
biomètrics. Aixó es deu principalment al fet que les firmes manuscrites tenen ha establir-se
com el mitjà més estès de verificació personal.
Les firmes són generalment reconegudes com un mitjà legal de verificar la identitat d'un
individu en institucions administratives i financeres
D'altra banda, l’anàlisi de verificació de la signatura no requereix mesures invasives i la gent
està familiaritzada amb l'ús de signatures en la seva vida diària.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 9
Per desgràcia, una signatura manuscrita és el resultat d'un complex procés en funció de l'estat
psicofísic del signant i les condicions en què el procés d'aposició signatura es produeix. Per
tant, les teories complexes han estat proposades per modelar els mecanismes psicofísics
subjacents en l’escriptura a mà i els processos de verificació de la signatura els quals segueixen
sent un repte obert, ja que, en una signatura es jutja la seva autenticitat o falsificació només
sobre la base d’unes poques referències.
Els estudis fins aleshores, s’han dividit en tres fases principals per realitzar el procés de
verificació de reconeixement de signatura de manera automàtica que són:
1) L’adquisició de dades.
2) Processament previ.
3) Extracció de característiques i classificació.
Durant la fase de classificació, s’extreuen les característiques extretes d'una firma introduïda
que es comparen amb la informació continguda a la base de coneixement, per tal de
diagnosticar l'autenticitat de la signatura introduïda. La verificació de signatura automàtica
implica aspectes de disciplines que van des de l'anatomia humana a l'enginyeria, i des de la
neurociència a la informàtica i la ciència.
A causa d'aquest fet, en els últims anys, els estudis sobre la verificació de signatures els
investigadors han treballat per a les universitats i les empreses, que estan interessades en no
només els reptes científics, sinó també en les valuoses aplicacions que es poden dissenyar a
partir del perfeccionament d’aquests coneixements.
Hi ha hagut molst avanços en aquest camp al 1994, una edició especial va reservar la recollida
de les activitats d'investigació més rellevants que van ser publicades fins aquell temps.
Successivament, diversos treballs han resumit l'augment dels esforços de recerca en aquest
camp, pel que fa a la zona més general d'escriptura anàlisi i processament.
En conjunció amb el creixement recent i l’extraordinària utilització d’Internet, la verificació
automàtica de signatures està sent considerada amb renovat interès. La creació de lleis i
reglaments específics, que han estat aprovats en molts països i l'atenció que diverses
associacions nacionals i internacionals han donat a la normalització de les dades de signatura
formats d'intercanvi, són evidència de la renovada atenció en aquest camp.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 10
L'objectiu d'aquest projecte és realitzar un esforç per facilitar i millorar aquests estudis per a
realitzar un aplicatiu en dispositius Android on s’ha realitzat l’integració de l’avançada
tecnologia d’aquests dispositius amb els estudis més recents utilitzant conjuntament una
llibreria molt efectiva en els sistemes de visió per computació anomenada opencv amb la qual
s’han pogut fer anàlisis amb diferents algorismes de tractament d’imatges per poder verificar
l’autenticitat de la signatura extreta de la imatge feta sobre un document i la generada i
agafada per l’usuari des de la pantalla del dispositiu mòbil.
Amb aquest estudi es podrà realitzar una àmplia gamma d'aplicacions comercials com ara:
banca, assegurances, cura de la salut, la seguretat d'identificació, gestió de documents, el
comerç electrònic, etc. Com en el sector de la investigació a nivell universitari o docent.
En els últims anys s’ha estat testimoni d'un canvi constant en les tecnologies dels ordinadors
d'escriptori per dispositius mòbils. En el quadre global de les plataformes disponibles, Android
es destaca com un participant dominant en el mercat i la seva popularitat segueix en augment,
generant un benefici en portabilitat pels usuaris que utilitzen aquests tipus de dispositius,
aquest creixement ha creat al mateix temps un ambient prolífic per a l'explotació pels
desenvolupadors amb un nivell avançat, que dissenyen i implementen programari maliciós a
part de tenir la capacitat de reutilització obtinguda il·legalment per atacs d’enginyeria inversa
en aplicatius ja existents, amb finalitat fraudulenta o atacs com sql injection.
Per aquesta raó i donada la importància que en l’actualitat té la seguretat informàtica en
aquests tipus d’aplicatius, s’ha considerat fer un estudi amb profunditat dels aplicatius que es
poden utilitzar per seguritzar-la, a més de les diferents tècniques de protecció de codi que s’ha
de tenir en compte degut el valor de les dades que s’administren utililitzant aquests tipus de
dispositius, ja que, és molt important protegir-los seguint les configuracions de seguretat
pertinents en aquests dispositius i les sugerències de seguretat en el moment d’ampliar o
millorar les funcionalitats de l’aplicatiu realitzat
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 11
1.2 Objectius i motivació per a la realització del projecte
La motivació per a realizar aquest treball de final de màster, ha estat, el desig de treballar en el
món de la seguretat informàtica i poder utilitzar els coneixements en seguretat adquirits
durant la titulació per resoldre el cas exposat, a més de l’ampliació de coneixements en
aplicatius per a dispositius mòbils en plataformes Android.
L’objectiu principal d’aquest projecte és, utilitzant l’adquisició de nous coneixements en el
món de la programació per dispositius Android, poder implementar un aplicatiu en aquesta
plataforma, la qual els usuaris que hagin creat un compte per poder-se loguejar, tinguin la
capacitat de validar la firma realitzada en un document comparant-la amb la creada per
l’usuari que és vol validar mitjançant la pantalla del dipositiu.
Per a la realització d’aquest projecte final de màster es poden indenfiticar les següents fases:
Estudiar la situación actual en els sistemes d’indentificació de firmes
Estudiar com implementar un aplicatiu Android
Estudiar com incorporar les llibreries opencv en el projecte
Estudiar com capturar l’imatge de la firma realitzada en el document
Estudiar com emmgatzema l’imatge generada per l’usuari des de la pantalla del
dispositiu
Estudiar com realizar l’implementació de l’algorisme de verificació i autenticitat de les
firmes
Estudiar les diferents tècniques i metodologies per implementar una aplicatiu Android
amb seguretat.
Estudiar les diferents tècniques i metodologies per seguritzar la base de dades en
aplicatius Android.
Proposar accions i projecte a realizar per millor l’algorisme de verificació de firmes
implementat
Oferir els resultats de les accions i projectes proposats i realitzats, per obtenir-ne una
bona base de coneixements i extreure conclusions rellevants.
Estudiar com realizar l’implementació d’un MVC cojuntament amb un Api rest per
guanyar amb eficiència en el consum de recursos de l’aplicatiu en el dispositiu mòbil
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 12
1.3 Planificació del projecte
Per a la realització d’aquest projecte final de màster, es va decidir seguir amb el següent pla de
treball (veure figura 1.1)
A. Estudiar la situación actual en els sistemes d’indentificació de firmes
B. Estudiar com implementar un aplicatiu Android
C. Estudiar com incorporar les llibreries opencv en el projecte
D. Estudiar com capturar l’imatge de la firma realitzada en el document
E. Estudiar com emmgatzema l’imatge generada per l’usuari des de la pantalla del
dispositiu
F. Estudiar com realizar l’implementació de l’algorisme de verificació i autenticitat de les
firmes
G. Estudiar les diferents tècniques i metodologies per implementar una aplicatiu Android
amb seguretat.
H. Estudiar les diferents tècniques i metodologies per seguritzar la base de dades en
aplicatius Android.
I. Proposar accions i projecte a realizar per millor l’algorisme de verificació de firmes
implementat
J. Oferir els resultats de les accions i projectes proposats i realitzats, per obtenir-ne una
bona base de coneixements i extreure conclusions rellevants.
Figura 1.1- Diagrama de Gannt
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 13
2- ESTRUCTURA ANDROID / INTERACCIÓ ENTRE COMPONENTS
En aquest apartat s’explicarà de manera resumida l’estructura del sistema operatiu Android, a
més de les característiques principals dels components i la seva interacció entre ells (Figura 2.1)
Figura 2.1 - Esquema de les diferents capes que composa el sistema operatiu Android
L’arquitectura del sistema Android està dissenyada de forma jeràrquica (com es pot observar
en la imatge), els seus components són dividits en capes, on els nivells més baixos agrupen
components relacionats amb la interacció del maquinari del dispositiu, les capes superiors
corresponen a processos de més alt nivell.
De manera general els components d’una capa utilitzen els serveis equipats per la capa inferior
(si existeix) oferint els seus serveis a les capes superiors.
A continuació, es farà una descripció de les característiques i funcionalitats de les diferents
capes de les quals es composa el sistema operatiu Android.
1- Linux Kernel (Primera capa): El nucli d'Android està conformat pel sistema operatiu Linux.
Les funcionalitats que proveeix aquesta capa depenen d'un nucli Linux multiusuari que
s'encarrega, entre altres coses, de l'administració de la memòria, els processos i els drivers dels
diferents recursos del hardware. En aquest nucli també s'implementen aspectes bàsics de
seguretat.
Com és la primera capa en l'arquitectura i la base de l'estructura d’aquesta primera capa,
depenen en gran mesura les del segon nivell, ja que, si un fabricant inclou un nou element de
maquinari, el primer que s'ha de fer perquè pugui ser utilitzat des d’Android, és la creació de
les llibreries de control o drivers necessaris dins el nucli de Linux encastat en el propi Android.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 14
2- Llibreries i temps d’execució (Segona capa): Aquesta capa s’agrupa, bàsicament en tres
tipus de componentes:
Llibreries natives: S’ofereix un conjunt de libreríes C/C++ que proveeixen alguns
serveis bàsics per aplicacions i altres programes. Aquests serveis són utilitzats pels
components de la capa superior. Entre aquestes funcionalitats s’inclouen facilitar
l’accés al hardware i a la base de dades. Aquestes llibreries natives funcionant en
diferents processos del kernel Linux.
Entre les libreries natives es troben:
- System C library: Una derivació de la libreria BSD de C estàndar (libe),
adaptada per a dispositius basats en Linux
- Media Framework (llibreria basada en PacketVideo's Apencare): Soporta
codecs de reproducció i grabació de multitud de formats d’àudio, vídeo i
imatges MPEG4, H.264, MP3, AAC, AMR, JPG y PNG.
- Surface Manager: Administra l’accés al subsistema de representació gràfica en
2D y 3D.
- WebKit: Soporta un modern navegador web utilitzat en el navegador Android i
en la vista webview. Es tracta de la mateixa llibreria que utilitza Google
Chrome i Safari de Apple
- SGL: Motor de gràfics 2D.
- LLibrerias 3D: Implementació basada en OpenGL ES 1.0 API. Les llibreries
utilitzant l’accelerador hardware 3D (si està disponible), o el software altament
optimitzat de projecció 3D.
- FreeType: Fonts en bitmap i renderització vectorial.
- SQLite: Potent i lleuger motor de bases de dades relacionals disponible per
totes les aplicacions.
- SSL: Proporciona serveis d’encriptació Secure Socket Layer.
• Màquina virtual: Android compta amb una màquina virtual, anomenada Dalvik, per a
l'execució de les aplicacions programades en Java. Aquesta executa arxius amb format Dalvik
executable (.dex) que està optimitzat per reduir al mínim el consum de memòria del dispositiu
mòbil. Cada aplicació Java és compilada a un format bytecode i posteriorment és executada en
una màquina virtual Dalvik pròpia, diferent a l'assignada a qualsevol altre aplicació. A més
d'utilitzar el llenguatge de programació Java en el desenvolupament d'una aplicació, també és
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 15
possible incloure codi natiu (com C o C ++) que corri per fora de la màquina virtual Dalvik.
Aquest tipus de codi, a compilar, s'executa directament en el processador del dispositiu mòbil.
No obstant això, l'execució de l'esmentat codi natiu continua sent afectat per les restriccions
del nucli Linux.
• Llibreries Estàndard. Proveeixen, a nivell d'execució d'aplicacions, la majoria de les
funcionalitats disponibles a les llibreries estàndar de Java, com per exemple, operacions
matemàtiques, de text, d'entrada / sortida entre altres coses
3- Framework d’aplicacions (Tercera capa). En aquesta capa es troba el framework que
s'encarrega d’entre altres coses, administrar el cicle de vida de cada aplicació, proveir el
conjunt d'Apis necessaris per al desenvolupament i fer de guia entre la interacció de les
aplicacions com amb les diferents parts que les composen.
Un dels objectius principals de l'arquitectura d'Android és la reutilització de components, ja
que, qualsevol aplicació pot oferir els seus serveis a una altre amb l'autorització corresponent,
és per aquesta raó que Android permet una comunicació entre els diferents components de
les aplicacions.
Una altra característica important del framework, és que un desenvolupador pot tenir accés a
les mateixes APIs que utilitzen les aplicacions principals , és a dir, aquelles aplicacions que ja
venen preinstal·lades al dispositiu. Totes les llibreries del framework estan escrites en Java i es
troben a la màquina virtual Dalvik de cada aplicació. Si l'aplicació requereix dur a terme alguna
acció, les llibreries es comuniquen amb el sistema Linux base on es verifiquen els permisos
d'accés als recursos del sistema de l'aplicació sol·licitant.
4- Aplicacions (Quarta capa) : En aquest nivell s'inclouen tant les aplicacions principals (per
exemple, client de correu electrònic, calendari, llibreta de contactes) com les noves aplicacions
escrites per altres desenvolupadors.
Tots dos tipus d'aplicacions s'executen en el marc imposat pel framework de la capa inferior.
No obstant això, l'accés a les APIs està restringit als fragments d'aplicacions escrits en el
llenguatge de programació Java. Si hi ha codi natiu, no es podrà accedir directament a les APIs
a través del mateix sense abans interposar codi Java que actuï com intermediari.
Els components d’una aplicació Android es construeixen a partir de diferents blocs anomenats
components. Cada component és una entitat única i compleix una funció específica, definint el
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 16
comportament general de l'aplicació. Un aspecte del disseny del sistema Android, és que una
aplicació pot iniciar un component d'una altre si es tenen els permisos respectius.
Totes les aplicacions per a dispositius Android (això inclou al malware) estan encapsulats en un
format específic, conegut com APK «Application Package File». Aquest format és l'utilitzat per
a la instal·lació i distribució d'aplicacions per a aquesta plataforma mòbil.
Hi ha quatre tipus de components d'una aplicació. Cada tipus s'utilitza per a un propòsit
diferent i té un cicle de vida diferent
Aquests tipus són:
Activitats (activity): Una activitat representa una pantalla de l'aplicació, on es proveeix
una interfície d'usuari per interactuar amb la mateixa. Típicament, cada aplicació té
una activitat principal que representa la primera pantalla que veu l'usuari en ser
iniciada des de la llista d'aplicacions disponibles. A partir d'aquest moment, és possible
passar a la següent pantalla (d'existir) cridant a una nova activitat.
Cada activitat té associada una vista. La vista constitueix el conjunt d'elements o
interfície gràfica que es presenten a l'usuari perquè interaccioni amb el sistema. Per
exemple, caixes d'edició, etiquetes o botons, entre d'altres. Per crear activitats
personalitzades és necessari definir una classe que hereti de la classe base Activity.
Tot i que una aplicació tingui una activitat principal, cadascuna d'aquestes és
independent de les altres, donant la possibilitat a una aplicació diferent d'iniciar
qualsevol activitat que no sigui, necessàriament, la principal (sempre que es tingui
l'autorització apropiada), per exemple una aplicació de correu electrònic.
Serveis (service): Un servei és un component d’execució que es desenvolupa en segon
pla sense oferir cap interfície amb l'usuari. Qualsevol component amb els permisos
adequats pot iniciar un servei o associar-se a un en execució per interactuar amb ell.
Si un component inicia un servei que ja es troba en execució, no es crea una nova
instància sinó que s'interactua amb la ja existent. L'ús més freqüent dels serveis és per
realitzar tasques que demanin una gran quantitat de temps (i no requereixin interacció
amb l'usuari); però, també poden ser utilitzats per tal de treballar conjuntament amb
processos remots. Per exemple, un servei podrà reproduir música o descarregar un
arxiu a través d'internet sense impedir que l'usuari segueixi utilitzant el seu telèfon
mòbil normalment (hi han dos tipus de serveis started i bounded)
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 17
Content Providers: És un component dissenyat per compartir informació entre
aplicacions. Aquesta informació pot estar guardada, per exemple, en bases de dades
SQLite, en una web o en qualsevol altre mitjà d'emmagatzematge persistent que
estigui disponible. D'aquesta manera un content provider actua com una interfície
entre les dades persistens i la resta de les aplicacions perquè, aquestes últimes, puguin
tant accedir com també modificar-se.
Broadcast Receivers: És un component el qual l’objetiu es rebre missatges, anuncis, els
quals són generats per el sistema o una altra aplicació, i disparar accions a partir dels
mateixos. Aquests missatges, anomenats broadcasts, es transmeten al llarg de tot el
sistema i són els broadcast receivers els encarregats de rebre i comunicar-ho a
l’aplicació a la qual pertanyen.
Tres dels quatre components descrits anteriorment (activitats, serveis i broadcast receivers)
són activitats que es comuniquen entre elles mitjançant un missatge asíncron anomenat
intent. Aquests missatges fan que diferents components individuals, perteneixents tant a una
mateixa aplicació com aplicacions diferents, es relacionin entre sí en temps d’execució.
Existeixen principalment dos maneres d’utilitzar un intent: com un broadcast o com un
missatge per interactuar amb activitats i serveis (Figura 2.2).
Figura 2.2 - Exemple de la interacció entre els components descrits anteriorment
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 18
2-1 Estructura a nivell de xarxa Android
Android utilitza biblioteques centrals per executar els serveis de xarxa; les biblioteques
centrals també utilitzen interfícies de programació d’aplicacions (API) que es desenvolupen
utilizant el llenguatge de programació Java (SDK de Android). L’API responsable de la gestió
inalàmbrica és la WifiManager i s’executa en el seu propi procés d’instància de la DVM.
El SDK d’Android ofereix un conjunt d’aplicacions per l’accés de dades sobre les xarxes Wi-Fi,
tals com intensitat del senyal, descobriment dels punts d’accés i l’execució de processos
vinculats al punt d’accés. Per permetre la conexió Wi-Fi gratuïta, hi ha certa informació
requerida que s’ha d’aquirir mitjançant la creació d’un permís explícit utilitzant l’arxiu
AndroidManifest.xml
Exemple de permisos de xarxa que es poden agregar als aplicatius Android fent servir el
AndroidManifest.xml (Figura 2.3)
1) CHANGE_WIFI_STATE: S’utilitza per autoritzar, establir o desactivar la Wi-Fi.
2) ACCESS_NETWORK_STATE: S’utilitza per donar permisos a l’aplicatiu per conectar-se a
internet.
3) ACCESS_WIFI_STATE: S’utilitza per sol·licitar qualsevol informació del servei de Wi -Fi.
Figura 2.3 - Exemple de configuració de androidManifest.xml
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 19
3. ESTRUCTURA I FUNCIONAMENT DEL PROJECTE
Pel funcionament del projecte, es va dissenyar incialment l’aplicatiu Android on l’usuari
obligatoriament haurà de crear-se un compte d’usuari per poder loguejar-se mitjançant el DNI
i contrasenya i poder utilizar les funcionalitats de l’aplicatiu, aquestes dades del compte
introduïdes per l’usuari seran administrades per un aplicatiu extern (Api rest) i les dades seran
emmagatzemades en un servidor de Sql. Altres funcionalitats que tindrà l’usuari desprès de
loguejar-se són: l’administració de les dades del seu compte (modificació (foto de perfil, nom,
email etc..) o baixa (s’eliminaran totes les dades enregistrades del compte) a més de la
funcionalitat de comparació de firmes, que es detallarà en apartats posteriors.
Per seguritzar la transmissió de dades, totes les dades que viatjaran entre (’aplicatiu – api rest
– servidor, servidor-api rest-aplicatiu) seran codificades en base 64 per evitar que si aquestes
dades són interceptades per algun atacant mitjançant algun programa d’anàlisi de xarxes com
el wireshark o altres (atac midle-man), aquestes dades no siguin fàcilment compreses per
aquest.
Cal dir que en el moment d’enregistrar la contrasenya de l’usuari en la base de dades , aquesta
serà codificada en Sha256 en el registre del servidor Sql, igual que en el moment que l’usuari
introdueixi la credencial de la contrasenya, aquesta serà codificada en Sha256 i comparada
amb els registres en el servidor de base de dades de Sql per permetre l’accés a les
funcionalitats o no.
L’aplicatiu Android enviarà les peticions a l’Api rest utilitzant el protocol HTTP i el mètode
POST. Es va utilizar aquest mètode “POST” d’enviament en lloc del “GET”, ja que, el mètode
“GET” envia les dades introduïdes per l’usuari en la mateixa Url quan es genera la petició, amb
aquest fet es perd seguretat, perquè, un atacant podria interceptar la petició i tenir
coneixement de quines dades ha enviat l’usuari, en canvi utilitzant el mètode “POST” les dades
introduïdes són enviades en el mateix cos de la petició amb la qual cosa dificulta la
interceptació d’aquestes.
A continuació l’Api rest interceptarà la petició realitzada per l’usuari mitjantçant l’aplicació
Android conjuntament amb les dades introduïdes per aquest i depenent de la petició
realitzada, l’Api rest enviarà la petició d’execució amb les dades introduïdes per l’usuari per
executar el stored corresponent el qual que está emmagatzemat en el servidor de base de
dades de Sql server.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 20
A continuació el servidor Sql server executarà els storeds amb les dades introduïdes per
l’usuari provinents de l’Api rest i retornarà la resposta a l’Api rest (poden ser dades o valor
numèrics de comprovació).
A continuació l’Api rest codificarà aquestes dades rebudes pel servidor Sql i les transformarà
en un array en format json, aquesta array json serà enviada a l’aplicatiu Android i serà
codificada per obtenir les dades o les respostes enviades per l’Api rest i provinents de
l’execució dels diferents storeds en el servidor de base de dades de Sql (Figura3.1).
Figura 3.1 - En la imatge es pot veure un esquema del funcionament del sistema implementat
Després de realitzar una explicació global del funcionament del sistema, a continuació es farà
una explicació més detallada de les funcionalitats i característiques de cada component.
3.1 Aplicatiu Android
A continuació es mostre les diferents interficies gràfiques de l’aplicatiu i la interacció que
tindran amb la resta (Figura 3.1.1).
Figura 3.1.1 - Esquema de les diferents interficies gràfiques que composen l’aplicatiu Android
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 21
A continuació s’exposaran les funcionalitats de les diferents interficies per número com es pot
visuatlitzar en la figura 3.1.1
Pantalla número 1 (pantalla d’inici) (figura 3.1.2)
figura 3.1.2 - Pantalla d’inici
És la pantalla amb la qual l’aplicatiu s’iniciarà, mostrant la presentació del projecte,
sel·leccionant el botó entrar, l’usuari accedirà a la pantalla número 2 on podrà donar d’alta la
seva compte d’usuari o loguejar-se amb un compte ja creat. (dni/contrasenya) (figura 3.1.2)
Pantalla número 2 Menú usuari (figura 3.1.3)
figura 3.1.3 Menú usuari
A l’accedir aquesta interfície provinent de la pantalla número 1, l’usuari podrà accedir a la
interfície 3 per donar d’alta el compte d’usuari (seleccionant el botó alta usuari) o loguejar-se
si l’usuari ja posseix un compte creat (sel·leccionant el botó login) accedint a la interfície
gràfica número 4 (login).
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 22
Pantalla número 3 Alta compte usuari (figura 3.1.4)
Algunes de les validacions que realitza la interfície número 3.
Inicialment camps buits DNI incorrecte union longitud >20
figura 3.1.4 - Interfície alta compte usuari
Al seleccionar el botó donar d’alta de la interfície número 2, l’aplicatiu farà accedir a l’usuari a
l’interfície número 3 on podrà donar d’alta el seu compte d’usuari insertant una imatge (al
seleccionar el botó fer foto, s’obrirà una activitat amb la qual l’usuari podrà realitzar la foto del
seu compte de perfil (previsulitzant-la en la mateixa interfície)) a continuació l’usuari haurà
d’introduïr les seves dades (nom , cognoms , DNI , contrasenya i email).
La pròpia interfície conté controls com es mostren en les diferents imatges anteriors, on en el
moment de donar d’alta a l’usuari (prement el botó donar alta usuari) es faran unes
validacions prèvies d’aquestes dades.
Si es produeix un error en la connexió o per l’entrada no vàlida de dades, l ‘aplicatiu farà
vibrar el telèfon i mostrarà el missatge d’error corresponent avisant a l’usuari com en els casos
següents:
No es permetrà camps buits.
El format del DNI ha de ser correcte (s’ha implementat una funció perquè faci aquesta
validació)
No es permetrà que les dades introduïdes continguin la cadena union (la raó es que
s’evita que hi puguin haver atacs de sql injection a través de les diferents dades que
s’introdueixen en la interfície i s’utilitzant per donar d’alta el compte d’usuari).
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 23
Si el DNI ja ha sigut introduït en la base de dades en un compte d’usuari, es mostrarà
un missatge d’avís informant que l’usuari ja existeix (es realitza aquesta acció, perquè
el login serà a través del DNI i aquest ha de ser únic en la base de dades).
Si la logintud de qualsevol de les dades introduïdes per l’usuari a través de l’interficie
és superior a 20 caràcters, es consideraran dades no vàlides i l’aplicatiu mostrarà el
missatge d’error (aquesta validació es realitza per evitar atacs de Sql injection, ja que,
les dades que s’han d’introduïr, no poden ser superiors aquesta longitud).
Una dada important, és que les dades que s’enviaran a l’Api rest per fer la inserció
(imatge,nom,congom….etc) estaran codificades en base64 per augmentar la seguretat
d’aquestes i la contrasenya serà codificada en SHA256 i enviada a l’Api rest que a continuació
cridarà el stored corresponent i insertarà les dades en el servidor de base de dades.
Amb el botó neteja es podran netejar les dades introduïdes per l’usuari i també es podrà
retornar a l’interfície número 2 mitjançant el botó enrere.
Pantalla número 4 (login) (figura 3.1.5)
Inicialment credencials incorrectes cadena amb union camps en blanc caràcters >20
figura 3.1.5 - Interfície login
Al sel·leccionar el botó login de la interfície número 2, l’aplicatiu farà accedir a l’usuari a
l’interfície número 4 on podrà loguejar-se en l’aplicatiu mitjançant el DNI i contrasenya.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 24
Els camps han d’estar introduïts obligatòriament, si aquest fet no es produeix, l’aplicatiu farà
vibrar el telèfon mòbil mostrant el missatge “cap dels camps pot estar buit” , altres accions
que pot validar l’aplicatiu és el fet que l’usuari introdueixi cadenes union o superior a 20 en
qualsevol de les dues entrades per loguejar l’usuari, l’aplicatiu mostrarà els missatges “cap del
camps pot contenir la cadena union “ o “cap dels camps pot tenir una longitud superior a 20”
respectivament segons els cas (com es mostren en les imatges)
Amb el botó enrere s’accedirà a la interfície número 2 i amb el botó netejar es tindrà la
capacitat de netejar els camps introduïts per l’usuari.
Pantalla número 5 Administrar compte usuari / Anàlisi firma (figura 3.1.6)
figura 3.1.6 -Interfície administrar compte usuari / Anàlisi firma
A l’introduir l’usuari les credencials, aquest accedirà a la interfície gràfica número 5 on tindrà
dues opcions: modificar les dades del compte al sel·leccionar el botó “administrar compte” o
realitzar l’anàlisi de firmes al sel.leccionar el botó “comparar firmes” , per últim al sel·leccionar
el botó menú Login, es retornarà a l’interfície número 4.
Pantalla número 6 Interfície administrar compte usuari (figura 3.1.7)
figura 3.1.7 Interfície administrar compte usuari
Al seleccionar el botó “administrar compte” de la interfície número 5, l’aplicatiu farà accedir a
l’usuari a l’interfície número 6 on podrà sel·leccionar les opcions “modificar compte” per
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 25
accedir a l’interfície número 7 o sel·leccionant el botó “baixa compte” per accedir a l’interfície
gràfica número 8 on l’usuari podrá donar de baixa el compte d’usuari. Seleccionant el botó
“enrera” l’aplicatiu farà accedir a l’usuari a l’interfície gràfica número 5.
Pantalla número 7 Modificar compte usuari (figura 3.1.8)
figura 3.1.8 - Interfície Modificar compte usuari
Al sel·leccionar el botó “administrar compte” de la interfície 6, l’aplicatiu farà accedir a l’usuari
a l’interfície número 7 on inicialment es carregaran les dades del compte d’usuari com: nom,
cognom, Email i imatge i l’usuari al seleccionar el botó “modificar compte”, podrà actualitzar
les dades introduïdes en l’interfície.
Les validacions en l’entrada de dades seguiran la línia que les interfícies anteriors en les quals
no es permetrà valors buits en cap dels camps, cadenes que continguin la cadena “union” i les
dades introduïdes amb una logintud superior a 20 caràcters (mostrant els missatge d’errors
corresponent i fent vibrar el telèfon mòvil).
El botó “enrera”, farà accedir a l’usuari a la interfície número 6 (hagi actualitzat les dades o no)
i amb el botó “neteja” es netejaran les dades de l’interfície.
Totes les dades seran codificades en base64 en el moment de ser enviades a l’Api rest que
posteriorment seran actualitzades en el servidor de base de dades.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 26
Pantalla número 8 Eliminar compte (figura 3.1.9)
figura 3.1.9 - Interfície eliminar compte usuari
Al sel·leccionar el botó “baixa compte” de la interfície 6, l’aplicatiu farà accedir a l’usuari a
l’interfície 8 on l’usuari tindrà la capacitat d’esborrar el compte (figura 3.1.10).
figura 3.1.10 - Missatge de confirmació eliminació compte usuari
Quan l’usuari seleccioni el botó (central), apareixerà un popup de confirmació perquè l’usuari
estigui totalment segur que vol eliminar les seves dades i compte en el servidor de base de
dades a través de l’aplicatiu.
Si acepta, s’enviarà la petició a l’Api rest i posterioment l’Api rest al servidor de base de dades
perquè a través de l’id de l’usuari codificat en base64 en la transimissió de dades, aquest
seleccioni l’usuari que ha d’eliminar en el servidor de base de dades.
A continuació a l’eliminar-se el compte, l’aplicatiu enviarà a l’usuari a l’interfície 2, on podrà
tornar a sel·leccionar l’opció de crear un compte d’usuari nou o si en té més d’un tornar-se a
loguejar (sene comptar amb l’eliminada anteriorment)
Si es sel·lecciona el boto “enrera” l’aplicatiu farà accedir a l’usuari a l’interfície número 6
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 27
Pantalla número 9 Foto a signatura del document (figura 3.1.11)
figura 3.1.11 - Interfície Foto a signatura del document i activitat per extreure imatge
Al sel·leccionar el botó “comparar firmes” de la interfície 5, l’aplicatiu farà accedir a l’usuari a
l’interfície 9 on l’usuari tindrà la capacitat de realitzar l’imatge de la firma en el document.
En el moment que l’usuari sel·leccioni el botó fer foto, s’activarà la càmara i l’usuari podrà
realitzar l’imatge de la firma la qual quedarà guardarda en la interfície.
A continuació sel·leccionant el botó “extreure firma” la imatge serà codificada en base64 i
l’aplicatiu farà que l’usuari accedeixi a l’interfície 10, on podrà realitzar l’extracció de la firma
mitjançant la pantalla del dispositiu mòbil.
Al seleccionar el botó enrera l’aplicatiu farà accedir a l’usuari a l’interfície 5.
Pantalla número 10 signatura realitzada a en el dispositiu mòbil (figura 3.1.12)
figura 3.1.12- Interfície signatura realitzada a en el dispositiu móvil i activitat firma
Al sel·leccionar el botó “extreure firma” de la interfície 9, l’aplicatiu farà accedir a l’usuari a
l’interfície 10 on l’usuari tindrà la capacitat de realitzar la firma en la pantalla del dispositiu
mòbil.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 28
En el moment que l’usuari sel.leccioni el botó “fer foto”, s’activarà una activitat on l’usuari
podrá realitzar la firma a la pantalla del dispositiu mòvil, tindra la possibilitat d’anular la
funcionalitat amb el botó “cancelar”, també l’usuari podrà esborrar la firma realitzada
utilitzant el botó de “borrar”, i tan bon punt l’usuari doni per vàlida la firma realitzada , amb la
sel·lecció del botó “guardar”, s’extraurà l’imatge de la firma i quedarà enregistrada en el visor
de interfície 10 (actual) .
Cal saber, que en el moment de realitzar la firma l’aplicatiu està dissenyat perquè l’usuari la
realitzi de manera hortizontal.
Al sel·leccionar el botó “comparar” es codificaran les dues imatges, la primera obtinguda de
l’interfície 8 (firma del document) i la segona realitzada en la pantalla (interfície actual) a més
dels privilegis de l’usuari que s’han enviat i codificat en base64 des de que l’usuari ha sigut
loguejat correctament en l’aplicatiu.
Al sel·leccionar el botó “enrera”, farà que l’usuari viatgi a l’interficie 9.
Pantalla número 11 Comparació de signatures (figura 3.1.13)
figura 3.1.13 Interfície comparació de signatures
Al sel.leccionar el botó “comparar” de la interfície 10, l’aplicatiu farà accedir a l’usuari a
l’interfície 11 on l’usuari tindrà la capacitat de realitzar la comparació de les dues firmes, al
sel·leccionar el botó “comparar” s’aplicarà la validació de la firma amb l’algorisme que
s’exposarà amb més detall en l’apartat de proves.
En aquesta interfície, es rebran les dues imatges codificades en base64 obtingudes de les
interfícies 9 (firma des del document) i 10 (firma de la pantalla) (incialment aquestes dues
imatges serán mostrades en l’interfície) a més dels privilegis de l’usuari.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 29
Al sel·leccionar el botó “comparar”, es realitzarà l’anàlisi amb l’algorisme i el resultat serà un
valor numèric que será enviat i codificat a base64 conjuntament amb els privilegis de l’ usuari a
l’interfície 12 .
Al sel·leccionar “enrera” s’accedirà a l’interfície 10 amb les dos imatges a comparar.
Pantalla número 12 Resultats (investigador/normal) (figura 3.1.14)
Usuari investigador Usuari normal
figura 3.1.14 - Interfícies resultats (investigador/normal)
Durant l’explicació de les anteriors interfícies (5,9,10,11,12), s’ha fet referència que entre elles
intercanviaven els privilegis de l’usuari (és un camp de la taula usuari, que per defecte en el
moment de crear-se el compte, agafarà per defecte el valor de “normal” (fa referència a un
usuari amb privilegis no investigador) a més d’altres dades
Els privilegis dels usuaris poden ser de dos tipus (normal per defecte o investigador) .
Usuari amb privilegis d’investigador:
figura 3.1.15 - Interfícies resultats (negatiu/positiu)
En el moment d’accedir a l’interfície 12 amb els privilegis d’investigador, l’aplicatiu mostrarà
les dues imatges amb els punt d’interés entre la firma extreta de la pantalla del dipositiu mòbil
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 30
i la imatge realitzada de la firma des del document, en l’últim visor es mostraran les dues
imatges analitzades en una mateixa imatge amb els punts d’interés que han fet match
(aplicant l’algorisme que s’exposarà en el següent punt amb més detall) a més de mostrar un
missatge amb el resultat obtingut.
Usuari amb privilegis normal:
figura 3.1.16 - Interfícies resultats (normal)
En el moment d’accedir a l’interfície 12 amb els privilegis “normal”, l’aplicatiu mostrarà una
imatge amb un X vermella amb el misatge “Les firmes no són iguals”, si el dignosi és que la
persona que ha realitzat la firma en la pantalla del dispositiu mòbil i l’extreta de l’imatge des
del document no són la mateixa persona. L’aplicatiu mostrarà una V verda si el dignosi és que
són la mateixa persona.
En qualsevol dels privilegis que l’usuari accedeixi aquesta interfície, al seleccionar el botó
“enrera” l’usuari retornarà a l’interfície número 5 per iniciar el procés d’extracció de firmes de
nou (pantalla/foto) o administrar el compte d’usuari.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 31
3.2 Api rest
El concepte del terme REST, es refereix originalment a un conjunt de principis d’arquitectura
que en l’actualitat és utilitzada en el sentit més ampli per descriure qualsevol interfície entre
sistemes que utilizi directament HTTP per obtenir dades o indicar l’execució d’operacions
sobre les dades, en qualsevol format (XML, JSON, etc) sense les abstraccions addicionals dels
protocols basats en patrons d’intercanvi de missatges, como per exemple SOAP.
Es possible dissenyar sistemes de serveis web d’acord amb l’estil d’arquitectura REST de
Fielding i també és possible dissenyar interfícies XML-HTTP d’ acord amb l’estil de trucada a
procediment remot (RPC), però sense utilitzar SOAP.
Aquest tipus de sistemes que segueixen els principis REST s’anomenen amb freqüència
RESTful.
REST afirma que la web té escalabilidad com ha resultat d’una sèrie de disenys fonamentals
que són el següents:
Un protocol client/servidor sense estat: cada missatge HTTP conté tota la informació
necessària per comprendre la petició. Com ha resultat, ni el client ni el servidor necessiten
recordar cap estat de les comunicacions entre missatges. Encara que, en la pràctica, moltes
aplicacions basades en HTTP utilitzen cookies i altres mecanismes per mantenir l’estat de la
sessió (algunes d’aquestes pràctiques, com la reescriptura de URLs, les quals no són permeses
per REST)
Un conjunt d’operacions ben definides que s’apliquen a tots els recursos d’ informació: HTTP
en sí defineix un conjunt petit d’operacions, les més importants són “POST”, “GET”, “PUT” i
“DELETE”.
S’utilitza una sintaxis universal per identificar els recursos. En un sistema REST, cada recurs es
direccionable únicament a través del seu URI.
L’utilització de hipervincles, tant per l’informació de l’aplicació com per les transicions d’estat
de l’aplicació fa que la representació dels estats en un sistema REST siguin típicament HTML o
XML.
Como resultat d’això, és possible navegar d’un recurs REST a molts altres, simplement seguint
enllaços sense requerir l’uilització de registres o una altre infraestructura addicional.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 32
Utilitzant aquesta infrastructura (Api rest) es va implementar lo que s’anomena MVC model-
vista-controlador.
La vista seria el propi dispositiu mòbil (les interfícies gràfiques) que seria el que rep les dades
provinents de l’Api rest i que anteriorment han estat demanades per aquest últim al servidor
de base de dades mitjançant storeds procedures conjuntament amb l’utilització i la creació de
dos models datos i datosmanager a més de la classe controller que faria la funció de
controlador.
L’Api rest espera les diferents peticions http realitzades. Utilitzant la classe ApiAreaRegistration
on es defineixen les diferents urls que es criden per realitzar les accions passant-li al
controlador i el mètode que cridarà aquest .
Exemple visual Alta usuari (aplicatiu-Api rest-servidor base de dades) .
En la l’interfície número 3 de l’aplicatiu Android, en el moment de sel.leccionar el botó “alta
usuari” i quan les dades introduïdes per l’usuari passin les validacions a les quals s’han fet
referència en l’apartat anterior d’aquest punt (3.1 aplicatiu Android). L’aplicatiu com es mostre
en el codi java (imatge de mà dreta i marcat en vermell) realitzarà l’enviament d’aquestes
dades codificades en base64 (per seguretat) mitjançant el mètode post a la url definida
(ip/port/nom) (figura 3.2.1) .
figura 3.2.1 - Exemple visual interfície gràfica (alta usuari) i codi java de l’aplicatiu Android
Mitjançant la clase definida com ApiAreaRegistration (figura 3.2.2) s’han definit les diferents
urls que s’utilitzaran per intercanviar les dades entre els dos aplicatius i el servidor de base de
dades, quan l’usuari realitzi la petició http mitjançant el mètode post a la url (des de l’aplicatiu
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 33
Android) , l’Api rest cridarà al controlador i l’acció o mètode a realitzar (com es pot veure en
l’imatge i marcat en vermell).
figura 3.2.2 - Exemple classe Apiregistrarion en l’api rest url utilitzada per donar alta usuari
A continuació s’accedirà al controlador (datoscontroller) que rebrà els paràmetres del cos de la
petició http pel mètode post i s’enviarà al mètode cridat anteriorment en el
apiArearegistration (action = “xxx2”).
Tot seguit es cridarà el model utilizant els paràmetres mitjançant l’objecte DatosManager.
Cridant el mètode corresponent (que en la imatge és datosmanager.xxx67(paràmetres))
passant-li els paràmetres rebuts provinents del cos de la petició http pel mètode post
generada pel dipositiu mòbil, aquesta funció (xxx2) les dades que retorna serán convertides
en un array json que pot ser un valor numèric o un conjunt de dades segons el mètode cridat
(en el cas de l’imatge, retornarà un valor numèric confirmant si s’ha donat d’alta l’usuari o no,
el qual serà enviat al dispositiu mòbil per ser analitzat) (figura 3.2.3)
figura 3.2.3 - Mètode cridat donar alta usuari en el controlador
Es varen definir els dos models mitjançant dues clase la “Datos”, que és l’objecte mitjançant
s’enviant i es reben les dades provinents de la transmisió entre els dos 2 aplicatius i el servidor
de base de dades. (figura 3.2.4)
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 34
figura 3.2.4 - Exemple model datos
El segon model implementat és la clase Datosmanager, mitjançant la qual es realitza la
connexió al servidor de base de dades com es veu en la imatge (figura 3.2.5) i els metodes per
obternir les dades del servidor de base de dades
figura 3.2.5 - Exemple visual de la conection string que es declara en el model datosManager
En la imatge es pot veure com en el model es decrlara la connectionstring que s’utilitzara per
realizar la connexió al servidor de base de dades
Finalment s’executarà el mètode que farà la crida al stored, el qual realitzarà la funció
d’insertar les dades per crear el compte d’usuari en el servidor de base de dades amb els
paràmetres (figura 3.2.6).
Figura 3.2.6 - Exemple del mètode implementat per donar d’alta la compte d’usuari
Com es pot observar en la imatge, per millorar en la seguretat en la transmissió de les dades i
les comunicacions entre l’aplicatiu Android , l’Api rest i el servidor de base de dades, s’han
seguritzar aquestes, utilitzant algunes de les tècniques a les quals es faran referència amb més
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 35
detall en apartats posteriors aquest, com són les tècniques d’ofuscació, que s’utilitzen per
nombrar dades, mètodes i altres amb noms poc comuns, amb la finalitat que si es produeix un
atac sigui en el codi o en la mateixa transició d’aquestes dades entre els aplicatius, hi hagi un
augment en la dificultat de la comprensió de les funcionalitats i dades per part de l’atacant.
La utilització de stored amb les tècniques d’ofuscació, fa que no s’enviïn les consultes a la base
de dades en clar donant informació a l’atacant del possible funcionament i estructura del
servidor de base de dades, seguritzant aquest servidor i dificultant possibles atacs.
A continuació l’Api rest retornarà la reposta que l’aplicatiu Android haurà d’analitzar (figura
3.2.7) per mostrar els diferents missatges implementats (s’ha creat el compte d’usuari o no)
figura 3.2.7 - Exemple visual analisi resposta de la crida del mètode post de la url en Android
En la imatge es pot veure la continuació del codi java per donar d’alta a l’usauri, on es recupera
la reposta que ha rebut l’aplicatiu Android de l’Api rest provinent del servidor de base de
dades, en aquest cas será un valors numèric (en altres funcionalitats pot ser un conjunt de
dades) (figura 3.2.8).
figura 3.2.8 - Exemple codi java aplicatiu Android analisi reposta mètode post donar alta usuari
Aquesta resposta serà tractada per l’aplicatiu per donar les diferents indicacions a l’usuari (si
s’ha creat el compte o no)
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 36
3.3 Servidor base de dades Sql server (Vmware)
Per implementar el servidor de base de dades es va utilitzar un màquina virtual, amb un
Windows server i Sql Server 2012 (figura 3.3.1).
figura 3.3.1 - Exemple Visual servidor de base de dades sql dels stored i taula implementades
En la imatge es pot veure les taules on es guarden les dades i els diferents storeds que cridarà
l’Api rest.
Per a visualitzar l’estructura de la base de dades amb els storeds realitzat, anar a l’Annex 1.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 37
4. RESULTATS DE L’APLICATIU EXTERN I INTRODUCCIÓ A LA LLIBRERIA
OPENCV
Per a realitzar l’algorisme d’anàlisi per diagnosticar que la firma realitzada en el document i la
feta per l’usuari en la pantalla del dispositiu Android són la mateixa persona, es va realitzar
una aplicació externa en llenguatge c++, amb la qual es va poder crear un laboratori de proves
per diagnosticar, quin era el millor algorisme conjuntament amb els paràmetres, que fessin
que el tant per cent d’encert fos molt més elevat.
En aquest laboratori creat, es va incorporar la llibreria opencv (Open Source Computer Vision)
la qual és una llibreria de codi obert dirigida principalment a la visió per computador en temps
real, desenvolupada per la divisió russa Intel en el centre de Nijni Nóvgorod (la llibreria
OpenCV és multiplataforma).
Aquesta es centra principalment, en el processament d'imatges en temps real. Està
optimitzada per ser utilitzada en processadors Intel, perquè si la llibreria detecta que les
llibreries d'Intel IPP (Integrated Performance Primitives) es troben en el sistema, en farà ús
automàticament per tal d'accelerar el rendiment de l'aplicació.
Aquesta llibreria es va incoporar tan al projecte per realitzar al laboratori de probes, com en el
projecte d’Android studio (es pot descarregar la llibreria per dipositius Android en la mateixa
web de opencv)
Els resultats tant en el laboratori com en el projecte Android utilitzant els algorismes, van ser
els mateixos, aquesta acció de crear aquest projecte extern, es va realitzar per poder fer
proves amb rapidesa i poder diagnosticar, quin era el millor algorisme per implementar en
l’aplicatiu desenvolupat per dispositius mòbils Android. A més, perquè els futurs
desenvolupadors que continuin el projecte, no hagin de carregar l’aplicatiu Android cada
vegada en el dispositiu.
Els algorismes que es van utilitzar d’aquesta llibreria anomenada opencv per a realitzar les
proves van ser:
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 38
4.1 SIFT (Scale-Invariant Feature Transform)
Amb aquest algorisme els detectors de cantonada com Harris i les rotacions dels objectes són
invariants, és a dir, fins i tot si es gira la imatge, es poden trobar les mateixes cantonades (és
obvi perquè les cantonades també són cantonades quan la imatge està girada també).
Un racó pot no ser una cantonada, si s'escala la imatge. Per exemple, es pot comprovar en
l’imatge de sota (figura 4.1). Un racó en una petita imatge dins d'una petita finestra la qual és
plana quan es redueix la imatge en la mateixa finestra. Amb aquest fet es fa que l’escabilitat
fós un problema.
figura 4.1 - tractament imatge algorisme Sift
Així que , el 2004, D.Lowe, va implementar un nou algorisme per reduïr aquesta casuística
mitjançant l’algorisme SIFT (Scale-invariant feature Transform), amb el qual es va definir les
característiques de les imatges analitzades mitjançant Keypoints invariants en l’escalat, amb
els quals s’obtenen els punts clau per calcular-ne els descriptors.
Hi ha principalment quatre etapes implicades en l'algoritme SIFT. Que s’exposaran a
continuació :
4.1.1 Escala-espai de detecció extrema Partint de la imatge de sota (figura 4.2), és obvi que no es pot utilitzar la mateixa finestra per
detectar punts clau amb diferents escalats. Està bé amb una petita cantonada. Però per
detectar cantonades més grans es necessiten finestres més grans.
Per aquesta raó, s'utilitza el filtrat d'espai escala. En ell, Laplacià de Gauss es troba per a la
imatge amb diferents valors de sigma. Log actua com un detector de bombolla que detecta
taques en diverses mides a causa del canvi en σ. En resum, σ actua com un paràmetre d'escala.
Per exemple, a la imatge superior (imatge 4.1), el nucli gaussià amb σ baixa dóna un alt valor
per a la petita cantonada mentre el nucli Guassia amb una alta σ s'adapta bé per ampliar la
cantonada. Així, es pot trobar els màxims locals en tota l'escala i l'espai que es dóna en una
llistat de valors (x, y, σ) significa que hi ha un punt significatiu potencial en (x, y) en l'escala σ.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 39
No obstant això, aquest registre és una mica costós, per la qual l’algorismes SIFT utilitza la
diferència de gaussianes que és una aproximació de registre. La Diferència de Gauss, s'obté
com la diferència de desenfocament gaussià d'una imatge amb dues σ diferents, que sigui σ i
kσ. Aquest procés es realitza per diferents vuitenes de la imatge en piràmide gaussian com es
representa en la imatge de sota (figura 4.2) :
Figura 4.2 Piràmides gaussianes
Una vegada que es troba aquest dog (diferència gaussiana), les imatges es busquen els
extrems locals sobre l'escala i l'espai. Per exemple, un píxel en una imatge es compara amb els
seus 8 veïns, així com 9 píxels en escala següent i 9 píxels en escales anteriors. Si es tracta d'un
extrem local, és un punt significatiu potencial. Bàsicament vol dir que aquest punt clau està
millor representat en aquesta escala (com es mostra en la figura 4.3)
Figura 4.3 tractament de l’escalat per l’algorisme SIFT
Alguns dels diferents paràmetres, que es poden configurar (SIFT) són:
1) Nombre d'octaves = 4,
2) El nombre de nivells d'escala = 5,
3) Inicial σ = 1,6,
4) K = 2-√
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 40
4.1.2 Localització de Keypoints
Una vegada que es troben les ubicacions possibles , és a dir, punts clau, han de ser refinats per
obtenir resultats més precisos. Per a realitzar això s’utilitza l’expansió de Taylor de la sèrie de
l'espai escalat per obtenir la ubicació més exacta dels extrems, si la intensitat en aquest
extrems és menor que un valor llindar es rebutja. Aquest llindar es diu contrastThreshold a
OpenCV (és un paràmetre configurable)
El dog (diferència gaussiana), té major resposta per les vores, de manera que les vores també
han de ser eliminades. Per a això, s'utilitza un concepte similar al detector de cantonada
Harris. Normalment s’utilitza una matriu 2x2 de Hesse (H) , per calcular la curvatura principal.
Amb aquesta acció es té coneixement que la cantonada del detector de Harris per les vores, té
un valor propi i que aquest valor és més gran que’l definit.
Si aquesta relació és més gran que un llindar, anomenat edgeThreshold en OpenCV, aquest
punt significatiu es descarta. Realitzant aquesta acció, s’elimina qualsevol punt clau de baix
contrast i els punts clau de vora, quedant només els punts d'interès més forts.
4.1.3 Orientació
Ara l’orientació s'assigna a cada punt clau per aconseguir invariància en la rotació de la imatge.
Es pren al voltant de l’ubicació del punt significatiu depenent de l'escala, la magnitud i direcció
del gradient amb el qual es calcula en aquesta regió.
Es crea un histograma d'orientació amb 36 contenidors que cobreixen 360 graus. Es pondera
per magnitud del gradient i la finestra circular-gaussiana ponderada amb σ igual a 1,5 vegades
l'escala de punt significatiu. El pic més alt en l'histograma es pren i qualsevol pic per sobre del
80% de la mateixa també es considera per calcular l'orientació. Es creen punts significatius
amb la mateixa ubicació i l'escala, però diferents direccions. Contribuint en l'estabilitat de
l’anàlisi.
4.1.4 Punt clau descriptor
A continuació es crea el descriptor amb el punt clau. Una finestra de 16x16 al voltant del punt
clau es definida. Es divideix en 16 sub-blocs de mida 4x4. Per a cada sub-bloc, es crea l’
histograma d'orientació. Pel qual un total de 128 valors d'ubicació estan disponibles. Es
representa com un vector per crear el descriptor en el punt significatiu. A més d'això, es
prenen diverses mesures per aconseguir robustesa enfront de canvis d'il·luminació, rotació etc.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 41
4.1.5 Matchs dels keypoints
Punts clau entre dues imatges es corresponen amb la identificació dels seus veïns més propers.
No obstant això, en alguns casos, el segon més proper pot estar molt a prop de la primera. Pot
ocórrer a causa del soroll o algunes altres raons. En aquest cas, es pren la relació de més
proper distància a-segon més proper distància. Si és major de 0,8, són rebutjats. Amb aquesta
acció s’eliminen al voltant de 90% de falsos matchs, mentre que només es consideren el 5%
com a correctes.
4.1.6 Proves amb l’algorisme SIFT en el laboratori
Dues imatge idèntiques
Imatge 1 imatge 2
Exemple 1
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 42
Exemple 2
Exemple 3
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 43
Dues imatges semblants
Imatge 1 Imatge 2
Exemple 1
Exemple 2
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 44
Exemple 3
Dues imatges diferents
Imatge 1 Imatge 2
Exemple 1
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 45
Exemple 2
Exemple 3
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 46
Comparació imatges extretes des de la pantalla del móvil (semblants)
Imatge 1 Imatge 2
Exemple 1
Exemple 2
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 47
Totalment diferents
Imatge 1 Imatge 2
Exemple 1
Exemple 2
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 48
4.2 SURF (Speeded-Up Robust Features):
És una versió del SIFT però més accelerada . En 2006, tres persones, Badia, H., Tuytelaars, T. i
Van Gool, L, van publicar un altre article, "Surf: accelerar característiques robustes", que va
introduir un nou algoritme anomenat SURF. Com el seu nom indica, és una versió accelerada
de l’algorisme SIFT.
En SIFT, Lowe aproximà La placià de Gauss amb la diferència de Gauss per trobar l'escala-espai.
SURF va una mica més enllà i s'aproxima el registre amb caixes de filtre.
A continuació la figura 4.4 mostra una demostració d'aquesta aproximació. Un gran avantatge
d'aquesta aproximació és que, la convolució amb filtre de caixa es pot calcular fàcilment amb
l'ajuda d'imatges integrals. I pot fer-se en paral·lel per a diferents escales. També el SURF es
basa en el factor determinant de la matriu de Hesse, tant per l'escala i ubicació.
Figura 4.4 - Matriu de Hesse
Per a l'assignació de l'orientació, SURF utilitza respostes en la direcció horitzontal i vertical pels
veïns de mida 6s. També s’apliquen els pesos gaussians. A continuació es representen en un
espai donat com es mostra a la imatge (figura 4.5)
L'orientació dominant, s'estima calculant la suma de totes les respostes dins d'una finestra de
posició amb un angle de 60 graus. L'interessant és que, la resposta es pot trobar utilitzant
imatges integrals molt fàcilment a qualsevol escala. Per a moltes aplicacions, no es requereix la
invariància de rotació, de manera que no hi ha necessitat de trobar aquesta orientació, fent
que s’acceleri el procés.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 49
SURF proporciona una funcionalitat tal anomenat Upright-SURF o O-SURF. Amb el qual es
millora la velocitat i la robustesa fins a + - 15º. OpenCV és calcula mitjançant un flag el qual
es pot configurar amb el valor de 0 si s’ha de calcular l'orientació o un 1 si l'orientació no s’ha
de calcular , depenet de la configuració s’aconsegueix guanyar en velocitat de procés..
figura 4.5 tractament de l’orientació algorisme SURF
Per les característiques descrites de la funció, SURF s’utilitzen respostes en direcció horitzontal
i vertical (de nou, l'ús d'imatges integrals facilita les coses). Es calcula utilitzant els veïns amb
una finestra de mida 20sX20s prenent al voltant del punt clau on S és la mida. Està dividit en
subregions 4x4. Per a cada subregió, les respostes d'ones horitzontals i verticals es representen
com un vector d'aquesta manera, . Aquest quan es
representa com un vector, dóna la característica del descriptor SURF amb un total de 64
dimensions. Aixó fa baixar la dimensió, aconseguint més velocitat de computació, a més de
proporcionar una millora de distinció de les característiques.
Per obtenir més distinció, la descripció del caràcter SURF té una versió estesa amb dimensió
128. Les sumes de i | es calculen per separat per i . De la mateixa
manera, les sumes de i se separen d'acord amb el signe de , duplicant així el
nombre de característiques. No s’afegeix molta complexitat de càlcul. OpenCV suporta el valor
del flag ampliat amb 0 i 1 per 64-dim i 128-dim respectivament (per defecte és 128-dim)
Una altra millora important, és l'ús del senyal de Laplace (es tracta d’una matriu de Hesse) la
qual subjau punts d'interès. Aquesta acció, no afegeix cap cost de computació, ja que, es
calcula durant la detecció. El signe del Laplacià distingeix taques brillants sobre fons foscos de
la situació inversa. En l'etapa d'adaptació, només es comparen les característiques si es tenen
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 50
el mateix tipus de contrast (com es mostra en la figura 4.6). Aquesta informació mínima
permet ajustar el més ràpid, sense reduir el rendiment del descriptor ..
Figura 4.6 - tractament punt d’interés que fan match
En resum, SURF afegeix un munt de característiques per millorar la velocitat en cada pas.
L'anàlisi mostra que és 3 vegades més ràpid que SIFT mentre que el rendiment és comparable
a SIFT. SURF és bo en el maneig d'imatges amb distorsió i la rotació, però no és bo en el
maneig de canvi de punt de vista i el canvi d'il·luminació.
4.2.1 Proves amb l’algorisme SURF en el laboratori
Dues imatge identiques
Imatge 1 imatge 2
Exemple 1
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 51
Exemple 2
Exemple 3
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 52
Dues imatges semblants
Imatge 1 Imatge 2
Exemple 1
Exemple 2
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 53
Exemple 3
Dues imatges diferents
Imatge 1 Imatge 2
Exemple 1
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 54
Exemple 2
Exemple 3
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 55
Comparació imatges extretes des de la pantalla del movil
Imatge 1 Imatge 2
Exemple 1
Exemple 2
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 56
Totalment diferents
Imatge 1 Imatge 2
Exemple 1
Exemple 2
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 57
4.3 ORB: (Oriented Fast and Rotated Brief)
Aquest algoritme, va ser creat per Ethan Rublee, Vincent Rabaud, Kurt Konolige i Gary R.
Bradski és una alternativa eficient per SIFT O SURFT el qual es va implementaren l'any 2011.
ORB és bàsicament una fusió de detector punt significatiu FAST i descriptor Breu amb moltes
modificacions per millorar el rendiment. En primer lloc, es més ràpid que els seu antecessor en
trobar punts clau, A més aquest aplica la mesura de contonada de Harris per trobar els millors
N punts entre ells. També utilitzar les piràmides per produir múltiples escales-característiques.
Es calcula la intensitat ponderada baricentre del pegat (patch) amb la cantonada situada al
centre. La direcció del vector d'aquest punt de cantonada en el centroide dóna l'orientació. Per
millorar la invariància en rotació, els moments es calculen amb x i y que han d'estar en una
regió circular de radi r, on r és la mida del pegat (patch).
ORB utilitza descriptors brief. Per a qualsevol conjunt de característiques de proves binàries n
en la posició es defineixen un 2*n vegades en la matriu, S, que conté les coordenades
d'aquests píxels. Després, utilitzant l'orientació del pegat (patch) , , la seva matriu de rotació
es troba i es fa girar a S per obtenir la versió amb la rotació guiada de S. ORB discretitza l'angle
a increments de (12 degrees), i construeix una taula de recerca de patrons brief
precalculats. Sempre que el punt clau d'orientació és consistent a través de punts de vista, el
conjunt correcte de punts s'utilitza per calcular el seu descriptor.
El ser un descriptor brief, té una propietat important i és que cada característica de bits té una
gran variància i una mitjana prop de 0,5. Però una vegada que està orientat al llarg de la
direcció punt clau, perd aquesta propietat a l’estar més distribuïda.
Aquesta alta variància, és un tret característic més discriminatiu, ja que, respon de manera
diferencial a les entrades.
Una altra característica a destacar en l’algorisme ORB, és que executa una recerca exhaustiva
entre totes les possibles proves binàries per trobar els que tenen alta variància i significa que
tenen un valor proper de 0.5, a més de ser correlacionades. El resultat obtingut es diu rBRIEF.
Per a l'adaptació dels descriptors, LSH multi-sonda que millora la LSH tradicional, s'utilitza , per
guanyar en velocitat , aquest fet fa que l’algorisme ORB sigui molt més ràpid que SURF i
seleccioni els descriptor funcionant millor que els seus antecesors (SURF i SIFT). ORB és una
opció excel·lent per dispositius mòbils tant de baixa potència com d’alta en el moment de
tractar la composició panoràmica de les imatges.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 58
4.3.1 Proves amb l’algorisme ORB en el laboratori
Dues imatge identiques
Imatge 1 imatge 2
Exemple 1
Exemple 2
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 59
Exemple 3
Dues imatges semblants
Imatge 1 Imatge 2
Exemple 1
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 60
Exemple 2
Exemple 3
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 61
Dues imatges diferents
Imatge 1 Imatge 2
Exemple 1
Exemple 2
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 62
Exemple 3
Algorisme ORB amb imatges extretes de la pantalla del mòvil
Imatges semblants
Imatge 1 Imatge 2
Exemple 1
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 63
Exemple 2
Totalment diferents
Imatge 1 Imatge 2
Exemple 1
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 64
Exemple 2
4.3.2 Conclusions amb l’algorisme ORB en el laboratori
Realitzades les proves en el laboratori amb els diferents algorismes (SIFT , SURF, ORB) i el
background estudiat de diferents articles respecte a la temática que es vol resoldre, es va
poder diagnosticar que l’algorisme que donava millor resultat pel reconeixements de firmes
era el ORB, ja que, aquest algorisme trovaba més trets caracteristics correctes respecte els
altres algorismes utilitzats, a més que el cònsum de recursos del dipositiu es redueix
considerablement amb aquest algorisme (cal esmentar que en la documentació s’han mostrat
els milllors resultats de cada algorisme en les diferents situacions).
Per tant, en l’aplicatiu Android es va implementar el mateix algorisme ORB realitzat en les
proves per poder validar la firma del solicitant.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 65
5. ELEMENTS DE SEGURETAT D’ANDROID
La majoria de les mesures de seguretat entre el sistema i les aplicacions deriva dels estàndars
de Linux, el nucli constitueix el nucli principal d'Android. Cap aplicació té els permisos per a
realitzar operacions que puguin alterar el comportament del sistema, com llegir o escriure
arxius o fitxers privats, accés a la xarxa o habilitar maquinari. A continuació es farà referència
alguns dels elements de seguretat que es poden configurar en Android:
5.1 Arxiu AndroidManisfest.xml
Un element de seguretat d'Android és l'arxiu de manifest. El fitxer de manifest està inclòs en el
paquet d'instal·lació d'Android (arxiu .apk), juntament amb el codi de bytes i altres recursos
relacionats. L'arxiu segueix l'estructura XML i proporciona tota la informació necessària a la
plataforma Android per a l'execució de l'aplicació. El fitxer de manifest és important per al
sistema, ja que, és on es defineixen els permisos de cada aplicació. Aquests permisos
funcionen de dues formes, la primera és com l'aplicació interactua amb el sistema mitjançant
l'accés a l'API del sistema i en segon lloc, la forma com el sistema i altres aplicacions
interactuen amb l'aplicació donada.
Per defecte, cada aplicació s'executa en un entorn d'espai aïllat sense cap tipus de permís per
realitzar una acció que pugui afectar el sistema operatiu en sí mateix.
Tota sol·licitud de permisos es realitza durant el moment d'instal·lació, on l'usuari aprova o
rebutja els permisos que sol·licita l'aplicació. Per tant, si l'usuari decideix concedir permís a
l'aplicació, a continuació, els recursos del sistema protegit estaran disponibles per l'aplicació,
en cas contrari l'accés als recursos serà denegat. És aquí on moltes aplicacions malicioses aprofiten per
instal·lar-se al sistema i accedir a la informació del dispositiu o denegar algun servei.
Els paquets d'instal·lació d'Android han de ser signats digitalment pel seu creador, amb una identificació
única per cada aplicació. En el model de seguretat d'Android no cal que el certificat del desenvolupador
estigui signat per un certificat d'autoritat de confiança, per tant les aplicacions són generalment
signades de manera digital amb certificats auto-signats, proporcionant la capacitat de verificar l'origen i
la protecció de la integritat.
Per establir un permís per a una aplicació, cal declarar-ho en el manifest un o més elements <uses-
permission> on s'especifica el tipus de permís que es vol habilitar.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 66
A la classe Android.Manifest.permission s'especifiquen tots els possibles permisos que es poden
concedir a una aplicació: utilització de wi-fi, bluetooth, trucades telefòniques, càmera, internet,
missatges SMS i MMS, vibrador, etc.
En els dispositius mòbils la seguretat juga un paper important, ja que, la descàrrega d'aplicacions
malicioses poden actuar de manera que llegeixin la llista de contactes, esbrinar la posició GPS, enviar
tota aquesta informació per Internet i acabar enviant missatges SMS. La seguretat en Android es
fonamenta en els següents tres pilars:
- Android impedeix que les aplicacions tinguin accés directe al hardware o interfereixin amb
recursos d’altres aplicacions.
- Tota aplicació ha de ser signada amb un certificat digital que identifiqui el seu autor. La
signatura digital també garantitza que el fitxer de l’aplicació no hagi sigut modificat.
- Si es desitja modificar l’aplicació aquesta ha de ser signada de nou, i només podrà fer-ho el
propietari de la clau privada.
5.2 Usuari Linux i accés a arxius
Per protegir l’accés a recursos utilitzats per altres aplicacions, contempla aïllament de
processos, ja que, té un mencanisme de seguretat extensible i permet eliminar parts
innecessàries i potencialment insegures, a més, Android crea un compte d’usuari Linux (user
ID) nou per a cada paquet (APK) instal·lat en el sistema. Aquest usuari és creat quan s’instal·la
l’aplicació i està de manera permanent durant toda la seva vida en el dispositiu.
5.3 L’esquema de permisos en Android
Per protegir certs recursos i característiques especials del hardware, Android defineix un
esquema de permisos. Totes les aplicacions que accedeixin aquests recursos estan obligades a
declarar la seva intenció d’utilizar-los. En cas de que una aplicació intenti accedir a un recurs
del que no ha sol·licitat permís, generarà una excepció de permís i l’aplicació serà
interrompuda immediatament. Quan l’usuari instal·la una aplicació, aquesta podrà examinar la
llista de permisos que sol·licita l’aplicació i decidir si es considera oportú instal·lar-la.
5.4 Mecanisme de seguretat sandbox
Aquest mecanisme és obligatori per a totes les aplicacions, ja que, realitza l’execució com un
procés amb identificadors de grup i usuari particulars. El que es permet amb aquestes
polítiques, és que els accessos puguin ser definits per a cada aplicació depenent dels seus
requeriments i propòsits. Aquests permisos són aprovats per l'usuari en temps d'instal·lació,
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 67
mitjançant l'acceptació de l’arxiu android manifest esmentat en aquest mateix punt. Els errors
de corrupció de memòria comprometen la seguretat completa del dispositiu; aquests errors
són minimitzats en Android a causa de que totes les aplicacions i els seus recursos estan en un
espai aïllat, de manera que una corrupció en memòria només permetrà l'execució del codi en
el context de l'aplicació i amb els permisos establerts per aquesta.
5.5 Partició del sistema i mode segur
La partició del sistema conté el nucli de Linux, les llibreries, el temps d'execució, el framework
d'aplicacions i les aplicacions. Aquesta partició és de només lectura. Quan un usuari inicia
l'equip en mode segur, només s'inicia la partició del sistema, de manera que només les
aplicacions bàsiques d'Android estaran disponibles, el que assegura que l'usuari pot iniciar el
seu telèfon amb un ambient lliure d'aplicacions de tercers i per tant, en un mode segur.
5.6 Sistema de xifratge
Des de la versió 3.0 d’Android es proporciona xifrat complet dels fitxers. Totes les dades es
xifran en el kernel utilitzant una clau derivada de la contrasenya de l’usuari per evitar atacs de
força bruta, aquesta es combina amb un salt a l’atzar i un hash al moment de l’encriptació, a
més, aquest xifratge es realitza amb un algoritme AES de 128 bits mitjançant CBC. La màster key
es xifra amb una altre clau AES de 128 bits, per aquesta raó s'utilitza la funció PBKDF2, implementada en
OpenSSL. EL salt es genera a partir d'una seqüència de nombres o contrasenya establerta per l'usuari.
Aquest és un procés irreversible en el qual es xifra per complet el sistema de fitxers, només es pot
revertir en cas de realitzar un esborrat a l'estat de fàbrica, perdent així les dades emmagatzemades.
Quan és necessari accedir a un fitxer determinat aquest es desxifra i es torna a xifrar un cop finalitzada
la seva modificació. El procés es realitza a nivell de bloc del sistema de fitxers. Actualment, el sistema
també permet el xifrat de dispositius d'emmagatzematge extern, un cop realitzat el procés, els fitxers
xifrats només seran accessibles des del mateix dispositiu.
La funcionalitat d’això és proporcionar resistència contra atacs de diccionari, ja que, Android compte
amb regles de complexitat de contrasenyes que es poden configurar a l’administrador del dispositiu i
són executades pel sistema operatiu.
5.7 Protecció per constrasenya
Android es pot configurar perquè sol·liciti una contrasenya d'usuari abans de proporcionar accés al
dispositiu, això facilita la prevenció de l'ús no autoritzat del dispositiu i la contrasenya utilitzada per
l'algorisme de xifrat.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 68
5.8 Administració de dispositius
Android proporciona un API per a l'administració de dispositius que conté funcions a nivell del sistema.
Fent ús d'aquest API es poden configurar funcionalitats com esborrar la informació de forma remota o
restaurar els valors de fàbrica, el que és útil en cas de pèrdua o robatori.
5.9 Millores de seguretat en l’administració de la memoria
Android ha inclós característiques de seguretat que fan difícil aprofitar els problemes comuns de
corrupció de memòria. Algunes d'aquestes característiques són a l’escollir de forma aleatòria les
posicions importants en memòria, reduïnt problemes de desbordaments i evitant l’execució de codi a la
pila i el heap.
5.10 Permisos de "root" en els dispositius
En Android només el nucli i un subconjunt petit d'aplicacions principals s'executen amb permisos de
root. Els permisos de root poden modificar el sistema operatiu, el nucli i qualsevol altra aplicació, a més,
es disposa de llibertat absoluta a les dades d'aplicació. Si un usuari modifica els permisos del dispositiu i
concedeix aquests permisos de root a les aplicacions, aquesta augmenta el risc de seguretat contra
aplicacions malicioses. Android ha permès que els permisos de root es puguin configurar, ja que,
aquesta és una propietat important per als desenvolupadors i per als usuaris que volen permetre la
instal·lació d'un sistema operatiu alternatiu.
5.11 Signatura de les aplicacions
La sol·licitud de signatura del Codi (paquet APK) permet als desenvolupadors identificar l'autor i
responsable de l'aplicació, les aplicacions que intenten instal·lar-se sense ser signades són rebutjades.
Aquesta signatura es fà per mitjà de certificats que són verificats en el moment de la instal·lació.
6. TIPUS D’ATACS ALS DISPOSITIUS ANDROID
Abans de realitzar un anàlisis dels possibles atacs que pot patir un dispositiu Android, es farà una
descripció dels tipus d’aplicacions que poden funcionar en un dispositiu mòbil Android, les quals es
poden dividir en tres categories operatives:
Web : Les aplicacions que funcionen a través d'un navegador web de propòsit general. De vegades
es refereix com WAP o llocs mòbils, aquests són l'equivalent a les aplicacions web mòbils funcionals
que han proliferat en l'última década i ofereixen múltiples opcions. Tot i que els llocs web normals
es poden utilitzar en els navegadors web mòbils, moltes empreses desenvolupen una aplicació web
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 69
per a mòbils separada, amb la finalitat d’optimitzar-les com ara la mida de pantalla més petita, la
navegació basada en el contacte i la disponibilitat de GPS.
Native: Aplicacions que operen fora del sistema operatiu del dispositiu mòbil natiu,
compilat per a la plataforma mòbil específica i l'aprofitament dels seus API. Aquests són
descarregats e instal·lats a través d'un mercat d’aplicacions.
Wrapper: Aplicacions que operen mitjançant l'aprofitament de les pàgines web dins del codi natiu
amb l’embolcall de l’aplicació, també es refereix a vegades com "aplicacions de petxina" o bé
"aplicacions híbrides." que apareixen com una aplicació nativa per a l'usuari final, la funcionalitat
basada en la web pot donar lloc a diferents vulnerabilitats que es troben en aplicacions natives
totalment codificades.
A continuació, després d’haver analitzat els tipus d’aplicatius que poden funcionar en un dipositiu
Android, es realitzarà un estudi de les principals amenaces en seguretat que poden patir els
smartphones amb aquest sistema operatiu, els quals es divideixen en tres grups segons la
procedència de l’atac.
1. Atacs des del dispositiu 2. Atacs des de la xarxa 3. Des del centre de dades
6.1 -Atacs des del dispositiu Els dispositius mòbils representen riscos significatius per a la informació corporativa sensible (SCI);
els riscos inclouen tant la pèrdua de dades com posar en perill la seguretat del dispositiu. Els
atacants es poden dirigir al dispositiu utilitzant una varietat de punts d'entrada:
1. Atacs procedents de carpetes, emails o altres aplicacions prerecarregades 2. Atacs procedents de Telèfon /Sms 3. Atacs procedent d’apliacions de tercers (apps) 4. Atacs al Sistema Operatiu
6.1.1 Atacs procedents de carpetes, emails o altres aplicacions Els atacs basats en carpetes poden incloure:
Phishing: Consisteix en l'adquisició d'informació personal, com noms d'usuari,
contrasenyes, i dades de la targeta de crèdit fent-se passar per una entitat de
confiança mitjançant correu electrònic spoofing.
La investigació ha demostrat que els usuaris mòbils tenen tres vegades més
probabilitats que els usuaris d'escriptori enviant informació personal a llocs phishing.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 70
Això és, en part, probablement a causa del baix escalat d’un navegador mòbil on es
mostra només una petita part de les direccions URL a causa del limitat visual de la
pantalla, els quadres de diàleg d'alerta limitats, reducció d’icones de bloqueig segures,
i la renúncia a molts indicadors d'interfície d'usuari, com ara grans icones ressaltants
com: parades d'emergència, barres de direcció, i altres indicadors visuals.
Framing: implica el lliurament d'un lloc web / WAP en un marc flotant, que pot
permetre el contenidor del lloc ser utilitzat per a executar atacs de clickjacking.
Clickjacking: També conegut com la reparació de la interfície d'usuari, el clickjacking
implica enganyar els usuaris en revelar informació confidencial o de prendre el control
del seu dispositiu quan l'usuari fa clic a l’enllaç o botó aparentment innòcua. Aquest
atac pren la forma de codi encastat o seqüències d'ordres que s'executen sense el
coneixement de l'usuari. Clickjacking s'ha explotat en els llocs incloent Facebook per
robar informació o usuaris directes per atacar llocs.
Drive-by-downloading: Android en particular, ha estat vulnerable a aquest atac, on
una visita al lloc web provoca una descàrrega sense el coneixement de l'usuari. La
descàrrega pot ser una aplicació maliciosa, amb la qual de forma automàtica s’instal·li
en el dispositiu. Aquests tipus d’atac tenen éxit quan els dispositius Android permeten
que les aplicacions de "fonts desconegudes" es puguin instal.lar.
L'home-en-el-Mobile (MitMo): Permet als usuaris maliciosos aprofitar el malware
instal·lat en els dispositius mòbils, amb la finalitat d’eludir els sistemes de verificació
de contrasenya, que envien els codis a través de missatges SMS de text els telèfons
dels usuaris per confirmar la identitat.
6.1.2 Atacs basats en telèfon/SMS
Baseband attacks: Els atacs que exploten les vulnerabilitats trobades en un telèfon
GSM / 3GPP processador de banda base, que és el maquinari que envia i rep senyals
de ràdio a la cel·la de les torres.
Smishing: Igual que en el phishing, però utilitza missatges de text de mòbil en lloc del
correu electrònic amb la finalitat de sol·licitar als usuaris a visitar llocs web il·legítims i
introduïr informació com noms d'usuari, contrasenyes i números de targetes de crèdit.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 71
RF Attacks: Bluejacking, atacs NFC i altres RF, són atacs amb la finalitat de trobar
vulnerabilitats en diversos canals de comunicació perifèrics, els quals es fan servir
típicament en les rodalies de dispositius en les comunicacions.
6.1.3 Atacs basats en aplicacions de tercers
Sensitive Data Storage: Es va tenir constància, que aplicacions populars
emmagatzemaven dades mostrejades de forma insegura.
No Encryption/weak encryption: Aplicacions que permeten la transmissió de les
dades xifrades dèbilment, són vulnerables als atacs.
Improper SSL validation: Errors en la capa de connexió segura d'una aplicació (SSL)
de validació, pot permetre vunerabilitats de seguretat de dades.
Config-manipulation: Inclou l'accés no autoritzat a l'administració d’interfícies,
botigues de configuració i recuperació de dades de configuració de text sense xifrar.
Dynamic runtime injection: Permet a un atacant manipular i abusar del temps
d'execució d'una aplicació per eludir els panys de seguretat, controls d'accés, la lògica
de desviació amb parts privilegiades d'una aplicació, i fins i tot robar dades
emmagatzemades a la memòria.
Unintended permissions: Les aplicacions mal configurades a vegades poden obrir la
porta a atacants mitjançant la concessió de permisos no desitjats.
Escalated privileges: Explota un error, defecte de disseny o configuració de supervisió
per tal d’obtenir accés als recursos protegits normalment des d'una aplicació o usuari.
6.1.4 Atacs basats en sistema operatiu
No passcode: Molts usuaris opten per no establir un codi d'accés, o utilitzar un PIN
feble, contrasenya o patró de bloqueig.
iOS jailbreaking: És un terme per a l'eliminació dels mecanismes de seguretat
implementats pel fabricant per tal d'evitar que el codi no autoritzat s'executi al
dispositiu. Una vegada que s'eliminen aquestes restriccions, el dispositiu pot
esdevenir una porta d'entrada pel malware i altres atacs.
Android rooting: Igual que en el jailbreaking, permet que els usuaris d'Android puguin
alterar o reemplaçar les aplicacions i ajustos del sistema i executar aplicacions
especialitzades que requereixen permisos d'administrador. Com al jailbreaking, pot
donar lloc a l'exposició de dades sensibles .
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 72
Passwords and data accessible: Dispositius com ara la línia de dispositius, tenen
vulnerabilitats conegudes en els seus mecanismes criptogràfics per emmagatzemar
contrasenyes xifrades i dades. Un atacant amb el coneixement d'aquestes
vulnerabilitats pot desxifrar el dispositiu, deixant al descobert les contrasenyes
d'usuari, claus de xifrat i altres dades privades.
Carrier-loaded software: Programari preinstal·lat en els dispositius poden contenir
errors de seguretat. Recentment, s'han trobat algunes aplicacions pre-carregades en
els telèfons Android per contenir vulnerabilitats en la seguretat, que podrien ser
utilitzades per grabar àudio, robar dades, i fins i tot espiar en trucades.
Zero-day exploits: Aquest atac sovint es produeix quan una vulnerabilitat és
explotada abans que els desenvolupadors de programari són capaços d'emetre un
comunicat per abordar-la.
6.2 Atacs procedents des de la xarxa
Wi-Fi (weak encryption/no encryption): Les sol·licituds que no implementen xifrat
quan s'utilitzen xarxes WI-FI, produeixen un augment en el risc de ser interceptades
per un espionatge maliciós mitjançant un atac a la connexió sense fils. Moltes
aplicacions utilitzen SSL/TLS, que proporciona un cert nivell de protecció; però,
alguns atacs contra SSL/TLS s'ha demostrat que poden exposar les dades critiques
d'usuari per part d’un atacant.
Rogue access points: Consisteix en instal·lar físicament l'accés sense fil no autoritzat,
en un punt que habiliti les parts d'accés a una xarxa segura.
Packet sniffing: Permet a un usuari maliciós, capturar i analitzar el tràfic de xarxa, que
normalment inclou nom d'usuari i la contrasenya de la informació transmesa en text clar.
Man-in-the-Middle (MITM): implica l'espionatge en una xarxa existent
en connexió, realitzant la intercepció de missatges, i la modificació d’aquestes dades.
SLStrip: És una tècnica de man-in-the-middle que explota la debilitat en el SSL / TLS
en els llocs web, en que l'usuari verifica que una connexió HTTPS
està present. L'atac rebaixa de manera invisible les connexions HTTP, sense xifrat, i
és difícil per als usuaris detectar-los en els navegadors mòbils.
Session hijacking: Implica l'explotació d'una clau de sessió per obtenir accés no
autoritzat a la informació de xarxa de l'usuari.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 73
DNS poisoning: L'explotació de DNS de la xarxa es pot utilitzar pels usuaris directes
d'una pàgina web a un altre lloc escollit per l'atacant. En alguns casos els atacs
també poden injectar contingut a través d'aplicacions.
Fake SSL certificates: És una altre tècnica man-in-the-middle que implica l'emissió
de falsos certificats SSL, amb el qual permet a un usuari maliciós interceptar el
trànsit en una suposat segment.
6.3 Atacs procedents des d’un centre de dades (web service o base de dades)
6.3.1 web services
Platform vulnerabilities: Les vulnerabilitats en el sistema operatiu, programari
de servidor, o mòduls d'aplicacions que s'executen en el servidor web poden
ser explotades per un atacant. Aquestes vulnerabilitats poden ser descobertes
mitjançant el control de la comunicació entre un dispositiu mòbil i el servidor
web, amb la finalitat de trobar debilitats en el protocol o l'accés a controls.
Server misconfiguration: Un servidor web mal configurat pot permetre no
autoritzar l’accés als recursos que normalment estan protegits.
Cross-site scripting (XSS): És un atac que consisteix a injectar codi JavaScript
maliciós en una pàgina web. Pàgines que són vulnerables a aquest tipus d’atac
són le que no realitzen cap control de les dades introduïdes per els ususaris a
través de la interfície. Aquest atac és utilitzat sovint per executar codi de forma
automàtica quan un usuari visita una pàgina, prenent el control del navegador
d'un usuari. Un cop establert el control del navegador, l'atacant pot aprofitar
aquest control en una varietat d'atacs, com la injecció de contingut o
propagació de malware.
Cross-site Request Forgery (CSRF): Petició en llocs creuats amb falsificació
per part d’un atacant en la creació d'HTTP (web), mitjançant les sol·licituds
basades en el coneixement de com una aplicació web en particular funciona,
enganyant un usuari o navegador en la presentació d'aquestes sol·licituds. Si
un lloc és vulnerables, l'atac es pot executar mitjantçant transaccions o
enviaments que semblin provenir de l'usuari. CSRF s'utilitza normalment
després que un atacant hagi aconseguit el control d'un usuari durant la sessió,
ja sigui a través de XSS, enginyeria social o altres mètodes.
Weak input validation: Molts dels serveis web confien excessivament en
l'entrada procedent de les aplicacions mòbils proporcionades per l'usuari final.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 74
No obstant això, els atacants poden forçar la seva pròpia comunicació amb el
lloc web o de derivació de controls lògics d'aplicació en la seva totalitat, amb la
conseqüència que es permet prendre avantatge en la validació lògica al
servidor, per realitzar accions no autoritzades
Brute-force attacks : Es tracta d'endevinar les entrades vàlides per a un camp,
sovint utilitzant una alta taxa d'intents i diccionaris de valors possibles. El més
ús comú d'un atac de força bruta és l'autenticació, però també es pot utilitzar
per descobrir altres valors vàlids en una aplicació web.
6.3.2 Base de dades
QL injection: Les interfícies que no validen correctament l'entrada de l'usuari
poden donar lloc a ser vulnerables atacs de SQL injection, fent que la base
de dades s’exposi o es manipulin les dades que haurien d'estar restringides
per part de l'usuari o sol·licitud.
OS command execution: Similar a la injecció de SQL, certs sistemes de bases
de dades proporcionen una mètode per a executar comandaments a nivell
de sistema operatiu. Un atacant pot injectar aquestes comandes en una
consulta, fent que la base de dades per executar aquestes comandes al
servidor, proporcionant a l’atacant privilegis addicionals, fins i tot incloent
l'accés al sistema a nivell d’arrel.
Privilege escalation: Això passa quan un atac aconsegueix guanyar un major
accés. En les bases de dades això pot conduir al robatori de dades sensibles.
abocament de dades , ja que , l’atacant fa que la base de dades bolqui alguns
o totes les dades dins d'una base de dades, exposant registres sensibles.
7. POLÍTIQUES DE CONFIGURACIÓ EN SEGURETAT DEL DISPOSITIU MÒBIL
Buscant protegir de millor manera els dispositius mòbils, s'han de tenir en compte les següents
recomanacions:
1- Utilitzar mètodes de bloqueig en el dispositiu. Existeixen mètodes com
contrasenyes, patrons, bloquejos biomètrics, de reconeixement de veu, entre
d'altres.
2- Realitzar suport periòdic dels elements importants emmagatzemats al dispositiu.
Hi ha eines de backup al núvol (No local) que permeten gestionar i mantenir-los
segurs, per si es requereix alguna recuperació.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 75
3- Aplicar xifrat a la memòria d'emmagatzematge, per fer impossible la còpia de les
dades i per tant l'extracció d'aquestes.
4- Fer servir algun mètode d'esborrat remot, que pot configurar-se a través de
múltiple mètodes. Per mitjà de Google Sync o Google Apps és possible realitzar
aquesta funció. D'aquesta manera si es perd o és robat el dispositiu es pot eliminar
la informació, per evitar la seva divulgació o manipulació.
5- Instal·lar antivirus en els dispositius, això donarà suport no només el tema
d'infeccions, sinó que podrà controlar l'accés no autoritzat al dispositiu, fent a
vegades de tallafocs a més de contenir algunes altres funcionalitats com
capturació de càmera, per si s'intenta desbloquejar el dispositiu de forma errònia
en múltiples ocasions, prendrà una foto per conèixer qui tracta de desbloquejar-lo.
Els antivirus tenen múltiples funcions i a nivell de seguretat és molt important
comptar amb ells.
6- S'ha de tractar d'evitar connexions a xarxes públiques i altres de procedència
dubtosa. Això inclou accés a Wi-Fi però també per mitjà de Bluetooth i infraroig. És
possible que a través d’aquests tipus de connexions, pugui ser robada informació
del dispositiu. Evitar instal·lar aplicacions desconegudes, de fonts no identificades,
fins i tot si provenen de Google Play. La majoria d'elles contenen malware i
elements que infecten el dispositiu, permetent el control remot.
7- Les actualitzacions de les aplicacions i del sistema operatiu són fonamentals per
protegir els dispositius, ja que, majoritàriament porten patchs de seguretat de
bugs (Falles) trobats durant la seva operació i per això sempre s'han d'instal·lar.
8- No connectar els dispositius via USB en equips públics i desconeguts, ja que, també
es poden tenir bretxes de seguretat a realitzar aquesta acció.
9- És important llegir manuals i instruir-se en quant a l'ús del dispositiu i del sistema
operatiu. En moltes ocasions es cometen errors i es deixen d'habilitar funcions de
seguretat per la falta de coneixement.
10- Per evitar la instal·lació de ROMS (Imatges del sistema operatiu) custom o
personalitzats. Aquests en general no tenen els nivells òptims de seguretat i poden
contenir elements maliciosos que poden generar problemes en el dispositiu, així
com el robatori d'informació.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 76
11- Si l’usuari és inexpert en el maneig d'Android, és recomana evitar fer "root" en el
sistema operatiu per obtenir permisos de súper usuari. Moltes aplicacions
malicioses s'aprofiten d'això per fer danys.
12- Permetre control remot. En cas de robatori, és important tenir una aplicació en el
dispositiu móbil que permeti controlar remotament. Aixi, es pot localitzar el
dispositiu, recuperar les seves dades emmagatzemades o borrades perquè no
siguin compromeses. També es pot tenir una aplicació que borri les dades
automàticament després de varis intents d’accessos fallits.
13- Habilitar accés inicial mitjançant codi pin o contrasenya.
8 GUIA DE SEGURETAT PEL DESENVOLUPAMENT D’APLICACIONS
ANDROID
A continuació, es farà referència a les pautes que tenen que seguir els desenvolupadors
d’aplicacions Android, per assegurar la confidencialitat , integritat i privacitat de les dades que
administren aquests tipus de dispositius mòbils.
Les pautes que han de seguir els desenvolupadors d’Android són les següents :
8.1 Augmentar la complexitat del codi i ús d’ofuscació en l’aplicatiu Android
Les aplicacions d'enginyeria inversa poden proporcionar informació valuosa sobre com
funciona l’aplicació. Dissenyar i programar una aplicació més complexa internament, fa que
sigui més difícil pels atacants l’anàlisi del funcionament de l'aplicació, aconseguint reduir el
nombre de vectors d'atac.
En el moment d’implementar l’aplicació en Android s’ha de limitar l’accés a:
1- Restricció del debugger: Una aplicació pot especificar mitjançant una trucada al
sistema específic i evitar que el sistema operatiu permeti al depurador inserir-se en el
procés. Per la prevenció d'un depurador de fixació, la capacitat d'un atacant per
interferir a baix nivell en temps d'execució és limitat. Un atacant primer ha de sortejar
les restriccions de la depuració per tal d’atacar l'aplicació en un nivell baix. Això afegeix
més complexitat a l’atac. Les aplicacions d’Android han de tenir aquest paràmetre
android: depurable = "false" definit en el Androidmanifest.xml, amb la finalitat d’
evitar la manipulació d’execució per un atacant o malware.
2- Comprovació de traça: Una aplicació pot determinar si és o no està sent actualment
traçat per un depurador o una altre eina de depuració. Si està sent rastrejat, l'aplicació
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 77
pot realitzar qualsevol nombre d'accions de resposta, com ara, descartar les claus de
xifrat per protegir dades d'usuari, notificar a un administrador del servidor o d'un altre
tipus de respostes en un intent per defensar-se. Això pot ser determinat pel control
dels indicadors d'estat del procés o l'ús d'un altre tècnica com la comparació del valor
de retorn de la traça adjunta. El control de la matriu de procés, depuradors de llistes
negres en la llista de processos o la comparació de les marques de temps en diferents
llocs del programa són algunes de les accions que es poden realitzar.
3- Optimització : Per amagar els càlculs matemàtics avançats i altres tipus de
lògica complexa, utilitzant les optimitzacions del compilador pot ajudar a ofuscar el
codi objecte perquè no pugui ser fàcilment desmuntat per un atacant. Això fa que sigui
més difícil per a un atacant obtenir una comprensió del codi particular. En Android això
es pot aconseguir més fàcilment mitjançant la utilització de les biblioteques de forma
nativa dels compilats amb el NDK. A més, utilitzant una LLVM ofuscador o qualsevol
SDK protector proporcionarà un millor codi màquina ofuscat.
4- Exclusió de binaris natius: És una manera eficaç d'augmentar el temps
i l'habilitat que es requereix d'un atacant per tal de veure l’aplicació implementada i
els nivells de les seves funcions. En eliminar un binari, la taula de símbols del binari es
queda buit amb la finalitat que l’atacant no pugui depurar fàcilment o realitzar
enginyeria inversa d'una aplicació. Excloent els binaris fa que es dificulti l’èxit en la
utilització de tècniques sstriping o UPX de reutilització de codi com es pot realitzar en
sistemes GNU / Linux .
8.2 Evitar lògica simple
Les proves lògiques simples en codi són més susceptibles a l'atac. exemple:
if sessionIsTrusted == 1
Aquestes proves lògiques simples en codi són més susceptibles a l'atac. Si un atacant pot
canviar el valor, permetrà que l’atacant sigui capaç d’eludir els controls de seguretat (Android
té els arxius binaris en Dalvik). Aquestes proves lògiques són fàcils d'eludir en molts nivells. En
Android, l'aplicació es pot descompilar amb Smali i la condició de branca ser modificada avanç
de ser compilada.
Per solucionar aquest fet, s’ha de pensar amb el millor paradigma de programació , on els
privilegis són imposats pel servidor quan la sessió no és de confiança o mitjançant la prevenció
de certes dades que han de ser desxifrades o disponibles d'una altre manera, això es realitza
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 78
amb la finalitat que l'aplicació pugui determinar que la sessió és de confiança amb l'ús de
desafiament / resposta, OTP, o altres formes d'autenticació. A més, és recomana declarar totes
les funcions de comprovació de seguretat de línia estàtica. Amb aquest enfocament es
compilen en línia fent més difícil la implementació del patch (és a dir, un atacant no pot
simplement anul·lar una funció o posar patchs en una funció). Aquesta tècnica requereix que
l'atacant es vegi obligat a posar pegats a cada instància de la verificació de l'aplicació, generant
un augment en la complexitat de l’atac. Per a aplicacions altament sensibles, és més sofisticat
enfocaments fundats en principis de codificació segura, poden iniciar una investigació
addicional. La integració de tècniques com ara el xifrat, les devolucions de trucada amb hora i
data de la programació basada en flux i altres tècniques, afegeixen un augment en la
complexitat dels possibles atacs.
8.3 Utilització de biblioteques de tercers
Els desenvolupadors depenen a vegades de biblioteques de tercers. És important fer un test de
proves d’aquestes llibreries mitjançant el codi que s’està desenvolupant o utilitzant altres tipus
d’eines per diagnosticar que aquestes biblioteques implementades per tercers, poden contenir
vulnerabilitats i debilitats que s’han d’evitar. Molts desenvolupadors erròniament assumeixen
que les biblioteques de tercers estan ben desenvolupades i provades, ja que , aquestes poden
generar un gran problema en el funcionament i seguretat en l’aplicatiu.
8.4 Aplicar tècniques de protecció contra manipulacions
Els atacants poden manipular o instal·lar una porta del darrere en una aplicació, tornar a signar
i publicar la versió amb el codi maliciós als mercats d'aplicacions de tercers (no Google Play) .
Aquest tipus d'atacs solen centrar-se en aplicacions populars i aplicacions financeres. Per
solucionar aquesta situació s’ha d’utilitzar tècniques de antisabotatge i detecció de
manipulacions tècniques per prevenir que l’aplicació sigui corrupta. Utilitzar mètodes com
checksum de comprovació, signatures digitals i altres mecanismes de validació per ajudar a
detectar l'arxiu i la seva manipulació, ajuden a diagnosticar aquest tipus d’atacs, ja que, quan
un atacant intenta manipular l'aplicació, el correcte checksum de comprovació no es conserva i
per tant és un mecanisme que serveix per poder detectar i prevenir l’execució. Aquestes
tècniques no són totalment infal·libles i poden ser anul·lades per una hacker amb
coneixements avançats. Quan el cheksum fa la comprovació de la signatura digital
conjuntament amb altres tècniques de validació, produeix un augment en la quantitat de
temps i esforç per part de l’atacant que ha de passar a descodificar amb èxit l'aplicació.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 79
Les aplicacions que s'han detectat amb una manipulació han de ser notificades a
l’administrador d’aquesta. En Android, la clau pública utilitzada per signar una aplicació es pot
llegir en el certificat de l'aplicació i s'utilitza per verificar si l'aplicació va ser signada amb la clau
privada del desenvolupador. Això es pot saber utilitzant la classe PackageManager amb la qual
és possible recuperar les firmes de l’aplicació i comparar-les amb el valor correcte. Si algun
atacant ha manipulat o re-signat l'aplicació, la comparació fallarà donant com a resultat la
detecció de la manipulació indeguda de l’aplicatiu.
8.5 Emmagatzemar de forma segura dades confidencials en la memòria RAM
Quan una aplicació està en ús, l'usuari o les dades específiques de l'aplicació poden ser
emmagatzemats en la memòria RAM i sense eliminar-les correctament quan l'usuari tanca la
sessió o els temps d'espera de la sessió a finalitzat. Les claus de xifrat poden romandre en la
memòria, per tant un atacant que es troba o roba el dispositiu, pot adjuntar un depurador i
bolcar la memòria de l'aplicació o carregar un mòdul del nucli per bolcar tot el contingut de la
RAM.
La gestió de contrasenyes i altres informacions sensibles de les aplicacions poden quedar
emmagatzemades en memòria, fins i tot si la memòria intermitja s'allibera durant algun temps.
Això pot crear un problema, si l'aplicació instal·lada realitza un atac al dispositiu utilitzant la
tècnica de desbordament de memòria intermitja (produint una fuga de dades). Aquest tipus
d’atac dona la capacitat a un atacant de bolcar la memòria del procés i recuperar les dades
sensibles emmagatzemades en la memòria. Les solucions per protegir el dispositiu contra
aquest tipus d’atac són: no mantenir les dades sensibles (per exemple, claus de xifrat) en la
memòria RAM més temps del necessari, anul·lar les variables que posseeixen les claus després
del seu ús, evitar l'ús d'objectes immutables de tecles sensibles o contrasenyes (com ara en
Android java.lang.String) i l'ús de matriu de caràcters al seu lloc. Encara que es referenciés els
objectes immutables, s'eliminin o anul·lin, poden romandre en la memòria fins l’esborrat total
d’aquests (que no pot ser forçat per l'aplicació).
Això es pot fer només pels llenguatges de baix nivell a causa que els compiladors i
màquines virtuals ignoraran aquestes operacions per raons de rendiment.
8.6 Comprovar la correcta eliminació segura de dades
En Android trucant File.delete () no esborra de manera segura l'arxiu de destí, una
arxiu sempre que no es sobreescrigui, pot ser recuperat en una imatge física del dispositiu.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 80
Tradicionalment els enfocaments per esborrar un arxiu generalment no funcionen en els
dispositius mòbils a causa de l'agressiva gestió de la memòria Flash NAND. La solució per
realitzar aquesta acció és operar sota el supòsit que les dades gravades en un dispositiu es
poden recuperar. Alguns casos, el xifrat podria afegir una capa addicional de protecció. A més ,
no es recomana per a la majoria de les aplicacions, la possible eliminació dels arxius i per tant
s’ha de sobreescriure tot l'espai disponible amb un arxiu de grans dimensions (el que obligaria
que NAND tingui que esborrar tot l'espai no assignat). Els inconvenients d'aquesta tècnica
inclouen el desgast Flash NAND, fent que l'aplicació i tot el dispositiu responguin lentament, a
més de que el consum d'energia sigui significatiu. Sempre que sigui possible, s’ha d’evitar
l'emmagatzematge de dades confidencials en el dispositiu i el xifrat de les dades confidencials
emmagatzemades en arxius, s’ha de reescriure el contingut del fitxer i sincronitzar-se abans
d'esborrar-se, però com s'ha descrit anteriorment, no són solucions totalment fiables per
solucionar el problema.
8.7 Evitar la cadena de consulta de les dades sensibles
Una vulnerabilitat important és produeix en l’execució d’una cadena de consulta senzilla
modificada. Els paràmetres de cadena de consulta són més visibles i amb freqüència es poden
emmagatzemar en memòria cau de forma inesperada (historial web, servidor web o un
servidor intermediari de registres, etc.) utilitzant una cadena de consulta. Per aquesta raó
aquest conjunt significatiu de dades s’han de xifrar. Si les credencials es transmeten com a
paràmetres de cadena de consulta (a diferència d'una sol·licitud POST que es realitza en el cos)
llavors aquestes són susceptibles d'estar connectades a diversos llocs.
Per exemple, en l’històrial del navegador de l'usuari, al servidor web, OGS, i dins dels proxies
inversos utilitzats dins de la infraestructura d'allotjament. Si un atacant aconsegueix
comprometre qualsevol d'aquests recursos, llavors pot ser capaç d’escalar privilegis mitjançant
la captura de les credencials d'usuari emmagatzemats allà. Per solucionar aquesta situació,
s’ha de fer l’ús del POST de manera segura i enviar les dades de l'usuari utilitzant tècniques
com XSRF amb protecció de testimoni. Les dades posteriors no són connectades per defecte en
àrees on les dades de cadena de consulta es poden trobar. POST o GET, s'han d'utilitzar
conjuntament amb les galetes de sessió temporals. El xifrat de dades utilitzant un no-zero amb
un vector d'inicialització i claus de sessió temporals, també poden ajudar a prevenir atacs de
reproducció. Les dades de la cadena de consulta poden ser encriptades utilitzant una clau de
sessió negociada temporalment entre els hosts que fan servir algoritmes de seguretat, com ara
Diffie-Hellman.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 81
8.8 Implementar emmagatzematge segur de dades
L'emmagatzematge de dades de forma segura en un dispositiu mòbil requereix una tècnica
adequada. Quan sigui possible, simplement no s’han d’emmagatzemar dades en la memòria
cau (aquesta és la manera més segura d'evitar riscos de dades en el dispositiu). Per tant,
sempre s’han de xifrar les dades de l'usuari, l'objectiu de xifrar utilitzant un clau mestre
generada de forma aleatòria, fa que també es xifrin utilitzant una contrasenya subministrada
per l'usuari cada vegada que les dades son visitades. Això evitarà que les dades siguin
recuperades amb facilitat mitjançant el dispositiu. (no es recomana que la clau principal o una
contrasenya s'emmagatzemi en el dispositiu).
8.9. S’ha d’utilitzar un entorn segur per a les cookies
Si una galeta no està marcada com "segur", pot ser transmesa a través d'una connexió
insegura sigui o no la sessió amb el host segur. En altres paraules, pot ser transmesa a través
d'una connexió HTTP. A més, l'establiment de l'indicador "HttpOnly" en una galeta prevé atacs
com cross-site scripting (XSS), a causa de que la galeta no es pot accedir a través del costat del
client (per exemple, no es pot accedir utilitzant un fragment de codi JavaScript). Per solucionar
aquesta situació, s’ha de posar en les capçaleres Set-Cookie per utilitzar la configuració en
mode "segur" i "HttpOnly". Aquests ajustos s'han d'aplicar a totes les galetes per les
aplicacions natives i / o web.
8.10 Validar totalment SSL / TLS
Moltes aplicacions no validen correctament els certificats SSL / TLS, deixant-los vulnerables a
atacs man-in-the-middle (MITM). Si una aplicació no pot validar correctament la seva
connexió al servidor, l'aplicació és susceptible a un atac MITM per un atacant de xarxa
privilegiada. Aquest tipus d'atac dóna a l’atacant la capacitat de capturar, veure i modificar el
tràfic enviat/rebut entre l'aplicació i el servidor.
Per solucionar aquesta situació, s’ha de fer que per a qualsevol aplicació que fagi servir les
dades altament sensibles, certificar el seu ús per protegir-les contra atacs MITM. La majoria de
les aplicacions estan definides conjuntament amb els llocs als quals s’han de connectar
(servidors de back-end) de manera inherentment i confiant en la infraestructura en la qual es
connecten, per tant, és acceptable (i, sovint més segur) utilitzar una infraestructura de clau
pública/privada, separant-les de les autoritats de certificació públiques. Amb aquest
enfocament, un atacant necessita TH i les claus privades del costat del servidor per dur a terme
un atac MITM contra un dispositiu del qual no es tingui accés físic. Les claus del certificat no
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 82
han de ser implementades per qualsevol funcionalitat de l’aplicació, ja que, fa servir les dades
altament sensibles. Per tant, s’ha d’aplicar el certificat adequat realitzant una correcta
validació d’aquests, que consta de dues parts:
1- Validació del certificat: Aquests Certificats han d'estar completament validats per
l'aplicació i estar signats per una autoritat de certificació de confiança.
2- Validació de nom d'amfitrió: L'aplicació ha de comprovar i verificar que el nom
d'amfitrió (Common Nom o CN) extret del certificat, no coincideix amb el del host i la
l’aplicació que té la intenció de comunicar.
La utilització dels certificats a un client HTTP Apache per defecte inclòs en Android, consisteix
en l'obtenció d'un certificat per al host desitjat, transformant el CERT en format .bks, llavors
s’ha de fixar el CERT a una instància de DefaultHttpClient. BKS té un magatzem de claus que
inclouen normalment els actius dins del l'arxiu APK de l'aplicació.
8.11 Protegir contra atacas downgrade SSL
Utilitzant la tècnica man-in-the-middle, un atacant pot evitar SSL / TLS transparent i segrestar
el trànsit HTTP en una xarxa, a més de realitzar un control del seguiment de les sol·licituds
HTTPS, l'eliminació de SSL / TLS crea una connexió no segura entre el client i el servidor.
Aquest atac pot ser particularment difícil de prevenir en aplicacions web mòbils (Aplicacions
web mòbils són essencialment pàgines web fetes per semblar-se a una aplicació). Per
solucionar aquest cas s’ha de ridereccionar tot el trànsit, fins i tot, el trànsit no sensible a
través d'TLS. Això evita qualsevol possible atac de downgrade o d'extracció, ja que, un atacant
necessita un text clar "punt d'entrada" inicial per dur a terme aquest atac. Per tant, s’ha de
validar que SSL / TLS està actiu. La validació de SSL / TLS és relativament senzilla en aplicacions
natives. Les aplicacions web mòbils poden validar SSL / TLS a través de JavaScript de manera
que si una connexió HTTPS no es detecta, el client seà redirigit.
Evitar l'ús d'icones o llenguatge dins de l'aplicació, garanteix que els usuaris d'una connexió
segura no depengui d'una sessió HTTPS validada. La formació d'usuaris és un component
important per reduir el risc d'atacs de downgrade SSL / TLS , a més de la utilització d’ alertes i
textos dins de l'aplicació, reforcen la conscienciació dels usuaris de la importància de protegir
el transit de la xarxa a través de HTTPS.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 83
8.12 Protecció del tractament de dades geològiques
Android pot utilitzar el GPS per determinar amb precisió la ubicació de l’usuari que utilitza
l’aplicatiu. El mal maneig d'aquest GPS de dades és un problema de privacitat i pot fer que
l'usuari vulnerable pateixi algun tipus d’atac si aquestes dades són adquirides per part d’un
atacant coneixent les ubicacions actuals o passades de la victima. La Informació sobre
Bluetooth local i/ o etiquetes NFC / RFID també poden filtrar informació de geolocalització.
A més, les aplicacions amb accés a la galeria d'imatges també poden impedir que els
posicionaments dels GPS emmagatzemin informació en ells (si existeix), mitjançant la
comprovació de les marques de temps i suposant que l'usuari va ser l’autor de la foto,
provocant un problema de privacitat per a l'usuari.
S’ha de pensar en les implicacions d’ús i evitar l'emmagatzematge de dades GPS. Aquesta
mesura permet adquirir una augment en la protecció de l’intimidat de dades sensibles que
utilitzen la majoria dels serveis de localització. Llevat que sigui necessari, no s’han de registrar
o emmagatzemar aquesta informació provinent del GPS. Mentre que pot ser útil l'ús de GPS
per a certes aplicacions, és rarament necessari enregistrar i emmagatzemar aquest tipus de
dades. Evitar això evita vulnerabilitats de privacitat i seguretat.
8.13 Insertar temporització de la sessió local en l’aplicatiu
Els dispositius mòbils són freqüentment robats o perduts, un atacant pot prendre avantatge
d'una sessió activa per accedir a dades sensibles, executar transaccions, o realitzar
reconeixement en els comptes d'usuari d'un dispositiu. A més, sense una sessió apropiada amb
temps d'espera, una aplicació pot ser susceptible a la intercepció de dades a través d'un atac
Man-in-The-Middle. Per protegir l’aplicació, s’ha de fer que quan aquesta no s’utilitza durant
més de 5 minuts, finalitzi la sessió activa, i redirigeixi l'usuari a la pantalla de registre fent que
l’usuari tingui que introduir les credencials d'accés per accedir a l'aplicació de nou.
8.14 Implementar autentificació Enhanced / Two-Factor
L'autenticació feble o inexistent pot concedir a un atacant l'accés no autoritzat a una aplicació.
Per protegir l’aplicació, s’ha de fer que les contrasenyes no siguin simples. La millor manera és
demanar la introducció de contrasenyes complexes i alfanumèriques, dotant-les almenys de sis
caràcters (més caràcters és sempre més forta). Exigir la selecció d'una paraula secreta o icona
com a part del procés d'inici de sessió pot ajudar a protegir els comptes dels usuaris.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 84
Hi han altres tipus d’autentificació a part de la clàssica (nom i contrasenya) que pot dificultar
els atacs com:
1- Paraula secreta addicional / icona.
2- Codi addicional proporcionat per SMS o correu electrònic.
3- Contrasenya més valor addicional conegut per l’ usuari,
4- Preguntes i respostes de seguretat, seleccionades per l'usuari amb antelació (per
exemple, durant el registre).
8.15 Protegir la configuració de l'aplicació
Els desenvolupadors d'Android solen emmagatzemar els ajustaments en un arxiu XML
compartit o preferències com les base de dades de SQLite, les quals estan encriptades per
defecte i poden ser llegides o fins i tot modificades amb permisos de root.
Per solucionar aquest problema, s’ha de compilar els ajustos en el codi quan sigui possible i
xifrar tots els fitxers de configuració mitjançant una connexió clau mestra conjuntament amb
la contrasenya xifrada, la qual ha de ser subministrada per l'usuari o amb una clau
proporcionada de forma remota quan un usuari es registrat en el sistema.
8.16 Amagar números de compte i l’ús de tokens
Moltes aplicacions emmagatzemen números de compte complets en diverses pantalles. per
solucionar-ho, s’ha de donar l'ús generalitzat d'aplicacions mòbils en llocs públics, on es
presenten els números parcials, això pot ajudar a garantir la màxima privacitat per obtenir
aquesta informació (Llevat que hi hagi una necessitat d'emmagatzemar el nombre complet en
el dispositiu, ja que, s’han de guardar els números parcialment ocults).
Sovint, els números de compte s'utilitzen per fer referència a les dades del compte al servidor;
Aquestes dades poden ser fàcilment robades de la memòria, o en alguns casos manipulades
per treballar amb els comptes que l'usuari no ha de tenir permís d'accés. Es recomana que en
lloc de números de compte, s’utilitzin tokens que poden assignar-se a cada compte i
proporcionar al client més seguretat.
Aquests tokens, que no han de ser deduïbles per l'usuari, han de ser mapatjats en el servidor
per a una compte real. En cas de ser robades les dades de l’aplicació, els números de compte
de l'usuari no seran exposats, per tant, un atacant tampoc serà capaç de fer referència als
números de compte directament, sinó que ha de determinar en primer lloc el símbol que
s'assigna al compte.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 85
8.17 Validar els valors de dades entrats pels usuaris
Els aplicatius generen dades que són emmagatzemades, això fa possible que aquestes dades
hagin estat interceptades i manipulades per atacants, aquest fet és la causa del tancament de
l'aplicació (generen un registre de clau de bloqueig), desbordaments de memòria intermitja,
injecció SQL, i altres atacs. Per aquesta raó, igual que amb la seguretat d'aplicacions web, tota
entrada des del client ha de ser tractada com a no fiable i per tant validar que el contingut
d’aquestes dades siguin el desitjats. Per aquesta raó els serveis han de filtrar a fons i validar
l'entrada de l'aplicació, a més de realitzar una desinfecció adequada de les dades introduïdes
per l'usuari abans de transmetre-les durant la recepció d’aquestes.
8.18 Evitar l'emmagatzematge de dades en l'aplicació de còpies de seguretat
La realització d'una còpia de seguretat de les dades en un dispositiu Android és potencialment
perillós, ja que, aquestes còpies de seguretat emmagatzemen informació sensible dins el
directori privat d'una aplicació. Per solucionar això, el programadors han de posar per defecte
el paràmetre allowBackup dins del fitxer del manifest (AndroidManisfest.xml) amb el valor de
false, ja que, si aquest atribut no té aquest valor, el sistema operatiu Android genera un fitxer
de còpia de seguretat (backup.ab) el qual inclou tots els subdirectoris i arxius continguts dins
el directori privat d'una aplicació en el sistema de fitxers del dispositiu.
8.19 Evitar tenir els registres logs habilitats en l’aplicatiu
Hi ha diversos frameworks de seguiment de funcionament de l’aplicatiu Android per part de
l'usuari, el quals recullen els registres de fallades d’Android, aquestes eines són molt útils per
al desenvolupament, però és important trobar un balanç entre mostrar suficient informació de
depuració per als desenvolupadors i la informació per a la reducció de possibles atacs. Si una
aplicació es bloqueja, el registre resultant pot proporcionar una valuosa informació a un
atacant. Per tant, per evitar aquesta vulnerabilitat s’ha d’assegurar que les aplicacions
publicades es construeixen sense advertiments i es provisionin a fons per evitar accidents.
Aquest test, sens dubte sempre s’ha de realitzar a causa del valor d'una registre de bloqueig.
Una altra mesura important és evitar l'enviament de registres d'errors a la xarxa de text
simple.
8.20 Tenir un control de registres de depuració generats per l’aplicatiu
Els registres de depuració estan dissenyats generalment per a ser utilitzats per detectar
defectes en una aplicació. Aquests registres poden tenir fuites d'informació sensibles que pot
ajudar a un atacant a crear atacs més poderosos. Per solucionar aquesta situació els
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 86
desenvolupadors han de tenir en compte el risc que els registres de depuració poden plantejar
en un entorn de producció.
S’ha de desactivar en producció el registre del sistema Android, el qual és utilitzat per
aplicacions per donar sortida als missatges de depuració mitjançant un buffer circular d'uns
pocs kilobytes emmagatzemats en la memòria. També pot ser possible recuperar registres de
depuració del sistema d'arxius en el cas d'una emergència en el nucli. En les versions més
recents dels arxius de registre d'Android han estat més acuradament aïllats i no requereixen
permisos de nivell de sistema.
En Android també es pot aprofitar Proguard o DexGuard per eliminar del tot el mètode de
crida a la classe de registre en les versions de llançament, eliminant així totes les trucades a
Log d’Entrada.
8.21 S’ha de ser conscient de la funcionalitat de copiar i enganxar en Android
Android suporta la funcionalitat de copy/paste. Les dades sensibles poden emmagatzemar-se,
recuperar-se o fins i tot podrien ser modificades des del porta-papers en text clar
independentment de si la font de les dades es xifren inicialment o no. Si és en text pla en el
moment en què l'usuari realitzi el copy, ho farà en text pla quan altres aplicacions accedeixin al
porta-papers. .
Això vol dir, que les aplicacions no poden ser d’escriptura el porta-papers, i l'única manera
d'utilitzar-les és mitjançant la interacció de l'usuari, fent llargues derivacions al menú del
porta-papers. Per solucionar aquest fet, s’ha de desactivar la funcionalitat de copy i paste per
al maneig de dades sensibles. La deshabilitació d’aquesta opció, pot ajudar ha evitar l'exposició
de les dades. En Android al porta-papers pot ser accedit per qualsevol aplicació i així es
recomana que es configuri apropiadament el seu contingut.
8.22 Implementació de Intents amb un control exhaustiu
Intents s'utilitzen per a la senyalització entre components i es poden utilitzar per:
1. Per iniciar una activitat, generalment l'obertura d'una interfície d'usuari per a una
aplicació.
2. Com transmissions per informar al sistema i aplicacions dels canvis.
3. Per iniciar, aturar, i comunicar-se amb un servei en segon pla.
4. Per accedir a les dades a través ContentProviders.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 87
5. Com a devolucions de trucades de gestió d’esdeveniments (una aplicació incorrecta
pot causar la pèrdua de dades i funcions restringides sent el carrer del flux del
programa el que està sent manipulat).
L’aplicació incorrecta dels intents pot causar la pèrdua de dades, funcions restringides sense
retorn i el mal flux del programa que està sent manipulat.
Per solucionar aquesta problemàtica s’ha de seguir les següents recomanacions:
1. Els components els qual s'accedeix a través d’intents poden ser públics o privats. El
valor per defecte depèn del filtre i és fàcil permetre erròniament habilitar el
component com a públic sent privat (establint el component androide: exported =
false a l'App Manifest per evitar aquesta situació).
2. Els components públics declarats en el manifest per defecte són oberts per a qualsevol
aplicació la qual pot accedir-hi. Un component no té perquè ser visitat per totes les
altres aplicacions, considerar l'establiment de permisos per al component declarat en
el manifest mitiga aquesta situació.
3. Les dades rebudes dels components públics no es poden confiar i han de ser
examinades.
8.23 Verificar el correcta funcionament de les activitats (activities) dissenyades
En les aplicacions Android una activitat és una "pantalla".
Una activitat pot ser invocada per qualsevol aplicació, permetent a un atacant carregar
elements de la IU d’una manera què el desenvolupador pot no pretendre, com saltar més enllà
d'una pantalla de bloqueig de contrasenya per accedir a dades o funcionalitats. Ens les
activitats s’ha definir un filtre d'Intenció per a una activitat que sense ell no pugui ser
exportada pel sistema.
Per tant, les activitats han de garantir un comportament adequat mitjançant la comprovació
d'estat de l'aplicació interna per verificar que estan disponibles per ser carregades. Per
exemple, veure primer si l'aplicació està en l'estat "desbloquejat" i si torna a la pantalla de
bloqueig. Independentment del que els filtres d'Intenció es defineixen, les activitats es poden
invocar directament amb les dades, de manera que la validació d'entrada és recomanada quan
s'opera en les dades proporcionades per una font no fiable.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 88
8.24 Utilització de broadcast amb cura
Si no hi ha permís, s'estableix quan s'envia un Intent de difusió, llavors qualsevol aplicació
sense privilegis pot rebre el “intent” llevat que tingui una destinació explícita. Un atacant
podria aprofitar un intent que no té cap permís de la següent manera:
1. Crear una aplicació maliciosa que inclou un component amb el mateix nom que un
component legítim.
2. Mentre que el nom (o espai de noms) no està ja en ús, l'aplicació maliciosa s’instal·la
en el dispositiu de destinació.
3. Extreure informació confidencial de l’intent de difusió enviat amb aquest nom de
component “?”.
Per solucionar aquestes possibilitats esmentades anteriorment, s’han d’utilitzar permisos per
protegir els Intents en l’aplicació. S’ha de tenir en compte que a l'enviar informació a través
d'un Intent de difusió a un component de tercers, aquest component podria haver estat
substituït per una instal·lació maliciosa.
8.25 Implementació de pendingintents amb cura
Un PendingIntent permet a una aplicació passar un Intent d'una segona aplicació, que més
endavant pot ser executat com si es tractés de l'aplicació d'origen (amb idèntics permisos).
Aquest permet a altres aplicacions tornar a cridar els components particulars de l'aplicació
d'origen. L’aplicació externa, si és maliciosa, pot tractar d'influir en la destinació e integritat de
les dades. Per evitar això, s’ha d’utilitzar els PendingIntents com a devolucions de trucada
retardada a BroadcastReceivers com a privades o emissions d’activitats, i per tant s’ha d’
especificar explícitament el nom del component a la base de l’intent.
8.26 Protegir els serveis d'aplicacions.
Els serveis s'utilitzen normalment per al processament en segon pla. Igual que
BroadcastReceivers i les activitats de les aplicacions, els serveis d'aplicacions poden ser
invocats per aplicacions externes i per tant han de ser protegides pels permisos d'exportació.
Una solució és quan es crida un servei amb dades sensibles, s’ha de validar que el servei és
correcte, és a dir, no pot ser un servei malintencionat. Si es té coneixement del nom exacte
del component del qual es vol connectar, s’ha d’especificar aquest nom en el intent utilitzat
per connectar. Un altre mètode que pot utilitzar és el checkPermission () , el qual serveix per
comprovar els permisos del paquet necessaris per rebre el intent desitjat. Aquests permisos els
concedeix l’usuari durant la instal·lació de l’aplicatiu.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 89
8.27 Realitzar bones pràctiques del webview en els aplicatius Android
Un WebViews pot introduir un nombre de problemes de seguretat, i s'ha d'aplicar
acuradament. En particular, una sèrie de vulnerabilitats explotables derivades de la utilització
de la API addJavscriptInterface s'han descobert, per evitar aquesta vulnerabilitat s’ha de
desactivar el suport de JavaScript i Plugin si no són necessaris. Si bé totes dues estan
desactivades per defecte, les millors pràctiques s’utilitzen per desactivar els fitxers locals. Això
restringeix l'accés al directori i mitiga els recursos actius de l'aplicació, generant protecció
contra atacs des d'una pàgina web amb la finalitat de tenir accés a una altre a nivell local a
través dels arxius accessibles. Una altre solució, és no permetre la càrrega del contingut dels
amfitrions de tercers. Això pot ser difícil d’aconseguir dins de l'aplicació. No obstant això, un
desenvolupador pot anul·lar el shouldOverrideUrlLoading i shouldInterceptRequest per
interceptar, inspeccionar i validar la majoria de les sol·licituds iniciades des de dins d'un
WebView. Un desenvolupador també pot considerar la implementació d'un esquema de llista
blanca utilitzant la classe URI, amb la finalitat d’inspeccionar els components d'un URI per
assegurar-se que coincideix amb una entrada d’una llista dels recursos aprovats.
8.28 Evitar l'emmagatzematge d'imatges de la càmera en memòria cau
Les aplicacions de comprovació remota de dipòsit permeten a una persona prendre una
imatge d'un xec amb el seu mòbil amb la càmera del telèfon i després enviar la imatge a la
seva institució financera per al seu dipòsit. Això té una problemàtica i és que moltes d'aquestes
aplicacions conservaran la imatge de verificació (o part d'ella) en la memòria NAND del
dispositiu mòbil, fins i tot després que s'elimini.
Per solucionar això, s’ha d’evitar transmetre una imatge de verificació mitjançant
l'emmagatzematge no volàtil del dispositiu, a continuació s’explica una possible alternativa:
1. Crear un SurfaceView que mostri una vista prèvia de la càmera o la vista prèvia en viu
del sensor de la càmera que està funcionant.
2. Inserir i programar un botó que permeti torna la vista prèvia de la càmera com una
matriu de píxels.
3. Finalment, convertir la matriu de píxels de mapa de bits, comprimir a un .jpg, codificar
a Base64 i enviar-lo a la localització remota.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 90
8.29 Els desenvolupadors sempre han de signar els arxius APK
Els arxius APK han d'estar correctament signats amb un certificat no caducat, per evitar això
s’ha de seguir els següents passos:
1. Signar una aplicació de producció amb un certificat de producció, no un certificat de
depuració.
2. Assegurar que el certificat inclou un període suficient de validesa (és a dir, no es expiri
durant la vida útil esperada de l'aplicació).
3. Google recomana que utilitzi el seu certificat com a mínim de 2048 bits de xifrat.
4. Assegurar que el magatzem de claus que conté la clau de signatura es protegeix
adequadament.
5. També, restringir l'accés al magatzem de claus que només aquelles persones que la
requereixen absolutament.
8.30 Funcions de seguretat integrades en el sistema operatiu Android
Android té funcions de seguretat integrades en el sistema operatiu que redueixen
notablement la freqüència i l'impacte dels problemes de seguretat de l'app. El sistema està
dissenyat de manera que es puguin compilar les apps amb permisos per defecte del sistema
d'arxius i evitar haver de prendre decisions difícils sobre seguretat.
Entre algunes de les funcions de seguretat principals que poden ajudar els desenvolupadors a
compilar apps segures s'inclouen les següents:
Durant l’implementació d’una aplicació Android, s’ha d’utilitzar una zona de proves
d'aplicacions, la qual aïlli les dades sensibles i l'execució de codi de l’app de les altres
apps.
S’ha de realitzar la utilització de framework d'aplicacions amb implementacions amb
funcionalitats sòlides de seguretat, utilitzant tècniques de criptografia, permisos ,IPC
segura i d’altres que es puguin implementar.
Les tecnologies com ASLR, NX, ProPolice, safe_iop, OpenBSD dlmalloc, OpenBSD calloc
i Linux mmap_min_addr , són tecnologies que els desenvolupadors han de tenir en
compte per mitigar riscos associats amb errors comuns d'administració de memòria i
d’altres.
Un desenvolupador ha de tenir un sistema d'arxius encriptat que pugui ser habilitat
per protegir les dades en dispositius perduts o robats.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 91
Per seguritzar l’aplicatiu a desenvolupar, el desenvolupador ha de tenir molt clar els
permisos que seran otorgats a cada usuari per restringir l'accés a funcions del sistema
i dades que només han de tenir accés els usuaris autoritzats.
En la configuració de la app, el desenvolupador a de definir els permisos de la
aplicació para controlar l’accés els recursos de l’app com accés internet, bluetooth ,
càmera i altres funcionalitats que puguin tenir els dispositius per aquesta plataforma.
8.31 Permisos en aplicacions Android
En el moment que els desenvolupadors implementin els permisos en l’aplicació, aquest ha de
minimitzar la quantitat de permisos que la app sol·liciti. La manca d'accés a permisos sensibles
redueix el risc d'utilitzar aquests permisos de forma inadvertida i errònia, pot millorar la
captació d'usuaris i fa que la app sigui menys vulnerable pels atacants. En general, si no es
requereix un permís perquè la app funcioni, no s’ha d’insertar.
Una recomanació, és que els desenvolupadors poden dissenyar l’aplicació de manera que no
requereixi permisos, cosa que es molt recomanable i redueix la possibilitat que l’aplicatiu sigui
vulnerable atacs. Per exemple, en lloc de sol·licitar accés a informació del dispositiu per crear
un identificador únic, s’ha de crear un únic GUID per l’aplicació. Com a alternativa, els
programadors en lloc d'utilitzar l’emmagatzematge extern (que requereix permís declarat en el
AndroidManifest), poden guardar aquestes dades en l'emmagatzematge intern.
A més de sol·licitar permisos, l’aplicació pot utilitzar <permissions> per protegir IPC que
comporti riscos de seguretat i s’exposi a altres aplicacions, com el ContentProvider. En general,
es recomana que els desenvolupadors utilitzin controls d'accés que no siguin permisos
confirmats pels usuaris quan sigui possible, ja que, aquests poden resultar confusos. Per
exemple, els programadors han de considerar fer servir el nivell de protecció de signatura,
mitjançant els permisos de comunicació IPC utilitzats entre aplicacions ofertes per un mateix
desenvolupador.
Els desenvolupadors en tot moment han d’evitar permetre fuites de dades protegides amb
permisos. Això passa quan l’app s’exposa, a través d'IPC, a dades que són accessibles perquè
l’app té permíssos per accedir-hi. No és recomanable que els usuaris de la interfície IPC de
l’app, no tinguin aquest mateix permís d'accés a les dades.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 92
8.32 Seguretat en l’utilització de xarxa en aplicatius Android
Les transaccions en xarxa són, per naturalesa, perilloses per a la seguretat, ja que inclouen la
transmissió de dades de l'usuari que podrien ser privades. Els usuaris són cada vegada més
conscients dels problemes de seguretat d'un dispositiu mòbil, especialment quan el dispositiu
realitza transaccions en xarxa, per la qual cosa és molt important que els desenvolupadors
implementin totes les pràctiques recomanades per protegir la seguretat de les dades de
l'usuari en tot moment.
8.33 Ús de criptografia en aplicacions Android
A més de proporcionar aïllament de dades, habilitar l'encriptació per part del programador en
tot el sistema d'arxius i proporcionar canals de comunicació segurs, genera una àmplia
varietat d'algoritmes per protegir les dades que fan servir criptografia.
En general, el desenvolupador ha de fer servir el nivell més alt d'implementació de framework
preexistent que pugui admetre el cas d'ús. Si aquests necessités recuperar de forma segura un
arxiu d'una ubicació coneguda, un simple URI HTTPS pot ser adequat i no requereix
coneixements de criptografia. Si el desenvolupador necessités un túnel segur, ha de considerar
utilitzar HttpsURLConnection o SSLSocket, en lloc d'escriure el seu propi protocol.
Si el desenvolupador té coneixement que no necessita implementar el seu propi protocol, es
recomana que no realitzi els seus propis algoritmes criptogràfics. És millor que els
desenvolupadors utilitzin algorismes existents i que ja s’han comprovat la seva eficàcia, com
per exemple algoritmes criptogràfics existents com els de la implementació d'AES o RSA,
proporcionats a la classe Cipher.
El desenvolupador ha d’utilitzar un generador de nombres aleatoris segur, SecureRandom, per
inicialitzar les claus criptogràfiques, KeyGenerator. L'utilització d'una clau que ha sigut
generada amb un generador de nombres aleatoris segur, debilitarà notablement la protecció
de l'algoritme i podria permetre atacs sense connexió. Si s’ha d’ emmagatzemar una clau per
tornar a utilitzar-la, el desenvolupador ha d’utilitzar un mecanisme com keystore, el qual
proporciona un mecanisme per a l'emmagatzematge i la recuperació de claus criptogràfiques.
8.34 Seguretat de càrrega dinàmica de codi en Android
No es recomana carregar codi des de fora de l'APK de l’aplicació. Fer-ho augmenta
notablement les probabilitats que es comprometi l'aplicació per la inserció o manipulació de
codi. També suma complexitat a l'administració de versions i la prova d'aplicacions. Finalment,
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 93
pot impossibilitar la verificació del comportament d'una aplicació, per la qual cosa podria estar
prohibida en alguns entorns.
Si l’aplicació implementada pel desenvolupador càrrega codi de forma dinàmica, el més
important que s’ha de recordar sobre el codi carregat dinàmicament, és que s'executi
conjuntament amb els mateixos permisos de seguretat que el APK de l'aplicació. L'usuari ha de
prendre la decisió d'instal·lar l’aplicació en funció de la identitat, i esperar que se li proporcioni
tot el codi necessari en l'aplicació, inclòs el codi de càrrega dinàmica.
El principal risc de seguretat associat amb la càrrega dinàmica de codi , és que aquest ha de
provenir d'una font verificable. Si els mòduls s'inclouen directament en l’aplicatiu APK, no
podran modificar-se a través d'altres aplicacions. Això és així, independentment que el codi
sigui una biblioteca nativa o una classe carregada amb DexClassLoader.
Hi ha moltes instàncies d'aplicacions que intenten carregar codi de fonts insegures, com a codi
descarregat de la xarxa mitjançant protocols sense xifrar o d'ubicacions que admeten
escriptura pública, com a mitjans d'emmagatzematge extern. Aquestes ubicacions podrien
permetre que algú a la xarxa modifiqui el contingut en trànsit, o que una altra aplicació del
dispositiu de l'usuari modifiqui el contingut en el dispositiu, respectivament.
8.35 Utilizació de programari lliure per millorar la seguretat
El programari antivirus Smartphone Android està disponible i és molt recomanable a causa del
mercat obert per Android Apps. S’ha de recordar que han aparegut falses aplicacions anti-
malware, per tant, s’ha de tenir constància que aquests aplicatius han estat descarregats des
del lloc del fabricant i no des de fons desconegudes, evitant instal·lar malware en el dipositiu.
Els antivirus que es poden utilitzar per augmentar la seguretat en els dipositiu mòbils són els
següents:
1. Free Antivirus: Antivirus gratuït per Android.
2. AVG Antivirus: Dóna seguretat mòbil lliure i antivirus per Android .
3. DR. Web Anti-virus Light : Antivirus gratuït per Android GuardX.
4. GuardX: Programari lliure d’antivirus per Android Lookout.
5. Lookout: Seguretat mòbil i antivirus per Android Norton Mobile Security.
6. Norton Mobile Security: Seguretat mòbil lliure i antivirus per telèfons Android ( l’aplicació
és gratuïta per mòbils i tablets).
7. Webroot Secure Mobile: Aplicació de seguretat per telèfons Android .
8. Orbot: Millora la privacitat amb comunicacions més segures.
9. WhisperCore: Proporciona xifrat i tallafocs d'aplicacions per Android.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 94
9. EINES D’ANDROID INCLOSES EN EL PROGRAMARI PER ANALITZAR I
DESENVOLUPAR APLICACIONS ANDROID AMB SEGURETAT
En aquest apartat es descriuren diferents eines incloses en el programari de Android que els
desenvolupadors poden utilitzar per analitzar les aplicacions Android amb la finalitat de
fortificar la seguretat. Les tècniques poden ser tant dinàmiques com estàtiques, és possible
detectar un disseny de l'aplicació amb sobreprivilegis, i trobar patrons de comportament
maliciós o traça de dades d’usuaris com ara les credencials d'accés.
L'anàlisi dinàmic és el procés d'extracció de la desitjada informació en temps d'execució.
Aquest mètode requereix la simulació de l'entrada completa del domini de la sol·licitud
examinada per aconseguir una alta precisió en l'avaluació del comportament del programa o
per fer un seguiment amb èxit de les dades desitjades.
Per contra, l'anàlisi estàtic s'executa en el codi de bytes en brut. En general, una eina
automàtica s'executa a través de l'objectiu en el codi i dóna sortida a una aproximació del seu
flux de control i flux de dades. L’aproximació exactitud depèn dels algoritmes d'enginyeria
inversa utilitzats per el desenvolupador amb l'eina d'anàlisis, així s’obtenen maneres de
protecció i un análisis de la tècnica del codi i quin ha sigut el seu comportament a sometre-la
aquestes tècniques.
A continuació s'enumeneran algunes les eines internes d'anàlisis que es poden utilizar per
millorar la seguretat en els aplicatius Android.
• Dexdump: Inclòs com a part del SDK d'Android estàndard, aquest és el més fàcil accés
a l’eina per a la realització d'un desenvolupador de codi de bytes Dalvik per realizat el
desmuntatge dels aplicatius Android.El programador por utilizar aquest algoritme
d'anàlisi implementat per realizar escombrat lineal, és a dir, analitzar el codi de bytes i
esperar per cada instrucció la resposta i diagnostricar si té exit l’aplicació analitzada.
En el cas de codi no ofuscat el desmuntatge serà un èxit, però, una modificació en el
control de la complexitat del flux pot fallar el procés de recuperació.
• Dedexer: Una eina desensamblador d'arxius. La qual pot ser utilitzada pel
desenvolupador per emetre el codi de bytes recuperats en una Jasmin de sintaxi
similar.
• baksmali Un dels descompiladores Dalvik codi de bytes més populars. Conté alguns
dels més sofisticats algoritmes d'anàlisi subjacent, recorregut recursiu taxa de
recuperació de baksmali etc. La millora d’aquest algoritme cau en el fet que la següent
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 95
instrucció no ha de ser necessàriament immediatament seguint els salts de corrent, és
a dir, ha de ser un procés correctament codificat. No obstant això, aquest enfocament
només minimitza, però no elimina els efectes d'alguns dels fluxos de control. A causa
de la seva popularitat, és utilitzat per baksmali en múltiples eines d'enginyeria inversa
com un desensamblador de base, entre els quals també ésta apktool coneguda
• dex2jar: Una eina de conversió d'arxius binaris que pren com a entrada un arxiu i
genera un .dex, el seu corresponent arxiu .jar el qual conté els arxius .class extrets.
Mitjançant dex2jar i qualsevol decompilador Java com JAD JD-GUI el programador o
pot utilizar per veure el codi Font.
• radare2 Una eina de consola interactiva, tant pel desmuntatge i l'anàlisi del codi byte.
Aquesta habilita als programadors un control molt precís de les accions de l'usuari
respecte al procés de descompilació. Per a les funcions de codi de bytes específics, la
descompilació es realitza amb la integració de codi obert mitjançant el decompilador
bumerang.
A més de l'ús de recorregut recursiu, els programadors tenen la capacitat d’especificar
la descompilació a partir d'una direcció específica. A causa d'aquest híbrid
enfocament, algunes tècniques d'ofuscació que trenquen altres descompiladors són
reversibles amb radare2, però, no de manera automàtica.
• Androguard: Aquesta eina realitza un anàlisi i processament de l'eina de desmuntatge
tant de codi de bytes i Dalvik bytecode optimitzat. L'eina té tres descompiladors
diferents: TAT, i DED JAD. El qual s'utilitza per defecte és TAT que és també el més
ràpid a causa del fet que es tracta d'un decompilador de codi natiu. El seu algoritme
subjacent és recorregut de manera recursiva.
També Androguard conté una base de dades de codi obert gran en línia amb els
patrons de malware coneguts. Les característiques addicionals, com ara el
mesurament de l'eficiència ofuscadora comparant un programa amb la seva versió
ofuscada, la visualització de l'aplicació en forma de gràfics i permisos d'exploració
estan disponibles com guions independents els quals el desenvolupador pot utilizar
per analitzar l’aplicació.
• Dexter: És una eina d'anàlisi en línia del processament d'arxius APK i mostre un
conjunt de resultats entre els quals es destaquen: permisos definits i utilitzats en
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 96
l'aplicació, relació d’ofuscat enfront el codi no ofuscat, relació d'interior enfront de
paquets externs, receptors i proveïdors de contingut transmès. Aquesta eina també
permet els desenvolupadors la visualització gràfica de la sol·licitud i la llista completa
de cadenes utilitzades per l'aplicació. encara que la llibertat d'utilitzar és més limitat, ja
que, Dexter té el seu codi tancat a la banda del servidor i només es pot realizar
l'anàlisis exclusivament de manera estàtica
• Dexguard: És un conjunt de scripts actualment automatitzat amb fils d’ofuscació i
recuperació de l'arxiu de .dex. Aquesta eina té una enfocament híbrid d'anàlisi dinàmic
i estàtic i es compon de:
1. L'arxiu .dex lector.
2. Desensamblador Dalvik.
3. Emulador Dalvik.
4. Arxiu analitzador .dex.
• IDA Pro: És una eina més comercial que el desenvolupadors poden utilizar per realitzar
enginyeria inversa en múltiples arquitectures suportades. Té diverses característiques
com el gràfic del programa la visualització i el suport dels plug-ins el quals s’estenen en
la seva funcionalitat estàndard
10. EINES EXTERNES PER ANALITZAR I PROTEGIR APLICACIONS ANDROID +
En el punt anterior s’ha fet una descripció d’eines incloses en els programari de
desenvolupadment d’Android, les quals els desenvolupadors poden utilitzar per analitzar el
comportament i realitzar enginyeria inversa en aplicacions d’Android, a continuació en aquest
punt es farà una descripició d’eines externes que es poden utilitzar o incorporar per realitzar
l’anàlisi d’aplicacions Android, amb la finalitat de fortificar la seguretat d’aquestes, que són les
següents:
1. CuckooDroid: És una extensió de cucut Sandbox sent un programari de codi obert per
a l'automatització d'anàlisi d'arxius sospitosos de programari maliciós. Proporciona la
inspecció APK tant estàtica com dinàmica, així permet evadir certes tècniques com:
detecció d'entorn virtual, extracció de clau de xifrat, inspecció SSL, empremta de
trucada d'API, firmes bàsiques de comportament i moltes altres característiques. És
molt personalitzable i extensible aprofitant el poder de la gran comunitat de cucut
existent.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 97
2. Cuco Sandbox: És un sistema d'anàlisi de programari maliciós de codi obert. Aquesta
aplicació permet analitzar arxius sospitósos, proporcionant resultats detallats que
s’efectuen a l'executar-la dins d’un entorn aïllat.
Aquest lloc és la principal eina dels cibercriminals i dels principals ciberatacs en
organitzacions empresarials. En aquests temps la detenció i eliminació de programari
maliciós no és suficient, és de vital importància entendre com funcionen en els
sistemes quan es desplega, comprendre el context, les motivacions i els objectius de
l'atac, les quals poden ser analitzades pels desenvolupadors del món de la seguretat,
mitjançant aquesta eina.
Algunes dades que es poden obtenir mitjançant aquesta eina: són la violació interna
de codi, recol·lecció de dades processables i anàlisi de possibles amenaces. Cuckoo
genera diferentes dades que incluoen:
1. Les funcions natives i API de Windows anomenades petjades.
2. Les còpies dels arxius creats i eliminants del sistema de fitxers.
3. Volcat de la memòria del procés sel·leccionat.
4. Volcat complet de memòria de la màquina d’anàlisi.
5. Captures de pantalla de l’escriptori durant l’execució de l’anàlisi del malware.
6. Volcat de xarxa generat per la màquina que ha de ser utilitzada per l’anàlisi.
Amb la finalitat que els resultats siguin millor interpretats per els desenvolupadors,
Cuckoo es capaç de processar i generar diferents tipus d’informes, que podrían
incloure:
o Informe JSON.
o Informe HTML.
o Informe MAEC.
o Interfície de MongoDB.
o Interfície HPFeeds.
El mès interesant, és que gràcies a l’amplia estructura modular del Cuckoo, es
possible personalitzar tant el processament com la fase de presentació d’informes.
Cuckoo proporciona tots els requisits per integrar fàcilment un entorn aillat amb
els sistemes existents, amb les dades que es desitgin, de la manera que es vulguin i
amb el format demanat.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 98
3. AndroL4b: És una màquina virtual orientada als aspectes de seguretat en Android
basats en la companyia Ubuntu, que inclou la col·lecció dels últims marcs, tutorials i
laboratoris, de seguretat, per realitzar enginyeria inversa i anàlisi de programari
maliciós en aplicacions Android. Conté les següents eines i laboratoris:
APKStudio: És un IDE multiplataforma per a l'enginyeria inversa i
recompilació de binaris d'aplicacions Android, dins d'una sola Interfície
d'usuari. Compte amb un disseny amigable, amb un editor de codi que
suporta ressaltat de sintaxi per Android smali i arxius de codi (*
.smali).
ByteCodeViewer: És la suite d'enginyeria inversa d'aplicacions
Android, amb diferents descompiladors Java, Editors de Codi de bytes,
compiladors de Java i connectors específics.
Marc Mobile Security (MobSF): És una applicació de codi obert per a
Mòbils Android. Conté un marc capaç de realitzar l'anàlisi estàtic i
dinàmic (Només es té permès l'anàlisi estàtic en aquesta màquina
virtual). Pot ser utilitzat per a un anàlisi de seguretat d'aplicacions
eficaç i ràpid, a més és compatible amb els binaris (APK i IPA) i el codi
font comprimit.
MobSF també pot realitzar proves de seguretat amb l’utilització de
Fuzzer AP, el qual port fer de: Recull d'informació, anàlisi de capçaleres
de seguretat, identificar vulnerabilitats específiques de la API mòbil
com: la XXè, FRSS de traspàs de rutes, IDOR i altres qüestions lògiques
relacionades amb la sessió.
4. Dorzer: Permet realitzar recerques de vulnerabilitats de seguretat en aplicacions i
dispositius, assumint el paper d’una aplicació, permetent interaccionar amb la
màquina virtual Dalvik, els punts finals de l'IPC d'altres aplicacions i el sistema operatiu
subjacent.
5. APKtool: És una eina que s’utilitza en l'enginyeria inversa de binaris d'aplicacions
Android. Pot descodificar als recursos de manera gairebé originals i reconstruir-los,
després de fer algunes modificacions, a més, també és possible depurar codi smali pas
a pas. Aquesta eina facilita el treball amb l'estructura d'arxius en projectes i amb
l'automatització de tasques repetitives, algunes com la construcció d'Apk.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 99
6. Android Studio IDE: És un entorn de desenvolupament integrat (IDE) per al
desenvolupament d'aplicacions Android, basat en IntelliJ idea. Android Studio ofereix
característiques que milloren la productivitat i seguretat en la construcció d'aplicacions
Android.
7. ClassyShark: És una eina per a desenvolupadors Android, permetent navegar de
manera fiable a través d’arxius executables d’Android i mostrant Informació important
com: les interfícies de classe i dels membres, el recompte de Dex i dependències. A
més també, suporta múltiples formats incloent: biblioteques (.dex, .aar, .so),
executables (.apk, .jar, .class) i tots els binaris XMLS Android: AndroidManifest,
recursos, dissenys, etc.
8. BurpSuite: És una plataforma integrada per a la realització de proves de seguretat
d'aplicacions Web. La diversitat d’eines fa que funcioni perfectament donant la
capacitat de realitzar tot el procés de proves com: cartografia i anàlisi de la superfície
d'atac d’una petició inicial a través de la recerca i explotació de vulnerabilitats de
seguretat.
9. Wireshark: És l'analitzador de protocols de xarxa més important del món. Permet
veure el que està succeint en una xarxa analitzada. Sent utiitzat tant en la industria
com en institucions educatives.
10. MARA: És un conjunt d'eines comunament utilitzades en enginyeria inversa i anàlisi
d'aplicacions per mòbils sota els estàndards de OWASP.
11. FindBugs-IDEA: S’utilitza per a realitzar l’anàlisi estàtic de codi de bytes a la recerca de
fallades en el codi Java.
12. AndroBugs: És un escàner de vulnerabilitats de seguretat d'Android que permet als
desenvolupadors i pentesters cercar possibles vulnerabilitats de seguretat en
aplicacions d'Android.
13. Metasploit: És un projecte de codi obert de seguretat informàtica que proporciona
informació sobre vulnerabilitats de seguretat i ajuda en proves de penetració
"Pentesting" i el desenvolupament de signatures per a sistemes de detecció d'intrusos.
14. DIVA Android: És una apliació dissenyada expressament per ser insegura. L'objectiu
d’aquesta és ensenyar els desenvolupadors, defectes que generalment es troben
presents en les aplicacions, causades per pràctiques de codificació pobres o insegures.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 100
15. InsecureBankv2: És una aplicació Android feta per desenvolupadors de seguretat
informàtica per aprendre les inseguretats d'aplicacions d'android. El seu component
de servidor de fons esta escrit en Python.
16. DroidBench: És un conjunt de proves de codi obert per evaluar l’eficàcia de les eines
d'anàlisi específiques per a aplicacions d'Android. La Suite es pot utilitzar per evaluar
tant estàticament com dinàmicament. Però en concret, conté interessants casos de
prova per a problemes d'anàlisi estàtic (sensibilitat de camp, la sensibilitat d'objectes,
avantatges i desavantatges en les longituds de via d'accés, etc.), així com modelar
correctament el cicle de vida d'una aplicació, maneig de devolucions de trucades
asíncrones i interaccionar amb la interfície d'usuari.
17. GoatDroid: És un entorn de formació totalment funcional i autònom per educar els
desenvolupadors de seguretat d'Android. GoatDroid requereix dependències mínimes
i és ideal tant per a principiants com per els usuaris més avançats.
18. AppUse: Va ser creat com una màquina virtual específica els pentester que estan
interessats en una plataforma personalitzada per a les proves de seguretat
d'aplicacions Android, amb opcions de captura dels problemes de seguretat i anàlisi
del trànsit d'aplicacions.
No hi ha la necessitat d’instal·lar emuladors, ni eines de prova, només es necessiten
certificats SSL del programari de servidor intermig (tot bé pre-Instal·lat). Pràcticament
és com una ruta inversa, ajustada específicament per a les proves de seguretat
d'aplicacions Android. No es permet realitzar proves en solitari de penetració
d'aplicacions, a més, també és possible analitzar-les en la recerca de programari
maliciós.
Les caracteritiques més destacades són:
o Totalment compatible amb varis dispositius. o Assistents per fer tècniques de pirateria. o Proxy amb suport de protocols binaris. o Posseeix seccions amb dades d'aplicació. o Vista en arbre de carpeta i estructura d'arxius de l'aplicació. o Capacitat per a eliminar, veure i editar arxius. o Capacitat per a extreure les bases de dades. o Dinàmic Proxy. o Permet realitzar enginyeria inversa d'aplicacions. o Indicador dinàmic per a l'estat del dispositiu Android. o Analitzadors avançats de APK. o Compatible amb Android. o Anàlisi de malware.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 101
19. HelDroid: És una eina per fer front a l'anàlisi de ransomware en aplicacions Android. El
que realitza és trobar pistes en el codi de bytes d'aplicacions Android, que indiquen la
presència de codi utilitzat per implementar les característiques típiques de
ransomware. Les característiques són:
Ús de rutines de xifrat en intervenció de l'usuari.
Bloquejar la pantalla i fer que el dispositiu quedi inutilitzable.
Missatges amenaçadors en la pantalla.
Abús de l'API d'administració de dispositius per al bloqueig o neteja
sense supervisió.
Aquesta eina es centra en les rutines que estan vinculades i l'abús de l'API d'Android
per la implementació de ransomware. L'enfocament de HelDroid és gairebé 100%
d'Anàlisi estàtic d'arxius APK.
Cada HelDroid analitza l’APK Android per decidir si es tracta d’una mostra de
ransomware mitjançant tres tipus de detectors Independents, que poden executar-
se en paral·lel:
Detector de text amenaçant.
Detector de xifrat.
Detector de bloqueig.
Cada detector busca un indicador específic de comportament de ransomware.
20. AndroTotal: És Un servei gratuït per escanejar arxius APK sospitosos contra múltiples
aplicacions antivirus mòbils. El qual es pot descarregar en http://andrototal.org
21. Annubis : És una eina d'anàlisi que es basa en executar els binaris i és emulat en un
entorn de proves. L'anàlisi es centra en els aspectes rellevants per la seguretat de les
accions de l'aplicació, fent un procés d’analisis senzill i permet obtenir resultats més
precisos. El qual es pot descarregar en http://ift.tt/V8JHvk
22. CopperDroid: Reconstrueix automàticament i amb precisió esdeveniments d'Interès,
no hi ha interaccions en solitari, sinó que realitza les comunicacions entre processos,
del qual semànticament és típic contextualitzat a través d'objectes complexos
d’Android. A causa de la cua els mecanismes de reconstrucció de copperDroid realitza
un diagonisi a través dels mètodes d'acció d'invocats, a més, és capaç de capturar
accions tant de Java com d'execució de codi natiu. L'anàlisi que realitza CopperDroid
gènera perfils de comportament detallats, que són molt adequats per proporcionar
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 102
trets interessants i obrir la possibilitat de noves línies d'investigació de malware. El
qual es pot descarregar en http://ift.tt/2gRWg3F
23. SandDroid: És un sistema d'anàlisi d’aplicacions Androi que funciona automàticament
combinant tècniques d'anàlisi estàtic i dinàmic. El qual es pot descarregar en
http://ift.tt/1tZNByl
24. Tracedroid: Permet pujar un arxiu APK d'Android per a realitzar un anàlisi
automatitzat. Registra el comportament de l'Aplicació executada, per desencadenar el
comportament reial de l'aplicació, Tracedroid emula algunes accions com: la Interacció
de l'usuari, les trucades entrants i missatges SMS,etc. Revelant la majoria dels intents
maliciosos d'una aplicació. La qual es pot descarregar en : http://ift.tt/21h5YdD
11. TÈCNIQUES D’OFUSCACIÓ DE CODI EN ANDROID
Les eines d’enginyeria inversa demostren la facilitat que el codi font pot ser recuperat
mitjançant programari per reconfigurar un aplicatiu amb intenCions malicioses, per aquesta
raó es farà una exposició de les diferents tècniques d’ofuscació que es poden implementar per
dificultar aquesta reconfiguració i produir una fortificació en la seguretat del codi
implementat.
Les següents tècniques es classifiquen en ordre ascendent d'acord amb el còmput de dificultat
per a la seva enginyeria inversa.
Identities name scrambling: Aquesta tècnica afecta el disseny del programa i pot ser
implementat tant en codi font com a nivell de codi de bytes. El seu propòsit és ocultar
el programa en un nivell abstracte mitjançant la substitució dels noms de les variables
significatives, mètodes, classes, els arxius amb els que proporcionen informació
metadades en relació amb la del codi. El nom d’identitats s’aleatoritza i s'implementa
tant en Proguard com en APKfuscator, amb algunes diferències importants.
Proguard treballa en el codi font de Java i utilitza el reemplaçament amb cadenes de
lèxics ordenats {a, b, c,..., aa, ab,...} el qual té un baix cost d'espai que és essencial en
dispositius mòbils. En canvi quan s’utilitza APKfuscator en el nivell de codi de bytes,
aquest explota la restricció del sistema de fitxers Unix amb un nom de classe per no
excedir de 255 caràcters. Aquest fet és possible, ja que, també a Dalvik el codi de bytes
produeix que l'estructura de classe d'element es defineixi utilitzant el format d'arxiu
.dex (un requisit del format .dex és tenir totes les cadenes ordenades alfabèticament).
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 103
Encoding manipulations: Aquesta transformació es posa a disposició tant d'arxius com
en estructures de dades del programa. Per especificació, l'ordre dels bytes en el
format .dex és ascendent cap a l'esquerra. El manual ARM en l’arquitectura de
referència afirma que els processadors ARM donen suport a l'accés mixta ascendent
cap a l'esquerra en el maquinari, el que significa que es poden fer funcionar tant en
littleEndian o maneres big-endian.
Per tant, el verificador DVM se suposa que és capaç de detectar la codificació de l'arxiu
.dex interpretat i convertir bigEndian a l'ascendent cap a l'esquerra i viceversa. Mentre
que el canvi de la codificació no és difícil de posar en pràctica, es suggereix com
potencialment eficaç, ja que, la majoria de les eines d'anàlisi de codi de bytes Dalvik
només funcionen amb codificació d’arxius
Strings obfuscation: Aquesta tècnica és coneguda perquè realitza la transformació de
dades aplicant-lo en el nivell de codi font. Tot i que no està implementada per
qualsevol codi obert examinat amb ofuscadors, és possible ajustar-la al nivell de Dalvik
en codi de bytes. Aquesta técnica d’ofuscació de cadena impedeix l'extracció
d'informació de metadades i és eficaç contra l'anàlisi estàtic. Atès que hi ha moltes
aplicacions de tractament de dades personals, és bastant comú emmagatzemar
cadenes tals com credencials d'usuari en una base de dades.
No obstant això, fa que la conseqüència de mantenir aquest últim en text pla, sigui un
blanc fàcil per a l'enginyeria inversa. Hi ha un significat per ofuscar el fils d'un
programa d'aleatorització i la variable de noms. El canvi d'aquest últim no afecta a la
semàntica del programa. Per contra, cadenes que han d'estar en una part xifrada s’ha
d'impedir l'extracció estàtica i, d'altra banda, han d'estar disponibles com a text sense
format en temps d'execució de tal manera que un procés com a usuari pugui ser
verificada i portada a terme amb èxit.
Depenent de si s'aplica sobre l'ofuscació codi font o el nivell de codi de bytes, l'esforç
necessari per obtenir la cadena de text sense format varia. Es pot fer a nivell de codi
font passant la cadena com a argument a un invertible funció de transformació F és F
(s) la qual s'emmagatzema en el codi.
Dead code injection variants: Injecció de codi Dead, és una altra transformació que
s'ha pres del x86. Afecta el flux de control de l'aplicació i s'implementa en nivell de
codi de bytes per tant Dalvik-obfuscador i APKfuscator, cadascuna de les eines utilitza
la seva pròpia variació de la tècnica. En essència, aquest algoritme modifica el flux de
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 104
control mitjançant la inserció de codi que mai s'executa, però, afegeix nodes i vores
per al programa gràfic que augmenta la complexitat, respectivament.
Per garantir que l'execució no passa pels camins falsos introduïts, una branca
condicional s'utilitza per a la redirecció. Per tant, cal que aquesta condició sigui
especialment triada com la producció (a priori se sap el resultat del programador),
però una que és computacionalment difícil d'estimar en temps d'execució, és a dir, o
bé és sempre veritat (dirigint a rutes "bones") o sempre és falsa (mai dirigir als camins
"dolents").
Tals construccions condicionals es diuen predicats opacs i que s'han utilitzat, entre
altres, en Java codi font ofuscació. En el codi de bytes és implementat en les dues
variants d'injecció de codi ofuscadors que están sent utilitzats legítimament, i aquesta
es defineix amb instruccions una mica especials.
Dalvik-obfuscator: El codi de transformació d'injecció morts esquerdat utilitzen eines
tant d'escombrat lineal i recursius per desmuntar algoritmes en el moment de la seva
presentació. Per injectar el codi de la instrucció de longitud variable fill-matriu-
datapayload s'utilitza abans que el punt d'entrada del mètode a ser ofuscat.
Dues instruccions s'afegeixen en la matriu de dades de càrrega útil que es solapen amb
el codi del mètode i un precedent predicat opac que torna a dirigir l'execució dels
continguts de mètodes vàlids. La xifra dóna una idea intuïtiva de la diferència entre el
codi no ofuscat i el codi ofuscat després d’utilitzar aquesta tècnica.
Executable compression: Aquest tècnica ès coneguda sota l'arquitectura x86 perquè
és sovint utilitzada pel malware per ocultar el seu codi. L'objectiu d'aquest mètode és
la construcció d'un sol executable que conté el codi comprimit del programa complet
mitjançant un descompresor.
La compressió, amb freqüència en combinació amb el xifrat de codi, s'utilitza tant per a
disminuir la mida de l'executable, així com a ofuscar el codi. Durant l'execució del
descompressor stub s'extreu en primer lloc el codi comprimit i després executa el
programa original.
La Inversió d'un programa que s'ha sotmès a una transformació d'aquest tipus no es
pot fer amb l'anàlisi estàtic. Els dos mètodes principals per analitzar, són o bé l'examen
manual del tros de la descompressió després de desemblar el programa o mitjançant
la realització d’anàlisis dinàmics.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 105
Self modifying code: La modificació és una transformació del codi conegut aplicat amb
èxit en l'arquitectura x86 el seu propòsit és impedir anàlisi dinàmic. S'utilitza sovint pel
malware en combinació amb atacs de desbordament de memòria intermitja, que
també ha trobat la seva aplicació en tècniques d'ofuscació de programari legítim.
Havent-hi un programa protegit contra els resultats d'anàlisi estàtic d'una manera més
complexa i idèntic sobre cada flux de control d'execució. Per contra, els canvis de codi
dinàmics tenen un efecte en temps d'execució que és alterar la ruta d'execució en
cada trucada del programa.
No és estrany que una tècnica d'ofuscació hagi estat dissenyada per equilibrar entre la
complexitat del programa afegit i la robustesa del codi modificat contra l'anàlisi. En
aquest sentit, les tècniques d'ofuscació dinàmic augmenten considerablement de la
capacitat de recuperació, però pot ser un repte per aplicar d’una manera uniforme en
un arxiu d'entrada APK.
Inserció Junkbyte: És una tècnica ben coneguda sota l'arquitectura x86. S'utilitza per a
confondre els desensambladors d'una manera que ells produeixen errors de
desmuntatge i no permetin interpretacions correctes per un analista. Això es realitza
mitjançant la inserció junkbytes en llocs seleccionats dins el codi de bytes en un
desensamblador el qual espera una instrucció. La posició d'un junkbyte ha de prendre
l'estratègia de desmuntatge per tal d'aconseguir un màxim de codi ofuscat.
Una altra condició per a la ubicació és que el junkbyte no s'ha d'executar, a causa
d'una execució donaria lloc a un comportament no desitjat de l'aplicació. Un junkbyte
ha d'estar ubicat en un bloc bàsic que mai serà executat. Poden assegurar que aquest
bloc bàsic no serà executat per l'addició d'un salt incondicional. També és possible
utilitzar una bifurcació condicional alhora que garanteix que els resultats de l’argument
avaluat en un valor constant. Aquesta tècnica utilitza predicats opacs.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 106
12- GUIA PER SEGURITZAR L’APLICATIU CONTRA ATACS SQL INJECTION
Utilitzant el fitxer APK subministrat, es va poder observar que l’aplicatiu utilitzava formularis
per cercar I insertar dades a través d’aquests per part de l’usuari (figura 12.1).
figura 12.1 - Interficie gràfica per donar d’alta el compte d’usuari
En la imatge es pot observar el formulari que utiliza l’aplicatiu per cercar els usuaris
Tota aquesta informació consultada i administrada pel dispositiu, està emmagatzemada en un
servidor de base de dades.
Per aquesta raó, s’ha considerat en aquesta documentació, fer referència a les tècniques més
importants per seguritzar l’aplicatiu analitzat contra atacs de Sql injection, els quals milloren la
seguretat, confidencialitat I integritat de les dades administrades per aquest aplicatiu.
12.1 Escapar els caràcters especials utilitzats en les consultes Sql
En parlar "escapar caràcters" s’està fent referència a afegir la barra invertida "\" davant de les
cadenes utilitzades en les consultes SQL per evitar que aquestes corrompin la consulta. Alguns
d'aquests caràcters especials que és aconsellable escapar són les cometes dobles ( "), les
cometes simples ( ') o els caràcters \ X00 o \ X1A, ja que, són considerats com a perillosos per
que poden ser utilitzats durant els atacs. Els diferents llenguatges de programació ofereixen
mecanismes per aconseguir escapar aquests caràcters.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 107
12.2 Verificar sempre les dades que introdueix l'usuari en l’aplicatiu
Si en una consulta s’està a l'espera de rebre un enter, no s’ha de confiar que sigui així, sinó que
és aconsellable prendre mesures de seguretat i realitzar la comprovació que realment es tracta
del tipus de dada que s’està esperant. Per a realitzar això, els llenguatges de programació
ofereixen funcions que realitzen aquesta acció, com per exemple en JAVA mitjançant la funció
isnumeric(), que retorna un booleà true o false segons si la cadena passada per paràmetre és
un valor numèric o no.
També és aconsellable comprovar la longitud de les dades per descartar possibles tècniques
d'injecció SQL, ja que, si per exemple s’està esperant rebre el nom de l’usuari no pot ser que
l’extensió de la cadena introduïda sigui superior a 20 caràcters. Per aquesta raó, en el moment
de rebre les dades l’aplicactiu, hauria de realitzar una anàlisi de l’extensió dels diferents
paràmetres que construirà la consulta SQL mitjançant la funció lenght (la qual retorna la
longitud del string).
12.3 Assignar mínims privilegis a l'usuari que connectarà amb la base de dades des de l’aplicatiu.
L'usuari que s’utilitzi per connectar-se a la base de dades des del codi implementat, ha de tenir
els privilegis justos per a realitzar les accions que necessita. No utilitzar mai un usuari amb
privilegis d’administrador llevat que hi hagi una raó de pes per fer-ho, ja que, d'aquesta
manera s’estarà donant facilitats als atacants perquè puguin accedir a tota la informació, amb
aquesta mesura utilitzant l’ús d’un compte d'accés limitat, és molt més segur i limita les
accions que es capaç de realitzar l’atacant.
12.4 Realitzar modificacions del codi per tenir una codificació correcta
Encara que pugui semblar una mesura poc important, no hi ha millor mesura per evitar aquest
tipus d'atacs que fer una bona programació, posant en pràctica les necessitats bàsiques i
l'interès per desenvolupar una aplicació totalment segura. A més de les mesures que es poden
prendre a l'hora d'implementar el codi, sempre s’ha d’utilitzar auditories de codi per assegurar
que no s’ha deixat cap tipus de porta oberta.
Aquesta tècnica consisteix, en la versió més bàsica, fent cerques dins del mateix codi per a
localitzar patrons de fragments de codi que siguin potencialment vulnerables a problemes
coneguts. És recomanable que l'auditoria no la faci la mateixa persona que ha escrit el codi,
sinó un equip diferent, per assegurar la imparcialitat.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 108
12.5 Protegir els logs
Una mesura important és desinfectar els missatges de registre de sortida utilitzant una llista
blanca de caràcters permesos. Es podria, per exemple, limitar tots els registres en caràcters
alfanumèrics i espais en l’aplicatiu. Els missatges detectats fora d'aquesta llista de caràcters
que puguin ser corruptes i que condueixi a un missatge de registre en relació amb un potencial
de LFI, permet notificar sobre un potencial atac.
És un mètode simple per als registres de text simple, on inclouen qualsevol entrada que no
sigui de confiança en el missatge. Una defensa secundària que podria utilitzar l’aplicatiu
analitzat és realitzar una codificació en base64 de la porció d'entrada quan no es confia, la
qual manté un perfil de caràcters limitats permesos, alhora que permet una àmplia gamma
d'informació que s'emmagatzema en el text.
12.6 Utilitzar SQL dinàmic només si és absolutament necessari.
SQL dinàmic gairebé sempre es pot reemplaçar amb declaracions preparades, consultes amb
paràmetres o procediments emmagatzemats. Les declaracions preparades, es pot utilitzar
procediments emmagatzemats. A diferència de les declaracions preparades, els procediments
emmagatzemats es mantenen a la base de dades (Totes dues requereixen en primer lloc
definir el codi SQL, i després passar-li els paràmetres aconsellablament filtrats per l’aplicatiu)
12.7 Instal·lar pegats (patch) regularment.
Tot i que el codi no tingui vulnerabilitats SQL, quan el servidor de base de dades, el sistema
operatiu, o les eines de desenvolupament (Android studio) que s’utilitzin per implementar el
codi tinguin vulnerabilitats, això també és arriscat. És per això que sempre s'ha d'instal·lar els
pegats (patch) i especialment els que facin referència a vulnerabilitats SQL.
12.8 Treure tota la funcionalitat que no s'utilitzi.
Els servidors de bases de dades són complexes i tenen molta més funcionalitat de la que es
necessita. Pel que fa a la seguretat, és millor per exemple, utilitzar els procediments
emmagatzemats quan l’aplicatiu analitzat realitza les diferents consultes a base de dades, ja
que, són més segurs respecte el xp_cmdshell en MS SQL, aquest llança un shell de
comandaments de Window, passa una cadena per a la seva execució i això és just el que un
pirata informàtic pot utilitzar per a realitzar atacs. Per aquesta raó, és aconsellable desactivar
aquest procediment i qualsevol altra funcionalitat que pot ser fàcilment utilitzada
inadequadament tant en base de dades com en el propi aplicatiu.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 109
12.9 Utilitzar eines de proves automatitzades per a les injeccions SQL.
Fins i tot si els desenvolupadors segueixen les regles i fan tot el possible per evitar consultes
dinàmiques amb l'entrada de l'usuari segur, encara s’ha de tenir un procediment per verificar
el compliment. Hi ha eines de proves automàtiques per controlar les injeccions SQL i
comprovar la fortificació de tot el codi de les aplicacions amb bases de dades.
Una de les eines més fàcils per provar les injeccions SQL, és l’anomenada Metasploit
(http://metasploit.com), el qual és una suite de penetració de prova, Metasploit té mòduls
específics de SQL-Server, amb els quals es poden realitzar simulació d’atacs, com per exemple
obtenir la clau de l’usuari “sa” d'una instància de SQL Server (l’eina es subministra amb
documentació completa i pot ser automatitzada per a proves de penetració a nivell d'empresa
o usuari).
12.10 No revelar ni informació ni les credencials amb privilegis d’administrador
(atacs d’ enginyeria social)
A part de validar les dades que els diferents usuaris introdueixen en l’aplicatiu, també s’ha
d’assegurar que els responsables o usuaris que administren l’aplicació Android, no revelin les
credencials que permetin tenir privilegis d’administrador (tant en l’aplicatiu mòbil com en la
base de dades), ja que, aquest tipus d’atacs estan basats en enganyar a un usuari o
administrador des d’un lloc en internet o altres (telefònicament), per obtenir informació o
credencials amb privilegis d’administrador. Per aquesta raó s’ha d’estar segur que els
administradors i usuaris estiguin conscienciats d’aquests tipus d’atacs.
12.11 Utilització de Firewall (application firewalls)
Si l’aplicació analitzada utilitzés un servidor web seria molt recomanable utilitzar els Web
Application Firewalls (WAF), ja que, són les aplicacions que s'instal·len a escala de servidor per
a controlar les peticions malintencionades que podrien donar lloc a un possible atac. Això es fa
mitjançant unes regles que es configuren i que permeten detectar possibles atacs fins i tot
abans que es produeixin. A més, aquests sistemes actuen en conjunció amb els servidors web,
de manera que permeten el bloqueig de la petició maliciosa i eviten l'atac.
12.12 Xifrar les dades sensibles en la base de dades
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 110
Com s’ha esmentat anteriorment, l’aplicatiu utilitza formularis mitjançant els quals l’usuari es
pot loguejar o realitzar consultes en base de dades, tot això inclou introduir dades com noms,
cognoms, contrasenyes i informació que pugui ser útil als agents maliciosos.
Per aquesta raó s'ha d'assegurar que, fins i tot si els atacants posseeixen les dades sensibles,
no siguin capaços d'explotar-les immediatament, donant temps per descobrir la infracció,
tapar el forat, i prendre altres mesures reactives, com ara l'aplicació de restabliment de
contrasenyes, per assegurar-se que les dades robades perden el seu valor abans que l'atacant
ho desxifri. Si s’utilitza el hashing de contrasenyes, s’ha d’utilitzar algoritmes forts com ara
SHA-2, que aviat es convertiran en l'estàndard de la indústria per a la protecció de
contrasenya. MD5 i SHA-1 són obsolets i poden revertir-se.
12.13. No mostrar més informació de la necessària:
Els atacants aprenen molt sobre l'arquitectura de base de dades mitjançant els missatges
d'error, per aquesta raó s’ha d’assegurar que l’aplicatiu analitzat mostri la mínima informació
quan es produeix un error, sigui en base de dades o en el propi aplicatiu Android implementat,
a més garanteix que si l’error és generat per un atacant extern, no rebi informació que faciliti
la millora del seu atac.
12.14 No emmagatzemar dades sensibles
Si no ho necessita cada vegada que s'emmagatzema la informació a la base de dades, s’ha de
tenir en compte el perjudici que pot arribar a ser si cau en les mans equivocades, i decidir si
realment és necessari emmagatzemar-les o no. Per tant, és molt important no emmagatzemar
informació confidencial a la base de dades a menys que realment s’hagi de fer. I tot i així, és
una bona política eliminar aquestes dades quan la informació no és d'ús.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 111
13- COM MONOTORITZAR I MITIGAR UN POSSIBLE ATAC EN L’APLICATIU
Al llarg del temps, l'avanç dels mitjans tecnològics i de comunicació ha provocat el sorgiment
de nous vectors d'atacs i de noves modalitats delictives que han transformat a Internet i les
tecnologies informàtiques en aspectes summament hostils per a qualsevol tipus d'organització
i persona que tingui un aplicatiu en un dispositiu mòbil connectat a internet .
En conseqüència, el present punt pretén oferir una ràpida visió de les mesures de
monitorització que es poden realitzar per detectar un atac lo abans possible o per contra si
s’ha patit un atac els passos a realitzar tan bon punt s’ha patit i s’han traspassat els esquemes
de seguretat en els sistemes informàtics.
13.1 Passos per prevenir un possible atac:
1) S’ha d’utilitzar l’aplicatiu de captura de paquets de Wireshark i l’execució d’alertes utilitzant
Snort, les quals s’han d’utilitzar per avisar els administradors que s’està patint un atac de sql
injection (també es podrien implementar altres regles per detectar altres tipus d’atac apart de
l’esmentat).
2) S’ha de realitzar un anàlisis del port obert, s’ha de tenir la seguretat que en el servidor no
s’estiguin realitzant connexions externes a ports no controlats, per aquesta raó s’ha de tenir un
control dels ports que utilitza l’aplicatiu amb el servidor i si es detecta que hi ha algun obert no
controlat, tancar-lo immediatament evitant que hi pugui haver portes del darrere (backdoors).
3) S’ha de realitzar un anàlisi dels processos que genera l’aplicatiu dins el sistema operatiu del
dipositiu mòbil on està funcionant. Amb aquesta acció es té la capacitat de detectar si hi ha
hagut alguna modificació del codi dissenyat per algun atacant que els administradors no
tinguin controlat, immediatament realitzar un versió nova, perquè tots els usuaris puguin
actualitzar l’aplicació mitigant aquesta modificació.
4) Utilitzant el msdos (incio -> ejectuar) es pot veure una llista amb totes les interfícies
connectades al servidor utilitzant la comanda netstat (figura 13.1).
figura 13.1 - Exemple netstat
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 112
Mitjançant aquesta comanda (netstat) es pot obtenir tot tipus d’informació de les connexions
realitzades al servidor (port, tipus de protocol de connexió, estat, mac). Realitzant aquesta
consulta, es pot tenir un control de les ip de la xarxa i ports que s’estan utilitzant en el
servidor, poden diagnosticar si hi ha algun intrús en el servidor.
Actualment molts dels routers actuals contenen utilitats de diagnòstic de xarxa poden facilitar
la tasca de detecció d’intrusos.
5) Tenint diagnosticat les ips les quals no es tenen constància que el servidor ha de interactuar
amb elles, es pot obtenir informació utilitzant aplicatius web com whois i altres, les quals
ajuden a analitzar la procedència de les ips, donant la capacitat als administradors de poder
diagnosticar si s’està produint un atac al servidor de l’aplicatiu, per una o varies ips externes al
servidor.
6) Una altra eina molt útil per detectar intrusos és Nmap, ja que, és una aplicació multi
plataforma usada per explorar xarxes i obtenir informació sobre els serveis, sistemes operatius
i vulnerabilitats derivades de la conjunció d'aquests. Amb aquesta eina es podria realitzar un
anàlisis de la xarxa i poder diagnosticar si s’està patint un atac.
13.2 Passos per mitigar un posible atac:
1) S’ha de realitzar la tallada de totes les connexions al servidor afectat per l’atac, d’aquesta
manera s’aconsegueix aïllar el servidor de l’aplicatiu mòbil i i evitar que l’atacant continuï
realitzant atacs (on està la base de dades de la qual s’obtenen les dades).
2) És molt important tenir un servidor de backups, per si es produeixen atacs es puguin
recuperar la major quantitat de dades possibles (donada la importància, s’ha considerat que
l’empresa o entitat té aquest servidor de còpies de seguretat funcionant correctament, en
aquest anàlisi s’ha de realitzar un còpia de seguretat diàriament de la base de dades utilitzada
per l’aplicatiu a un servidor intern (amb un accés molt restringit i una protecció extremada)),
també cada cert període de temps s’ha de realitzar una neteja d’aquestes còpies de seguretat
(les més antigues), aquesta neteja s’ha de realitzar per temes de espai i funcionalitat del
servidor intern.
3) Un vegada obtinguda la copia de seguretat, s’ha de realitzar un comparació entre la base de
dades d’anyada o atacada amb el backup més recent, fent aquesta comparació es pot
diagnosticar si s’ha realitzat alguna modificació o eliminació de dades (hi han programes que
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 113
es poden fer servir per realitzar comparacions entre base de dades (ALTOVA)), si fos així s’ha
de realitzar un anàlisis d’aquestes dades eliminades o modificades tenint coneixement en
quina part de l’aplicatiu s’utilitzen, amb aquesta acció es dóna la capacitat als administradors
de localitzar on estan les possibles vulnerabilitats de l’aplicatiu mòbil.
4) Un cop realitzada la comparació de la base de dades i tenint una aproximació per on es pot
haver generat l’atac. S’ha de realitzar un recuperació de les dades eliminades o modificades
per l’atacant (amb la comparació esmentada anteriorment es pot saber aquesta informació) i
actualitzar o recuperar aquestes dades mitjançant el backup en la base de dades de producció.
5) Un cop realitzada la recuperació de les dades danyades per l’atac esmentat en el punt
anterior, s’ha de realitzar una auditoria i revisar mitjançant els passos esmentats (en el punt 3
“Pautes per seguritzar l’aplicatiu conta atacs de sql Injection”) en aquest document que s’hagin
implementat correctament, A més de la utilització de programes com SQLmap o Metasplopit,
perquè tan bon punt hi hagi la seguretat que aquestes mesures estan implementades
correctament, es posin a prova totes elles.
6) Un cop realitzat els passos anteriors i tenint la seguretat que les mesures de seguretat tant
en base de dades com en l’aplicatiu mòbil funcionen correctament, s’ha de tornar a posar en
marxa el servidor de l’aplicatiu mòbil de base de dades. Un dada important, és que els passos
esmentats anteriorment per mitigar l’atac s’han de realitzar sense tenir el servidor i la base de
dades funcionant en producció, amb aquesta acció es té la seguretat que l’atacant no té la
capacitat de seguir explotant les vulnerabilitats de l’aplicatiu mòbil contra la base de dades.
Les mesures de monitorització que s’han de realitzar per detectar l’atac ràpidament són:
La utilització de Snort pot ajudar molt en realitzar monotorizacions, ja que, és un sniffer de
paquets i un detector d'intrusos basat en xarxa (es monitoritza tot un domini de col·lisió).
És un programari molt flexible que ofereix capacitats d'emmagatzematge de les seves bitàcoles
tant en arxius de text com en bases de dades obertes com MySQL. Implementa un motor de
detecció d'atacs i escombrat de ports que permet registrar, alertar i respondre davant
anomalies prèviament definides. Així mateix existeixen eines de tercers per mostrar informes
en temps real (ACID) o per convertir-lo en un sistema detector i preventor d’intrusos (IDS).
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 114
Aquest IDS implementa un llenguatge de creació de regles flexible, potent i senzill. Pot
funcionar com sniffer, és a dir, realitza el registre de paquets (permet guardar en un arxiu els
logs per a la seva posterior anàlisi, un anàlisi offline) com un IDS normal (en aquest cas NIDS).
Quan un paquet coincideix amb algun patró establert en les regles de configuració, es logueja.
Així se sap quan, d'on i com es va produir l’atac. Durant l’anàlisi es pot tenir un aplicatiu
Android vulnerable a Sql injection a través dels paràmetres que s’introdueixen en els
formularis d’aquesta.
Una altra eina molt útil per diagnosticar l’estat i correcte funcionament de la xarxa és el
programa wireshark abans conegut com Ethereal, és un analitzador de protocols utilitzat per a
realitzar anàlisis i solucionar problemes en xarxes de comunicacions, per a desenvolupament
de programari i protocols.
La funcionalitat que proveeix és similar a la de tcpdump, però afegeix una interfície gràfica i
moltes opcions d'organització i filtrat d'informació. Així, permet veure tot el trànsit que passa a
través d'una xarxa (usualment una xarxa Ethernet, encara que és compatible amb algunes
altres) establint la configuració en mode promiscu (absorció de tots els paquets que circulen
per la xarxa analitzada). També inclou una versió basada en text anomenada tshark.
Permet examinar dades d'una xarxa viva o d'un arxiu de captura salvat en disc. Es pot analitzar
la informació capturada, a través dels detalls i sumaris per cada paquet. Wireshark és
programari lliure, i s'executa sobre la majoria de sistemes operatius Unix i compatibles,
incloent Linux, Solaris, FreeBSD, NetBSD, OpenBSD, Android, i Mac OS X, així com en Microsoft
Windows.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 115
14. CONCLUSIONS I TREBALLS FUTURS
Durant la realització, es va iniciar un investigació exhaustiva de les diferents possibilitats que
els sistemes de visió per computació podien ser aplicables en l’anàlisi de comparació de firmes
que s’ha realitzat en aquest treball final de màster, es va incorporar la llibreria opencv i
conjuntament amb els coneixements previs que es varen adquirir amb les ùltimes
investigacions, es va implementar un laboratori de proves amb els diferents algorismes pel
tractament i d’anàlisi d’imatges que incorpora aquesta llibreria.
D’aquest estudi es van poder seleccionar els 3 algorisnes que es varen considerar més eficaços
pel cas que s’estava realitzant (SURF,SIFT,ORB), amb els quals es va realizar un estudi més
exhaustiu d’aquests i quins paràmetres podien ser modificables per aconseguir una major
efectivitat per satisfer les necessitats del projecte més satisfactòricament (signatures) .
Per aquesta ráo i perquè els desenvolupadors que vulguin realizar millores en el treball
realitzat, es va implementar un aplicatiu extern amb el qual es va guanyar rapìdessa per a
realitzar la bateria de proves (aquest aplicatiu extern esta afegit conjuntament amb el codi
Font), obtenint els mateixos resultats que realitzant l’implementació en el dipositiu Android (es
va comprovar prèviament).
Fent referència aquest punt, es va poder diagnosticar que el millor algorisme en resultat i en
eficiència en el consum de recursos en el dispositiu móvil, era el ORB respecte els altres
algorismes candidats.
Durant la realització del treball de màster i els coneixements que es varen anar adquirint es
van poder assolir els següent objectius marcats incialment:
Estudiar la situació actual en els sistemes d’indentificació de signatures.
Estudiar com implementar un aplicatiu Android.
Estudiar com incorporar les llibreries opencv en el projecte.
Estudiar com capturar l’imatge de la firma realitzada en el document.
Estudiar com emmgatzemar la imatge generada per l’usuari des de la pantalla del
dispositiu.
Estudiar com realitzar l’implementació de l’algorisme de verificació i autenticitat de les
signatures.
Estudiar com realizar l’implementació d’un MVC cojuntament amb un Api rest per
guanyar amb eficiència en el consum de recursos de l’aplicatiu en el dispositiu mòbil.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 116
A més, durant la realització del projecte i com a futur professional de la seguretat informàtica,
es va realitzar un estudi en profunditat en seguretat en aplicacions mòbils Android, ja que,
cada vegada hi ha una major entrada en el món empresarial, on es realitzen
desenvolupaments a mida per interactuar amb les aplicacions de negoci. L'auditoria i les bones
pràctiques en l’implementació d'aplicacions mòbils per part dels desenvolupadors, és
necessària per garantir la confidencialitat de la informació gestionada per les aplicacions
internes i per les aplicacions comercials.
Amb aquest anàlisis i estudi de les diferents eines i tècniques per protegir i millorar la
seguretat en l’aplicatiu Android desenvolupat, es van assolir els següents objectius de cares els
futurs desenvolupadors que estiguin interessats en continuar el projecte:
Estudiar les diferents tècniques i metodologies per implementar una aplicatiu Android
amb seguretat.
Estudiar les diferents tècniques i metodologies per seguritzar la base de dades en
aplicatius Android.
A partir dels objetius resolts i de l’implementació de l’aplicatiu demanat, els treballs futurs que
es poden realitzar a partir del projecte implementat són el següents:
Millorar l’algorisme ORB mitjançant els paràmetres que té per elevar el tant per cent
d’efectivitat.
En lloc de loguejar l’usuari mitjançant el DNI i contrasenya , es podria implementar un
sistema mitjançant el sistema biomètric de la ditada com s’exposa en la següent url :
http://www.androidhive.info/2016/11/android-add-fingerprint-authentication/
Realitzar proves amb el laboratori implementat amb algorismes de tractament
d’imatges diferents als esmentats en aquesta memòria.
Ampliar les funcionalitats de l’aplicatiu, segons les necessitats de l’entitat o usuari que
utilitizi l’aplicatiu.
Proposar accions i projecte a realizar per millorar l’algorisme de verificació de firmes
implementat
Oferir els resultats de les accions i projectes proposats i realitzats, per obtenir-ne una
bona base de coneixements i extreure conclusions rellevants.
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 117
15- REFERÈNCIES
Documentació consultada
https://radiosyculturalibre.com.ar/biblioteca/INFOSEC/Ataques-a-bases-de-datos.pdf
file:///C:/Users/axel/Downloads/Tecnicas-de-SQL-Injection.pdf
https://es.wikipedia.org/wiki/Inyecci%C3%B3n_SQL
https://www.owasp.org/index.php/SQL_Injection
https://pdfs.semanticscholar.org/d2d0/01e2a45614528cd014040becb67a80a1af8d.pd
f
http://stackoverflow.com/questions/17063826/how-to-create-jar-for-android-library-
project
https://www.cryptolux.org/images/9/94/Alexandrina-thesis.pdf
https://www.cryptolux.org/images/9/94/Alexandrina-thesis.pdf
http://isyou.info/jowua/papers/jowua-v6n4-4.pdf
https://www.defcon.org/images/defcon-22/dc-22-presentations/Strazzere-
Sawyer/DEFCON-22-Strazzere-and-Sawyer-Android-Hacker-Protection-Level-
UPDATED.pdf
https://pdfs.semanticscholar.org/d5cb/d4cb442be8fe0268d809cdd496f02b06f100.pdf
http://www.cs.wayne.edu/fengwei/16sp-csc5991/labs/lab5-instruction.pdf
https://tirateunping.wordpress.com/2016/12/07/herramientas-para-el-analisis-de-
aplicaciones-maliciosas-en-android/
http://blog.segu-info.com.ar/2013/08/apkanalyser-permite-analizar-archivos.html
http://gustavopeiretti.com/android-reducir-apk/
https://miguelangellv.wordpress.com/2013/04/23/proguard-optimiza-reduce-y-
ofusca-el-codigo-de-tus-aplicaciones-android/
http://www.techrepublic.com/blog/software-engineer/protect-your-android-apps-
with-obfuscation/
http://www.vogella.com/tutorials/AndroidLibraryProjects/article.html
http://fuzion24.github.io/android/obfuscation/ndk/llvm/o-llvm/2014/07/27/android-
obfuscation-o-llvm-ndk/
http://fuzion24.github.io/android/obfuscation/ndk/llvm/o-llvm/2014/07/27/android-
obfuscation-o-llvm-ndk/
https://www.excelsior-usa.com/articles/java-obfuscators.html
https://insights.sei.cmu.edu/sei_blog/2014/04/two-secure-coding-tools-for-analyzing-
android-apps.html
http://www.vogella.com/tutorials/AndroidTools/article.html
http://tools.android.com/recent/dealingwithdependenciesinandroidprojects
https://www.researchgate.net/publication/311222768_Android_Code_Protection_via
_Obfuscation_Techniques_Past_Present_and_Future_Directions
http://www.androidengineer.com/2010/07/optimizing-obfuscating-and-
shrinking.html
http://blog.scalac.io/2016/02/11/android-reverse-engineering.html
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 118
http://blog.theliel.es/2011/02/android-algo-de-ingenieria-inversa-para-parchear-una-
aplicacion-firmarla-y-volver-a-colocarla.html
https://developer.android.com/studio/projects/android-library.html
https://robotsandpencils.com/blog/use-proguard-android-library/
https://handouts.secappdev.org/handouts/2016/Eric%20Lafortune/Code%20Obfuscat
ion%20Techniques.pdf
https://pdfs.semanticscholar.org/d5cb/d4cb442be8fe0268d809cdd496f02b06f100.pdf
https://arxiv.org/pdf/1502.01625.pdf
http://stackoverflow.com/questions/14570989/best-practice-for-storing-private-api-
keys-in-android
https://realm.io/news/360andev-ana-baotic-best-practices-app-security-android/
https://www.cnet.com/how-to/protect-your-android-device-from-malware/
http://www.androidcentral.com/three-basic-steps-protecting-your-android-device-
viruses
http://www.javaworld.com/article/2076837/mobile-java/twelve-rules-for-developing-
more-secure-java-code.html
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Android - Content Provider Injection Case of Study - https://viaforensics.com/mobile-
security/ebay-android-content-provider-injectionvulnerability.html
ANDROID OS (2012). HISTORIA DE ANDROID. [Citado: Mayo 28 de 2015]. Disponible
en: http://androidos.readthedocs.org/en/latest/data/historia/
CARACTERÍSTICAS DEL SISTEMA OPERATIVO ANDROID (1995). [Citado Mayo 25 de
2015] Disponible en: http://www.samsung.com/co/article/android-2-2os-explained/
DRAKE, Joshua; FORA; Pau Oliva; ZA Lanier; COLLIN, Mulliner. Etal. Android Hackers’s
handbook. Indianapolis: John Wiley & Sons, Inc., 2013, 577 p.
EL ANDROID LIBRE. LA HISTORIA DE ANDROID EN IMÁGENES: DESDE SUS INICIOS
HASTA AHORA.[Citado Abril 10 de 2015].Disponible en:
http://www.elandroidelibre.com/2014/06/la-historia-de-android-en-imagenes-
desdesus-inicios-hasta-ahora.html
EVOLUCIÓN DE MÓVILES[Citado: Mayo de 2014] Disponible
en:http://dispositivosmobilesits.blogspot.com/2012/02/evolucion-de-moviles.html
http://www.hacking-tutorial.com/hacking-tutorial/hacking-android-
smartphonetutorial-using-metasploit/#sthash.9RNHAwR0.dpbs
FERNANDES, Jerónimo. Banco de pruebas de seguridad para plataformas móviles
Android. Cartagena, 2014. Tesis de Grado: Universidad Politécnica de Cartagena.
GIRONES, Jesús Tomas. El gran libro de Android. México: Alfaomega, 2012. 403p.
INSTITUTO NACIONAL DE TECNOLOGÍAS DE LA COMUNICACIÓN INTECO. (2008).
[Citado: Febrero de 2015] Estudio sobre seguridad en dispositivos móviles y
Smartphones. Disponible en: https://www.inteco.es/file/rdj_9ad_DHM_jZcyjTYRlw
INSTITUTO NACIONAL DE TECNOLOGÍAS DE LA COMUNICACIÓN INTECO.
(2011).Estudio sobre hábitos seguros en el uso de Smartphones por los niños y
adolescentes españoles. Disponible en:
http://www.inteco.es/Estudios/Estudio_smartphones_menores
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 119
LABORATORIO DE REDES Y SEGURIDAD. Ataques a dispositivos móviles. Recuperado
de:
http://redyseguridad.fip.unam.mx/proyectos/buenaspracticas/ataquesadispositivos
moviles.html
LA HISTORIA DE ANDROID. [Citado: Mayo 28 de 2015]. Disponible en:
http://www.android.com/intl/es-419_mx/history/
NORMA TECNICA COLOMBIANA NTC 1486. Documentación, presentación de tesis,
trabajos de grado y otros trabajos de investigación. Bogotá: Icontec.
SANTANA, A. (Enero de 2011). “Una infraestructura de comunicaciones clienteservidor
para dispositivos móviles”. Disponible en:
http://tesis.bnct.ipn.mx/dspace/bitstream/123456789/9891/1/210.pdf
TODO ANDROID (2015).Qué es Android 5.0 Lollipop: novedades y características de
esta versión de Android. Disponible en: http://www.todoandroid.es/index.php/faq-
de-android/65-versiones/1672-que-esandroid-5-0-lollipop-novedades-y-
caracteristicas-de-esta-version-de-android.html
REFERENCIAS [1] J. Fingas, “Android climbed to 79 percent of smartphone market
share in 2013, but its growth has slowed,” January 2014. [Online].
Available: http://www.engadget.com/2014/01/29/ strategy-analytics-2013-
smartphone-share/ [2] A. Shabtai, Y. Fledel, U. Kanonov, Y. Elovici, and S. Dolev,
“Google Android: A State-of-the-Art Review of Security Mechanisms,” ArXiv e-prints,
Dec. 2009. [3] E. Chin, A. P. Felt, V. Sekar, and D. Wagner, “Measuring user confidence
in smartphone security and privacy,” Proceedings of the Eighth Symposium on Usable
Privacy and Security - SOUPS ’12, no. 1, p. 1, 2012. [Online].
Available: http://dl.acm.org/citation.cfm? doid=2335356.2335358 [4] Google, “Notes
on the implementation of encryption in android 3.0,” 2014. [Online].
Available: https://source.android.com/devices/tech/ encryption/android crypto
implementation.html [5] ——, “Android 4.3 apis,” 2014. [Online].
Available: http://developer. android.com/about/versions/android-4.3.html [6] ——,
“Platform versions,” 2014. [Online]. Available: http://developer.
android.com/about/dashboards/index.html [7] ——, “Detecting pirated applications,”
Febrero 2014. [Online]. Available:
http://www.google.com/patents/EP2693356A2?cl=en [8] B. Bosschert, “Steal
whatsapp database (poc),” Marzo 2014. [Online].
Available: http://bas.bosschert.nl/steal-whatsapp-database/ [9] ——, “Steal whatsapp
update,” Marzo 2014. [Online].
Available: http://bas.bosschert.nl/steal-whatsapp-update/ [10] US-CERT/NIST,
“Vulnerability summary for cve-2013-6271,” Diciembre 2013. [Online].
Available: http://web.nvd.nist.gov/view/ vuln/detail?vulnId=CVE-2013-6271 [11]
Google, “Facial recognition,” Junio 2013, pN 8457367. [Online].
Available: http://patft1.uspto.gov/ [12] V. Rastogi, Y. Chen, and X. Jiang, “Evaluating
Android Anti-malware against Transformation Attacks,” NORTHWESTERN University,
no. March, 2013. [Online]. Available: https://www.eecs.northwestern.edu/
docs/techreports/2013 TR/NU-EECS-13-01.pdf
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 120
http://www.android.com/
http://developer.apple.com/technologies/ios/
http://www.infospyware.com/. ¿Qué son los Malwares?
http://www.cnccs.es/. Malware en Smartphones CNCCS
http://www.genbeta.com/. Tapjacking, un problema de seguridad en los móviles
Android
http://www.securitybydefault.com/. Aplicaciones de seguridad desde Android
http://www.diariopyme.com/. Decálogo de seguridad para dispositivos móviles
http://labs.mwrinfosecurity.com/blog/2012/04/23/adventures-with-android-
webviews/ https://developer.android.com/training/articles/security-
tips.html#WebView
Pinto, Marcus (2007). The Web Application Hacker’s Handbook: Discovering and
Exploiting Security Flaws (Kindle Locations 2813-2816). Wiley. Kindle Edition
https://developer.android.com/tools/publishing/app-signing.html#cert
ObjC-Obfuscator https://github.com/FutureWorkshops/Objc-Obfuscator iOS-Class-
Guard https://github.com/Polidea/ios-class-guard FairPlay DRM overview on iOS
https://www.theiphonewiki.com/wiki/Copy_Protection_Overview Bugging Debuggers
on iOS https://www.theiphonewiki.com/wiki/Bugging_Debuggers LLVM-Obfuscator
https://github.com/obfuscator-llvm/obfuscator/wiki (for iOS and Android)
http://developer.android.com/guide/publishing/licensing.html#app-obfuscation
Android - ProGuard: http://proguard.sourceforge.net/ -
http://developer.android.com/tools/help/proguard.html Android - DexGuard:
Android - https://gist.github.com/scottyab/b849701972d57cf9562e
http://www.sans.org/reading-room/whitepapers/forensics/forensic-analysis-
iosdevices-34092
Android/iOS Full Database Encryption - http://sqlcipher.net/ Android Storage Options -
http://developer.android.com/guide/topics/data/datastorage.html
Your app shouldn’t suffer SSL’s problems - https://moxie.org/blog/authenticity-
isbroken-in-ssl-but-your-app-ha/
Moxie Marlinspike’s sslstrip exploitation tool - https://moxie.org/software/sslstrip/
http://op-co.de/blog/posts/android_ssl_downgrade/ M1 - Weak Server Side Controls
CWE 325 Protect Against CSRF with Form Tokens DETAILS REMEDIATION REFERENCES
•
http://commonsware.com/blog/2013/09/11/beware-accidental-apis-avoid-
intentsextras.html http://commonsware.com/blog/2014/04/30/if-your-activity-has-
intent-filter-exportit.htm
Sample code here https://gist.github.com/scottyab/d5ab6a284622ebc46d5a
Documentació provinent de CWE/OWASP
CWE: https://cwe.mitre.org/
OWASP: https://www.owasp.org/index.php/Main_Page
M8 - Security Decisions via Untrusted Inputs; M10 - Lack of Binary Protections CWE-
656: Reliance on Security Through Obscurity
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 121
M8 - Security Decisions via Untrusted Inputs; M10 - Lack of Binary Protections CWE
200 C
M10 - Lack of Binary Protections CWE-354: Improper Validation of Integrity Check
Value
M8 - Security Decisions via Untrusted Inputs CWE 829 M4 - Unintended Data Leakage
CWE-316: Cleartext Storage of Sensitive Information in Memory
CWE-200: Information Exposure
CVE-2014-0160 Heartbleed M4 - Unintended Data Leakage
CWE-312: Cleartext Storage of Sensitive Information
CWE-313: Cleartext Storage in a File or on Disk • M2 - Insecure Data Storage,
M4 - Unintended Data Leakage CWE 598 OWASP Mobile Top 10: M2 - Insecure Data Storage
CWE: CWE-312 - Cleartext Storage of Sensitive Information,
CWE-313 - Cleartext Storage in a File or on Disk,
CWE-522 - Insufficiently Protected Credentials,
CWE- 215 - Information Exposure Through Debug Information R OWASP Mobile Top 10: M9 - Improper Session Handling
CWE CWE-614 - Sensitive Cookie in HTTPS Session Without 'Secure' Attribute
OWASP Mobile Top 10: M3- Insufficient Transport Layer Protection
CWE: CWE-319 - Cleartext Transmission of Sensitive Information
OWASP Mobile Top 10: M3- Insufficient Transport Layer Protection
CWE: CWE-757: Selection of Less-Secure Algorithm During Negotiation ('Algorithm
Downgrade')
M5 - Poor Authorization and Authentication
M5 - Poor Authorization and Authentication
CWE-200: Information Exposure
M4 - Unintended Data Leakage
CWE 200
OWASP Mobile Top 10: M9 - Improper Session Handling
CWE: CWE-613 - Insufficient Session Expiration
OWASP Mobile Top 10: M5 - Poor Authorization and Authentication
CWE: CWE-308: Use of Single-factor Authentication
M2 - Insecure Data Storage,
M4 - Unintended Data Leakage
CWE 312, 313
OWASP Mobile Top 10: M3- Insufficient Transport Layer Protection
CWE: CWE-311 - Missing Encryption of Sensitive Data,
CWE-319 - Cleartext Transmission of Sensitive Information
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 122
M8 - Security Decisions via Untrusted Inputs
CWE 79, 89, 120
OWASP Mobile Top 10: M2 - Insecure Data Storage,
M4 - Unintended Data Leakage
CWE: CWE-538 - File and Directory Information Exposure
M2 - Insecure Data Storage,
M4 - Unintended Data Leakage
CWE 312, 313, 522, 200
M4 - Unintended Data Leakage
CWE 215
M2 - Insecure Data Storage;
M4 - Unintended Data Leakage
CWE 312, 313, 522
M10 - Lack of Binary Protections; M8 - Security Decisions via Untrusted Inputs
CWE 215
M4 - Unintended Data Leakage
CWE 200
M1 - Weak Server Side Controls
CWE 325
M2 - Insecure Data Storage
CWE 280
M8 - Security Decisions via Untrusted Inputs; M10 - Lack of Binary Protections
CWE 927
M8 - Security Decisions via Untrusted Inputs;
M10 - Lack of Binary Protections
CWE-927: Use of Implicit Intent for Sensitive Communication
https://developer.android.com/training/articles/security-tips.html#Permissions
http://shop.oreilly.com/product/0636920022596.do
M8 - Security Decisions via Untrusted Inputs; M10 - Lack of Binary Protections
CWE-925: Improper Verification of Intent by Broadcast Receiver Use Broadcasts
Carefully
M8 - Security Decisions via Untrusted Inputs; M10 - Lack of Binary Protections
CWE-927: Use of Implicit Intent for Sensitive Communication
M8 - Security Decisions via Untrusted Inputs;
M10 - Lack of Binary Protections
CWE-280: Improper Handling of Insufficient Permissions or Privileges
M8 - Security Decisions via Untrusted Inputs;
M10 - Lack of Binary Protection
CWE 285: Improper Authorization
M7 - Client Side Injection
CWE 926: Improper Export of Android Application Components
M10 - Lack of Binary Protections
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 123
CWE-79: Improper Neutralization of Input During Web Page Generation (Cross-site
Scripting) •
M4 - Unintended Data Leakage
CWE 200: Information Exposure
M4 - Unintended Data Leakage
CWE 200: Information Exposure
M6 - Broken Cryptography
CWE-310: Cryptographic Issues
CWE-326: Inadequate Encryption Strength Sign Android APKs DETAILS REMEDIATION •
• • • • REFERENCES •
M1 - Weak Server Side Controls
CWE 203
Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010 -
http://op-co.de/blog/posts/android_ssl_downgrade/ OWASP
Mobile Top 10: M1 - Weak Server Side Controls
CWE: CWE-326 - Inadequate Encryption Strength REFERENCES •
M9 - Improper Session Handling
CWE 613
M1 - Weak Server Side Controls
CWE 307, 200, etc. (could be multiple)
M1 - Weak Server Side Controls
CWE 200 - Multiple CWE's
Documentació provinent opencv
https://enoxsoftware.github.io/OpenCVForUnity/3.0.0/doc/html/class_open_c_v_for_unity_1
_1_o_r_b.html
http://opencv-python-
tutroals.readthedocs.io/en/latest/py_tutorials/py_feature2d/py_matcher/py_matcher.html
https://wwwpub.zih.tu-
dresden.de/~cvweb/teaching/Courses/WS_2014_15/HS/UpdateOnFeatures_StefanHaller.pdf
http://www.sersc.org/journals/IJSEIA/vol8_no3_2014/2.pdf
http://cs.au.dk/~jtp/SURF/report.pdf
http://docs.opencv.org/2.4/opencv_tutorials.pdf
http://mirror-eu.wiki.ros.org/attachments/Events(2f)CoTeSys(2d)ROS(2d)School/OpenCV.pdf
https://www.inf.fu-berlin.de/lehre/SS09/CV/uebungen/uebung09/SIFT.pdf
https://pdfs.semanticscholar.org/3f67/3caedafdfea1c5b4e77118792b6a22fa4998.pdf
https://en.wikipedia.org/wiki/Scale-invariant_feature_transform
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 124
Annexa 1 manual laboratori de proves
Per a realizar aquest aplicatiu, es var utilitzar visual studio 2013 i la incorporació al projecte de
la llibreria opencv 3.2.0.
1) S’ha d’executar el programa des de l’executable (figura 1.1).
figura 1.1 - Exemple visual com obrir el projecte del laboratori de proves
2) Per fer funcionar l’aplicatiu, s’ha de canviar les rutes d’on s’agafaran les dues imatges a
analitzar, es varen realitzar diferents firmes des de la pantalla del dipositiu mòbil i a
documents amb la firma a mà, per fer l’anàlisi d’autenticitat de l’usuari.
El codi es composa d’un main, on es pot observar l’utilització de imread de la llibreria opencv
on s’emagatzemen les imatges a analitzar com un objecte Mat. (figura 1.2)
figura 1.2 - es mostren les rutes modificables on s’obtenen les imatges a analitzar
A continuació, s’ha de configurar amb quin algorisme es realitzarà la detenció del punt clau, en
el codi es pot veure com es poden declarar un dels tres tipus (ORB,SIFT,SURF) segons
l’algorisme i les necessitats del cas , com s’ha esmentat anterioment el més eficient amb
l’estudi realitzat és el ORB i per tant s’ha deixat descomentat i és el que agafarà per defecte.
(imatge 1.3)
figura 1.3 - es pot veure l’algorisme per defecte que utilitzarà l’aplicatiu
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 125
Utilitzant el drakeypoint, es dibuixaran els punt claus en les imatges que posterioment seran
mostrades, declaran els descriptos amb els paràmetres que es considerin oportuns.(figura 1.4)
figura 1.4- configuració incial per dibuixar els punts claus
Es declara quin tipus d’algorisme match es vol implementar per diagnosticar els punt claus que
coincideixen entre les dues imatges analitzades, per defecte l’aplicatiu utilitzarà força bruta (hi
han altres tipus de match configurables)
A continuació, es dibuixaran en la mateixa imatge les dues imatges analitzades amb els punts
d’interès que fan match amb l’algorisme definit, a més de les dues imatges separades per
finestres. (figura 1.5)
figura 1.5- es pot veure com mitjançant els descripto es mostrarà l’anàlisi
Es pot observar, com es mostren les dues imatges analitzades amb els punts d’interès i la final
que serien les dues juntes amb els seus punts d’interès i quin punts claus fan match (figura 1.6)
figura 1.6- resultat obtingut
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 126
Annexa 2 manual de l’aplicació completa
La configuració que s’ha de realitzar des de l’aplicatiu Android és el següent:
S’ha de modificar la ip en totes les funcionalitats on es realitzi la petició post a l’Api rest per la
ip de la màquina on estigui funcionant l’Api rest, com es pot veure en la figura 2.1:
figura 2.1 - exemple de petició post la qual s’haura de canviar la ip que es marca en vermell per
la ip de la màquina on s’estigui executant l’Api rest
Per fer funcionar l’aplicatiu Api rest s’ha de seguir els següents passos.
1) Botó dret sobre l’icona del visual studio amb permisos d’administrador (no s’adjuntat
un executable amb el codi, ja que, s’ha de configurar la connexió de l’Api rest amb el
servidor de base de dades i cada connexió és diferent) (figura 2.2)
figura 2.2- s’ha d’obrir el visual studio amb permisos d’administrador
2) S’ha d’obrir el projecte des del programa visual studio (figura 2.3)
figura 2.3- Com obrir el projecte des del visual studio
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 127
3) S’ha de buscar l’executable del projecte (figura 2.4)
figura 2.4- l’executable del projecte
4) S’ha d’accedir a la classe de datosmanager com es veu en la (figura 2.5 )
figura 2.5- es pot observar la connection string (cadenaconnexio) des d’aquesta clase
5) S’ha de modificar la “cadenaconnexio” la qual s’utilitza per fer que l’Api rest es
connecti a la màquina virtual on està el servidor de base de dades de Sql .
6) A continuació, s’exposaran els paràmetres que s’han de configurar de la variable
“cadenaconnexio” esmentada anteriorment.
6.1) data source: És el nom del servidor que té el Window server, com es pot
comprovar en la figura 2.6 es pot obtenir aquesta informació en el mateix
administrador del servidor de Windows server (figura 2.6).
figura 2.6- Es pot observar com obtenir el valor del paràmetre data source
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 128
6.2) Initial catalog: És a la base de dades, on anirà a buscar les dades l’Api rest (xx4)
6.3) User Id (sa): És amb l’usuari que accedirà al servidor de base de dades (per
seguretat es varen limitar els permisos d’aquest usuari, perquè només tingués els
permisos suficients per a realitzar les accions que necessita l’aplicació).
6.4) Password: És la contrasenya per accedir el servidor de Sql.
El servidor de base de dades, si es configura mitjançant un màquina virtual com s’ha realitzat
en el projecte, s’ha de configurar un bridge en aquesta màquina virtual perquè estigui dintre
de la xarxa i del mateix rang de ip.
En el cas realitzat 192.168.(número) (figura 2.7)
figura 2.7- es pot observar com la màquina virtual i la local estan en la mateixa xarxa
Per configurar el bridge en la màquina virtual, s’ha realitzat de la següent manera :
figura 2.8 - En aquesta imatge es pot veure com configurar el pont de la màquina virtual
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 129
Es configura amb la targeta de xarxa corresponent sigui wi fi o de xarxa, automàticament la
màquina virtual estarà dintre del rang d’ip de la màquina host. (figura 2.9)
figura 2.9 es pot observar com la màquina virtual utilizarà la tarja de xarxa per connectar la
màquina virtual a la xarxa local .
Realitzant la comprovació que estan dintre de la mateixa xarxa utilitzant la comanda ping del
cmd de Windows (figura 2.10)
Figura 2.10 En la imatge es pot veure com la màquina virtual està connectada a la xarxa
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 130
Annexa 3 Storeds i taules utilitzades en el servidor de base de dades.
Per implementar la base de dades i els storeds es va utilitzar una tècnica anomenada
d’ofuscació, la qual fa que el nom de la taula, els storeds i els paràmetres que rebran aquests
per administrar el compte d’usuari, continguin noms poc comuns per dificultar la comprensió
d’aquests per part d’un posible atacant.
La taula on s’emagatzemen les dades dels comptes dels diferents usuaris (figura 3.1) .
figura 3.1- taula on s’emmagatzement les dades dels usuaris
xx45 = El primer camp és un id autoincrementable
xx4 = És el camp on s’emmagatzema la contrasenya del compte d’usuari amb form SHA256
xx6 = S’emmagatzema el cognom de l’usuari que ha creat la compte
xx81 = És el camp on s’emmagatzema l’imatge codificada.
xx89 = És el dni de l’usuari que ha creat la compte
xx91 = És el email de l’usuari que ha creat la compte
xx193 = És el nom de l’usuari que ha creat la compte
X68 = Permisos de l’usuari (valor numeric 1 (normal) o zero (investigador))
Als diferents storeds, hi haurà una validació de les dades, per evitar atacs de sql injection
mitjançant l’introducció de sentències Sql malicioses com per exemple union en els
parametres que rebrant els diferents storeds.
Els diferents storeds, com s’esmentat en apartats anteriors on s’exposava el funcionament de
l’Api rest i com interectua amb el servidor de base de dades, contenen noms ofuscats per no
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 131
facilitar la comprensió del funcionament del servidor de base de dades i com interectuen amb
els diferents disposisitus movils, per si hi ha un possible atacant.
Per què els futurs desenvolupadors que vulguin continuar el projecte i no tinguin problemes
de comprensió, tots els storeds contenen comentaris de la seva funcionalitat de quin són i
amb quin ordre rebrant els paràmetres.
Els diferents stored que es varen utilizar són els següents:
Stored Actualitzar usuaris
Aquest stored la funcionalitat és permetre a l’usuari actualitzar les dades del compte d’usuari
creat mitjançant el nom, cognom,email, imatge, aquestes dades són introduides a través de
l’interficie de l’aplicatiu Android i enviades a l’Api rest el qual crida el stored passant-li els
paràmetres i actualitzant les dades.
Incialment es fa un validació de les dades introduides per asegurar que no contenen
sentències union en la consulta de sql (per evita atacs de sql injection).
Al finalitzar l’actualització, el stored enviarà un valor nùmeric a l’Api rest confirmant si s’han
actualitzat les dades de l’usuari correctament i aquest mateix valor numèric será enviat a
l’aplicatiu Android que avisarà a l’usuari que el compte d’usuari s’actualitzat correctament o
no (figura 3.2).
figura 3.2- Stored Actualitzar usuaris
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 132
Stored eliminar usuari
El stored següent, la funcionalitat que té és eliminar el compte d’usuari quan l’usuari clica
sobre el botó de l’interficie desde l’aplicatiu Android i confirma l’eliminació del compte.
Aquest enviarà el id a l’Api rest i aquest cridarà el seguent stored per realizar el delete del
compte, si el compte s’ha esborrat correctament s’esborraran les dades i enviarà un valor null
que serà enviat a l’Api rest i aquest l’enviarà a l’aplicatiu Android per finalment ser tractat
(figura 3.3)
figura 3.3- Stored eliminar usuari
Stored obtenir permisos usuari
Amb el següent stored s’obtenen els permisos de l’usuari després de realitzar el login,
(investigador/normal) i per tant la manera en que l’aplicati mostrarà els resultats variarà
segons el valor d’aquests camp (figura 3.4)
figura 3.4- Stored obtenir permisos usuari
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 133
Stored Login
L’usuari introduirà les dades per loguejar-se en l’aplicatiu mitjançant el DNI i contrasenya,
(s’ha fet la mateixa validació dels paràmetres per evitar atacs de sql injection) , si conté la
cadena union retornarà un valor NULL i que serà enviat a l’Api rest i aquest l’enviarà a
l’aplicatiu Android, el qual farà un tractament d’aquesta dada i avisarà a l’usuari mitjançant un
missatge d’avís que les dades no poden contenir la cadena Union (figura 3.5).
figura 3.5- Stored Login
Obtenir dades usuari
En l’interficie de l’aplicatiu Android la qual permet a l’usuari modificar les dades del compte,
aquesta utilitza el següent stored amb el qual mitjançant el id de l’usuari obté les seves dades,
que a continuació seran enviades a l’Api rest i aquest les enviarà a l’aplicatiu Android per
mostrar-les (figura 3.6).
figura 3.6- Obtenir dades usuari
Tfm- seguretat en sistemes biotmètrics
Axel Picón Magdalena - Treball Final de Màster Pàgina 134
Stored Alta usuaris
Quan l’usuari introdueix les dades per donar el compte d’usuari i ha passat les validacions,
aquestes són enviades a l’Api rest la qual realitzarà la crida del següent stored passant-li els
paràmetres , el stored agafarà les dades i farà una última validació d’aquestes per evitar atacs
de sql injection, si alguns dels paràmetres conté aquesta cadena(union) , automàticament el
stored enviarà un valor null a l’Api rest i que posterioment es enviat a l’aplicatiu Android el
qual serà tractat i avisarà a l’usuari amb el missatge corresponent, si les dades són correctes
seran insertades i crearà un nou registre, el qual retornarà un valor numèric mitjançant el
count i que aquest l’enviarà a l’aplicatiu Android, perquè sigui tractat i avisi que el compte s’ha
creat correctament (figura 3.7)
figura 3.7- Stored Alta usuaris
Stored Existeix usuari
Amb el stored següents farà una validació que el DNI introduït depenent si el DNI existeix o no
el Stored retornarà un 1 (si existeix) o un zero (si no existeix) , aquest stored és molt important
, ja que, el DNI no pot estar repetit en el servidor de base de dades ha de ser únic.
figura 3.8 - Stored Existeix usuari