kryptopic : desenvolupament d'una aplicació...
TRANSCRIPT
Victor Aguilera Salleras Memòria del màster Pàgina 1
KryptoPic
Memòria del màster universitari de
seguretat en las tecnologies de la
informació
Autor: Victor Aguilera Salleras Director del projecte: Jordi Herrera Joancomartí Data: 01/06/2013
Victor Aguilera Salleras Memòria del màster Pàgina 2
Agraïments
Vull donar les gràcies a tots els membres de la UOC, especialment als professors, per tota la
ajuda amb la resolució de dubtes i el seguiment del màster a lo llarg d’aquests dos últims anys.
També vull agrair l’ajuda del Juan Antonio Boneu, per tota la feina desinteressada del disseny
dels gràfics de l’aplicació.
Victor Aguilera Salleras Memòria del màster Pàgina 3
Resum del treball
Resum
Aquest projecte consisteix en la realització d’una aplicació per Smartphones amb sistema
Android anomenada KryptoPic. Aquesta aplicació està enfocada en la realització de fotografies
xifrades i la gestió d’aquestes, tant des del punt de vista del propi xifratge com del possible
procés posterior de compartir imatges.
Per la realització ha sigut necessari seguir un procés que ha anat des de la comprensió de les
necessitats del problema fins al desenvolupament i disseny de l’aplicació adquirint
coneixements tant del desenvolupament d’aplicacions en Android com de funcions
criptogràfiques i relatives a la seguretat.
Summary
This project covers an application development for Smartphones under the Android system
called KryptoPic. This application is focused on capturing encrypted pictures and his
subsequent management, as much of the cryptography point of view itself as the possible
subsequent process of sharing the pictures.
For the development it has been required to follow a process that includes from the problem
requirements to the development and design of the application acquiring knowledge as much
the Android application development as cryptographic and security related functions.
Victor Aguilera Salleras Memòria del màster Pàgina 4
Contingut
1. Introducció ................................................................................................................................ 6
1.1 Objectius i Requisits ............................................................................................................ 7
Objectius ............................................................................................................................... 7
Requisits ................................................................................................................................ 7
2. Descripció i funcionament general de l’aplicació ...................................................................... 9
2.1 Casos d’us .......................................................................................................................... 12
3. Detalls de la implementació de l’aplicació .............................................................................. 13
3.1 Tecnologia emprada al projecte ........................................................................................ 13
Software .............................................................................................................................. 13
Hardware ................................................................................................................................. 13
3.2 Mòduls de l’aplicació i implementació .............................................................................. 14
3.2.1 Algoritme de xifrat ..................................................................................................... 14
3.2.2 Imatges xifrades ......................................................................................................... 14
3.2.3 Compartir imatges ...................................................................................................... 18
3.2.4 Gestió de la clau d’accés ............................................................................................ 18
3.2.5 Activitat principal ....................................................................................................... 20
3.2.6 Mòdul de preferències ............................................................................................... 20
3.2.7 Mòdul de càmera ....................................................................................................... 20
3.2.8 Mòdul BMPFactory ..................................................................................................... 20
3.2.9 Mòdul de xifratge ....................................................................................................... 21
3.2.10 Mòdul d’opcions ....................................................................................................... 21
3.2.11 Mòduls de diàleg ...................................................................................................... 22
3.2.12 Mòdul de visualització .............................................................................................. 24
3.3 Relacions entre mòduls ..................................................................................................... 27
4. Anàlisi de l’aplicació ................................................................................................................ 28
4.1 Test realitzats .................................................................................................................... 31
5. Conclusions.............................................................................................................................. 34
5.1 Possibles millores .............................................................................................................. 35
6. Bibliografia .............................................................................................................................. 36
7. Annexos ................................................................................................................................... 37
7.1 Algoritme SHA1 ................................................................................................................. 37
Perquè SHA1 i no MD5 ........................................................................................................ 37
Victor Aguilera Salleras Memòria del màster Pàgina 5
7.2 Algoritme AES .................................................................................................................... 39
7.3 Algorisme PBKDF2 ............................................................................................................. 41
Victor Aguilera Salleras Memòria del màster Pàgina 6
1. Introducció
Des de fa relativament pocs anys, els Smartphones han entrat amb força al mercat de la
telefonia mòbil esdevenint els tipus de terminals més comuns. Avui dia ja és d’allò més normal
fer servir el terminal per un munt de tasques no relacionades directament amb la telefonia.
Una de les funcionalitats més populars d’aquest tipus de dispositius és el de càmera
fotogràfica i actualment ja és estrany trobar un Smartphone que no compti de sèrie amb una
càmera.
Aquestes noves possibilitats, per desgracia també tenen la seva part dolenta, i a la vegada que
ens faciliten la vida i ens obren un nou món de possibilitats, també obren la porta a accessos
no desitjats a informació personal. Tot això afegit a la volatilitat de la informació digital (és
fàcilment eliminable, corrompible o reproduïble) i les tarifes planes a dades, presenta nous
problemes de cara a la seguretat.
Centrant-nos en el camp de la fotografia, la idea d’aquest TFM és implementar una solució per
poder protegir aquestes fotos en cas de robatori, pèrdua de mòbil o accés no autoritzat al
terminal.
En concret es tracta de desenvolupar una aplicació Android per xifrar les fotografies que
realitzem des del terminal.
Victor Aguilera Salleras Memòria del màster Pàgina 7
1.1 Objectius i Requisits
Objectius
Després d’examinar l’actual mercat d’Android (Google Play) no s’han acabat de trobar
solucions satisfactòries al problema de la seguretat de les fotografies realitzades amb el
terminal. S’ha trobat programari que ataca el problema però de manera poc efectiva o amb
solucions parcials, com aplicacions que xifren les fotografies un cop realitzades, convertint-les
en fitxers de dades i tractant-les de manera individual.
L’objectiu és proporcionar una eina que integri tant la realització de fotos com la visualització
d’aquestes a partir d’una clau proporcionada per l’usuari. A la vegada, caldria que les fotos
xifrades continuessin sent fotos per tal de no alterar el funcionament normal del dispositiu.
S’ha decidit dissenyar l’aplicació intentant mantenir un equilibri entre usabilitat i seguretat.
Molt possiblement és podria haver dissenyat l’aplicació de manera més segura, però s’ha optat
en sacrificar una mica la seguretat per millorar l’experiència de l’usuari.
Partint d’aquesta òptica s’aniran explicant les successives decisions de disseny en base a
mantenir una galeria de mida mitja d’imatges privades amb visualització àgil que no pas una
aplicació per tenir unes poques imatges amb seguretat molt elevada i de difícil accés.
Requisits
Per tal de realitzar la tasca proposada, s’han establert els següents requisits funcionals que és
creu que hauria de complir la aplicació tal com està definida:
Realitzar fotos amb l’aplicació: La aplicació ha de permetre per ella mateixa realitzar
fotos que quedin automàticament xifrades sense haver de accedir a cap altra opció de
gestió d’arxius o fotografies per realitzar aquesta opció.
Xifrar fotos ja existents a la galeria: La aplicació també ha de permetre seleccionar una
imatge existent a la galeria i xifrar-la, ja sigui amb una clau genèrica, com una clau
puntual.
Enviar o compartir una foto: L’aplicació ha de permetre enviar una imatge xifrada a
traves dels canals disponibles al terminal. Abans d’enviar la foto, s’ha de poder
assignar una nova contrasenya específica.
Les imatges xifrades s’han de poder visualitzar a traves de l’aplicació ja sigui fent servir
la contrasenya per defecte o demanant a l’usuari que entri una contrasenya en cas de
ser diferent a la contrasenya per defecte.
Requisits de seguretat:
Victor Aguilera Salleras Memòria del màster Pàgina 8
Fent referencia a la seguretat, l’aplicació ha de xifrar cada foto automàticament al fer-
la amb un algoritme suficientment robust i que evidentment permeti la seva posterior
visualització.
Cada imatge ha de poder-se xifrar amb una contrasenya diferent en cas de voler
compartir-la per no haver de donar la teva pròpia contrasenya.
L’aplicació ha de poder comprovar la validesa de les contrasenyes emprades (si una
contrasenya és vàlida per una imatge o si la contrasenya introduïda coincideix amb la
genèrica) però en cap moment s’han de desar les contrasenyes en clar a la memòria
física.
L’aplicació no ha de permetre en cap cas la visualització d’una imatge si la contrasenya
proporcionada no és vàlida.
Imatge 1
Victor Aguilera Salleras Memòria del màster Pàgina 9
2. Descripció i funcionament general de l’aplicació
Com s’ha comentant anteriorment, l’aplicació basa el seu funcionament en la realització de
fotografies i el posterior xifratge d’aquestes.
Finalment s’ha decidit establir una contrasenya global per l’aplicació que serveixi per xifrar i
desxifrar imatges automàticament i eliminar la possibilitat d’establir una contrasenya
personalitzada per cada imatge. Aquesta decisió ve donada per un fet d’usabilitat, ja que tenir
un munt d’imatges amb contrasenyes diferents al final acaba portant a confusió i poca agilitat
per visualitzar fotos. Per l’altra banda hi hauria una possibilitat molt elevada de que l’usuari
acabés oblidant alguna de les contrasenyes emprades.
Arribats a aquest punt ens trobem amb una problemàtica: Si l’usuari decideix canviar la
contrasenya de l’aplicació, ens obligaria a desxifrar totes les imatges del dispositiu i tornar-les
a xifrar, cosa que podria implicar un temps considerable així com el perill d’interrupció del
procés (per falta de bateria per exemple) i quedar-se amb la meitat d’imatges amb
contrasenyes diferents. Aquesta problemàtica es tractarà més endavant.
Quan accedim a l’aplicació per primer cop, l’aplicació detectarà que no hi ha cap configuració
disponible (Imatge 1) i es demanarà a l’usuari que creï la seva contrasenya per defecte que
servirà accedir en un futur a l’aplicació i xifrar les imatges. Aquesta contrasenya no es podrà
recuperar i serà necessària cada cop que es vulgui accedir a l’aplicació en un futur. En aquesta
versió no s’ha implementat cap mecanisme de recuperació de la contrasenya.
En cas que el programa ja hagi estat configurat amb anterioritat, se li demanarà aquesta
contrasenya per tal de poder accedir al programa. Si la contrasenya s’introdueix
incorrectament més de tres cops, l’aplicació finalitzarà sense donar accés a la mateixa.
Funcionalment, l’aplicació està dividida en dues seccions principals, la realització de fotos i la
visualització d’aquestes i un cop introduïda la contrasenya, l’aplicació mostrarà el menú
principal amb 3 opcions, com es pot veure a la imatge 1:
Capturar una imatge
Visualitzar imatges
Canviar contrasenya
També tenim una icona per accedir al menú d’opcions des de la barra d’eines de l’aplicació.
Si l’usuari accedeix al menú d’opcions, se li donarà l’opció de canviar la seva contrasenya del
programa o d’obtenir informació sobre el programa actual (versió, etc.).
L’opció de capturar imatge accedirà directament a l’aplicació per defecte del Smartphone per
realitzar fotografies. (Recordem que al sistema Android es poden tenir diverses aplicacions de
tipus càmera, disponibles per qualsevol altra aplicació).
Un cop realitzada la fotografia i acceptada la vista prèvia, aquesta és xifrada automàticament i
desada a la carpeta d’imatges del programa que normalment és ‘/pictures/kryptopic’. Aquesta
Victor Aguilera Salleras Memòria del màster Pàgina 10
carpeta és pública i accessible des de la galeria d’imatges per defecte d’Android. La situació
d’aquest directori dependrà del propi sistema i pot trobar-se tant a la memòria interna del
terminal com a la memòria externa en forma de SDCARD.
Després d’això l’usuari torna a la pantalla principal.
Imatge 2
La darrera opció és la visualització d’imatges. Si l’usuari accedeix a aquesta opció, l’aplicació
obrirà la galeria d’imatges d’Android, o en cas d’haver-hi més d’una aplicació de galeria
instal·lada al dispositiu, ens permetrà escollir la que vulguem per tal de seleccionar una
imatge.
Un cop la imatge estigui seleccionada, hi ha dues possibilitats:
És una imatge xifrada per l’aplicació: En aquest cas, es provarà de desxifrar la imatge
amb la contrasenya genèrica.
Si tot és correcte, la imatge es mostrarà a la pantalla, en cas contrari, l’aplicació
interpretarà que la imatge està xifrada amb una altra contrasenya (una imatge enviada
per algun amic per exemple) i demanarà a l’usuari que la introdueixi per poder
visualitzar aquella imatge. En aquest moment, la imatge només es visualitzarà si la
contrasenya introduïda per l’usuari és correcta.
És una imatge sense xifrar: En cas de ser una imatge sense xifrar, l’aplicació no
realitzarà cap acció extra, simplement carregarà la imatge i la mostrarà al visor
Victor Aguilera Salleras Memòria del màster Pàgina 11
d’imatges.
Un cop es visualitza la imatge, disposàrem d’una barra d’eines amb les següents opcions:
Xifrar imatge: Aquesta opció només estarà disponible si la imatge és una imatge sense
xifrar. En aquest cas l’aplicació xifrarà la imatge actual amb la contrasenya de l’usuari
(en cap cas es demanarà una contrasenya nova per xifrar imatges nostres). La imatge
sense xifrar serà eliminada i deixarà d’estar disponible.
Desxifrar imatge: Aquesta opció només estarà disponible si la imatge és una imatge
xifrada. En aquest cas la imatge xifrada és eliminada i es crea una imatge nova sense
xifrar a partir de la visualització actual.
Eliminar imatge: Aquesta opció ens permet eliminar la imatge que estem visualitzant
en aquell moment.
Compartir: Aquesta darrera opció, és de les característiques més interesants del
programa. Ens permet compartir la imatge actual fent servir les opcions per compartir
imatges que disposi el dispositiu (correu electrònic, Facebook, Whatsapp, etc.). Per
aquesta fi, es demanarà a l’usuari que introdueixi una contrasenya nova per aquella
imatge. Posteriorment, la imatge és xifrarà amb aquesta nova contrasenya i s’enviarà
mitjançant el mètode seleccionat. D’aquesta manera evitarem comprometre la nostra
contrasenya personal, i només les persones que coneguin aquesta nova contrasenya
seran capaces de visualitzar la imatge. En tot cas, el receptor de la imatge o la persona
que vulgui visualitzar aquestes imatges xifrades, caldrà que disposi també de
l’aplicació instal·lada.
Victor Aguilera Salleras Memòria del màster Pàgina 12
2.1 Casos d’us
A continuació es mostra un diagrama amb els casos d’us de l’aplicació i les diferents relacions
entre aquests. Les fletxes indiquen el flux de l’aplicació a traves de les diferents opcions
d’aquesta.
Imatge 3
Victor Aguilera Salleras Memòria del màster Pàgina 13
3. Detalls de la implementació de l’aplicació
3.1 Tecnologia emprada al projecte
Per la realització d’aquest treball s’han fet servir diverses eines tant per la programació de
l’aplicació com pel disseny dels seus recursos gràfics (imatges de fons, icones, etc...)
Per altra banda, només hem pogut disposar de dos terminals bastant similars entre ells per
poder testejar l’aplicació en un entorn real.
A continuació es mostra una relació d’aplicacions i hardware fet servir per la realització
d’aquest treball:
Software
The Android Developer Tools v21.1.10
(http://developer.android.com/tools/sdk/eclipse-adt.html)
Oracle Eclipse Juno v4.2.1
Android SDK
Oracle Java JDK 1.7
Adobe Photoshop CS5 (http://www.photoshop.com)
Gliffy (http://www.gliffy.com)
Hardware
Samsung Galaxy S2 GT-I9100 (Android 4.1.2 custom ROM)
Samsung Galaxy S3 GT-I9300 (Android 4.2 custom ROM)
Victor Aguilera Salleras Memòria del màster Pàgina 14
3.2 Mòduls de l’aplicació i implementació
En aquesta secció es descriuen les implementacions i decisions de disseny de les diferents
parts de l’aplicació, així com una descripció dels mòduls dels que es composa, encarregats
cadascun d’una tasca concreta.
3.2.1 Algoritme de xifrat
Degut a les necessitats del projecte en quant a xifratge (i.e. la necessitat de xifrar imatges i
contrasenyes amb possibilitat de tornar al seu estat original fent servir la mateixa contrasenya)
s’ha optat per fer servir l’algoritme AES128. Aquest algoritme és un algoritme simètric molt
popular que proveeix d’un xifratge suficientment robust per considerar-lo adient al projecte.
(A l’apèndix és pot trobar un apartat dedicat a aquest algoritme).
Encara que l’opció desitjada era fer servir l’algoritme AES256, s’ha optat finalment per
l’AES128 degut a les restriccions legals d’aquest algoritme segons el país.
3.2.2 Imatges xifrades
Un altre dels requeriments bàsics a l’hora de dissenyar l’aplicació era que les imatges
mantinguessin el seu estatus d’imatge encara que estiguessin xifrades. Una de les grans
mancances en totes les aplicacions examinades de xifratge de imatges és el tractament dels
fitxers xifrats. La problemàtica bé del fet que una imatge quan es xifra, deixa de ser imatge per
passar a ser un conjunt de bytes aleatoris (des del punt de vista de visualització).
Des d’un principi, una de les màximes d’aquest projecte ha estat trobar una manera de
mantenir les imatges xifrades amb format d’imatge (encara que visualment no aportin cap
informació útil). L’objectiu d’això és no alterar de cap manera el normal funcionament dels
dispositius o ús de la imatge. És a dir, encara que la imatge estigui xifrada, aquesta és seguirà
tractant com imatge a la galeria d’imatges d’Android i és seguirà podent compartir a traves de
xarxes socials i fent el mateix ús que si es tractés d’una imatge normal.
Potser l’única excepció en aquest punt, seria el cas de tractar la imatge (e.g. modificar-la amb
un editor d’imatges). Per aquest fi i per tal de conservar el format d’imatge a partir d’un array
de bytes xifrat, s’ha optat per afegir una capçalera d’imatge BMP al conjunt de bytes xifrats per
tal de simular una imatge real. D’aquesta manera, les imatges xifrades tindran format BMP i
podran ser tractades com imatge.
A la següent imatge podem veure com es visualitza una imatge xifrada. Com podem observar,
encara que la imatge segueix sent visualitzable i tractable com a tal, el seu contingut és
totalment aleatori i impossible de visualitzar si no desxifrem la imatge.
Victor Aguilera Salleras Memòria del màster Pàgina 15
Per tal d’aconseguir visualitzar la imatge xifrada, inicialment es va sopesar l’opció de xifrar la
imatge i provar de mostrar aquesta imatge xifrada. El problema en aquest cas és que Android
per defecte, fent servir la seva càmera, treballa amb imatges JPG. L’algoritme JPG a més
d’aplicar una capa de compressió, és un algoritme dels anomenats LOSSY, això és, que
introdueix pèrdues a la qualitat d’imatge per tal homogeneïtzar la imatge resultant i millorar la
compressió. De fet, aquest format ni tant sols tracta la imatge com un conjunt de píxels
directament, si no que treballa a nivell de freqüències focalitzant el resultat totalment a la
reducció de la mida final. D’aquesta manera és impossible, generar una imatge xifrada i
convertir-la a format JPG, ja que encara que especifiquéssim una pèrdua de qualitat del 0% (el
format JPG permet especificar la quantitat de pèrdua que es vol aconseguir), donat els
algoritmes de procés aplicats a la imatge, és impossible assegurar que no s’hi ha produït una
modificació d’un byte.
Donat que l’algoritme de xifratge emprat a l’aplicació és l’AES (en mode ECB), una alteració
d’un sol byte resultaria en la impossibilitat de desxifrar la imatge.
Per tal de solucionar aquest problema, hem ideat un sistema fent servir un format LOSSLESS
(sense pèrdua), per tal de poder manegar els bytes interns sense por a una alteració posterior.
En aquest cas s’ha optat pel format BMP, ja que és un format força simple i molt popular, amb
lo que no hi hauria d’haver problemes de compatibilitat.
El format BMP va ser dissenyat per Microsoft pel Windows 1.0 i també es va fer molt popular
al OS/2 (en la seva versió del format). Encara que l’especificació inicial era molt simple, tenia
una paleta fixa de colors, no suportava compressió i estava enfocat a les targetes gràfiques de
l’època (CGA, EGA, Hercules, etc.).
Actualment, encara que el format ja suporta compressió i diverses opcions, és possible definir
BMP amb opcions mínimes i sense compressió en 54 bytes de manera que sigui sent totalment
compatible.
A continuació és mostra una taula amb la capçalera del format BMP emprat:
Imatge 4
Victor Aguilera Salleras Memòria del màster Pàgina 16
Offset Size Description
0 2 signature, must be 0x4D42
2 4 size of BMP file in bytes (unreliable)
6 2 reserved, must be zero
8 2 reserved, must be zero
10 4 offset to start of image data in bytes
14 4 size of BITMAPINFOHEADER structure, must be 40
18 4 image width in pixels
22 4 image height in pixels
26 2 number of planes in the image, must be 1
28 2 number of bits per pixel (1, 4, 8, or 24)
30 4 compression type (0=none, 1=RLE-8, 2=RLE-4)
34 4 size of image data in bytes (including padding)
38 4 horizontal resolution in pixels per meter (unreliable)
42 4 vertical resolution in pixels per meter (unreliable)
46 4 number of colors in image, or zero
50 4 number of important colors, or zero
A partir d’aquest punt, la solució adoptada consisteix en crear una capçalera BMP per sobre
del fitxer JPG, que contingui aquest i permeti mantenir les dades com a imatge vàlida.
D’aquesta manera es pot xifrar tot el fitxer JPG original sense modificar-lo o tractar-lo de cap
manera.
En aquest punt, prenent el fitxer JPG xifrat com a un bloc de bytes, es calcula quina alçada i
amplada aproximada tindria una imatge quadrada que contingués aquella quantitat de bytes:
Mida = Round(sqrt(bytes.length()/3)-1);
Victor Aguilera Salleras Memòria del màster Pàgina 17
Aprofitant que la imatge JPG xifrada és un bloc de bytes de mida variable, afegirem abans
d’aquest buffer de dades, una capçalera nostra que ens permetrà verificar la imatge abans de
desxifrar-la i identificar-la com a imatge xifrada per l’aplicació.
La capçalera és la següent:
Offset Mida Descripció
0 5 signatura, string “krypt”
5 1 Versió de la imatge (per si en un futur afegíssim
capacitats noves al fitxer xifrat)
6 20 Resum SHA1 de la clau per desxifrar la imatge
El primer camp és simplement una cadena de text amb el text “krypt”.
El segon camp és un byte amb el número de versió del format de la imatge. Aquest
número ens pot servir donat que en cas de treure noves versions de l’aplicació que
ampliessin les possibilitats afegint informació a la imatge (i.e. coordenades on es va
xifrar, o identificador de l’usuari que la va xifrar), la nova aplicació pogués detectar
imatges de versions anteriors i tractar-les correctament.
Finalment, per optimitzar tot el procés, s’ha inclòs el hash SHA1 de la contrasenya
necessària per desxifrar la imatge, de manera que es pot comprovar si la contrasenya
és correcta abans de desxifrar la imatge i d’aquesta manera estalviar temps de procés
o resultats no desitjats (amb l’AES128, encara que la possibilitat és molt petita, es pot
donar el cas de processar correctament una imatge amb una contrasenya incorrecta
encara que els resultats fossin aleatoris).
Un cop tenim un buffer de bytes amb la imatge xifrada precedida de la nostra capçalera es
construeix una imatge BMP a mida, amb l’alçada i amplada calculades prèviament , que conté
el nostre buffer de bytes. Com que el format BMP permet especificar un format d’imatge
sense compressió, els visualitzadors mostraran correctament la imatge, encara que les dades,
siguin dades xifrades.
El format final de la imatge quedaria de la següent manera:
Victor Aguilera Salleras Memòria del màster Pàgina 18
Capçalera BMP
Capçalera KryptoPic
Dades xifrades
D’aquesta manera, també es resol el problema de la mida, ja que una JPG està ja comprimida i
les dades xifrades tindran una mida molt similar (quasi exacta) a les dades originals. Si
xifréssim nosaltres la imatge en format cru, caldria que implementéssim algun sistema de
compressió (ja que una imatge JPG de 2MB, podria ocupar fàcilment més de 10MB).
3.2.3 Compartir imatges
Un dels requisits i punts claus del desenvolupament d’aquesta aplicació, és el fet de poder
compatir les imatges xifrades fent servir els canals disponibles al terminal (e-mail, whatsapp,
instagram, ...).
Aquest punt presentava unes problemàtiques clares relatives al tema de la seguretat: Per una
banda no podem donar la nostra contrasenya per permetre a la resta de gent veure certes
imatges i de totes maneres, com s’ha explicat a l’anterior apartat, la nostra contrasenya no és
més que per poder accedir a la contrasenya real que ni tan sols coneixem.
La solució en aquest cas ha estat forçar a l’usuari a xifrar de nou la imatge en el moment en
que es vol compartir. En el moment que un usuari selecciona l’opció de compartir imatge, es
demana que s’introdueixi una nova contrasenya (que per seguretat es comprova que sigui
diferent a la pròpia de l’usuari). Amb aquesta nova contrasenya es crea una copia temporal
xifrada de la imatge original (no es modifica en cap cas la imatge original) i s’esborrarà en el
moment que la imatge és enviada a l’aplicació corresponent.
3.2.4 Gestió de la clau d’accés
La gestió de la clau d’usuari és bastant senzilla, alhora que efectiva.
Un cop obtinguda la contrasenya per part de l’usuari, haurem de derivar d’aquesta una altra
clau vàlida fent servir l’algoritme PBKDF2 (clau de l’usuari). Això és debut a que al fer servir
Victor Aguilera Salleras Memòria del màster Pàgina 19
l’algorisme AES128, ens caldrà una clau d’exactament 128 bits (16 bytes) i no ens serveix
qualsevol contrasenya introduïda per l’usuari. D’aquesta manera també ens assegurem una
contrasenya amb una bona entropia i un salt incorporat (el algorisme PBKDF incorpora un salt).
Per altra banda l’aplicació generarà una altra contrasenya (aquesta ja de 128 bits) aleatòria
(clau mestra de xifrat). Aquesta contrasenya aleatòria, serà la contrasenya real que es farà
servir per xifrar i desxifrar imatges. Aquesta clau mestra de xifrat estarà xifrada fent servir
l’algoritme AES128 emprant com a contrasenya, la clau de l’usuari (contrasenya de l’usuari
derivada amb l’algoritme PBKDF).
Imatge 5
D’aquesta manera, si l’usuari no introdueix la contrasenya correctament, no es tindrà accés a
la contrasenya mestra. Això soluciona un altre dels problemes esmentats a l’apartat de
descripció del funcionament general de l’aplicació. Es comentava que si l’usuari vol canviar la
seva contrasenya, la problemàtica esdevindria la gran carrega que suposa el fet de desxifrar i
tornar a xifrar totes les imatges. Fent servir aquest sistema, només caldria desxifrar i tornar a
xifrar la contrasenya mestra generada per l’aplicació amb la nova clau d’usuari derivada de la
nova contrasenya de l’usuari.
S’ha decidit en aquest cas no guardar cap referencia o hash a la clau a les preferències de
l’aplicació. Normalment en aplicacions d’aquest tipus, es té guardat el hash de la clau i es fan
les comprovacions de la clau correcta contra aquest hash. En el nostre cas simplement es
guarda la contrasenya mestra xifrada amb AES128, i es prova de desxifrar cada cop que l’usuari
entra la seva contrasenya.
Victor Aguilera Salleras Memòria del màster Pàgina 20
3.2.5 Activitat principal
Un dels elements principals del sistema Android són les activitats (Activities). Aquestes
activitats són objectes proporcionats pel propi sistema i podrien ser definides, de manera
enfocada a la redacció d’aquest document1, com lo que en altres OS d’escriptori coneixem com
“finestra”.
En aquest cas concret, l’activitat representa la vista o pantalla principal de l’aplicació (Veure
imatge 1). Mostra aquesta vista i les tres opcions principals (fer fotografies, visualitzar imatges
i anar al menú d’opcions).
Aquest mòdul també és l’encarregat de demanar i verificar la contrasenya. Quan s’inicia el
programa, comprova que existeixi alguna contrasenya guardada a la memòria física i mostrà el
diàlegs de creació de contrasenya nova o de demanar contrasenya actual segons el resultat.
3.2.6 Mòdul de preferències
Aquest mòdul conté les funcions auxiliars per facilitar la interacció amb la configuració del
programa. Permet desar i recuperar valors de configuració de l’aplicació com la contrasenya
del programa. Facilita la conversió de cadenes text a arrays binaris.
3.2.7 Mòdul de càmera
Gestiona el funcionament de la càmera activant-la quan és necessari i recollint la imatge
resultant del procés. Fa servir el Intent de càmera per defecte d’Android i recull la informació
resultant, que pot ser la cancel·lació del procés de presa de fotografia o la URI del fitxer amb la
fotografia realitzada.
3.2.8 Mòdul BMPFactory
En aquest mòdul és troben totes les funcions encarregades de crear un fitxer BMP,
especialment les funcions que generen la capçalera BMP i la capçalera pròpia de l’aplicació.
També des d’aquest mòdul es gestionen els processos de xifrat i desxifrat, encara que les
funcions de xifratge no estiguin contingudes pròpiament en aquest mòdul.
Finalment, és l’encarregat de llegir les capçaleres de les imatges BMP i comprovar que es
tracten d’ imatges creades amb l’aplicació i que la contrasenya proporcionada per desxifrar-les
coincideix amb el hash SHA1 trobat a la capçalera.
1 Encara que la documentació oficial d’Android dona una definició més extensa del concepte Activity,
s’ha simplificat la definició amb objectiu de millorar la redacció i claredat del document
Victor Aguilera Salleras Memòria del màster Pàgina 21
3.2.9 Mòdul de xifratge
Com el seu nom indica, aquest mòdul és l’encarregat de gestionar les funcions de xifratge
emprant l’algoritme AES permetent xifrar o desxifrar un buffer de bytes. També és el mòdul
encarregat de generar les contrasenyes aleatòries així com contrasenyes vàlides mitjançant
l’algoritme PBDKF2. El mateix mòdul conté el salt que fa servir l’aplicació per aquest propòsit.
També podem trobar aquí, funcions auxiliars com la del càlcul del hash SHA1, a partir d’un
array de bytes.
3.2.10 Mòdul d’opcions
Aquest mòdul representa a la activitat que representa el menú d’opcions de l’aplicació. En
aquest menú podem seleccionar tant l’opció de canviar la nostra contrasenya personal com
poder veure informació sobre la versió actual de l’aplicació.
Com s’ha comentat abans, si canviem la contrasenya de l’usuari, en realitat només desxifrem i
tornem a xifrar la clau mestra de l’aplicació amb la nova contrasenya personal evitant la
càrrega extra de desxifrar i xifrar un altre cop totes les imatges.
Imatge 6
Victor Aguilera Salleras Memòria del màster Pàgina 22
3.2.11 Mòduls de diàleg
Aquests mòduls, comprenen tots aquests que representen el diàlegs de l’aplicació:
Mòdul Alertbox: Diàleg que mostra un missatge amb un botó. Emprat per donar la
benvinguda al programa el primer cop que s’accedeix a la aplicació i com a explicació
prèvia de la necessitat d’establir una contrasenya per l’usuari.
Imatge 7
Mòdul de contrasenya: Aquest mòdul és l’encarregat de demanar la contrasenya a
l’usuari i comprovar que correspon amb la contrasenya guardada per l’aplicació. En cas
negatiu i després de tres errors, retornarà amb un missatge de cancel·lació que
l’activitat principal interpretarà com un senyal per finalitzar l’aplicació.
Imatge 8
Victor Aguilera Salleras Memòria del màster Pàgina 23
Canvi de contrasenya: És el mòdul encarregat tant d’establir la contrasenya de l’usuari
el primer cop que s’accedeix a l’aplicació com de canviar-la més endavant. És el mòdul
que controla el diàleg amb dues caixes d’introducció contrasenya i que valida que
siguin iguals per tal d’acceptar la nova contrasenya.
Imatge 9
Contrasenya d’imatges: És el mòdul encarregat de gestionar el diàleg que demana i
comprova la contrasenya en el cas de voler visualitzar una imatge que no estigui
xifrada amb la nostra contrasenya de l'aplicació.
Imatge 10
Victor Aguilera Salleras Memòria del màster Pàgina 24
3.2.12 Mòdul de visualització
Aquest és un dels mòduls principals, correspon a la activitat del visualitzador d’imatges. Per si
sol, no té gaire funcionalitat pròpia tret de mostrar una imatge. Però és el mòdul que
s’encarrega de gestionar les crides a la resta de mòduls per xifrar, desxifrar, demanar
contrasenyes o gestionar les imatges.
Quan s’accedeix a aquesta activitat des del menú principal, el primer que es fa és cridar a la
galeria d’imatges. En cas de cancel·lar o error a l’obrir la imatge, es retorna al menú principal.
Quan es selecciona una imatge correctament, l’aplicació provarà de llegir la capçalera de
l’aplicació per obtenir la signatura interna i la clau SHA1. Si la signatura no coincideix,
l’aplicació interpretarà que estem davant d’un fitxer JPG normal i procedirà a mostrar la
imatge sense processar-la de cap manera. En aquest cas, l’opció de la barra d’eines de
desxifrar no estarà disponible ja que la imatge a mostrar no està xifrada.
Imatge 11
En cas de trobar la signatura de l’aplicació al fitxer de la imatge (la cadena ‘kryptopic’ a una
posició concreta del fitxer) es procedirà a comparar el hash SHA1 trobat també a l’interior del
fitxer, amb el hash SHA1 de la clau mestra de la aplicació.
Victor Aguilera Salleras Memòria del màster Pàgina 25
En el cas de que coincideixin, es procedirà a desxifrar la imatge fent servir la clau mestra de la
aplicació. Per aquest fi, es crearà un fitxer temporal amb format JPG a partir del fitxer BMP
amb la imatge desxifrada i es visualitzarà aquest fitxer.
Si per altra banda el hash contingut a la imatge no coincideix amb el de la clau mestra,
l’aplicació interpretarà que la clau utilitzada per xifrar la imatge és diferent (normalment
imatges xifrades que envia una altra persona) i passarà a mostrar un diàleg de introducció de
contrasenya. Si la contrasenya és correcta, es procedirà com al cas anterior creant un fitxer
temporal desxifrat i mostrant-lo. En cas contrari es tornarà al menú principal. En ambdós casos
la icona de xifrar no estarà disponible ja que les imatges són imatges xifrades.
Imatge 12
Durant la visualització de les imatges, depenent de si són imatges xifrades o no, tindrem
disponibles les opcions de desxifrar i xifrar respectivament. Aquestes dues opcions crearan un
fitxer nou (JPG o BMP segons escaigui) i esborraran el fitxer original.
També tindrem l’opció en tot moment d’esborrar la imatge actual.
En cas que visualitzant una imatge es premi la icona de compartir, s’obrirà el diàleg
d’introducció de contrasenya i es procedirà a xifrar la imatge amb aquesta nova contrasenya.
Victor Aguilera Salleras Memòria del màster Pàgina 26
Posteriorment es demanarà que es seleccioni l’aplicació amb la que volem compartir la imatge
i es deixarà a disposició de l’aplicació destí la gestió de la imatge xifrada.
Imatge 13
En tots els casos, en el moment que s’abandona l’activitat de visualització, s’eliminen totes les
imatges temporals que s’hagin creat.
Victor Aguilera Salleras Memòria del màster Pàgina 27
3.3 Relacions entre mòduls
Imatge 14
Les fletxes indiquen que un mòdul envia informació de retorn en aquella direcció, per
exemple, el mòdul de xifratge, envia les dades d’una imatge xifrada a BMP Factory,
que a la seva vegada, construeix una imatge BMP i la retorna al mòdul de visualització.
Victor Aguilera Salleras Memòria del màster Pàgina 28
4. Anàlisi de l’aplicació
En aquesta secció es pretén analitzar la seguretat de l’aplicació i els seus sistemes per protegir
la informació.
Per poder analitzar la seguretat que l’aplicació aporta, cal posar en perspectiva l’objectiu
general d’aquesta. La aplicació està clarament enfocada a un tipus d’usuari estàndard i
majoritari dintre del món dels Smartphones. Això és, gent sense coneixements tècnics, fent un
ús personal de les aplicacions de manera no professional.
En altres paraules, l’aplicació està dissenyada amb l’objectiu de satisfer les necessitats de
privacitat d’un usuari comú provant de mantenir un nivell de seguretat acceptable però en cap
cas dissenyat per satisfer necessitats de xifratge professional o amb objectius professionals.
En qualsevol cas, res impedeix fer servir l’aplicació per protegir informació sensible de manera
professional. Queda a discreció del professional avaluar si l’aplicació compleix els requisits en
cada cas.
A continuació s’analitzen les característiques o sistemes de seguretat que l’aplicació
implementa:
El principal sistema, tant per xifrar imatges com la contrasenya personal de l’usuari és
l’algorisme AES128. Aquest algorisme ja ha sigut comentat prèviament. En aquest cas
voldríem fer èmfasi en la seguretat que aquest algorisme aporta. Com s’ha comentat
abans, s’ha escollit aquesta versió del algorisme donat que molts governs posen
restriccions a la exportació i importació de dades criptogràfiques en versions més
potents del mateix algorisme.
Amb tot, aquest algorisme es considera segur, ja que encara que a finals de 2009 es va
poder fer un atac a l’algorisme millorant la velocitat de procés respecte a un atac de
força bruta, segueix sent segur ja que el temps de procés és massa alt. Oficialment
aquest algorisme no es considera trencat, per lo tant considerem que les imatges
xifrades són impossibles de desxifrar si no es coneix la clau de xifratge. Afegint que
l’usuari no coneix la clau de xifratge (només disposa de la clau per poder desxifrar la
veritable clau), en cas de accés no autoritzat al sistema i sostracció de les imatges, faria
impossible la visualització d’aquestes des del punt de vista de trencar l’algorisme.
A l’anterior punt s’analitza la seguretat des del punt de vista del algorisme de xifratge
de les imatges, però cal tenir en compte que cada imatge incorpora el hash SHA1 de la
clau amb la que ha estat xifrada.
És coneguda la possibilitat de generar col·lisions per aquest algorisme i per tant la seva
debilitat (encara que no es una tasca trivial), però aquest no es un problema que afecti
a l’aplicació (ja que necessitem la clau exacta per desxifrar l’algorisme AES.
Lo interesant en aquest cas, seria analitzar la possibilitat de trencar la clau amb un atac
de força bruta.
La clau que es vol obtenir, es una clau vàlida per xifrar amb l’algorisme AES128. Com el
seu nom indica, la mida de la clau es de 128 bits (16 bytes), això ens dona un total de
Victor Aguilera Salleras Memòria del màster Pàgina 29
2^128 possibilitats per calcular. Avui dia, la possibilitat de programar GPUs mitjançant
CUDA per fer tasques no relacionades directament amb els gràfics, ha permès disposar
d’una potencia de càlcul molt superior a la d’una CPU convencional que sacrifica la
seva potencia crua de càlcul a canvi de la seva versatilitat.
En aquests moments la velocitat mitja per processar hashos SHA1 es situa de mitja en
els 85 milions de hashos per segon.
Si fem els càlculs dels 2^128 possibles hashos entre els 85 milions de hashos
processables per segon, podem veure que encara que disposéssim de varies GPUs
processant hashos paral·lelament, seria inviable trobar la clau en un temps raonable.
Per tant, es considera segur per l’aplicació incloure el hash SHA1 dintre de la pròpia
imatge.
El següent punt a tractar seria l’emmagatzemat de la contrasenya mestra. Aquesta
s’emmagatzema xifrada amb AES128 dintre de les preferències del sistema Android.
En aquest cas s’ha decidit no guardar ni tant sols el hash d’aquesta clau i comprovar la
seva validesa en funció del correcte processament del algorisme de desxiframent del
AES128. Pel funcionament de l’algorisme AES128, sabem que la majoria dels casos
produiran un error al provar de desxifrar un bloc de dades AES si la clau d’usuari no és
vàlida, però no s’ha considerat perillós el fet de que és produís un processament
correcte de l’algorisme amb una clau incorrecta, ja que la possibilitat de que es
produeixi amb una altra clau alfanumèrica és pràcticament nul·la, i encara que això
passés, el resultat AES obtingut (la clau mestra), seria errònia.
Aquestes preferències, en principi són privades per cada aplicació i cap aplicació pot
accedir a les preferències d’una altra aplicació. Tampoc un usuari manualment. Aquí el
problema ve amb els telèfons “rootejats”, ja que en aquest cas, l’usuari té accés a tot
el sistema lliurament i podria llegir les preferències. En aquest cas tampoc es considera
una amenaça, ja que les dades que podria llegir un atacant, seria al contrasenya
mestra xifrada amb AES128 i com s’ha discutit anteriorment, les dades xifrades amb
aquest algorisme es consideren prou segures
L’últim punt a tractar és sobre el sistema de fitxers i el procés de xifratge i
desxiframent. L’aplicació per poder xifrar i desxifrar imatges, necessita crear fitxers
temporals a partir de la imatge original per poder tractar-la. Aquests fitxers s’esborren
en quant s’han fet servir o en tot qualsevol cas, en el moment que es destrueix
l’activitat de visualització.
El problema en aquest cas, ve del funcionament del sistema de fitxers. L’Android
gestiona dos tipus de memòria: La memòria interna i la memòria externa (normalment
en forma de SDCARD extraïble.
El fet de seleccionar una o una altra, queda a discreció del sistema operatiu. En
principi, fitxers multimèdia són guardats a la memòria externa si està disponible, però
no sempre es pot assegurar aquesta afirmació. El sistema Android pot acceptar els
sistemes de fitxers FAT32, EXT3 i EXT4, encara que lo normal és acceptar que la
Victor Aguilera Salleras Memòria del màster Pàgina 30
SDCARD estarà en format FAT32, ja que no és tan simple o a nivell d’usuari fer servir
els altres sistemes de fitxers en tots els terminals Android.
El sistema FAT32, per gestionar els fitxers que conté, implementa una taula interna
(amb una còpia de la mateixa) on conté un índex amb tots el fitxers del sistema i la
seva posició a la memòria tal com podem veure a la següent imatge:
Imatge 15
Quan creem un nou fitxer al sistema de fitxers, s’afegeix un nou element al índex FAT i
es marca l’espai que ocupa el fitxer com ocupat.
El problema ve quan s’elimina un fitxer: L’acció d’esborrar no existeix a les memòries.
A una memòria s’escriuen dades o es modifiquen, sempre contenen algun valor,
encara que aquest sigui aleatori). El procediment a seguir en el sistema FAT32 (i en la
majoria de sistemes de fitxers), és marcar el fitxer com eliminat a l’índex, i marcar
l’espai com a lliure. D’aquesta manera, el fitxer segueix existint a la memòria fins que
l’espai que ocupava aquell fitxer és sobreescrit per algun altre fitxer.
Un problema afegit del sistema FAT32, és que ni tan sols s’esborra l’entrada de l’índex,
només s’activa un indicador que el marca com esborrat.
D’aquesta manera, és relativament fàcil, si no hi ha hagut massa moviments de dades
a la memòria, recuperar fitxers esborrats.
Mitjançant aquest sistema, un possible atacant podria provar de recuperar fitxers
esborrats de la SDCARD i trobar fotos originals abans de que hagin estat xifrades.
Encara que s’accepta una possible vulnerabilitat en aquest punt que caldria millorar en
un futur, l’aplicació sempre fa servir el mateix nom pels fitxers temporals (temp.jpg). El
sistema FAT32 només suporta un sol fitxer amb el mateix nom i en el moment que es
Victor Aguilera Salleras Memòria del màster Pàgina 31
crea un nou fitxer amb aquest nom, si que és per tota referencia a l’anterior fitxer i el
fa impossible de recuperar, lo que disminueix bastant el risc d’atac per aquesta via.
En el cas de que les imatges estiguin a la memòria interna del Smartphone, el sistema
Android manega la memòria interna de manera independent i no permet un accés a
baix nivell al sistema de fitxers de manera externa. Aquesta operació és podria
realitzar accedint com a “root” al telèfon i fent servir una aplicació específica per
aquest cas.
Una possible solució a aquest problema, seria escriure bytes amb el valor 0 a sobre de
cada fitxer que s’elimina del sistema. El problema que tenim en aquest cas, és que el
temps d’operació s’incrementaria bastant i ja de per si, degut al xifratge AES és bastant
lent.
Degut a limitacions temporals del projecte, i a l’enfocament d’aquest, finalment no
s’ha considerat implementar-ho i es deixa per futures versions.
4.1 Test realitzats
Respecte a la seguretat, s’ha pensat en realitzar uns tests per assegurar que el xifratge de les
imatges és prou segur.
S’ha descartat fer proves sobre els algoritmes de xifratge en si mateixos ja que són prou
estàndards i estudiats com per confiar en la seva seguretat, no obstant, s’ha procedit a xifrar
unes imatges amb propietats lo suficientment peculiars com per sospitar que encara que
estiguin xifrades podria intuir-se la imatge.
Aquests casos corresponen a imatges amb pocs colors o monocromàtiques ja que aporten
molt poca variació entre els seus colors o formes.
En aquesta primera imatge, podem veure una imatge normal amb varis colors transformada en
bytes aleatoris al ser xifrada i impossible de deduir la seva forma original.
Victor Aguilera Salleras Memòria del màster Pàgina 32
Imatge 16
En el segon cas s’ha volgut provar una imatge bicolor, de manera que es pogués testejar la
problemàtica que podria resultar de xifrar una imatge molt simple i veure quin resultat
obteniem:
Imatge 17
Com podem observar, al ser una imatge molt més simple, la compressió JPG és molt més gran i
resulta en una imatge molt més petita però igualment aleatòria i indesxifrable.
Finalment s’ha provat un cas més extrem fent servir una imatge monocromàtica, amb una
forma extremadament simple:
Victor Aguilera Salleras Memòria del màster Pàgina 33
Imatge 18
Observem que la imatge és encara més petita i encara que presenta algun patró estrany (no és
totalment homogènia), impossibilita qualsevol identificació.
Victor Aguilera Salleras Memòria del màster Pàgina 34
5. Conclusions
En aquest apartat es detallen les conclusions a les que s’han arribat després d’haver finalitzat
el projecte:
Tot i que en un principi semblava un treball més o menys senzill, m’he adonat de la dificultat i
quantitat de feina que pot implicar un projecte de simple aparença.
He pogut aprofundir més en els algoritmes de xifratge i funcions hash, un món que sempre
m’ha cridat la atenció. He pogut constatar lo avançats que estan actualment els sistemes de
xifratge, ja que encara que porten molts anys de vigència segueixen sent sistemes de
referència.
Si que hi ha moltes veus demanant que es comencin a cercar nous substituts d’aquests
sistemes, però no sembla que vagin a ser trencats en un futur pròxim, i els mateixos algoritmes
tenen versions molt més avançades dels mateixos (del AES tenim la versió AES512 per
exemple).
Com a cas remarcable, podríem parlar del cas Wikileaks. No és difícil trobar per les xarxa
torrent, el famós fitxer xifrat en AES256 que suposadament conté tots els documents encara
no filtrats per l’organització del Julian Assange. Encara avui dia ningú ha pogut obrir aquest
fitxer.
M’agradaria remarcar per altra banda, encara que la funció del treball de final de màster és
aplicar els conceptes de criptografia i els sistema Android només és un mitjà per la realització
d’aquest, que estava molt interesant en introduir-me al món de la programació per dispositius
mòbils.
La meva experiència respecte a aquest punt, no ha sigut tant bona com esperava i tinc
sentiments encontrats respecte a la programació Android.
Per una banda, trobo un avanç molt gran tenir un sistema obert en el que poder programar
aplicacions, i no tinc cap dubte que és el futur i que cada dia les coses estaran més enfocades a
aquest tipus de dispositius.
Per una altra banda, reconec que no és un sistema tot lo directe o simple que m’hagués
esperat, tenint en compte que les noves tecnologies cada dia intenten ser més simples de cara
al programador. Intueixo que tot ve dels inicis d’Android i la seva evolució. S’ha anat millorant
molt el sistema des de la primera versió però a la vegada, això queda molt patent i
s’arrosseguen moltes coses que afegeixen una complicació innecessària.
La documentació oficial d’Android és bastant escassa, encara que veig que Google està fent
esforços en aquest camp. També tinc la impressió que hi ha massa versions de l’API i això
implica canvis molt sovint en la manera de fer les coses. Per altra banda entenc que els món
dels Smartphones és un mon molt viu on cada dia apareixen noves coses i a la vegada molt
volàtil, on és molt fàcil quedar-te fora del mercat si no t’actualitzes.
Victor Aguilera Salleras Memòria del màster Pàgina 35
No tinc cap dubte és que el futur estarà en les pròximes generacions de terminals mòbils i
tabletes on es faciliti encara més la creació d’aplicacions i el seu disseny.
5.1 Possibles millores
Degut al temps limitat per la realització del projecte s’han quedat varies coses sense fer que
m’hagués agradat millorar (i es provarà de fer-ho un cop s’acabi el màster). Aquí es presenta
una llista amb les coses que es consideren pendents:
Recuperació de la contrasenya: Caldria pensar un sistema per recuperar la
contrasenya, en cas d’oblit, ja que actualment, si l’usuari perd la contrasenya és
impossible accedir a l’aplicació de cap manera. No és un tema gens senzill, per que en
molts casos implicaria un possible forat de seguretat o facilitat per accedir al
programa. Una opció seria implementar algun tipus de servei online que permetés
recuperar la contrasenya però això implicaria desenvolupar i mantenir aquest servei.
Com s’ha comentat anteriorment, una de les possibles vulnerabilitats resideix en el fet
de que es possible recuperar fitxers esborrats de la memòria externa (SDCARD) del
dispositiu.
Caldria implementar un mecanisme per esborrar de manera segura els fitxers
temporals, per exemple sobreescrivint amb 0’s tot el fitxer abans d’esborrar-lo.
D’aquesta manera seria impossible recuperar aquests fitxers.
Millores estètiques:
- Un dels grans problemes d’Android és la quantitat de dispositius diferents que hi
ha al mercat. Això fa que dissenyar una aplicació sigui una feina enorme
simplement pel fet d’adaptar-se als diferents formats (mides de pantalla, alineació
d’aquesta). Caldria tenir varies versions dels gràfics per diferents mides de
pantalla.
- Una altra millora estètica, seria implementar un diàleg amb alguna icona animada
mentre es processen els fitxers ja que el temps d’espera és suficientment alt quan
es carrega o es xifra una imatge com per donar la sensació de que l’aplicació no
respon.
- Correcta visualització de les imatges respecte a la seva rotació original.
Com a millora final, es podria implementar una càmera pròpia del programa, que
permetés xifrar la imatge directament sense tenir que fer operacions a la memòria,
eliminant i canviant de nom els fitxers. Això permetria fer servir aquesta càmera des
de qualsevol altre aplicació.
Victor Aguilera Salleras Memòria del màster Pàgina 36
6. Bibliografia
Wikipedia the free encyclopedia. Advanced Encryption Standard [en línia]. [Consulta 5 de Maig].
Disponible a: http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
UCSB Departament of Computer Science. Rijndael Animator [en línia]. Santa Barbara, California:
Enrique Zabala [Consulta 6 de Maig]. Disponible a: http://www.cs.ucsb.edu/~koc/cs178/EnriqueZabala/
UBM Tech EETimes. How secure is AES against brute forcé attacks? [en línia]. Mohit Arora [Consulta 3
de maig]. Disponible a: http://www.eetimes.com/design/embedded-internet-design/4372428/How-
secure-is-AES-against-brute-force-attacks-
Wikipedia the free encyclopedia. SHA-1 [en línia]. [Consulta 5 de Maig]. Disponible a:
http://en.wikipedia.org/wiki/SHA-1
Not implemented. Comparing Hash Algorithms: Md5, Sha1 or Sha2? [en línia]. Andreas Bonini, 29 Març
2013 [consulta 4 d’abril]. Diponible a: http://www.not-implemented.com/comparing-hash-algorithms-
md5-sha1-sha2/
Wikipedia the free encyclopedia. PBKDF2 [en línia]. [Consulta 5 de Maig]. Disponible a:
http://en.wikipedia.org/wiki/PBKDF2
Password-Based Key Derivation Function 2 (PBKDF2) A JavaScript implementation (version 1.5) [en
línia]. Parvez Anandam [consulta 7 de Maig]. Disponible a: http://anandam.name/pbkdf2/
The Busy Coder's Guide to Android Development [ebook]. Mark L. Murphy [consulta 3 de maig]. ISBN:
978-0-9816780-0-9. Disponible a: http://commonsware.com/Android/
Pragmatic Programmers , LLC. Hello Android. 3rd Edition. Estats Units: Brunette, 2011. 320 pag. ISBN
978-1-934356-56-2
Wikipedia the free encyclopedia. JPEG [en línia]. [Consulta 5 de Maig]. Disponible a:
http://en.wikipedia.org/wiki/JPEG
Image Engineering.How does the JPEG compression work? [en línea]. [Consulta 16 de Maig]. Disponible
a: http://www.image-engineering.de/index.php?option=com_content&view=article&id=522
Wikipedia the free encyclopedia. BMP file format [en línia]. [Consulta 5 de Maig]. Disponible a:
http://en.wikipedia.org/wiki/BMP_file_format
Ted Gruber Software. BMP (Windows) Header Format [en línia]. Ted Gruber. [Consulta 2 de Maig].
Disponible a: http://www.fastgraph.com/help/bmp_header_format.html
Victor Aguilera Salleras Memòria del màster Pàgina 37
7. Annexos
7.1 Algoritme SHA1
L’algoritme SHA1 és un tipus d’algoritme de hash dissenyat per la Agencia Nacional de
Seguretat dels Estats Units (NSA). Aquest tipus de funcions, estan dissenyades per mitjançant
un algoritme, mapejar un conjunt d’elements d’entrada en un rang de sortida finit. És a dir, a
partir d’un conjunt de bytes, permeten obtenir-ne un resum d’aquest, que sempre serà el
mateix i tindrà la mateixa mida, sigui quina sigui la quantitat de dades d’entrada.
Imatge 19
Font: Wikimedia Commons
L’objectiu d’això és que el valor del hash serveixi com a representació compacta de les dades
d’entrada.
Altra de les seves propietats és que, donat que el resultat és un resum de les dades d’entrada,
és impossible poder obtenir aquestes dades a partir del hash. L’ús més estès d’aquest tipus de
funcions és la de la verificació de contrasenyes sense haver de emmagatzemar (i per tant
exposar) aquestes. Es calcula el hash de la contrasenya i és compara amb un hash prèviament
calculat i emmagatzemat. D’aquesta manera, encara que patim un accés no autoritzat al
sistema, no exposaríem totes les claus.
El SHA-1, és la segona versió d’aquest algoritme. Prèviament existia el SHA-0, i actualment
disposem del SHA-256, SHA-384 i SHA-512 (tots ells anomenats SHA-2).
Perquè SHA1 i no MD5
Inicialment es va optar per l’algoritme MD5 donada la seva popularitat i acceptació, però
finalment es va decidir fer servir el SHA-1, per la relació entre simplicitat i seguretat. Calcular
Victor Aguilera Salleras Memòria del màster Pàgina 38
un hash SHA-512 és molt més costos i el resultat ocupa molt més espai. Per altra banda els
SHA-1 ha sigut un algoritme molt estudiat i atacat. Això permet a dia d’avui confiar en la seva
robustesa.
A l’any 2004, l’algoritme MD5 va quedar seriosament compromès per part d’un equip
d’investigació xinés. El SHA-1, a dia d’avui, encara no ha estat trencat. És a dir, no s’han pogut
generar col·lisions (blocs de dades que generin un hash conegut).
Si que s’han fet aproximacions i maneres de trencar-ho amb velocitats molt superiors a la força
bruta, però malgrat tot, i sabent que el seu temps de vida serà limitat, es considera segur.
Taula dels algoritmes:
Algoritme Mida de sortida
(bits)
Col·lisions
trobades?
SHA-0
160
Si
SHA-1 Atac teòric
SHA-256/224 256/224
No
SHA-512/384 512/384
MD5 120 Si
Victor Aguilera Salleras Memòria del màster Pàgina 39
7.2 Algoritme AES
Al 1997, l’Institut Nacional de Normes y Tecnologia (NIST) va realitzar un concurs per escollir
un nou algorisme de xifrat capaç de protegir informació sensible durant el segle XXI. Aquest
algoritme és va denominar Advanced Encryption Standard (AES).
En aquesta convocatòria s'indicaven diverses condicions per als algorismes que es
presentaran:
Ser de domini públic, disponible per a tothom.
Ser un algorisme de xifrat simètric i suportar blocs de, com a mínim, 128 bits.
Les claus de xifrat podrien ser de 128, 192 i 256 bits.
Ser implementable tant en hardware com en software.
Finalment l’algorisme Rijndael, creat per John Daem i Vincent Rijmen va ser escollit guanyador
al novembre del 2001 i es va convertir en l’estàndard AES després d’alguna petita modificació
(l’AES treballa sobre mides blocs fixos de 128,192 o 256 bits, mentre que l’algoritme original
Rijndael acceptava qualsevol mida de bloc múltiple de 32).
Aquest algoritme destaca especialment en la seva facilitat d’implementació tant en software
com en hardware, així com el seu baix consum de memòria.
Aquest algoritme funciona fent servir una xarxa de substitució-permutació sobre els blocs a
xifrar i té quatre operacions possibles:
1 – SubBytes: En aquest pas és realitza una substitució no lineal on cada byte és reemplaça
amb un altre d’acord amb una taula de cerca
2 – Shiftrows: En aquest pas és realitza una transposició on cada fila del bloc és Rotat de
manera cíclica un nombre determinat de vegades.
3 – MixColumns: Operació de barreja que opera a les columnes del bloc, combinant els quatre
bytes en cada columna utilitzant una transformació lineal.
4 – AddRoundKey: cada byte del bloc és combinat amb la clau. Cada clau es deriva de la clau de
xifrat utilitzant una iteració de la clau.
Per aquesta aplicació s’ha escollit la versió de AES128, ja que tenint en compte que s’ha
d’executar a dispositius mòbils, és important tenir en compte la potencia de procés, i aquests
algoritmes en general, són bastant costosos.
Dintre de l’algoritme AES, hi han varis modes de xifratge, però els podem resumir en els dos
mes bàsics: el ECB i el CBC.
Aquest primer mode (Electronic CodeBook) té com a principal característica, el fet que tots els
blocs de dades a xifrar es xifren amb la mateixa clau inicial de manera seqüencial tal com es
mostra a la imatge:
Victor Aguilera Salleras Memòria del màster Pàgina 40
Imatge 20 Font: Wikimedia Commons
En canvi el mode CBC, comença amb un vector de dades inicial que serveix per fer un XOR amb
les dades que es volen xifrar abans d’aplicar el xifratge amb la clau. A partir d’aquí, cada nou
bloc de dades abans de ser xifrat, es manipula amb un XOR fent servir el bloc de dades xifrat
anterior. D’aquesta manera cada nou bloc de dades depèn de l’anterior i canvia la seva forma
segons el bloc anterior (en el mode ECB, un mateix bloc de dades sempre dona el mateix
resultat xifrat).
Imatge 21 Font: Wikimedia Commons
En aquest projecte s’ha fet servir el mode ECB, ja que encara que és un mode a priori
considerat insegur per dades crues (imatges en format RAW o textos), és més ràpid de
processar i per imatges JPG proporciona una seguretat força acceptable.
Victor Aguilera Salleras Memòria del màster Pàgina 41
7.3 Algorisme PBKDF2
L’algorisme PBKDF2 (en anglès Password-Based Key derivation function), és un algorisme de
derivació de clau criptogràfica pertanyent a RSA Laboratories.
Aquest algorisme aplica una funció pseudoaleatòria similar a un hash criptogràfic juntament
amb un salt varies vegades seguides per produir lo que es coneix com clau derivada.
Aquesta clau derivada és considera una clau segura per fer servir com a clau criptogràfica
segura, ja que s’ha afegit una carrega computacional important al iterar tants cops el mateix
algorisme. A més al afegir un salt, evitem un atac mitjançant taules rainbow i forcem a la
necessitat de fer un atac per força bruta. Per altra banda, al aplicar aquesta funció aconseguim
claus de mida homogènia, que donat que les farem servir per xifrar amb AES128, en el nostre
cas concret, és totalment necessari.
Els estàndards recomanen com a mínim aplicar 1000 iteracions el algorisme i un salt de un
mínim de 64 bits.
L’algoritme PBKDF2 es pot definir amb 5 paràmetres amb la següent funció:
on:
PRF és la funció de hash que es farà servir (en el nostre cas és SHA1)
Contrasenya és la contrasenya que volem derivar
Salt és el salt que volem fer servir
c és el número d’iteracions desitjat (en el nostre cas 1000)
dkLen és la mida desitjada de la clau resultant (128 bits en el nostre cas)
DK serà la clau resultant que volem obtenir