Ver/Abrir

Teléfonos Android como dispositivos de
cifrado versátiles
Lic. Anna Roxana Fernández Gironés
Tesis presentada como requisito parcial para optar al título de:
Master en Ciencias de la Computación
Tutores
Msc. Alejandro Tamayo Castillo
Dr. Miguel Katrib Mora
Universidad de la Habana
Facultad de Matemática y Computación
La Habana, Cuba
Junio, 2015
Dedicatoria
A mi madre que tanto deseó este momento.
Agradecimientos
Muchas gracias a mi madre por apoyarme y aconsejarme en los momentos difíciles, por
su inmensa dedicación de todos los días e infinito amor.
Muchas gracias a mi abuela por su comprensión y cariño diario.
Gracias a mi esposo, quién creyó en mí y me animó a seguir adelante.
Gracias también a mis tutores por asesorarme en todas las etapas del presente trabajo.
Muchas gracias a todos aquellos que, de una forma u otra, me ayudaron en este difícil
camino.
I
Resumen
Los teléfonos inteligentes son ya omnipresentes en las comunicaciones modernas. Al ser
los dispositivos móviles más utilizados, resulta interesante considerar la capacidad de los
mismos, en particular aquellos con Sistema Operativo Android, para aplicar mecanismos
de cifrado de forma versátil. Este trabajo de diploma tiene como objetivo comprobar la
factibilidad y analizar la seguridad y versatilidad de usar un teléfono Android como opción
a los llamados Trusted Personal Devices (TPD), así como ilustrar cómo pudiera ser utilizado
en la práctica. Para ello se hace uso de la tecnología TrustZone incorporada en el hardware
de los últimos teléfonos móviles, la cual proporciona confianza directamente desde el
hardware al igual que los Trusted Platform Module (TPM).
Palabras Claves
Android, Cifrado, Codificación, Dispositivo Móvil, Llave Segura, Plataforma de Confianza,
Privacidad, Seguridad, Teléfono Inteligente, Zona Segura.
II
Abstract
Smartphones are now ubiquitous in modern communications. As most used mobile
devices, it is interesting to consider the potential thereof, particularly those with Android
Operating System, to implement encryption / decryption mechanisms in a versatile way.
This master thesis aims to test the feasibility, analyze security and versatility of an Android
phones as option to called TPD and illustrate how it could be used in practice. For this
purpose it is used The TrustZone technology built into the hardware of the latest mobile
phones, which provides confidence directly from the hardware like the TPM.
Keywords
Android, Encryption, Decryption, Mobile Device, Secure Key Storage, Trusted Platform,
Privacy, Security, Smart Phone, Trust Zone.
III
Tabla de contenido
1.
2
Introducción ............................................................................................................... 1
1.1
Motivación ............................................................................................................. 3
1.2
Problema ................................................................................................................ 4
1.3
Objetivos ................................................................................................................ 4
1.4
Retos ...................................................................................................................... 4
1.5
Estado del Arte ....................................................................................................... 4
1.5.1
Medios de Cifrado ........................................................................................... 5
1.5.2
Cifrado en Dispositivos Móviles ...................................................................... 6
1.5.3
Herramientas de Cifrado para Dispositivos Móviles ....................................... 7
Tecnologías................................................................................................................... 14
2.1
3
4
2.1.1
AES ................................................................................................................ 14
2.1.2
RSA ................................................................................................................ 19
2.2
Ambiente de Ejecución Seguro. Zona Segura ...................................................... 20
2.3
Trasmisión de la información de forma segura. SSL ............................................ 23
2.4
Autentificación del usuario .................................................................................. 26
2.5
Navegación por los ficheros cifrados. WebDAV .................................................. 27
Prototipo ...................................................................................................................... 29
3.1
Arquitectura ......................................................................................................... 29
3.2
Funcionamiento ................................................................................................... 30
3.3
Módulos ............................................................................................................... 37
3.4
Bibliotecas y Clases Utilizadas .............................................................................. 39
Resultados .................................................................................................................... 51
4.1
5
Algoritmos de cifrado ........................................................................................... 14
Casos de Uso ........................................................................................................ 52
Conclusiones ................................................................................................................ 55
Bibliografía .......................................................................................................................... 56
IV
Listado de Figuras
Figura 1-1 SPD de SPYRUS..................................................................................................... 6
Figura 1-2 BoxCryptor (Imágenes de Google Play) ............................................................... 8
Figura 1-3 Arquitectura de Herramientas de Cifrado para Dispositivos Móviles ................. 9
Figura 1-4 Compartir ficheros cifrados entre usuarios con estas herramientas ................ 10
Figura 1-5 Compartir ficheros cifrados con grupos. ........................................................... 11
Figura 1-6 DroidVault (Imágenes de Google Play).............................................................. 12
Figura 2-1 Cifrado por Bloques ........................................................................................... 15
Figura 2-2 Cifrado Continuo................................................................................................ 15
Figura 2-3 Ejemplo de Cifrado con ECB (Tomado de Wikipedia) ....................................... 16
Figura 2-4 Cifrado utilizando el modo CBC ........................................................................ 17
Figura 2-5 Descifrado utilizando CBC.................................................................................. 17
Figura 2-6 Cifrado utilizando CFB ....................................................................................... 17
Figura 2-7 Descifrado usando CFB ...................................................................................... 18
Figura 2-8 Ejemplo del esquema de Relleno PCKS7 ........................................................... 19
Figura 2-9 Zona Segura ....................................................................................................... 20
Figura 3-1 Arquitectura de CryptoDROID ........................................................................... 30
Figura 3-2 Contraseña para acceder a CryptoDROID ......................................................... 31
Figura 3-3 Certificados Generados por la CA de CryptoDROID .......................................... 31
Figura 3-4 Generando Certificados Digitales ...................................................................... 32
Figura 3-5 Interfaz de CryptoDROID ................................................................................... 32
Figura 3-6 Conectándose a CryptoDROID desde un Navegador Web ................................ 33
Figura 3-7 Alerta de Seguridad por Certificado Auto-Firmado........................................... 33
Figura 3-8 Descarga de Certificado Raíz ............................................................................. 34
Figura 3-9 Comparación de Huella Digital .......................................................................... 34
Figura 3-10 Instalación de Certificado ................................................................................ 35
Figura 3-11 Navegación Segura .......................................................................................... 36
Figura 3-12 Conexión con El servidor WebDAV de CryptoDROID ...................................... 36
Figura 3-13 Estructura de Fichero Cifrado con CryptoDROID ............................................ 38
V
Figura 3-14 Composición de AndroidKeyStore hardware-based ........................................ 40
Figura 3-15 Composición de AndroidKeyStore software-based......................................... 41
Figura 3-16 Generación de las llaves públicas y privadas................................................... 42
Figura 3-17 Código que Genera las Llaves AES ................................................................... 42
Figura 3-18 Inicialización para cifrado con AES .................................................................. 42
Figura 3-19 Líneas para el Cifrado con RSA ........................................................................ 43
Figura 3-20 Generación de Certificado Raíz ....................................................................... 43
Figura 3-21 Uso de las clases para Generar el par de llave pública y privada.................... 44
Figura 3-22 Salva de Certificado raíz en formato PEM ....................................................... 44
Figura 3-23 Salva de llave privada ...................................................................................... 45
Figura 3-24 Transformación de la llave privada ................................................................. 46
Figura 3-25 Autenticando certificados con SSL .................................................................. 47
Figura 3-26 Métodos WebDAV .......................................................................................... 48
Figura 3-27 Formación de XML compatible con WebDAV ................................................. 48
Figura 3-28 Priemer Paso CryptoDROID ............................................................................. 49
Figura 4-1 Integración con las herramientas de Office ...................................................... 54
VI
Listado de Tablas
Tabla 4-1 Procesos Secuenciales (Tiempo en Segundos) ................................................... 51
Tabla 4-2 Procesos Paralelos (Tiempo en Segundos) ......................................................... 52
Introducción
Página | 1
1. Introducción
Hoy en día, gracias a los dispositivos móviles se ha hecho popular acceder a datos e
información en cualquier momento y lugar. Un factor importante a considerar entonces,
es la seguridad y confiabilidad de esos datos consultados, generados y almacenados, ya
sea en el propio dispositivo o en la Nube Móvil (Mobile Cloud Computing, MCC) [1]. La
Nube Móvil es un nuevo modelo computacional que combina la nube, la infraestructura
de comunicación inalámbrica, los dispositivos de cómputo portables, los servicios de
geolocalización y otras características. La diferencia con el paradigma de Computación en
la Nube (Cloud Computing) es sutil. En la Nube Móvil, los actores protagónicos son los
dispositivos móviles, y las aplicaciones y servicios se ajustan a sus características
específicas como la resolución de pantalla, el ancho de banda, la capacidad de
almacenamiento y procesamiento, los sensores, entre otros [2].
Existen muchas amenazas a la confiabilidad e integridad de la información almacenada en
los dispositivos del usuario final. Algunas de esas amenazas están basadas en las propias
Aplicaciones, la Web y la Red utilizada. También están las amenazas físicas como el robo o
pérdida del dispositivo, permitiendo a personas ajenas disponer de la información que
contiene [3] [4].
Los Proveedores de Servicios en la Nube (Cloud Service Providers, CSP) insisten en que sus
servidores y los datos almacenados en ellos están lo suficientemente protegidos contra
cualquier tipo de robo, argumentando que los datos contenidos en sus servidores están
más seguros que los datos residentes en los dispositivos personales del usuario. Sin
embargo, en la realidad los CSP también son víctimas de ataques como el incidente
ocurrido con iCloud en el 2014 [5] o el de DropBox en el 2012 [6] donde se filtró
información privada de los usuarios sin autorización. Por otra parte, las nubes no son
infalibles y los datos almacenados en ellas no están exentos de extraviarse o modificarse,
lo mismo a consecuencia de un fallo en la seguridad o algún error humano [7].
Además de estos problemas, la seguridad de los datos en el intercambio de la información
a través de las Redes de Comunicación (Internet), que pueden llegar a ser hostiles, es un
factor a considerar.
Por estas y otras razones puede ser conveniente aplicar medidas adicionales de seguridad
para proteger la información y los primeros controles para alcanzar esta meta son la
autentificación (que el que accede sea verdaderamente quien dice ser) y el cifrado de la
información (que la información solo la pueda ver quien tenga el secreto de cifrado) [4].
Esto no significa que se deban rechazar las bondades del almacenamiento en la nube que
brindan los CSP como el bajo consto de un servicio que garantiza alta calidad y
disponibilidad. Por tanto, hay que encontrar una variante que a la vez permita seguir
utilizando estas facilidades y garantice la seguridad de los datos almacenados. Una
Introducción
Página | 2
solución puede ser codificar los datos utilizando un algoritmo de cifrado fuerte, antes de
subirlos a la nube. De esta forma, ni el CSP ni alguien que logre obtener el dato almacenado
tendrían acceso a su contenido.
El problema entonces estaría en dónde almacenar el secreto para descifrar los datos y
cómo realizar este proceso para que sea versátil y seguro. Si se almacena el secreto (una
llave de cifrado) en la nube, se tendría el mismo problema. Existen soluciones
empresariales para esto, dónde la solución consiste en que la empresa instala un servidor
de llaves propio, y los datos viajan constantemente desde el CSP hacia este servidor a
través de la red para realizar el descifrado [8] [9]. De esta manera el secreto (la llave
privada en una Public Key Infrastructure, PKI) necesaria para descifrar la información,
nunca sale fuera de la empresa ni se transmite por Internet.
Existen numerosos dispositivos personales, en particular, aquellos que cumplen con
fuertes demandas de seguridad, privacidad y confiabilidad, los cuales son denominados
Dispositivos Personales de Confianza (TPD de su nombre en inglés). Para garantizar estos
aspectos, los TPD presentan hardware dedicado a técnicas de cifrado [10].
Algunos de los teléfonos inteligentes más recientes con sistema operativo Android
incorporan ya como parte de su hardware la posibilidad de almacenar este secreto de
cifrado de forma segura, así como la posibilidad de realizar las operaciones de cifrado en
lo que se denomina un entorno protegido que está separado del entorno de ejecución
normal del dispositivo. Esta característica permitiría convertir estos dispositivos móviles
en dispositivos de cifrado personal, realizando la codificación de los datos entre el CSP y el
usuario.
Note que los datos, una vez cifrados, pueden almacenarse lo mismo remotamente en el
CSP que localmente en la memoria del dispositivo móvil; lo importante es cómo realizar el
cifrado de forma tal que el secreto se proteja y que el proceso de cifrado no se realice fuera
del entorno de ejecución seguro. En el presente trabajo de tesis se explorará la versatilidad
y factibilidad de utilizar estos dispositivos con tal propósito.
En la sección 1.1 del primer capítulo del presente trabajo, se introduce el motivo que
originó la investigación de los dispositivos Android como dispositivos de cifrado versátiles
y seguidamente en 1.2 se presenta el problema científico. A continuación en 1.3 se
enumeran los objetivos que se quieren alcanzar. Luego, en la sección 1.4 se presentan los
retos se deben superar. En la sección 1.5, se muestra una panorámica general de lo que
está desarrollado en el campo de investigación que sigue este trabajo de tesis, a su vez,
dividido también en secciones para su mejor comprensión. La primera sección 1.5.1
muestra los medios de cifrado existentes hoy en día, con sus diferencias, ventajas y
desventajas. La siguiente sección 1.5.2 da una breve explicación del cifrado de los datos,
en particular, las técnicas utilizadas en dispositivos móviles y brinda criterios de
Introducción
Página | 3
comparación entre ellas. En la última parte de este capítulo 1.5.3 se presentan las
herramientas que cifran en los dispositivos móviles así como sus características principales.
En el Capítulo 2 se presentan las tecnologías utilizadas para el desarrollo de este trabajo
de diploma. Se explican y exponen los algoritmos de cifrado en la sección 2.1 la cual se
divide un subsecciones para explicar los diferentes tipos de algoritmos de cifrado
utilizados. En la sección siguiente, la 2.2, se presentan las nuevas tecnologías incorporadas
en los teléfonos Android recientes, siendo estas, la pieza clave del desarrollo. En las
secciones 2.3, 2.4 y 2.5 se brinda solución a los retos enunciados en el capítulo anterior.
El Capítulo 3 está dedicado al prototipo de aplicación Android propuesto con el fin de
permitir que el teléfono se comporte como un TPD. Para ello se ha dividido este capítulo
en tres secciones. La primera de ellas 3.1 muestra la arquitectura de CryptoDROID (nombre
que se le ha dado al prototipo). La segunda de las secciones de este capítulo 3.2 explica el
funcionamiento del prototipo mientras que la siguiente sección 3.3 muestra los módulos
y la implementación en concreto de CryptoDROID. La última de estas secciones 3.4 da un
bosquejo por las bibliotecas que brinda Android y que fueron utilizadas.
En el capítulo 4 se expone el resultado alcanzado, mostrándose la versatilidad de los
teléfonos Android recientes para reemplazar a los TPD, así como algunos posibles usos del
prototipo desarrollado, en ambientes que pueden ser o no protegidos.
En el último capítulo 5 se brindan las conclusiones de este trabajo de tesis.
1.1 MOTIVACIÓN
Integrar funcionalidades bajo un mismo dispositivo ha sido el gran éxito de los teléfonos
inteligentes. Los teléfonos móviles de hoy, además de su funcionalidad básica (las
comunicaciones por voz) juegan también los papeles de agendas personales, cámaras
digitales, dispositivos de juego, dispositivos de almacenamiento y GPS entre otras muchas
aplicaciones. Los teléfonos móviles son dispositivos de uso permanente que se han
convertido prácticamente en una “extensión” de su propietario humano. Si pudiéramos
utilizarlos además como TPD se les agregaría una nueva funcionalidad, cumpliéndose el
deseo de utilizar un solo dispositivo para varias funciones y nuestra información en dichos
dispositivos se mantendría segura.
Utilizar un teléfono Android como TPD tiene muchos usos y posibles escenarios. En el
entorno empresarial por ejemplo, un ejecutivo puede utilizar su móvil como TPD para
codificar la información antes de subirla a la nube, o bien guardar directamente dicha
información (ya codificada) en el teléfono. Otro posible escenario es el ámbito personal,
dónde no queremos almacenar en la nube información privada o íntima sin cifrar para que
no esté expuesta a fallos técnicos o ataques en los CSP.
Introducción
Página | 4
1.2 PROBLEMA
¿Es factible el reemplazo de los Dispositivos Personales de Confianza (TPD) por teléfonos
inteligentes Android?
1.3 OBJETIVOS
Con el fin de dar solución al problema plateado se presentan los siguientes objetivos
específicos:
1.
Analizar la viabilidad y versatilidad del uso de un teléfono inteligente Android actual
como opción a un TDP, evitando con ello la necesidad de un dispositivo extra que requiera
de un huésped para funcionar y que además implique un coste económico añadido.
2.
Proponer un mecanismo para la gestión versátil de la información personal del
usuario desde cualquier PC u otro dispositivo, garantizando la seguridad de la información
utilizando un teléfono Android como TPD.
Este trabajo está enfocado a los teléfonos inteligentes con sistema operativo Android por
ser el sistema operativo predominante en el mercado y por presentar las APIs necesarias
para la implementación de aplicaciones que utilizan el cifrado por hardware y por
consiguiente la Zona Segura.
1.4 RETOS
Para cumplir con estos objetivos, es necesario resolver los siguientes tres problemas
fundamentales:
1.
Establecer los mecanismos de cifrado de la información y garantizar el
almacenamiento de la llave privada de forma segura en el propio dispositivo Android.
2.
Garantizar la trasmisión de los datos de forma segura entre el dispositivo Android
y el dispositivo final (cualquier dispositivo que tenga un navegador web estándar, como
una PC u otro dispositivo móvil), asegurando el canal de comunicación.
3.
Garantizar la autentificación del usuario en el dispositivo final.
La propuesta del presente trabajo, incluye soluciones para cada uno de estos retos, las
cuales serán detalladas posteriormente en las secciones del Capítulo 2 .
1.5 ESTADO DEL ARTE
El medio más usado para transportar información en nuestros días, sin contar la Nube, son
los dispositivos USB de almacenamiento externo. La mayoría de ellos no presentan
protección de la información que contienen. Aquellas memorias USB que sí presentan
algún tipo de protección se les llama Secure USB Flash Drive. La protección en estos
dispositivos consiste en la autentificación del usuario y el cifrado/descifrado de los datos
Introducción
Página | 5
que contienen. Teniendo en cuenta estas dos funcionalidades, existen tres tipos de
implementación que dan lugar a estas memorias USB seguras: software-based, hardwarebased partitioning y hardware-based [11].
La adopción de una u otra de estas variantes depende de las necesidades del usuario y de
los criterios prioritarios que este defina, tales como, grado de seguridad o valor
económico.
1.5.1
Medios de Cifrado
Software-based realiza las funciones de autentificación y cifrado/descifrado utilizando
solamente software que ejecuta fuera del dispositivo (en un hospedero). Existe una gran
variedad de éste software de cifrado en el mercado (FolderLock1, Dekart Keeper2,
CryptoForge3, Advanced Encryption Package Pro4, etc.). Están disponibles para varias
plataformas y presentan una amplia variedad de funcionalidades que van desde
mecanismos de respaldo y generadores de contraseñas seguras hasta limpiadores de
historial. Algunos de ellos tienen además, la facilidad de enviar ficheros que se descifran
por si solos con el fin de poder compartir datos sensibles por redes inseguras.
Estos softwares funcionan hospedados en un dispositivo de almacenamiento, como una
memoria USB o un disco duro de la PC, y cifran una parte de él. Por lo general montan una
unidad virtual y es en dónde el usuario guarda su información una vez abiertos. Cuando se
cierran nuevamente, la unidad virtual se desmonta. La forma de acceder a los datos
almacenados en dicho dispositivo es a través de una contraseña que provee el usuario.
Su debilidad es que requieren de un software y un dispositivo hospedero para acceder a
dichos datos, y esto está expuesto a tampering, es decir, un atacante puede modificar el
software o el dispositivo hospedero para obtener la contraseña y por consiguiente, hacerse
con los datos descifrados.
Una ventaja que presentan es el bajo costo económico que conllevan, ya que algunas veces
puede llegar a ser gratuito o precios menores a 50 euros. Otro aspecto positivo es su
facilidad de uso.
Hardware-based partitioning soporta la división del dispositivo físico en múltiples
particiones teniendo particiones para los datos que necesitan protección y otras para los
datos que no son sensibles. Muchos de los dispositivos que usan esta modalidad son
capaces también de cifrar por ellos mismos los datos que contienen en estas particiones
seguras. Esta funcionalidad se logra con un chip que tienen incorporado.
1
http://www.newsoftwares.net/folderlock/
http://www.dekart.com
3
http://www.cryptoforge.com
4
http://www.aeppro.com/products/aep.shtml
2
Introducción
Página | 6
Hardware-based cifra/descifra la información dentro del dispositivo USB con una llave que
es generada y guardada dentro de él. Estos son dispositivos USB más sofisticados, llamados
dispositivos USB de confianza o Secure Pocket Drive (SPD), como los de la compañía
SPYRUS5 que cargan un sistema operativo propio para ejecutar directamente en la
computadora anfitriona, de tal modo que se pueden hacer las operaciones necesarias con
la seguridad de no dejar rastros al concluir. Pueden apreciarse alguno de ellos en la Figura
1-1.
Figura 1-1 SPD de SPYRUS
Estos dispositivos brindan varias ventajas. La primera de ellas es la gran variedad que
existen en el mercado. Variedad en cuanto a modelos (USB, SSD) y en cuanto a capacidades
(16-256 Gb), incluso existen algunos modelos que tienen una interfaz USB y presentan el
hardware de cifrado en él, pero se puede cambiar su memoria interna (microSD) tantas
veces como se quiera. Otra ventaja que promueven, y es la que ha hecho populares a estos
dispositivos, es que la llave de cifrado se guarda en el hardware del mismo y nunca sale de
este, lo que los hace altamente confiables. Sin embargo, la desventaja principal es que se
necesita siempre de un dispositivo anfitrión para procesar la información por lo que
entonces se corre el riesgo de que se hackee el driver o software que ejecuta en el
dispositivo hospedero permitiendo acceder a la información segura.
1.5.2
Cifrado en Dispositivos Móviles
Hoy en día tenemos numerosas técnicas de cifrado para proteger la información y los datos
como por ejemplo: Cifrado de disco duro (Full Disk Encryption, FDE), utilizada por iOS y
BlackBerry, Cifrado de disco virtual (Virtual Disk Encryption, VDE) y Cifrado de ficheros o
carpeta (File / Folder Encryption, FE) usada por Windows Phone y Android [4].
5
http://www.spyrus.com
Introducción
Página | 7
El cifrado de disco (FDE) tradicionalmente trabaja bajo el sistema de ficheros para proveer
codificación y descodificación instantánea para todas las tareas de lectura/escritura en el
dispositivo. Por esta razón, la llave de cifrado debe de estar accesible para el sistema de
ficheros y en consecuencia si el dispositivo está en el estado desbloqueado, entonces la
llave y los datos son vulnerables. Además, como FDE cifra tanto los ficheros del usuario
como los ficheros del sistema operativo, existe una mayor probabilidad de hackear la llave,
ya que el hacker conoce tanto el texto plano (bloque donde se encuentran datos siempre
iguales del Sistema Operativo, los cuales no varían por dispositivos) como el texto cifrado
(de estos bloques del Sistema Operativo) y puede utilizar técnicas conocidas y
documentadas en la literatura para obtener la llave (Know-plaintext attack) [12].
Si se trabaja en un ambiente con computadoras, estas se pueden poner en suspensión o
apagarse para proteger la llave. Con los teléfonos inteligentes sin embargo, es imposible
pues es necesario mantener las funcionalidades básicas de comunicación. En [13]
proponen una solución para proteger la llave en FDE.
El cifrado de fichero o carpeta (FE) disminuye las vulnerabilidades de FDE hasta que el
usuario se autentifica satisfactoriamente y los datos son descodificados. Pero una vez que
esto ocurre, cualquier proceso que se esté ejecutando en el dispositivo (como puede ser
un virus) con acceso a los datos del usuario, puede tener entonces acceso a la información.
Esto sin contar la pérdida o robo de la contraseña de autentificación [4] con un keylogger
o un malware que adquiera una copia de la llave de la memoria del dispositivo (en
soluciones en que el almacenamiento de la llave es por software).
1.5.3
Herramientas de Cifrado para Dispositivos Móviles
Existen ya algunas herramientas para cifrado en teléfonos con sistema operativo Android.
Estas pueden dividirse en dos grupos:
− Herramientas de cifrado local, dónde la aplicación de cifrado ejecuta en el teléfono
y los datos se almacenan en el mismo (ejemplo Boxcryptor6, Cryptonite7).
− Herramientas de cifrado remoto, dónde la aplicación de cifrado ejecuta en el
teléfono pero los datos se almacenan en la nube. Este grupo puede subdividirse en
dos: aquellas herramientas dónde el almacenamiento remoto es un servicio nativo
especializado (ejemplo SpiderOak8 y Wuala9) o aquellas que reutilizan servicios de
almacenamiento existentes (ejemplo Boxcryptor, Cryptonite) como Google Drive,
Dropbox, SkyDrive, etc [14].
6
https://www.boxcryptor.com
http://code.google.com/p/cryptonite
8
https://spideroak.com
9
https://www.wuala.com
7
Introducción
Página | 8
La mayoría de estas herramientas utilizan el sistema de archivos EncFS10, diseñado para
crear una capa de abstracción entre un sistema de archivos virtual, dónde el usuario
almacena sus datos y el sistema de archivos real dónde se almacenan los ficheros ya
encriptados [15]. EncFS permite utilizar como sistema de archivos real, tanto el disco duro
local del dispositivo como los servicios en la nube (Google Drive, Dropbox, SkyDrive, etc).
Para el usuario final, el sistema de archivos virtual es transparente, ya que se visualiza y
accede como un “disco duro” más conectado al dispositivo [16].
En la Figura 1-2 se muestra la interfaz de Boxcryptor y se puede aprecia su funcionamiento.
Note que es necesario registrarse en Boxcryptor para poder utilizarlo. También es
necesario proporcionar una contraseña (PIN) para poder acceder a los datos cifrados ya
sea en el propio dispositivo o en los CSP.
Figura 1-2 BoxCryptor (Imágenes de Google Play)
Estas herramientas utilizan para cifrar los datos Advanced Encryption Standard (AES) con
diferentes modalidades (CBC11, CFB12, XTS13) (los algoritmos de cifrado se explicarán más
detalladamente en la sección 2.1) para cifrar los datos. Algunas de ellas, añaden un nivel
de seguridad adicional, generando una llave AES aleatoria para cada fichero y esta se cifra
a su vez con Rivest Shamir Adleman (RSA). Utilizando RSA+AES se mejora la seguridad, ya
que si un hacker se hace con la llave AES que se utilizó para cifrar el fichero, solo habrá
obtenido acceso a dicho fichero y no a los restantes. Pero esta mejora conlleva a proteger
10
FUSE-based cryptographic filesystem
Cipher Block Chaining
12
Cipher Feedback
13
Xor encrypt xor based tweaked codebook mode with ciphertext stealing
11
Introducción
Página | 9
fuertemente el bloque cifrado con RSA, utilizando una llave de 4096 bits mínimo (antes de
Android 4.3 solo se podía utilizar hasta 2048) y un algoritmo de relleno (padding)
criptográficamente fuerte, ya que éste entonces sería el objetivo fundamental del hacker
(si se obtiene de alguna forma la llave privada, se tendría acceso a todos los datos cifrados).
Pero como se puede lograr que el bloque RSA siempre contenga información aleatoria
entonces le sería muy difícil a un hacker realizar ataques conocidos (adaptive chosen
ciphertext attacks) [17]. Utilizar el algoritmo RSA para cifrar todo un fichero no sería
conveniente ya que el proceso de descifrado de RSA es lento [18] y además se expondría
la llave privada a mayores ataques.
Todas estas herramientas tienen una característica en común: la aplicación encargada de
cifrar o descifrar ejecuta donde mismo el usuario va a acceder a los datos. Esto puede
apreciarse en la Figura 1-3 que representa la arquitectura de estas herramientas.
Servidores de la herramienta
Cryptonite / Boxcryptor / etc.
Google Drive / Dropbox SkyDrive
Motor de Cifrado
Llave Privada
Datos / Wifi
UI Aplicación
Fichero 1
Fichero 2
Fichero 3
.
.
.
.
Fichero n
Motor de Cifrado
Llave Privada
UI Aplicación
Fichero 1
.
Fichero n
Otros Dispositivos Personales
Figura 1-3 Arquitectura de Herramientas de Cifrado para Dispositivos Móviles
Si se quisiera compartir los datos cifrados almacenados en la nube, entre un dispositivo
Android y una PC de escritorio, habrá que compartir la llave privada entre ambos
dispositivos e instalar la herramienta también en la PC de escritorio. Pero
independientemente de que la llave privada se pueda proteger por contraseña, al tener
que estar almacenada en todos los dispositivos que acceden a los datos cifrados (hablamos
de diferentes sistemas operativos, diferente software y distintas características de
seguridad y protección) se amplían entonces las posibilidades de hacking.
Introducción
Página | 10
La solución podría ser entonces que cada uno de estos dispositivos (incluyendo la PC de
escritorio) brindase por hardware un mecanismo para el almacenamiento seguro de la
llave privada y la ejecución segura de las operaciones de cifrado, similar al TrustZone de
Android (se verá con detalle en la sección 2.2). Pero en la práctica, actualmente sólo un
conjunto pequeño de dispositivos brindan esta característica, por lo que las herramientas
anteriores están expuestas por diseño a múltiples tipos de ataques documentados en la
literatura.
Muchas de estas herramientas brindan además soporte para compartir datos cifrados
entre usuarios. Por ejemplo, un usuario A solicita la llave pública del usuario B al servidor
de claves de la aplicación (por ejemplo, Boxcryptor) con el fin de codificar la llave con que
se cifró el archivo que quiere compartir con el usuario B. El usuario A escribe junto a los
datos del fichero cifrado la nueva llave cifrada y luego el proveedor de almacenamiento en
la nube sincroniza el archivo modificado ya cifrado. El usuario B, entonces, utiliza su llave
privada para descifrar la llave del archivo que le envió A y así poder tener acceso a su
contenido. En la Figura 1-4 se hace una representación de esta funcionalidad.
Servidores de la Herramienta
1
2
A
A Cifra el fichero y escribe en el
la llave cifrada con la llave
pública de B
B usa su llave privada para descifrar
el fichero compartido por A
B
3
4
Proveedor de Almacenamiento
Figura 1-4 Compartir ficheros cifrados entre usuarios con estas herramientas
Si un archivo se comparte con varios usuarios a la vez (que no pertenecen a un grupo)
entonces se sigue este mismo proceso pero se codifica la llave con que se cifró el fichero
con cada una de las llaves públicas de los usuarios con quien se comparte el archivo. Las
diferentes llaves cifradas se escriben todas en el fichero compartido, junto a los datos del
fichero, también cifrados. Eso aumenta considerablemente el tamaño del fichero y
complejiza la administración de las llaves [19].
Introducción
Página | 11
Además de compartir archivos cifrados entre usuarios, algunas de estas herramientas
también comparten ficheros codificados con Grupos, lo que las hace muy populares en el
entorno empresarial. La Figura 1-5 muestra el mecanismo utilizado.
Un usuario que quiera compartir contenido cifrado con un grupo, sigue prácticamente la
misma lógica que se utiliza para compartir entre usuarios. El usuario A solicita al servidor
de llaves de la aplicación la llave pública del Grupo con quién se quiere compartir los datos.
Luego cifra el archivo a compartir con la llave pública del grupo y a continuación escribe
en el archivo cifrado la nueva llave codificada. El proveedor de almacenamiento en la nube
sincroniza el archivo modificado. Luego un miembro del grupo que quiera tener acceso a
ese archivo tendría que pasar por varios pasos. Primero utilizar su llave privada para
descifrar y tener acceso a la llave de membresía del grupo. Posteriormente utilizaría la llave
de membresía del grupo para descifrar la llave privada del grupo y utilizaría esta a su vez
para tener acceso a la llave del archivo cifrado. Finalmente, teniendo esta llave se
descifraría el archivo y se tendría acceso a su contenido. Claro está, que todos estos pasos
son transparentes para el usuario.
Servidores de la Herramienta
Un usuario B miembro del grupo con el
5 que compartió el fichero utiliza su Llave
Privada para Descifrar la llave de
Membresía del Grupo
1
2
A
A Cifra el fichero y escribe
en el la llave cifrada con
la llave pública del grupo
6
7
B utiliza la llave de membresía para
descifrar la Llave Privada del Grupo
B utiliza la llave privada del Grupo para
descifrar la Llave del Fichero compartido
B
3
4
Proveedor de Almacenamiento
Figura 1-5 Compartir ficheros cifrados con grupos.
Para poder tener disponibles estas funcionalidades los servidores de estas herramientas
guardan todas las llaves implicadas en estos mecanismos, las privadas, las públicas ya sean
de usuarios o de grupos. Por supuesto, las llaves no se guardan en texto plano, las llaves
están cifradas con la contraseña del usuario o las claves de membresía de grupo.
Una herramienta interesante que utilizan los dispositivos Android para cifrar y descifrar los
datos es DroidVault [20] (se puede apreciar en la Figura 1-6). DroidVault garantiza a los
dueños de datos sensibles la protección de los mismos en dispositivos Android
Introducción
Página | 12
potencialmente inseguros. Esta herramienta enfoca a servidores de datos remotos
(empresas) como los dueños de los datos sensibles. Estos datos sensibles son compartidos
en los dispositivos móviles de los usuarios finales (empleados de la empresa) que se
definen como los usuarios de los datos. Esta herramienta hace uso de la nueva tecnología
incorporada en los teléfonos inteligentes recientes para protección de las llaves de cifrado
(sección 2.2) al igual que la propuesta de la presente tesis que se mostrará en el Capítulo
3.
DroidVault es un sistema diseñado por partes que está separado del sistema operativo y
presenta tres componentes fundamentales: El módulo de procesamiento de la
información, un módulo puente y el módulo de entrada y salida de los datos hacia y desde
la pantalla del dispositivo. El módulo de procesamiento de la información es el encargado
de mantener un canal de comunicación seguro con el servidor de datos con el fin de
intercambiar información y de procesarla. El módulo puente facilita las comunicaciones
entre el sistema operativo y el módulo de procesamiento, y el último módulo es el
encargado de mostrar los datos en la pantalla al usuario y de recoger cualquier dato
producido por el mismo.
Figura 1-6 DroidVault (Imágenes de Google Play)
Esta herramienta presenta además cuatro servicios importantes para proteger los datos
en todo momento: seguridad en la comunicación con la red, seguridad en el
almacenamiento, seguridad en la entrada y salida de los datos y seguridad en el ambiente
de procesamiento de los datos.
Para obtener la seguridad en el intercambio con la red DroidVault implementa las
comunicaciones utilizando SSL con las dos fases que conlleva, cifrado y trasmisión de los
datos. DroidVault cifra la información en el mundo seguro, preparándola para ser enviada
Introducción
Página | 13
(El mundo seguro es un entorno de ejecución confiable que traen algunos de los teléfonos
inteligentes actuales y que será comentado en la sección 2.2 de este trabajo de tesis).
Para este cifrado utiliza diferentes tipos de APIs criptográficas con algoritmos simétricos y
asimétricos presentes en el mundo seguro. Esta herramienta además presenta un
certificado en su almacenamiento seguro para construir una cadena de confianza con otros
certificados digitales y así autenticar servidores remotos. Para la fase de transmisión de los
datos cifrados utiliza llamadas al sistema operativo a través del módulo puente. Las
respuestas obtenidas son verificadas por la herramienta.
El ambiente seguro solo provee un almacenamiento limitado, por tanto DroidVault
necesita utilizar el sistema de ficheros de Android para poder guardar los datos sensibles y
garantizar el almacenamiento. Para ello DroidVault cifra los datos y utiliza llamadas de
escritura y lectura del sistema de ficheros el cual guarda la información completamente
cifrada.
A diferencia de los servicios anteriores donde se le da amplia participación a Android en
las acciones realizadas por DroidVault, en el caso de la entrada y salida de información por
la pantalla o el teclado del dispositivo móvil, la herramienta toma el control por completo
de estas partes del dispositivo incorporando dentro de ella controladores (drivers) propios
para la pantalla y el teclado.
Con el fin de asegurar el procesamiento de los datos DroidVault cifra los datos sensibles
que provienen y son enviados a los servidores de los datos. Una vez cifrada la información
DroidVault utiliza metadatos para el procesado de descifrado los cuales son a su vez
cifrados y guardados en el sistema de ficheros.
DroidVault como la mayoría de las herramientas existentes, también se puede utilizar con
proveedores de almacenamiento en la nube como DropBox.
La propuesta de este trabajo de tesis (CryptoDROID) presenta semejanzas con esta
herramienta. La más evidente, es la utilización de la Zona Segura. DroidVault, no ve al
usuario como dueño del teléfono móvil, como dueño también de los datos. Para
DroidVault los dueños de los datos son las empresas que comparten dichos datos con los
teléfonos inteligentes de sus trabajadores. Es decir, los datos se almacenan en la empresa,
y aquellos que se extraen temporalmente de ese entorno, se aseguran en DroidVault, pero
una vez que se finaliza su uso, se devuelve el dato actualizado a la empresa y se elimina
del dispositivo móvil. Es aquí dónde radica la diferencia fundamental con CryptoDROID,
pues en este último, el dueño de los datos es el dueño también del dispositivo móvil. En
CryptoDROID, el dispositivo móvil actúa como servidor de datos y caja fuerte.
Tecnologías
Página | 14
2 Tecnologías
Este capítulo está compuesto por varias secciones con el fin de aclarar las tecnologías
utilizadas en la implementación de CryptoDROID y el lector pueda entender fácilmente los
aspectos del desarrollo del prototipo presentado. Estas tecnologías utilizadas, son las
respuestas a los retos encontrados durante el desarrollo de este trabajo de tesis. Cada una
de ellas se explica de forma general y además se expone el uso específico que se le da en
CryptoDROID, con el fin de alcanzar los objetivos propuestos, teniendo en cuenta las
limitantes que presentan y adaptándolas al entorno de uso del prototipo implementado.
2.1 ALGORITMOS DE CIFRADO
Existen actualmente varios mecanismos de cifrado que se dividen en dos grupos:
− Cifrado simétrico dónde la misma llave se utiliza para codificar y decodificar la
información. Ejemplos de este tipo de cifrado son Data Encryption Standard (DES),
Triple DES, AES, Rivest Cipher (RC2), RC4, entre otros.
− Cifrado asimétrico existen dos llaves conocidas como llave pública y llave privada.
La llave pública se utiliza para codificar la información y la llave privada, que es
secreta, para decodificarla. Como ejemplos tenemos RSA, Digital Signature
Algorithm (DSA).
En las siguientes subsecciones se explicarán solamente AES y RSA que son los algoritmos
que se utilizaron en este trabajo.
2.1.1
AES
En criptografía, AES es un estándar [21] para cifrar datos, de llave simétrica, basado en el
principio de diseño red de sustitución-permutación (Substitution-Permutation Network,
SPN). Este principio consiste en tomar un bloque de texto plano y dividirlo en sub bloques
a los cuales se les aplicarán permutaciones (P-boxes) y sustituciones (S-boxes) que vienen
dadas por el intercambio de posición de estos bloques y por aplicar la operación XOR con
la llave respectivamente. Como resultado, se obtiene el bloque de entrada cifrado. En el
caso del descifrado, se hacen las mismas operaciones pero en orden inverso.
AES tiene un tamaño de bloque fijo, 128 bits, que constituyen el tamaño de bloque a cifrar
y el tamaño de la salida cifrada, mientras que la llave puede tener un tamaño de 128, 192
y 256 bits. Esta diferencia de bits implica diferente número de iteraciones del algoritmo.
En el caso de 128 bits se harían 10 iteraciones mientras que con 192 y 256 bits se
ejecutarían 12 y 14 iteraciones respectivamente [21].
La estructurada de datos con la cual trabaja AES es una matriz de bytes de 4x4 llamada
state, que se inicializa con el bloque de 128 bits (16 bytes) de texto claro que se le pasa al
algoritmo como entrada. Sobre esta matriz se aplican las iteraciones del algoritmo dónde
Tecnologías
Página | 15
cada una de ellas se encarga de aplicar diferentes tipos de sustituciones y permutaciones
de su principio de diseño.
AES es rápido tanto en software como en hardware [22], relativamente fácil de
implementar y es muy popular por ser difícil de romper con fuerza bruta.
Modos de Operación utilizados
Los modos de operación son técnicas que se utilizan para mejorar o adaptar un algoritmo
de cifrado. Estos modos dependen de la forma en que se cifraran los datos, ya sea por
bloques de bits (block cipher) como se muestra en la Figura 2-1, o sin divisiones, cifrándose
los bits uno a uno continuamente (stream cipher) como se muestra en la Figura 2-2.
Figura 2-1 Cifrado por Bloques
El tamaño típico de los bloques de cifrado es 64 o 128 bits. El tamaño de bloque que se usa
con AES es 128 bits.
Figura 2-2 Cifrado Continuo
Existen varios modos de cifrado para algoritmos simétricos:
− Electronic Code Book (ECB) que es el modo básico utilizando un cifrado por bloques
(block cipher), pues toma los bloques de datos y los cifra independientemente con
la misma llave, permitiendo paralelización. Este modo no se recomienda debido a
que dos bloques con los mismos datos producen el mismo dato cifrado y el mismo
patrón del dato, lo que facilita el hacking. Esto puede apreciarse en las Figura 2-3
dónde se muestra una imagen sin cifrar primeramente, luego la imagen cifrada
usando ECB y finalmente la imagen cifrada con otro modo de operación.
Tecnologías
Página | 16
Figura 2-3 Ejemplo de Cifrado con ECB (Tomado de Wikipedia)
− Cipher Block Chaining (CBC) Elimina la desventaja del modo ECB ya que presenta
un vector de inicialización diferente por cada bloque cifrado lo que implica que el
cifrado de datos iguales resulta en datos cifrados diferentes. Un vector de
inicialización (IV) es una cadena aleatoria de 16 bytes que se utiliza, aplicando un
XOR junto a la llave, para generar una nueva llave con la que se cifra el bloque.
Existen técnicas para generar IV, aunque básicamente el IV puede ser una cadena
aleatoria de bytes. En el caso de CBC, cada bloque utiliza un IV diferente, generado
de forma encadenada. La entrada del algoritmo AES-CBC sería una llave y un IV,
que se utiliza para cifrar el primer bloque, y el resultado cifrado sería el IV del
siguiente bloque. Este modo garantiza que un texto con los mismos caracteres
(ejemplo, todos 0) genere una codificación arbitraria de caracteres, dificultando el
hacking. La desventaja que presenta es que el cifrado debe ser hecho de forma
secuencial pues el cifrado de un bloque depende del bloque anterior. CBC es uno
de los modos más populares y uno de los seleccionados en la implementación de
nuestro prototipo. Hay que resaltar que para descifrar el contenido, se requiere
conocer además de la llave, cual fue el IV utilizado. El IV una vez que se utiliza puede
ser público, ya que su único objetivo es saltear un poco el resultado cifrado.
Tecnologías
Página | 17
Figura 2-4 Cifrado utilizando el modo CBC
En las Figura 2-4 y 2-5 se muestra el cifrado y descifrado respectivamente,
utilizando este modo.
Figura 2-5 Descifrado utilizando CBC
− Cipher Feedback Mode (CFB) Es parecido a CBC pues también utiliza un vector de
inicialización, pero el proceso es algo diferente. Se toma el IV y se procede a la
codificación de la llave. Al resultado se le aplica un XOR con el bloque sin cifrar y se
obtiene el bloque cifrado. Este bloque cifrado se utiliza como IV para la codificación
del bloque siguiente. Las Figuras 2-6 y 2-7 muestran el proceso de cifrado y
descifrado con este modo. CFB al utilizar un stream cipher no necesita de padding.
Este modo de operación junto con CBC son los utilizados en el presente prototipo.
Figura 2-6 Cifrado utilizando CFB
Existen otras variantes de modos de operación, algunas que se derivan de estas formas
principales y otras variantes nuevas.
Tecnologías
Página | 18
Figura 2-7 Descifrado usando CFB
Esquemas de Relleno
El algoritmo AES, cifra bloques exactos de 128 bits. Por tanto, para cifrar un texto largo,
habría que dividir este en pedacitos de 128 bits. Pero el texto no tiene por qué coincidir
exactamente y su tamaño ser múltiplo de 128, por lo que el último bloque requerirá de un
procesamiento adicional conocido como esquema de relleno (padding).
El esquema de relleno en un cifrado por bloques resuelve el problema de que el tamaño
de los datos en claro no sea múltiplo del tamaño de bloque del algoritmo de cifrado. Para
ello, se rellena el último bloque de cifrado con datos que siguen cierto patrón. Existen
varios sistemas de relleno como por ejemplo Zero Padding o Bit Padding. El primero
adiciona cuantos 0 sean necesarios al final del bloque, mientras que el segundo añade un
bit “1” al final del texto y luego tantos 0 como sean necesarios. El problema de este
esquema de relleno, es que es criptográficamente débil y está sujeto a ataques conocidos.
En la segunda guerra mundial, los aliados lograron romper el código enigma, cifrado
utilizado por el ejército Alemán, al darse cuenta que cada mensaje cifrado finalizaba con
“Heil Hitler!” o empezaba con “Spruchnummer” (número de mensaje). Conocer la forma
de parte del texto claro, puede ayudar a un atacante a romper el cifrado y obtener la llave.
Un esquema de relleno más fuerte, es PCKS7 que es el que se utilizará en la presente
propuesta junto a AES. Consiste en llenar bytes completos con el valor de la cantidad de
bytes a llenar. La Figura 2-8 representa este esquema de relleno. Si fuese necesario rellenar
con 2 bytes entonces la línea 2 de la figura 2-3 sería la indicada.
Tecnologías
Página | 19
Figura 2-8 Ejemplo del esquema de Relleno PCKS7
De los modos AES anteriormente expuestos, algunos como AES-CBC requieren
obligatoriamente un esquema de relleno por utilizar block cipher y otros como AES-CFB no
lo requieren ya que utilizan un stream cipher.
Uno de los objetivos de las herramientas de cifrado, consiste en que el tamaño del texto
claro sea exactamente igual al tamaño del texto cifrado. Una técnica conocida es utilizar
un modo de operación más resistente a ataques (por ejemplo AES-CBC) para los bloques
enteros, y en el caso del último bloque, para no requerir un esquema de relleno, utilizar
AES-CFB que es más propenso a ataques, pero no requiere espacio adicional. Claro, la llave
y el vector de inicialización se requieren también, pero son elementos que no se guardan
junto al fichero, ya que la llave se genera a partir de una clave que se sabe el usuario y el
IV puede autogenerarse según metadatos existentes.
2.1.2
RSA
RSA es un algoritmo de cifrado asimétrico que presenta dos llaves, una pública y una
privada. La llave pública consiste en dos números (n, e) dónde 𝑛 = 𝑝 ∗ 𝑞 siendo p y q
números primos grandes no públicos. Se escoge e tal que 1 < 𝑒 < 𝑛, 𝑃𝐺𝐶𝐷(𝑒, 𝜑(𝑛)) =
1 . Siendo 𝜑(𝑛) = (𝑝 − 1) ∗ (𝑞 − 1) y PGCD el mayor divisor común. La llave privada por
su parte es d y se obtiene 𝑑 = 𝑒 −1 (𝑚𝑜𝑑 𝜑(𝑛)).
El proceso de cifrado y descifrado están representados en la ecuaciones siguientes.
𝐸(𝑚) = 𝑚𝑒 (𝑚𝑜𝑑 𝑛) = 𝑐
𝐷(𝑐) = 𝑐 𝑑 (𝑚𝑜𝑑 𝑛) = 𝑚
Para romper RSA a partir de su llave pública (única técnica conocida hasta ahora) se
necesita factorizar n y para factorizar un número de b bits se tarda 𝛩(2𝑐𝑏
1/3 𝑙𝑜𝑔 𝑏 2/3
).
RSA presenta esquemas de relleno al igual que AES. Esto es muy importante para proteger
el algoritmo de ataques llamados oráculos y de sustitución [23]. En ningún caso es
recomendable rellenar con ceros o inventarse un esquema de relleno propio, ya que estos
deben probarse y no todos los existentes son seguros. Por ejemplo, existen RSA-SAEP+
(Simplified Asymmetric Encryption Padding) y RSA-OAEP (Optimal Asymetric Encryption
Padding). Este último es el más fuerte actualmente y se usa en PKCS#1, que es el esquema
que se utilizará en el prototipo.
Tecnologías
Página | 20
2.2 AMBIENTE DE EJECUCIÓN SEGURO. ZONA SEGURA
Algunos de los teléfonos inteligentes Android más recientes tienen en su hardware una
característica llamada Zona Segura (ARM TrustZone®), la cual tiene la tarea de crear un
entorno seguro separado del Sistema Operativo al cual los atacantes no tienen acceso. Se
llama Entorno de Ejecución Confiable (Trusted Execution Environment, TEE). Esta
tecnología se utiliza para proveer confianza en el almacenamiento de la llave así como
operaciones de cómputo seguras [24] [25].
La zona segura está basada en dos ambientes separados completamente, llamados worlds
cuyo aspecto fundamental es que usan recursos de software y hardware separados. El
primero normal world es el conocido hasta ahora y es en el que funcionan el sistema
operativo y las aplicaciones. El segundo mundo es nuevo y se ha denominado secure world.
Las aplicaciones en este mundo son llamadas Truslets. En la Figura 2-9 se muestra esta
separación de ambientes.
Figura 2-9 Zona Segura
En el mundo seguro, corre un sistema operativo llamado secure world OS y los Truslets
deben cumplir ciertos requisitos con el fin de proveer servicios de seguridad especiales
tales como el almacenamiento seguro de la llave. Un ejemplo de estos requisitos es que el
TEE debe permitir que las aplicaciones ejecuten separadas, lo que asegura que aplicaciones
maliciosas no puedan acceder o modificar el código o los datos de otra aplicación. Otro
requerimiento fundamental es el almacenamiento seguro de los datos para proteger el
secreto y la integridad de los datos binarios que representan las aplicaciones, así como los
datos que estas utilizan mientras no están en ejecución [24].
El sistema operativo Android ya implementa el almacenamiento por hardware de la llave
de cifrado en los dispositivos móviles que ya tienen Zona Segura (por ejemplo, la línea de
Tecnologías
Página | 21
teléfonos Nexus de Google) y que además presentan los controladores para comunicarse
con ella. Android brinda también una API para su utilización de la cual pueden servirse las
aplicaciones.
En los teléfonos actuales que disponen de Zona Segura, toda la memoria del sistema está
separada, incluyendo la RAM y los registros de los CPUs. Una parte dedicada al mundo
normal y otra para el mundo seguro. Esto significa que el mundo normal no puede acceder
a la memoria del mundo seguro. La Zona Segura también tiene un procesador dedicado al
cifrado y almacenamiento de las llaves que solo puede ser accedida por el mundo seguro
[24].
Una de las características fundamentales de la Zona Segura es el bit de seguridad en el bus
de comunicaciones [25]. El procesador ARM tiene un bus de comunicación llamado AXIbus que se usa por el procesador principal para comunicarse con los periféricos. Estos
periféricos pueden estar localizados en el mismo chip o fuera. Cuando múltiples sistemas
(el mundo seguro y el mundo normal) están en un mismo chip, este bit seguro se añade al
bus para poder comunicar a los periféricos que la transacción que están recibiendo es del
mundo seguro o del mundo normal. Todos los periféricos deben chequear el estado del bit
para asegurarse de no dejar escapar información del mundo seguro al normal.
Otro aspecto del hardware de la Zona Segura es la separación de los dos mundos en el
propio procesador. Esto está indicado por el bit llamado NS-bit (Non-Secure-bit) en el
registro de configuración segura (Secure Configuration Register, SCR) del procesador. Este
bit puede ser cambiado solamente por el sistema que se ejecuta en el mundo seguro.
Cuando NS-bit es 0 el procesador está operando en el mundo seguro, de otra forma está
operando en el mundo normal.
Un estado especial se crea dentro del mundo seguro para facilitar el intercambio o
activación de los mundos. Este estado se llama monitor mode. El mundo normal puede
inicializar este monitor mode llamando a la instrucción Secure Monitor Call (SMC). Las
excepciones del hardware como las interrupciones también pueden causar el cambio hacia
el mundo seguro. Cuando el cambio entre mundos ocurre a consecuencia de una llamada
al SMC o por una excepción, se habilita el monitor mode del mundo seguro. El monitor
mode se asegura que el estado del mundo que se está dejando está salvado y que el estado
del mundo en el que se está entrando sea restaurado [26]. Se recomienda habilitar el
monitor mode también para el intercambio del mundo seguro al mundo normal.
Un limitante que presenta la utilización de la Zona Segura es que la llave nunca podrá
extraerse de la misma y en caso de pérdida del dispositivo móvil, los datos cifrados no
podrán volverse a descifrar. Una solución pudiera ser generar la llave fuera del entorno
seguro para poder resguardarla por otra vía (por ejemplo, un dispositivo USB en una caja
fuerte) y luego introducirla en el mundo seguro, de dónde no se podrá extraer. También,
se realiza como técnica, la generación de una llave que se salva en el sistema de archivos
Tecnologías
Página | 22
del teléfono, pero cifrada y gestionada por el mundo seguro. De esta forma, la llave sería
recuperable y transmisible hacia otros dispositivos, sin perder la seguridad.
Estas características serán utilizadas en nuestro trabajo para el almacenamiento seguro de
la llave privada que se utilizará para codificar la información y son la respuesta al primer
reto encontrado.
Existe sin embargo una forma de vulnerar la seguridad de la Zona Segura. En el caso de
que el teléfono esté “rooteado” es decir, que se tengan todos los permisos para trabajar
con las aplicaciones y acceso para inspeccionar el sistema de ficheros, la Zona Segura es
vulnerable. Las llaves creadas por el TEE no se guardan precisamente en la Zona Segura
debido al tamaño limitado de esta y a la cantidad de llaves que pueden generarse.
Cuando una nueva llave se genera, dos ficheros son creados en la carpeta
/data/misc/keystore/user_0:
− Un archivo USRPKEY que guarda parámetros del par de llaves generado, incluyendo
la llave privada cifrada por una llave especial del dispositivo que se encuentra
dentro de la Zona Segura y nunca sale de ahí.
− Un archivo USRCERT que guarda el certificado para la llave pública.
Ambos ficheros tienen el siguiente formato de nombre (identificador de la
aplicación)_USRPKEY_(alias de la llave) y (identificador de la aplicación)_USRCERT_(alias
de la llave). Por ejemplo 10102_USRPKEY_CryptoDroid. El alias de la llave se escoge por el
programador de la aplicación.
La carpeta /data/misc/keystore/user_0 con los ficheros de las llaves, no es accesible por
un usuario que no tenga los privilegios de root y las aplicaciones no pueden acceder a las
llaves de otras aplicaciones. Usando los permisos de root un atacante puede renombrar o
copiar estos archivos dentro del mismo directorio en el mismo dispositivo móvil, con el
identificador de una aplicación maliciosa. Bajo este escenario la llave privada puede ser
accedida por la aplicación maliciosa. Claro, la llave seguiría cifrada y no se conocería como
tal, pero podría utilizarse para realizar operaciones de cifrado/descifrado, vulnerando la
seguridad de los datos del usuario. Por tanto, un teléfono rooteado, es inseguro por
definición.
La Zona Segura no es una característica utilizada solamente por móviles con Sistema
Operativo Android, Microsoft también hace uso de ella con Trusted Lenguage Runtime
(TLR), el cual es un sistema que protege la confidencialidad e integridad de las aplicaciones
.NET para móviles, de las brechas de seguridad del Sistema Operativo. Proporciona la
separación de la lógica sensible de las aplicaciones, del resto de la aplicación
independizándola del Sistema Operativo y de las otras aplicaciones [27]. Con el TLR una
aplicación móvil está particionada en dos componentes: un pequeño componente que se
ejecuta en el mundo seguro y un componente grande potencialmente inseguro que
Tecnologías
Página | 23
implementa la mayoría de las funcionalidades de la aplicación y se ejecuta en el mundo
normal.
El prototipo de este trabajo, utilizará la API de cifrado de Android para realizar las
operaciones criptográficas. En caso de que el teléfono tenga por hardware estas
características de zona segura, se aprovechará la seguridad que esta brinda, asumiendo
que el teléfono es seguro y no está rooteado. En caso de teléfonos “normales” que no
implementen Zona Segura, igualmente el prototipo funcionará, lo que las operaciones se
realizarán por software en el mundo normal.
2.3 TRASMISIÓN DE LA INFORMACIÓN DE FORMA SEGURA. SSL
Los teléfonos se utilizan para almacenar y generar datos. Estos datos pueden transmitirse
hacia afuera y hacia adentro de los mismos a través de la Wifi, Bluetooth, de la Red de
Datos o el cable USB. El prototipo del presente trabajo, pretende utilizar protocolos de
comunicación estándares y que al extremo conectado al dispositivo utilizado para cifrar se
le añada solamente el requisito de tener un navegador web estándar para realizar la
comunicación. Esto descarta el uso del cable USB o el Bluetooth ya que para su utilización,
se requiere instalar software adicional en el dispositivo y este no es un objetivo. Se
descarta también la Red de Datos pues es inexistente en nuestro país, por tanto es
imposible hacer pruebas sobre ella. La transmisión entonces, se efectuará a través de la
Wifi interna sin conexión a Internet.
Como se conoce, existen varias técnicas de cifrado para el intercambio de información. En
un cifrado simétrico, antes de que los datos sean enviados, la llave debe compartirse entre
el emisor y el receptor. El emisor luego de haber cifrado la información usando la llave
previamente adquirida, la envía y el receptor descifra la información haciendo uso de la
misma llave que comparte con el emisor. Esto implica poner de acuerdo a cada par emisorreceptor, lo que no es muy viable precisamente en el escenario móvil, y no siempre el que
codifica para enviar tiene que tener el poder de decodificar para ver.
En un cifrado asimétrico por otra parte, la llave pública se utiliza para codificar la
información y la llave privada, para decodificarla [7]. La ventaja de la Infraestructura de la
llave Pública sobre el cifrado simétrico es la llave pública puede viajar por redes inseguras
permitiendo que diferentes emisores dispongan de dicha llave para comunicarse con el
receptor de forma segura porque para descifrar la información que envían, este también
necesita de la llave privada. En el caso del cifrado simétrico, la llave tiene que conocerse
por ambas partes y no puede transmitirse por redes públicas, por lo que es poco útil su
uso en la nube. Sin embargo, se conoce que los algoritmos de cifrado asimétrico son más
lentos que los simétricos, por tanto, una estrategia a seguir sería la utilización mixta de los
mismos.
Para proteger las comunicaciones del ataque conocido como ataque de hombre
intermedio (Man In The Middle Attacks, MITM) existen protocolos como Transport Layer
Tecnologías
Página | 24
Security (TLS) y Secure Sockets Layer (SSL) que utilizan una PKI para cifrar las
comunicaciones asegurándolas entre los servidores web y los navegadores.
SSL funciona de la siguiente forma [28]. Primeramente el navegador hace un pedido a una
página segura (https://) y en respuesta, el servidor web envía su llave pública y su
certificado digital. Para garantizar la seguridad adecuadamente, no basta con enviar la
llave pública y esperar por la información cifrada, ya que un hacker pudiera interceptar la
comunicación con el potencial emisor y enviarle a este una llave pública falsa para así leer
el contenido cifrado que este envíe. Para que el emisor y receptor no se enteren de la
interferencia, se recodificaría dicha información ya leída con la llave pública real antes de
enviarla al receptor. Esto se resuelve mediante un mecanismo de verificación de llave
pública dónde el emisor (navegador) solamente aceptará llaves públicas confiables. Para
ello, se han establecido Autoridades Certificadoras (CA) como VeriSing14, por ejemplo, que
son las encargadas de generar pares públicos y privados, firmados digitalmente, de forma
tal que posteriormente se pueda verificar la validez de la llave [29].
Los certificados contienen información sobre los dueños de los mismos, e-mail, nombre
del dueño, uso del certificado, fecha de validez, nombre distintivo (DN) el cual incluye el
nombre común (CN) (que es la URL o la dirección de e-mail, en dependencia de para que
se use el certificado) y el identificador de la persona (entidad) que certifica (firma) el
certificado. Los certificados también incluyen un hash que se utiliza para asegurarse de
que el certificado no ha sido modificado.
Seguidamente el navegador chequea si el certificado digital es válido en cuanto a fecha
de validez, si está relacionado con el sitio al que se está accediendo (comprueba que la
URL sea igual al CN) y si fue expedido (firmado) por una parte confiable como VeriSing y si
no ha sido revocado.
Para firmar un certificado, una CA crea un hash a partir del mensaje escrito en él y lo cifra
con su llave privada. El hash es un número proporcionado por una función de hash. Esta
función es de un solo sentido, por lo tanto, es imposible obtener el mensaje a partir del
hash y como pequeños cambios en el mensaje implican grandes cambios en el hash, es
extremadamente difícil modificar el mensaje y mantener el hash original. La CA luego
incluye este hash cifrado dentro del certificado acompañado del mensaje original.
Para comprobar esta firma digital, el navegador recrea el hash del mensaje incluido en el
certificado y descifra el hash original con la llave pública obtenida anteriormente. En caso
de ser iguales, se está en presencia de un certificado válido.
Una vez que las verificaciones al certificado sean exitosas, entonces el navegador le envía
al servidor web una llave simétrica aleatoria cifrada con la llave pública del servidor y
14
https://www.verisign.es
Tecnologías
Página | 25
además, cifrado con la llave simétrica la URL requerida con otros datos http. El servidor
web entonces usa su llave privada para descifrar la llave simétrica del navegador y la
utiliza en las labores de descifrado de los datos enviados por el navegador. Seguidamente
responde a los pedidos de este enviando el documento html y los datos http cifrados con
la llave simétrica del navegador. El navegador a su vez descifra los datos y muestra la
información.
En un mundo cada vez más dinámico, como es el caso de los escenarios en que participan
los teléfonos inteligentes, dónde las direcciones IP cambian constantemente, es mucho
más difícil utilizar un certificado digital válido generado por una CA de confianza, ya que
habría que asociar también dinámicamente dicho IP con un nombre de dominio válido.
Existen varios servicios como DynDNS15, FreeDNS16 y NoIP17 que pretenden resolver este
problema, pero requieren que el dispositivo esté conectado a Internet y ciertos
mecanismos de autenticación. Estos servicios necesitan la instalación de una aplicación
extra en nuestro dispositivo móvil como DynDNS client18. Una vez instalada, el IP del móvil
se relacionaría, por ejemplo, con el nombre galaxys4.dyndns.org, por lo que se podría
acceder a él vía http://galaxys4.dundns.org. En caso de que la IP cambie, DynDNS client se
encargaría de actualizar el registro DNS, lo que permitiría el acceso a nuestro dispositivo
de forma permanente. Esto resuelve sólo el descubrimiento del dispositivo en la red y no
la seguridad del canal con SSL. Para asegurar el canal, utilizando HTTPS, se requiere un
certificado digital válido (Certificate Authority-signed certificates) que ponga “en verde” la
barra de nuestro navegador. No basta con tener un certificado digital (por ejemplo, uno
auto-firmado), ya que si el navegador no es capaz de verificar la autenticidad de dicho
certificado mediante una entidad certificadora, un hacker podría cambiar el certificado y
simular HTTPS. El problema es que las autoridades certificadoras, sólo generan certificados
para dominios registrados. Por tanto, si queremos HTTPS con una “barra verde”, habría
que comprar un dominio galaxys4.com y sacar un certificado para él. DynDNS también
brinda este servicio pero requiere costo adicional.
Si quisiéramos utilizar un certificado digital auto-firmado (Self-signed) para asegurar el
canal con nuestro dispositivo móvil (y así no incurrir en gastos adicionales) tendremos que
considerar que nos saldrá una advertencia de seguridad en el navegador y tendremos que
validar o no el certificado digital manualmente y proseguir con la navegación.
Para determinar que el certificado digital es el correcto, habría que mostrar la huella digital
(thumbprint o fingerprint, lista de números o hash que identifican al certificado digital de
forma única) en la pantalla del dispositivo Android para que el usuario pueda comparar
15
http://es.dyn.com/dns/
http://freedns.afraid.org/
17
http://www.noip.com/managed-dns
18
https://play.google.com/store/apps/details?id=com.dyndns&hl=es...This
16
Tecnologías
Página | 26
éste con el que muestra el navegador y en caso de coincidir saber que es el certificado
correcto. Una vez que se valide el certificado, la navegación será tan segura como con
“barra verde”.
Como se comentó anteriormente, los navegadores web validan los certificados
comparando el CN del certificado con la IP o el nombre de la URL. Para que estos
certificados entonces sean válidos, cada vez que se conecte con una IP determinada, habría
que validar el certificado para dicha IP. Dado que las direcciones IP son dinámicas y varían
constantemente sería molesto para el usuario, tener que validar un certificado digital
diferente para cada una de ellas.
Para evitar esto, CryptoDROID presenta su propia CA. La CA de CryptoDROID genera un
certificado digital raíz y una llave privada. La CA se encarga de generar los certificados
digitales para cada una de las IPs dinámicas y los firma con la llave privada. Como estos
certificados están firmados por la CA, el navegador confiará en ellos y el usuario no tendría
que estar aceptando y validando cada vez que se cambia de IP un nuevo certificado,
siempre y cuando, el certificado de la CA se añada a la lista de confianza de entidades
certificadoras del sistema operativo. Para ello, es necesario que la primera vez que se
conecta con CryptoDROID desde una PC, se haga la instalación del Certificado Digital Raíz
y una vez confiando en él, se confiará en el resto de los certificados generados.
Este es un paso manual que atenta contra la versatilidad del uso de la propuesta del
presente trabajo, pero es el mecanismo más sencillo encontrado que no requiere conexión
a Internet. Además, si se utilizase CryptoDROID en un entorno empresarial interno, este
despliegue de certificados pudiera realizarse de forma centralizada automáticamente. Por
otra parte, el usuario no debería acceder a sus datos privados desde cualquier PC que no
sea confiable, ya que esta podría contener virus o alguna aplicación maligna que haga copia
sin autorización de los datos del usuario, y para ello no hay protección ya que una vez que
el usuario autorice el acceso al dispositivo, cualquier aplicación que ejecute con los
privilegios de dicho usuario pudiera acceder a toda su información privada. Por tanto, el
paso de instalar el certificado raíz de CryptoDROID se haría solo la primera vez en los
dispositivos confiables del usuario.
Con este mecanismo se resuelve el segundo de los retos planteados en el capítulo
introductorio.
2.4 AUTENTIFICACIÓN DEL USUARIO
Una vez establecido el canal seguro (utilizando SSL o TLS), se debe proceder a la
autenticación del usuario. Como se sabe, la autentificación por contraseña no es del todo
segura debido a que a veces estas pueden ser fáciles de adivinar, los usuarios las suelen
escribir en algún papel, las envían por email o las comparten de alguna forma con un
tercero. Un mecanismo de autentificación de dos pasos disminuye estos problemas. Los
Tecnologías
Página | 27
mecanismos de dos pasos, usualmente incluyen un secreto que conoce el usuario y una
prueba adicional que se genera automáticamente que el usuario no conoce. Esto garantiza
que un usuario malintencionado que robe el secreto, no pueda acceder a la información.
El primer paso sería un secreto estático (PIN, contraseña) que solo el usuario conoce, que
le permita solo a él acceder a su información. El segundo de estos pasos sería la generación
de un secreto volátil (código autogenerado y aleatorio) que se confirmaría a través de un
mecanismo alternativo a la conexión de red, para así autenticar el canal de comunicación,
pudiendo ser este un QRCode que pueda validarse a través de la cámara del teléfono u
otro sensor o simplemente un código autogenerado que se visualice en la pantalla del
teléfono. En CryptoDROID, este segundo paso es un nombre de usuario autogenerado que
se muestra en la interfaz del teléfono y que el usuario debe leer y utilizar para conectarse
al móvil. Se escogió esta alternativa sobre el QRCode y los sensores debido a una limitante
de los clientes WebDAV existentes en el mercado. WebDAV es una extensión del protocolo
HTTP, que se explicará en la próxima sección, que permite manejar colecciones de ficheros
de forma remota. El sistema operativo Windows, por ejemplo, integra con el explorador
de Windows, un cliente WebDAV que permite acceder remotamente a estas colecciones
como si fueran una carpeta más del disco duro, abstrayendo al usuario final de toda la
complejidad de la transmisión por la web. Pero el tipo de autenticación que el cliente
WebDAV de Windows soporta es la básica de HTTP, requiriendo un nombre de usuario y
una contraseña. Esto impide, realizar autenticaciones extras utilizando otros mecanismos.
Por tanto, se decidió, que CryptoDROID generase un usuario aleatorio como verificación
de segundo paso, y la contraseña que fuese el secreto del usuario. Con esto se garantiza
que la persona que esté sentada en la PC y que intenta acceder a la información privada
sea realmente el portador del teléfono (y no otra persona conectada a la Red) y con el
primer paso se autentica al dueño de la información privada (por si alguien se robó o se
encontró el teléfono perdido).
Está claro que esto no ayuda si la contraseña y el móvil fueron robados a la vez (por
ejemplo, si el usuario está bajo una amenaza física), pero el caso que eso suceda, es menos
probable y ya depende de la persona y no de la tecnología.
Con este mecanismo de autentificación se resuelve el último de los retos planteados en el
capítulo introductorio.
2.5 NAVEGACIÓN POR LOS FICHEROS CIFRADOS. WEBDAV
Una vez superada satisfactoriamente la autentificación viene la fase de la navegación
dónde se trabaja con los ficheros guardados en el teléfono. Para ello se utiliza el protocolo
Web Distributed Authoring and Versioning (WebDAV) el cual consiste en una extensión del
Protocolo HTTP con el objetivo de administrar recursos remotamente [30].
Tecnologías
Página | 28
WebDAV agrega en un conjunto de métodos, encabezados y tipos de contenido añadidos
a HTTP con el fin de manejar las propiedades, el bloqueo de los recursos, la creación y
modificación de colecciones y la manipulación de las URLs.
Las colecciones es el término utilizado por WebDAV para el agrupamiento de recursos,
URIs, en muchos casos similar a un directorio. Al igual que con el método PUT para crear
archivos, las colecciones se crean con el nuevo método MKCOL que se le añade a HTTP.
Las propiedades se refieren a metadatos asociados a archivos y colecciones (Autor, Título,
Tamaño, entre otras). Un cliente puede mostrar u obtener las propiedades asociadas a un
recurso con el nuevo método PROPFIND, y puede cambiarlas con el método PROPPATCH.
Algunas propiedades son completamente creadas y controladas por los usuarios (por
ejemplo, una propiedad llamada “color”), y otras creadas y administradas por el servidor
WebDAV (por ejemplo, la propiedad que contiene la última fecha de modificación de un
archivo). Las primeras son llamadas propiedades “muertas” y las segundas
propiedades “vivas”.
La gestión de los bloqueos de recursos en WebDAV es opcional. Los clientes pueden usar
los nuevos métodos LOCK y UNLOCK para mediar el acceso a un recurso. En la mayoría de
los casos estos métodos se utilizan para crear bloqueos de escritura exclusivos, aunque
también es posible tener bloqueos de escritura compartidos.
En el caso de una PC Windows, con WebDAV se podrán visualizar los datos del teléfono
como si fuese una carpeta más del sistema operativo y el usuario final (el dueño del
teléfono Android) se abstraerá de los mecanismos de transmisión y codificación que
existen por detrás. Otros dispositivos, con otros sistemas operativos no Windows,
accederían también a los datos, ya que integran clientes WebDAV en su interfaz (como es
el caso de Gnome, en Ubuntu Linux) o tienen una aplicación disponible para este fin en la
tienda de aplicaciones relacionadas al sistema operativo (Google Play, en el caso de
Android). Es entonces dónde el intercambio entre el navegador y la aplicación de cifrado
fluye y el teléfono cumple con su función de TPD.
Con el objetivo de probar la velocidad de transmisión de ficheros cifrados con la zona
segura y ficheros normales que no pasan por el proceso de cifrado, y así obtener una
estadística, en el prototipo también se permitió el acceso a la memoria SD-CARD del
teléfono a través de la interfaz WebDAV. De esta forma el usuario puede acceder a los
datos cifrados y a las partes de la memoria de su teléfono que no está cifrada.
Prototipo
Página | 29
3 Prototipo
La propuesta del presente trabajo, a diferencia de las existentes analizadas en el estado
del arte, permitirá utilizar un único dispositivo como dispositivo de cifrado, pero, a través
de la red, se podrá acceder a estos datos cifrados desde otros dispositivos. Esto significa
que el usuario podrá acceder a sus datos desde cualquier dispositivo, pero el
cifrado/descifrado se realizará en un único dispositivo personal (el teléfono Android). Y
como la llave privada no saldrá de dicho dispositivo, ya que está a su vez almacenada de
forma segura por hardware utilizando la Zona Segura, las probabilidades de hacking se
minimizan.
Con esto se podrá reemplazar el TPD clásico, usualmente en formato memoria USB, por
un teléfono Android. Como valor agregado, el almacenamiento de los datos cifrados se
podrá realizar, en la memoria local del teléfono y en la nube, lo que no puede lograrse con
un TPD clásico.
CryptoDROID, es el nombre que se le ha dado al prototipo que permite al teléfono
comportarse como un TPD aplicando todos los mecanismos de seguridad descritos
anteriormente en el capítulo 2.
El prototipo tiene como objetivo mostrar la factibilidad del reemplazo de los TPD por un
teléfono Android además de analizar su seguridad, así como ilustrar su utilización en la
práctica con un modelo de aplicación que supere los problemas que se encontraron
durante el desarrollo de este trabajo.
En la implementación se utilizan algoritmos estándares de codificación como RSA y AES,
paralelizando las operaciones de trasmisión, codificación y decodificación para a su vez
explorar así las capacidades multi-núcleo de los teléfonos inteligentes actuales. Se brinda
una interfaz de comunicación estándar utilizando los protocolos HTTPS y WebDAV para
acceder a la información.
3.1 ARQUITECTURA
La Figura 3-1 muestra la arquitectura de CryptoDROID. En la parte izquierda de la imagen
se muestra un teléfono Android dividido por una línea discontinua roja. Esto representa la
división de los mundos (el mundo seguro del mundo normal). En el mundo seguro se
generará y se guardará la llave y además se ejecutarán los procesos de cifrado y descifrado
de los datos. En el mundo normal se ejecutarán el servidor web seguro con SSL y el servidor
WebDAV. Este mundo se comunicará con el seguro como se expondrá en la sección 3.4. La
interfaz de usuario muestra los datos necesarios para establecer una comunicación segura
con las PCs clientes de CryptoDROID.
Trusted Personal Device
Prototipo
Página | 30
Zona
Android
Segura TEE
SO
Llave
Llave
Privada
Privada
Motor de
Cifrado
Motor
de
Cifrado
UI
Aplicación
UI
Servicio
Aplicación
de
Aplicación
Fichero
Llave 11
Fichero
de
Llave 2
Fichero
Maestra
Fichero 2
Maestra
Fichero 3
Fichero 3
.
.
.
Fichero n
.
Fichero n
Datos / Wifi
HTTP WebDav
SSL
Google Drive / Dropbox
SkyDrive
LAN
WAN
INTERNET
UI Aplicación
Aplicación
Motor
de Cifrado
UI
Fichero
Fichero
1 1
Fichero
2 2
Fichero
Fichero 3
Fichero
3
.
..
. Fichero n
Fichero n
Llave Privada
Otros Dispositivos
Personales
Figura 3-1 Arquitectura de CryptoDROID
Se puede apreciar también en la Figura 3-1 que los demás dispositivos personales de
confianza no tienen la aplicación instalada y por consiguiente no tienen la llave de
descifrado de los ficheros codificados. Estos dispositivos personales se conectan a través
de la Wifi con CryptoDROID y de esta forma se tiene acceso a los ficheros cifrados utilizando
el protocolo WebDAV.
3.2 FUNCIONAMIENTO
CryptoDROID funciona de la siguiente manera. El dispositivo Android estará cumpliendo la
función de servidor e intercambiando información con un cliente, es decir, se conectaría
la PC al móvil usando la Wifi.
Existen un conjunto de fases que se deben satisfacer para establecer una comunicación
exitosa y se cumpla el objetivo perseguido. Una vez el usuario acceda a CryptoDROID se
requerirá que introduzca una contraseña previamente configurada. Este Layout se
muestra en la Figura 3-2.
Prototipo
Página | 31
Figura 3-2 Contraseña para acceder a CryptoDROID
Si la contraseña es correcta CryptoDROID levanta un Servicio Web en el móvil y se despliega
un mecanismo de descubrimiento para detectar las posibles IP por las cuales el usuario
pudiera conectarse desde un cliente WebDAV. Usando estas IPs la CA del prototipo genera
los certificados digitales que se utilizaran para validar el canal con el navegador. Ejemplos
de certificados generados se pueden ver en la Figura 3-3.
Figura 3-3 Certificados Generados por la CA de CryptoDROID
En la Figura 3-4 se muestra la imagen de espera de CryptoDROID mientras se generan los
certificados requeridos en este paso.
Prototipo
Página | 32
Figura 3-4 Generando Certificados Digitales
El servidor web brinda un conjunto de direcciones (IP + puerto) por los cuales se pudiera
establecer la comunicación, siempre utilizando SSL. Estas IPs varían y para no utilizar
aplicaciones de terceros como DynDNS Client se recomienda conectarse a CryptoDROID
usando una IP y no un nombre o dominio. La Figura 3-5 muestra la interfaz de usuario de
CryptoDROID representativa dónde se aprecian el conjunto de direcciones para conectar.
En la interfaz de usuario también se encuentra un nombre de usuario autogenerado que
el usuario debe escribir en el cliente WebDAV como parte de la autenticación de dos partes
y una contraseña que se debe usar para autenticarse.
Figura 3-5 Interfaz de CryptoDROID
Prototipo
Página | 33
El usuario entonces escribiría manualmente en la barra de direcciones del navegador, una
de las direcciones proporcionadas por CryptoDROID tal y como muestra La Figura 3-6.
Figura 3-6 Conectándose a CryptoDROID desde un Navegador Web
Seguidamente, el navegador dará una alerta de seguridad, como la que se muestra en la
Figura 3-7, pues no reconoce el certificado digital auto-firmado. Entonces lo que debe
hacerse es aceptar el riesgo como se señala en la figura con los círculos rojos (uno en
Firefox y otro en Internet Explorer).
Figura 3-7 Alerta de Seguridad por Certificado Auto-Firmado
CryptoDROID como Autoridad Certificadora entonces pone a su disposición la descarga de
un certificado digital raíz como muestra la Figura 3-8 el cual debe ser instalado sólo la
primera vez que se usa la aplicación en la PC desde dónde se accede a CryptoDROID. Los
pasos a seguir están bien señalados en la figura con círculos rojos y números.
Prototipo
Página | 34
Figura 3-8 Descarga de Certificado Raíz
Cuando se abre el certificado, se debe comprobar que la huella digital (fingerprint) del
mismo sea igual al que está mostrando CryptoDROID en la pantalla. Este paso se aprecia
en la Figura 3-9. Nótese que se debe acceder a la pestaña detalles de la ventana Certificado
y en ella, hacer clic en la Huella Digital para poder ver el fingerprint completo y poder hacer
la comparación con el de CryptoDROID.
Comparar
Fingerprint
Figura 3-9 Comparación de Huella Digital
Prototipo
Página | 35
Una vez satisfecha la comprobación y se sepa que el certificado es genuino, se debe
proceder a la instalación del mismo en la pestaña General de la misma ventana Certificado.
La Figura 3-10 muestra una guía para el asistente de la instalación en el caso de Windows.
Figura 3-10 Instalación de Certificado
Una vez instalado el certificado, nótese en la Figura 3-11 el candado que garantiza la
navegación segura. Una vez garantizado esto, podemos utilizar un cliente WebDAV para
conectarnos al servidor WebDAV integrado dentro de CryptoDROID o utilizar el que viene
integrado con Windows. La Figura 3-11 ilustra cómo hacerlo.
Prototipo
Página | 36
Figura 3-11 Navegación Segura
Una vez establecida la conexión con el servidor WebDAV se tendría acceso a dos
directorios principales como muestra la Figura 3-12. El primero de ellos es el private en
dónde se encuentran los datos cifrados y cada vez que se acceda a alguno de ellos
CryptoDROID se encarga de descifrarlos para que el usuario tenga acceso a él. Así también
si se copian ficheros dentro de la carpeta private estos se estarán copiando y cifrando a la
vez.
Figura 3-12 Conexión con El servidor WebDAV de CryptoDROID
En este punto hay que hacer una salvedad importante. El cliente WebDAV de Windows
guarda en una carpeta de la PC todos los ficheros que se han manejado
(%systemdrive%\windows\ServiceProfiles\LocalService\AppData\Local\Temp\TfsStore)
Prototipo
Página | 37
utilizándola como su caché. Por lo tanto, si estos son sensibles, deben ser eliminados una
vez que se termine el trabajo, acción que Windows no realiza automáticamente.
La segunda carpeta es sdcard por la cual se puede navegar y tener acceso a la memoria del
teléfono. Esta carpeta no está cifrada. Aquí se explotan las capacidades del protocolo
WebDAV brindándole funcionalidad extra a CryptoDROID.
3.3 MÓDULOS
CryptoDROID se divide en tres partes fundamentales. El módulo de procesamiento
(cifrado/descifrado), el módulo de transporte y la interfaz de usuario.
El módulo de procesamiento está compuesto por una clase fundamental llamada
EncryptionDecryptionManager que es la encargada de llevar a cabo los procesos de Cifrado
y Descifrado. Para ello se utilizan dos algoritmos de cifrado, AES y RSA. El primero se utiliza
para cifrar a los ficheros (generándose una llave y un vector de inicialización aleatorios por
fichero) y el segundo para cifrar las llaves AES utilizadas para cifrar dichos ficheros. En
particular se utiliza AES con el modo de operación CBC y una llave de 256 bits para todos
los bloques a cifrar a excepción del último donde se utiliza el modo CFB. Ambos modos
utilizan NoPappding, es decir, no utilizan esquema de relleno alguno, ya que el primer
modo se aplica a bloques enteros que no requieren de relleno y el segundo modo garantiza
que el tamaño del contenido del fichero original sea igual al tamaño del contenido del
fichero cifrado. Pero a cada fichero, además de su contenido, se le añade un metadato de
512 bytes, dónde se almacena la llave AES utilizada para cifrar el fichero, un vector de
inicialización autogenerado y se reservan 16 bytes para uso futuro. A este bloque se le
aplica RSA con ECB, PCKS1Padding y con una llave de 4096 bits. Esta mezcla entre RSA y
AES aumenta la seguridad de los datos, ya que si un hacker descubre la llave para cifrar
dicho fichero, solo tendría acceso a su contenido y no al resto de los ficheros.
Como se utiliza el modo encadenado de AES-CBC, para evitar tener que volver a cifrar el
fichero completo si el usuario realiza un cambio en una parte de él, estos se procesan por
bloques de tamaño fijo (16Kb en principio) y a cada uno de estos bloques se le genera su
propio vector de inicialización para saltear el texto cifrado. Pero para no tener que
almacenar un vector de inicialización por cada bloque (el IV se requiere obligatoriamente
para descifrar los datos) y no gastar espacio extra (dónde un IV por bloque puede ser
considerable), el vector de inicialización de AES se autogenera a partir del inicial utilizando
la siguiente fórmula 𝐸𝑆𝑆𝐼𝑉(𝑘) = 𝐴𝐸𝑆256(𝐼𝑉, 𝑘) dónde k es el número de bloque. De esta
forma, a la hora de descifrar la información se puede volver a generar el ESSIV y no es
necesario guardarlo. Esto ocurre con todos los bloques a excepción del primero que tiene
su vector de inicialización (IV) aleatoriamente generado y que sí se guarda junto con la
llave AES cifrada a su vez con RSA en el encabezado del fichero tal y como se muestra en
la Figura 3-13. El resto del fichero se llena con los bloques AES, divididos a su vez por los
Prototipo
Página | 38
bloques de tamaño fijo y el último de ellos es variable ya que cambia el modo AES de CBC
a CFB.
LLAVE AES 256
512 bits
(64 bytes)
VECTOR INICIALIZACIÓN
AES 128
RANDOM PADDING
BLOQUE CIFRADO AES
Bloque 0
(16 Kb)
...
Bloque cifrado
con
RSA 4096
128 bits
AES 256 CBC +
ESSIV
BLOQUE CIFRADO AES
.
.
.
BLOQUE CIFRADO AES
Bloque n
(max 16 Kb)
...
AES 256 CFB +
ESSIV
Figura 3-13 Estructura de Fichero Cifrado con CryptoDROID
El módulo autoridad certificadora (implementado en la clase CaManager) es el encargado
de generar todos los certificados digitales que sean necesarios para asegurar los canales
de comunicación con CryptoDROID.
El módulo de transportación es el módulo intermedio entre el módulo de procesamiento
y la interfaz de usuario. Está compuesto por la clase SecureWebServerDroid. La idea que
envuelve esta clase es levantar un servidor web seguro que utilice el protocolo SSL para
transportar los datos. Para ello se utilizan certificados digitales firmados por el módulo
autoridad certificadora que se generan por cada una de las posibles direcciones IP.
También, dentro de la clase SecureWebServerDroid, se ha realizado una implementación
del protocolo WebDAV para lograr que el usuario tenga la sensación de estar trabajando
sobre ficheros que están en la PC con la cual accede a los datos y no en el dispositivo móvil.
Prototipo
Página | 39
La implementación de WebDAV realizada, permite ir leyendo el stream SSL en tiempo real
y mientras van llegando los datos, se van dividiendo en bloques de 16 Kb, y CryptoDROID
va realizando el cifrado de los mismos en paralelo mientras se llena el buffer del stack
TCP/IP con los próximos 16 Kb. Esto ha traído como resultado que sea tan rápido transmitir
documentos cifrados como no cifrados a través de WebDAV.
La interfaz de usuario es relativamente sencilla. El primer Layout además de presentar el
nombre de nuestro prototipo muestra la huella digital del certificado raíz, generado por
CryptoDROID, y las URLs por las cuales se puede conectar con él. Este primer Layout
también presenta un nombre de usuario nuevo autogenerado cada vez que se accede a la
aplicación y que sirve como parte de la autentificación de dos pasos.
3.4 BIBLIOTECAS Y CLASES UTILIZADAS
Mono es un proyecto open source que brinda un compilador de C# y el CLR para sistemas
operativos No-Windows. Junto con C#, corren otros lenguajes en Mono como Java, F#,
Basic, entre otros. Desde sus inicios Mono ha crecido incorporando las muchas
características de .NET. Xamarin, una empresa creada por los desarrolladores de Mono,
se dedica a mantener y desarrollador este producto además de nuevos productos como
MonoTouch y Mono for Andorid. El primero permite a los desarrolladores familiarizados
con C# desarrollar aplicaciones para Apple iPhone, mientras que el segundo permite a los
desarrolladores .NET crear aplicaciones nativas que corren sobre Android. Estas
aplicaciones se sienten como las aplicaciones de Java nativas. Con Mono for Android las
aplicaciones son compiladas a código ejecutable que ejecuta sobre los dispositivos
Android.
Xamarin Android (anteriormente conocido como Mono for Android) brinda una capa .NET
sobre la capa nativa de programación en el sistema operativo Android permitiendo a los
desarrolladores crear aplicaciones que ejecuten nativamente sobre Android. Mono for
Android brinda también una capa puente entre las APIs nativas de Android y las APIs de
.NET.
Debido a esto, en el prototipo que se ha implementado, se utilizan muchas bibliotecas .NET
como: System.IO, System.Security, System.Text, System.Security.Cryptography
entre otras.
Android utiliza una máquina virtual especial llamada Dalvik como base para las aplicaciones
y servicios. Esta máquina virtual está basada en el lenguaje Java y como resultado, una
parte de las APIs de Java fueron portadas a Android y nuevas fueron añadidas. Las APIs de
Java que proporcionan operaciones criptográficas se encuentran en el paquete
Java.Security. Funcionalidades adicionales que no se encuentran en las bibliotecas de
Java están implementadas en el paquete Android.Security. Xamarin Android garantiza
que toda esta API se pueda utilizar con C#.
Prototipo
Página | 40
Módulo de Procesamiento
Android brinda varias soluciones con el fin de guardar la llave de cifrado de forma segura
y las operaciones criptográficas desde sus inicios con la API versión 1. La clase
Java.Security.KeyStore brinda una interfaz estandarizada para la salva de la llave. La
clase KeyStore solo provee una interfaz para guardar las llaves y facilidades para obtener
instancias de clases encargadas de guardar las llaves. La salva de la llave en realidad se
realiza por diferentes tipos de almacenadores de llaves. Cada uno de estos tipos está
definido en una clase que implementa la interfaz Java.Security.KeystoreSpi. La clase
KeyStore usa los métodos proporcionados por KeystoreSpi brindando métodos
uniformes usados por los programadores para salvar la llave.
Actualmente el almacenamiento de la llave de forma segura se realiza utilizando dos tipos
de almacenamiento de llaves principales: Bouncy Castle19 y AndroidKeyStore [25].
Bouncy Castle es una biblioteca para Java que se encuentra en todas las versiones de
Android, de forma limitada. Existen muchas funcionalidades en la biblioteca original que
los desarrolladores de Android consideraron no necesarias. Sin embargo, la versión
completa de esta biblioteca puede incluirse en cualquier aplicación de Android y se puede
encontrar en Github con el nombre de Spongy Castle.
AndroidKeyStore se añade en la API 18 (Android 4.3). Se comunica con un servicio llamado
KeyStore el cuál se inicia cuando el dispositivo arranca. Los fabricantes de dispositivos
móviles desarrollan controladores para su hardware que se comunican con este servicio
para proveer almacenamiento basado en el hardware. Si estos controladores no existen
entonces el almacenamiento será basado en software.
Figura 3-14 Composición de AndroidKeyStore hardware-based
19
https://www.bouncycastle.org/
Prototipo
Página | 41
AndroidKeyStore se implementa en los dispositivos que presentan Zona Segura utilizando
el servicio KeyMaster que ejecuta sobre Android y un Truslet que se ejecuta en el TEE y es
el responsable de las operaciones sobre la llave. Una aplicación como la que propone este
trabajo, que utilice AndroidKeyStore (hardware-based) realizaría este proceso como se
muestra en la Figura 3-14.
Con el fin de ofrecer la misma interfaz con AndroidKeyStore para aquellos dispositivos
móviles que no disponen del hardware necesario o no presentan los controladores, se ha
desarrollado un equivalente basado en software del Truslet KeyMaster. La Figura 3-15
muestra una aplicación utilizando AndroidKeyStore software-based.
AndroidKeyStore no brinda una API para proteger las llaves con una contraseña
especificada por el usuario, lo que podría proteger de la vulnerabilidad que presenta la
Zona Segura de los ataques en teléfonos rooteados.
Diferentes dispositivos móviles tienen diferentes AndroidKeyStore, lo que implica que
pueden tener o no TEE. Incluso el mismo modelo de dispositivo móvil puede tener o no la
TEE dependiendo de la versión de Android que tenga.
Figura 3-15 Composición de AndroidKeyStore software-based
Un almacenador de llave de un tipo en especial, puede accederse con la siguiente línea de
código _keyStore = KeyStore.GetInstance(type); dónde type sería un string con el
valor "AndroidKeyStore" (en este caso).
Java.Security también brinda KeyPairGenerator el cual genera la llave RSA utilizada para
cifrar las llaves AES con que se cifran a su vez los ficheros. Esta clase genera un par de llaves
(pública y privada) y para ello, necesita de parámetros tales como el tamaño de la llave
(4096 bits en este caso), el tiempo durante el cual este par va a ser válido, un alias (string
definido por el desarrollador) para poder recuperar la llave privada posteriormente y el
Prototipo
Página | 42
contexto de la aplicación que está generando el par de llaves, entre otros parámetros. Un
ejemplo de código se muestra en la Figura 3-16.
public KeyPair GenerateKeyPair(Context context, string alias, string language="en-en")
{
Calendar cal = Calendar.GetInstance(new Locale(language));
Date now = cal.Time;
cal.Add(CalendarField.Year, 25);
Date end = cal.Time;
KeyPairGenerator kpg = KeyPairGenerator.GetInstance("RSA", _provider);
kpg.Initialize(new KeyPairGeneratorSpec.Builder(context)
.SetAlias(alias)
.SetStartDate(now)
.SetEndDate(end)
.SetSerialNumber(BigInteger.ValueOf(1))
.SetSubject(new X500Principal("CN="+alias))
.SetKeySize(4096)
.Build());
return kpg.GenerateKeyPair();
}
Figura 3-16 Generación de las llaves públicas y privadas
Para generar las llaves AES para el cifrado de los datos sensibles, se utiliza la clase
KeyGenerator que se encuentra dentro de la biblioteca Javax.Crypto. La llave se obtiene
con las líneas de código que muestra la Figura 3-17. El parámetro _algorithm es un string
con el valor "AES" (en este caso).
var keyGenerator = KeyGenerator.GetInstance(_algorithm);
keyGenerator.Init(512);
var key = keyGenerator.GenerateKey();
Figura 3-17 Código que Genera las Llaves AES
Nótese en la Figura 3-17 que se genera una llave de 512 bits cuando AES sólo acepta 256.
Además de la llave AES, se está generando a la vez, el vector de inicialización (IV) de 128
bits y el resto no se utiliza.
var aesCipher = Cipher.GetInstance(_algorithmAesCipher);
aesCipher.Init(CipherMode.EncryptMode, new SecretKeySpec(key, _algorithmAesCipher),
new IvParameterSpec(iv));
Figura 3-18 Inicialización para cifrado con AES
En Javax.Crypto también encontramos la clase Cipher que se utiliza para cifrar los bloques
de datos. En la Figura 3-18 se muestran las líneas de código para la inicialización de estos
Prototipo
Página | 43
objetos para le cifrado con AES. El parámetro _algorithmAesCipher es un string con el
valor "AES/CBC/NoPadding" (que cumple con el formato Algoritmo/Modo/Padding) y se
utiliza CipherMode.EncryptMode o CipherMode.DecryptMode en dependencia de que
proceso se quiera ejecutar.
Nótese en la Figura 3-18 también la utilización de las clases SecretKeySpec e
IvParameterSpec que se encuentran en la biblioteca Javax.Crypto.Spec. Estas clases
se utilizan para especificar la llave y el vector de inicialización respectivamente.
var rsaCipher = Cipher.GetInstance(_algorithmRsaCipher);
rsaCipher.Init(CipherMode.EncryptMode, publicKey);
rsaCipher.Init(CipherMode.DecryptMode, privateKey);
Figura 3-19 Líneas para el Cifrado con RSA
En la Figura 3-19 se muestra la inicialización del objeto Cipher utilizado para el cifrado con
RSA. La inicialización para RSA no es muy diferente de la inicialización para AES. El
parámetro _algorithmRsaCipher es un string con el valor "RSA/ECB/PKCS1Padding". Se
utiliza CipherMode.EncryptMode o CipherMode.DecryptMode de igual forma pero el segundo
parámetro es la llave pública o privada en dependencia del proceso a ejecutarse.
Módulo Autoridad Certificadora
Para generar y manejar los certificados, se han utilizado las bibliotecas de Bouncy Castle
(Org.BouncyCastle.Asn1,
Org.BouncyCastle.Crypto,
Org.BouncyCastle.Math,
Org.BouncyCastle.OpenSsl,
Org.BouncyCastle.Pkcs,
Org.BouncyCastle.Security,
Org.BouncyCastle.Utilities,
Org.BouncyCastle.X509,
entre
otras).
La
clase
X509V3CertificateGenerator es la encargada de generar el certificado.
var certificateGenerator = new X509V3CertificateGenerator();
certificateGenerator.SetSerialNumber(serialNumber);
certificateGenerator.SetSignatureAlgorithm(signatureAlgorithm);
var issuerDN = new X509Name("CN=" +CryptoDroidIssuerName);
var subjectDN = new X509Name(subjectName);
certificateGenerator.SetIssuerDN(issuerDN);
certificateGenerator.SetSubjectDN(subjectDN);
certificateGenerator.SetNotBefore(dateNotBefore);
certificateGenerator.SetNotAfter(dateNotBefore.AddYears(25));
certificateGenerator.SetPublicKey(subjectKeyPair.Public);
var certificate = certificateGenerator.Generate(subjectKeyPair.Private, random);
Figura 3-20 Generación de Certificado Raíz
Prototipo
Página | 44
La Figura 3-20 muestra el código para la utilización de esta clase. Nótese en el código que
se van llenado datos referentes al certificado cómo número de serie, algoritmo para el
firmado, el nombre de la entidad que brinda el certificado así como la llave privada
utilizada para firmarlo y la pública distribuida a los clientes (navegadores). Estas llaves se
generan usando las clases KeyGenerationParameters y RsaKeyPairGenerator. La Figura 321 muestra su utilización.
var keyGenerationParameters = new KeyGenerationParameters(random, keyStrength);
var keyPairGenerator = new RsaKeyPairGenerator();
keyPairGenerator.Init(keyGenerationParameters);
AsymmetricCipherKeyPair issuerKeyPair = keyPairGenerator.GenerateKeyPair();
Figura 3-21 Uso de las clases para Generar el par de llave pública y privada
CryptoDROID guarda datos necesarios dentro de la memoria del teléfono en una carpeta
que lleva su nombre. Dentro de ella hay una carpeta llamada cert en dónde se salvan todos
los certificados generados y sus llaves privadas, para cada una de las IPs posibles por las
cuales se puede conectar un usuario a CryptoDROID (Figura 3-3) así como también el
certificado digital raíz (ca.cer) con su llave privada (ca.key).
var caCertFile = Path.Combine(AppDataPath, "ca.cer");
using (var caFileStream = new FileStream(caCertFile, FileMode.Create,
FileAccess.ReadWrite))
{
var beginBytes = Encoding.ASCII.GetBytes("-----BEGIN CERTIFICATE-----\n");
caFileStream.Write(beginBytes, 0 , beginBytes.Length);
var certBytes = certificate.GetEncoded();
certBytes = Base64.Encode(certBytes, Base64Flags.Default);
caFileStream.Write(certBytes, 0, certBytes.Length);
var endBytes = Encoding.ASCII.GetBytes("-----END CERTIFICATE-----\n");
caFileStream.Write(endBytes, 0, endBytes.Length);
}
Figura 3-22 Salva de Certificado raíz en formato PEM
La vía para guardar estos certificados y sus llaves se muestra en las Figuras 3-22 y 3-23,
respectivamente. Con la llave se hace uso de las clases PrivateKeyFactory,
PrivateKeyInfo y PrivateKeyInfoFactory con el fin de cifrar y descifrar la llave privada.
System.Security.Cryptography.X509Certificates es la biblioteca utilizada para generar
y manejar los certificados digitales por SSL, mientras que System.Security.Cryptography
contiene las clases para las llaves. Debido a esto, los certificados y las llaves
(Org.BouncyCastle.X509.X509Certificate,
RsaPrivateCrtKeyParameters)
de
las
Prototipo
Página | 45
bibliotecas de Bouncy Castle anteriormente expuestas, hay que transformarlas a instancias
de las clases X509Certificate2 y RSAParameters respectivamente.
var caKeyFile = Path.Combine(AppDataPath, "ca.key");
using (var caFileStream = new FileStream(caKeyFile, FileMode.Create,
FileAccess.ReadWrite))
{
var buffer =
PrivateKeyFactory.EncryptKey(PkcsObjectIdentifiers.PbeWithSha1AndDesCbc, Password,
Encoding.UTF8.GetBytes(Guid.NewGuid().ToString()), 10, privateKey);
caFileStream.Write(buffer, 0, buffer.Length);
}
Figura 3-23 Salva de llave privada
La transformación del certificado es relativamente sencilla. Una vez se lean los bytes del
fichero donde se guarda el certificado (*.cer) se crea el objeto X509Certificate2. El
proceso con la llave privada es un poco más complejo. La Figura 3-24 muestra el código
para alcanzar dicho objetivo.
Prototipo
Página | 46
var x509 = new X509Certificate2(pemObject.Content);
using (var caKeyStream = new FileStream(caKeyFile, FileMode.Open, FileAccess.Read))
{
var buffer = new byte[caKeyStream.Length];
caKeyStream.Read(buffer, 0, buffer.Length);
var bcKey = PrivateKeyFactory.DecryptKey(Password, buffer);
PrivateKeyInfo info = PrivateKeyInfoFactory.CreatePrivateKeyInfo(bcKey);
var seq = (Asn1Sequence)Asn1Object.FromByteArray(info.PrivateKey.GetDerEncoded());
if (seq.Count != 9)
throw new PemException("malformed sequence in RSA private key");
var rsa = new RsaPrivateKeyStructure(seq);
RsaPrivateCrtKeyParameters rsaparams = new RsaPrivateCrtKeyParameters(rsa.Modulus,
rsa.PublicExponent, rsa.PrivateExponent,
rsa.Prime1,rsa.Prime2, rsa.Exponent1,
rsa.Exponent2, rsa.Coefficient);
var rp = new RSAParameters();
rp.Modulus = rsaparams.Modulus.ToByteArrayUnsigned();
rp.Exponent = rsaparams.PublicExponent.ToByteArrayUnsigned();
rp.D = rsaparams.Exponent.ToByteArrayUnsigned();
rp.P = rsaparams.P.ToByteArrayUnsigned();
rp.Q = rsaparams.Q.ToByteArrayUnsigned();
rp.DP = rsaparams.DP.ToByteArrayUnsigned();
rp.DQ = rsaparams.DQ.ToByteArrayUnsigned();
rp.InverseQ = rsaparams.QInv.ToByteArrayUnsigned();
var rsaCsp = new RSACryptoServiceProvider(new CspParameters()
{
KeyContainerName = Guid.NewGuid().ToString(),
KeyNumber = (int)KeyNumber.Exchange,
Flags = CspProviderFlags.CreateEphemeralKey
});
rsaCsp.ImportParameters(rp);
x509.PrivateKey = rsaCsp;
}
Figura 3-24 Transformación de la llave privada
Módulo de Trasportación
La trasportación de los datos seguros es un punto importante a considerar cuando se está
tratando con datos sensibles. Para lograr una transmisión segura, se hace uso del
protocolo SSL que se implementa con la utilización de la biblioteca System.Net.Security,
la cual contiene la clase SslStream, que es la encargada de autenticar los certificados y
proveer transportación segura. La Figura 3-25 muestra el proceso de autenticación de
certificados creados por el módulo de autoridad certificadora.
Prototipo
Página | 47
TcpClient client = (TcpClient)obj;
try
{
Stream clientStream = client.GetStream();
using (SslStream sslStream = new SslStream(clientStream, false, (sender,
x509Certificate, chain, errors) => true, null))
{
try
{
sslStream.AuthenticateAsServer(_certificate, false, SslProtocols.Tls |
SslProtocols.Ssl2 | SslProtocols.Ssl3, false);
}
catch (Exception ex){...}
if (sslStream.IsAuthenticated)
{
var localEndPoint = (IPEndPoint) client.Client.LocalEndPoint;
var remoteEndPoint = (IPEndPoint) client.Client.RemoteEndPoint;
ProcessRawRequest(sslStream, localEndPoint, remoteEndPoint);
}
else
throw new ArgumentException("SSL Not authenticated");
}
}
catch (Exception ex){...}
Figura 3-25 Autenticando certificados con SSL
WebDAV se utiliza para transportar los ficheros y para hacer operaciones indicadas por el
usuario sobre ellos. Para ello se necesitan leer los pedidos del cliente y actuar en
consecuencia. Dado que WebDAV añade a HTTP algunos métodos se deben hacer las
implementaciones pertinentes para ellos. La Figura 3-26 muestra fragmentos de código
dónde se usan éstos nuevos métodos.
Prototipo
Página | 48
case "COPY":
{
var currentPath = GetCurrentPath(basePath, context.Request.Url);
if (IsLocked(context, currentPath))
break;
"DELETE":
var overwrite case
= context.Request.Headers["Overwrite"]
!= null &&
{
(context.Request.Headers["Overwrite"].ToLower()
!= "f");
var= currentPath
= GetCurrentPath(basePath,
context.Request.Url);
var destinationPath
GetCurrentPath(basePath,
new
if (IsLocked(context, UriKind.Absolute));
currentPath))
Uri(context.Request.Headers["Destination"],
break;
if (!overwrite && File.Exists(destinationPath))
bool handled = false;
{
if (Directory.Exists(currentPath))
SendHttpException(context,
new CustomHttpException(412, "File exists"));
{
break;
try
}
{
Directory.Delete(currentPath, true);
handled = true;
}
case "MKCOL":
catch{...}
{
} = GetCurrentPath(basePath, context.Request.Url);
var currentPath
if (!handled
&& File.Exists(currentPath))
if (IsLocked(context,
currentPath))
{
break;
File.Delete(currentPath);
Directory.CreateDirectory(currentPath);
handled = true;
}
context.Response.ContentLength64
= 0;
context.Response.StatusCode = 201;
context.Response.StatusDescription = "Created";
context.Response.WriteResponse();
break;
}
Figura 3-26 Métodos WebDAV
Para la creación del xml compatible con WebDAV se hace uso de las clases XNamespace,
XAttribute, XElement y XDocument las cuales se encuentran en la biblioteca
System.Xml.Linq. Ejemplo del código utilizado se muestra en la Figura 3-27.
XNamespace d = XNamespace.Get("DAV:");
var dXmlns = new XAttribute(XNamespace.Xmlns + "D", "DAV:");
string timeout = "Second-3600";
if (!string.IsNullOrWhiteSpace(context.Request.Headers["timeout"]))
timeout = context.Request.Headers["timeout"];
var response = new XElement(d + "lockdiscovery", new XElement(d + "activelock",
new XElement(d + "locktype", new XElement(d + "write")),
new XElement(d + "lockscope", new XElement(d + "exclusive")),
new XElement(d + "depth", 0),
new XElement(d + "timeout", timeout),
new XElement(d + "locktoken", new XElement(d + "href", currentLock.LockId)),
new XElement(d + "lockroot", new XElement(d + "href", context.Request.Url))
));
var document = new XDocument();
document.Add(new XElement(d + "prop", dXmlns, response));
var content = Encoding.UTF8.GetBytes("<?xml version=\"1.0\" encoding=\"utf-8\"?>" +
document.ToString(SaveOptions.DisableFormatting));
Figura 3-27 Formación de XML compatible con WebDAV
Prototipo
Página | 49
Módulo Interfaz de Usuario
La interfaz de usuario consta de tres Layouts (vistas) exclusivamente. El primero de ellos
es el que requiere la contraseña del usuario como parte de la autentificación de dos pasos
(Figura 3-2). La contraseña se utiliza (además de para autenticarse) para cifrar un archivo
XML de preferencias (preferences.xml). En él se guarda la contraseña de cifrado de los
certificados digitales generados por el prototipo para habilitar SSL y el nombre del teléfono
que especifique el usuario, que será también, el nombre de la autoridad certificadora. Este
fichero se guarda dentro de la memoria del teléfono en la carpeta de la aplicación. Este
fichero está cifrado usando el módulo de procesamiento.
Los controles que se ven en este primer Layout dependen de si es o no la primera vez que
se usa CryptoDROID. Al usarse por primera vez se debe especificar un nombre para el
teléfono que será el nombre de la CA a su vez. También debemos poner la contraseña por
primera vez. La Figura 3-28 muestra este primer paso.
Figura 3-28 Priemer Paso CryptoDROID
El segundo Layout es una pantalla de espera con una barra de progreso (splash) dónde
CryptoDROID realiza, por detrás, las acciones de levantar el servidor web y WebDAV
además de generar los certificados digitales (Figura 3-4). El último de estos Layouts, y un
poco más complejo, es el que se muestra en la Figura 3-5.
Este Layout primeramente muestra la huella digital que el usuario debe aceptar cuando
hace las comparaciones de las huella digitales del certificado digital raíz, expuesto
anteriormente.
Prototipo
Página | 50
Luego se muestra un nombre de usuario que se utiliza en el mecanismo de la
autentificación de dos pasos. Este texto es generado aleatoriamente cada vez que cargue
la aplicación.
Finalmente en este Layout tenemos las posibles URL desde dónde se puede conectar el
usuario a CryptoDROID.
Resultados
Página | 51
4 Resultados
Algunos investigadores han hecho experimentos con dispositivos móviles comprobando la
eficiencia de los mismos con diferentes algoritmos de cifrado. En [31], por ejemplo, se
muestra el costo computacional y gasto de energía de dispositivos móviles, en particular,
Personal Digital Assistants (PDA).
El objetivo del presente trabajo es determinar la factibilidad del uso de los dispositivos
Android como TPD y se han realizado pruebas experimentales, cifrando ficheros de
diferentes tamaños midiendo el tiempo de trasmisión de estos a través de la Wifi, así como
los tiempos de cifrado y descifrado. Para enviar los datos a través de la Wifi se han dividido
los ficheros en pedazos de 512 y 1024 Kb. En estas pruebas se ha utilizado como dispositivo
de experimentación un LG Nexus 4 y un Samsung Galaxy S4 I9505.
En un primer experimento se han obtenidos los datos reflejados en la Tabla 4-1 dónde
todos los procesos (trasmisión, cifrado y descifrado) se hacen secuencialmente.
Tabla 4-1 Procesos Secuenciales (Tiempo en Segundos)
FICHERO MB
PEDAZO KB
TIEMPO TRANSMISIÓN
TIEMPO CIFRADO
TIEMPO DESCIFRADO
10
512
10,700207
13,013372
13,692602
1024
12,058876
11,368568
10,850026
512
25,612569
35,089403
35,754266
1024
20,445324
29,583636
30,463215
512
46,822301
72,676688
72,723570
1024
34,827859
57,977663
60,66749
512
117,19555
160,18396
191,76817
1024
96,731922
145,74216
143,25981
512
159,84573
278,31695
305,89414
1024
209,85103
232,29126
232,22242
512
309,93109
540,45671
546,46130
1024
313,25476
477,81032
480,71711
512
701,67109
1155,7875
1224,5357
1024
664,96668
947,08605
965,89349
32
64
128
256
512
1024
En un segundo momento, se realizó un experimento similar, pero haciendo uso de la
paralelización con el fin de explotar la capacidad multi-núcleo que brindan los dispositivos
seleccionados para la experimentación. Como es de esperar, estos resultados son más
alentadores, mejorando considerablemente los tiempos. Los mismos se muestran en la
Tabla 4-2.
Resultados
Página | 52
Tabla 4-2 Procesos Paralelos (Tiempo en Segundos)
FICHERO MB
PEDAZO KB
10
512
1024
32
512
1024
64
512
1024
128
512
1024
256
512
1024
512
512
1024
1024
512
1024
TIEMPO TRANSMISIÓN
TIEMPO CIFRADO
TIEMPO DESCIFRADO
4,0228048
3,8419804
4,0693318
4,2270722
4,215069
4,3412256
12,286913
12,0682194
12,272882
12,3267226
12,0492597
13,0174481
23,5903803
23,5894773
26,0900268
23,9045025
23,897819
25,0175025
47,3620253
47,2744787
48,0567149
47,6968507
47,5494378
48,7462562
94,7632723
95,1144448
94,8198077
94,8572613
95,5489421
95,9584601
188,857015
195,3625435
190,0780195
189,7798195
188,6458115
190,028967
375,4802342
373,1416232
373,433388
374,8283404
373,1119809
374,4629174
De estas pruebas experimentales podemos deducir que el proceso de cifrado no afecta el
rendimiento.
Esto es debido a que el cuello de botella se forma en la trasmisión de los datos, ya que la
velocidad promedio es de aproximadamente 2.5 Mb/s que depende de la velocidad de la
Wifi que es de 56 Mbit/s (aunque ya existen dispositivos modernos con una mayor
velocidad de 150 Mbit/s).
Dado que el proceso de cifrado tarda aproximadamente lo mismo que el proceso de
trasmisión de la información, en lo que llega un pedazo del fichero al dispositivo Android
otro se va cifrando y así el tiempo de cifrado no perjudica el rendimiento.
4.1 CASOS DE USO
Para ilustrar el funcionamiento de CryptoDROID se podrían utilizar varios escenarios, por
ejemplo, para mantener información confidencial de clientes segura, tal como sus datos
de contacto como teléfonos, emails, direcciones, etc. Otro ejemplo pudiera ser, mantener
notas de algún proyecto de investigación protegidas de caer en manos de un plagiador. Sin
embargo, la más ilustrativa, la más práctica y la de mayor alcance para todo tipo de
usuarios es el caso de tener guardadas y seguras las contraseñas o documentos como
contratos de bancos o tiendas, que contengan información de cómo acceder a servicios en
línea. Siendo así, este es el caso de uso que expondremos a continuación.
Hoy en día existen muchos servicios en la web y todos ellos requieren por lo general
suscripciones y con ellas contraseñas. Un usuario promedio está inscrito en sitios para
Resultados
Página | 53
encontrar trabajo, para encontrar vivienda, en páginas para aprender idiomas, en una gran
variedad de redes sociales y correos electrónicos. El médico y los bancos también necesitan
registros los cuales conllevan a contraseña muchas veces difíciles de recordar pues se
exigen contraseñas seguras (tamaño mayor a 8 caracteres y además combinar números,
letras y caracteres especiales). Si adicionamos a esto, que las contraseñas de estos sitios
no pueden ser la misma en todos los casos, pues si la de una página es descubierta se
tendría acceso a todas las demás, tendríamos una cantidad considerable de contraseñas
que recordar. Según un estudio de Microsoft realizado en el Reino Unido, un usuario
gestiona unas 25 credenciales como promedio, de las cuales solamente 1 de cada 4 no se
repiten [32].
La mayoría de los usuarios inexpertos escriben las contraseñas en papel y las llevan con
ellos en la cartera o en documento de texto sin cifrar dentro de su dispositivo de
almacenamiento externo. Esta es la estrategia más riesgosa pues quien encuentre este
documento extraviado, está a un par de clics de distancia de hacerse con una cuenta
bancaria.
Servicios como Google o Facebook tienen métodos para ayudar al usuario a recordar sus
contraseñas o a resetearlas con facilidad. Pero estos métodos no son fiables dado que en
muchas ocasiones son preguntas personales del usuario, fáciles de adivinar.
Una solución poco segura, sería permitir a los navegadores que guarden todas las
contraseñas y el proceso de autentificación sería transparente para el usuario. Además de
no recomendado, esto no es práctico ya que no siempre se utiliza el mismo navegador o
el mismo dispositivo de conexión.
Existen servicios en la nube que proveen métodos para esta problemática. Google por
ejemplo, presenta este servicio donde sólo tienes que recordar la contraseña para acceder
a un fichero con todas las demás. Pero tendríamos que confiar en la buena voluntad y
honestidad del proveedor de servicio así como en su seguridad en cuanto a ataques.
Existen también varias herramientas que guardan las contraseñas e incluso las resetea
para el usuario. Pero tendríamos el mismo problema de que no es una solución práctica
pues la mayoría de los usuarios tiene 3 dispositivos como promedio con los cuales acceder
a sus cuentas.
En un escenario como este es donde CryptoDROID podría surtir efecto, pues se tiene un
fichero con todos los registros de los sitios, incluyendo su contraseña, y cada vez que el
usuario necesite acceder a alguna de ellas, se conecta a CryptoDROID con el fin de poder
acceder a sus registros.
Otro uso interesante que se le puede dar a CryptoDROID, más allá de su función de cifrado,
es el de poder utilizar al teléfono como memoria USB. Con la implementación de un
servidor WebDAV, un usuario podría guardar archivos directamente en la memoria del
Resultados
Página | 54
teléfono sin necesidad del cable USB a través de la Wifi. En un ambiente desconectado
como nuestro país, donde no se puede acceder de una forma transparente a los CSP,
manejar ficheros desde el teléfono a través de la Wifi sería una aplicación práctica. Además
se podría integrar directamente con herramientas de Office como muestra la Figura 4-1.
Existen varias ventajas con esta integración. La primera y más evidente es que no habría
que copiar el fichero de office que se quiere modificar en una ubicación extra.
Directamente se abre el archivo cifrado y luego de las modificaciones pertinentes se cierra
y se salva. Office se encarga de su sincronización.
Figura 4-1 Integración con las herramientas de Office
Conclusiones
Página | 55
5 Conclusiones
En nuestros días, es una necesidad la protección de información sensible como medida de
seguridad obligatoria, debido a la gran cantidad de ataques existentes. Disponer entonces
de un mecanismo fácil de utilizar, pero a la vez seguro y que no implique gastos adicionales,
sería de gran utilidad. Esta propuesta podría ser una herramienta segura para la protección
de los datos sensibles en los dispositivos Android de forma segura y portable, ya que
viajarían junto a él por estar en el teléfono y podrían accederse en todo momento. Al estar
cifrados utilizando la última tecnología (zona segura), se protegerían contra robo u otros
tipos de ataques.
Este trabajo muestra que el reemplazo de los TPD por teléfonos Android es posible siempre
y cuando el usuario acepte las limitaciones que esto implica. La primera de ellas es la
pérdida de la llave si se pierde o se le es sustraído el dispositivo, pero esta limitante
también existe cuando se usa un TPD. Una ventaja en comparación con un TPD, es que se
puede resguardar la llave privada mediante otro mecanismo y restaurarla en caso de
pérdida o extravío, así como tener respaldo de la información cifrada en la nube. Otra
limitante es la seguridad del canal de comunicación (con “barra verde”) que no es tan fácil
de lograr, ya que habría que pagar servicios adicionales o realizar la verificación
(instalación) del certificado digital manualmente. La última de las limitantes es la velocidad
de trasmisión de los datos desde y hacia el dispositivo móvil, pues la velocidad de la Wifi
que, aunque en los nuevos dispositivos es cada vez mayor, aún no se puede comparar con
la de un dispositivo USB 3.0. Sin embargo, no usar el USB nos independiza de llevar el cable
USB del teléfono junto con él y de necesitar el driver para que funcione en el dispositivo
que se esté utilizando para acceder al móvil.
Bibliografía
Página | 56
Bibliografía
[1]
S. a. Z. J. a. L. D. a. J. J. Nepal, «A mobile and portable trusted computing platform,»
EURASIP Journal on Wireless Communications and Networking, vol. 2011, nº 1, p.
75, 2011.
[2]
Y. C. a. R. K. Dejan Kovachev, «Mobile Cloud Computing: A Comparison of
Application Models,» Information Systems & Database Technologies RWTH Aachen
University , Ahornstr. 55, 52056 Aachen Germany, 2011.
[3]
P. G. Sujithra M, «Mobile Device Security : A Survey on Mobile Device Threats ,
Vulnerabilities and their Defensive Mechanism,» International Journal of Computer
Applications (0975-8887), vol. 56, nº 14, pp. 24-29, 2012.
[4]
M. S. M. S. Karen Scarfone, «Guide to Storage Encryption Technologies for End User
Devices Recommendations of the National Institute of Standards and Technology,»
2007.
[5]
L. O´Connor, «Celebrity Nude Photo Leak: Just One More Reminder That Privacy
Does Not Exist Online and Legally, There’s Not Much We Can Do About It,» 2014.
[En línea]. Available: digitalcommons.law.ggu.edu. [Último acceso: 28 01 2015].
[6]
«BBC
News,»
1
agosto
2012.
[En
línea].
Available:
http://www.bbc.com/news/technology-19079353. [Último acceso: 24 enero 2015].
[7]
R. a. C. R. Bhadauria, «A Survey on Security Issues in Cloud Computing».
[8]
C. W. K. R. a. W. L. Shucheng Yu, Achieving Secure, Scalable, and Fine-grained Data
Access Control in Cloud Computing, IEEE INFOCOM: Dept. of ECE, Worcester
Polytechnic Institute, Dept. of ECE, Illinois Institute of Technology, 2010.
[9]
Q. L. a. J. W. Guojun Wang, Hierarchical Attribute-Based Encryption for Fine-Grained
Access Control in Cloud Storage Services, Changsha, Hunan Province, P. R. China:
School of Information Science and Engineering, Central South University, 2010.
[10] L. M. A. L. J. C. P. J. v. D. Frank C. Bormann, Concept for Trusted Personal Devices in
a Mobile and Networked Environment.
Bibliografía
Página | 57
[11] Y. L. K. L. T. J. D. V. a. K. Y. Jaein Kim, «Vulnerability to Flash Controller for Secure
USB Drives,» Soonchunhyang University, Asan, Republic of Korea.
[12] A. Biryukov, «Known Plaintext Attack,» de Encyclopedia of Cryptography and
Security, 2011, pp. 704-705.
[13] A. a. O. P. C. V. Skillen, «Deadbolt : Locking Down Android Disk Encryption,» 2013.
[14] K. a. S. S.Raju, «Overview of Dropbox Encryption in Cloud Computing,» Department
of IT, Mahendra Engineering College, Namakkal, India, 2014.
[15] V. Gough, «EncFs,» 2011.
[16] R. M. A. S. Zhaohui Wang, «Implementing and Optimizing an EncryptionFilesystem
on Android,» Department of Computer Science George Mason University Fairfax,
USA, 2011.
[17] R. Laboratories, «RSAES-OAEP Encryption Scheme,» RSA Security Inc, Bedford,MA
01730 USA, 2000.
[18] M. a. V. J. Shand, «Fast implementations of RSA cryptography,» Computer
Arithmetic, 1993.
[19] R. Sandro, «A survey of key management for secure group communication,» ACM
Computing Surveys, vol. 35, nº 3, pp. 309-329, 2003.
[20] H. H. G. B. Y. J. Z. L. P. S. Xiaolei Li, «DroidVault: A Trusted Data Vault for Android
Devices,» Department of Computer Science and Graduate School for Integrative
Sciences and Engineering, National University of Singapore , Singapore , 2014.
[21] N. I. o. S. a. Technology, «Announcing the ADVANCED ENCRYPTION STANDARD
(AES),» Federal Information Processing Standards Publication 197 , USA, 2001.
[22] J. K. D. W. D. W. C. H. N. F. T. K. M. S. Bruce Schneier, «"The Twofish Team’s Final
Comments on AES Selection,» 2000.
[23] R. Focardi, «Practical Padding Oracle Attacks on RSA,» Hakin9 - Defend Yourself!
Hands-on Cryptography, 2012.
Bibliografía
Página | 58
[24] T. Cooijmans, Secure Key Storage and Secure Computation in Android, 2014.
[25] J. d. R. a. E. P. Tim Cooijmans, «Analysis of Secure Key Storage Solutions on
Android,» Radboud University Nijmegen , 2014.
[26] ARM, «Building a Secure System using TrustZone Technology,» ARM Limited, 2009.
[27] H. R. S. S. A. W. Nuno Santos, «Using ARM TrustZone to Build a Trusted Language
Runtime for Mobile Applications,» Proceedings of the 12th Workshop on Mobile
Computing Systems and Applications, Utah, USA, 2011.
[28] F. Martin, «SSL Certificates HOWTO,» 2002.
[29] D. B. a. A. Lioy, «Towards Simplifying PKI Implementation: Client-Server based
Validation of Public Key Certificates,» Dip. Automatica e Informatica Politecnico di
Torino, Torino, Italy, 2002.
[30] N. W. Group, «HTTP Extensions for Web Distributed Authoring and Versioning
(WebDAV),» L.M. Dusseault, Editor, 2007.
[31] H. a. H.-J. J. Rif`a-Pous, «Computational and Energy Costs of Cryptographic
Algorithms on Handheld Devices,» Future Internet, vol. 3, 2011.
[32] «BBC,»
BBC
Mundo,
23
mayo
2013.
[En
línea].
Available:
http://www.bbc.co.uk/mundo/noticias/2013/05/130522_tecnologia_contrasenas
_claves_internet_seguridad_dp. [Último acceso: 25 febrero 2015].