INVESTIGACION BASADA EN EL DISEÑO:
Tiene como objetivo contribuir a la solución de problemas relevantes al mismo tiempo que se hacen aportes significativos en un área del conocimiento, mediante el análisis de problemas aun no resueltos en un ambiente del mundo real y su solución de una manera novedosa y rigurosa a través del diseño de artefactos [127].
Esta metodología describe las siguientes fases: 1. Identificación
2. Determinación 3. Diseño y desarrollo 4. Evaluación
5. Comunicación
PRINCIPIOS DE SEGURIDAD DE LA INFORMACION:
La seguridad de la información generalmente está enfocada hacia los sistemas de Tecnologías de Información. Esta seguridad contiene la seguridad tanto física como operacional y organi- zacional del sistema de información.
A continuación, se describen los principios que conforman la seguridad de la información [4]: Integridad: es la garantía de la exactitud y completitud de la información y los métodos de su procesamiento. Asegurar que la información puede ser lo suficientemente precisa para su propósito. Este principio, representa uno de los principales indicadores de seguridad de la información.
La integridad de la información, no se basa solo en que el dato sea correcto, sino que además, se pueda confiar en él [128]. Para este principio, se tienen métodos como Hashing [129] , firma electrónica o protección con antivirus.
Confidencialidad: principio de seguridad que genera el requisito de protección contra inten- tos deliberados o accidentales para realizar lectura de datos no autorizados. La confidenciali- dad abarca los datos en el almacenamiento, durante el proceso y mientras están en tránsito [130].
Es la garantía de que la información se comparte solo entre personas u organizaciones autori- zadas. La violación de este principio, se puede dar cuando los datos no se manejan de manera adecuada [128]. Para esto, se tienen métodos de aseguramiento como tipos de cifrado: simé- trico (una clave secreta, se aplica al texto de un mensaje para cambiar su contenido) o asimé- trico (un par de claves, una publica disponible para cualquier persona que quiera enviar un mensaje y una privada solo para la persona que la conoce) [131].
Página 52 Disponibilidad: principio de seguridad que declara que los usuarios autorizados tienen acce- so a la información cuando lo requieran y de que el sistema es capaz de recuperarse rápida y completamente en caso de ocurrir un desastre. En este principio se consideran aspectos como: tolerancia a fallos, recuperación, redundancia, entre otros.
Este principio genera el requisito de la protección contra algún modo de causar una denega- ción de servicios o de datos [130].
Control de acceso: el principio de control de acceso o autorización: se asegura que un usua- rio autorizado tenga acceso a una información determinada.
Para este principio, se pueden usar por ejemplo ACL’S (colección secuencial de sentencias de permiso o rechazo que se aplican a direcciones o protocolos de capa superior) [132] o DMZ (red local ubicada entre la red interna y externa de una organización) [133].
Autenticación: principio que declara que quién solicita un acceso es quién dice ser. Para poner en práctica este principio, generalmente se verifica la identidad de un usuario, proceso o dispositivo, como un prerrequisito para permitir el acceso a los recursos de un sistema por medio de: contraseñas, dispositivos biométricos, firmas electrónicas, entre otros [130].
No repudio: asegurar que una entidad intervino en una transacción, es decir, que quién gene- re un evento válidamente, no pueda retractarse. Esto apoya la disuasión, el aislamiento de fallos, la detección y prevención de intrusos y acciones legales. Para tener un control de esto muchas veces se utilizan registro de eventos o logs.
Auditabilidad: principio que se encarga de verificar el adecuado funcionamiento de la segu- ridad.
POLITICAS DE SEGURIDAD:
Uno de los componentes de los modelos de seguridad son las políticas de seguridad. Una Política de seguridades un conjunto de requisitos definidos por los responsables de un siste- ma, que indica en términos generales que está y que no está permitido en el área de seguridad durante la operación general del sistema [134].
La RFC 1244 define una Política de seguridadcomo una “declaración de intenciones de alto nivel que cubre la seguridad de los sistemas informáticos y que proporciona las bases para definir y delimitar responsabilidades para las diversas actuaciones técnicas y organizativas que se requerirán” [135].
A grandes rasgos, la formulación de políticas de seguridad conlleva a: - Un análisis de riesgos, para adecuar políticas al contexto.
- Tener unos encargados para monitorizar las operaciones y los cambios en las políti- cas de seguridad.
En el caso del Proyecto de investigación, nuestros cambios en las políticas de seguridad se ven relacionados con el versionamiento de la plataforma. Para el alcance de este proyecto, se tuvo en cuenta las políticas definidas por la plataforma Android versión 4.1.
ASPECTOS DE UNA POLITICA DE SEGURIDAD
Generalmente en la definición de una política de seguridad, se tienen algunos conceptos apli- cados, como [136]:
Decisión: elección de un curso de acción determinado entre varios posibles.
Plan: conjunto de decisiones que definen cursos de acción futuros y los medios para conse- guirlos. Consiste en diseñar un futuro deseado y la búsqueda del modo de conseguirlo. Estrategia: conjunto de decisiones que se toman para determinar políticas, metas y progra- mas.
Política: definiciones establecidas por la dirección, que determina criterios generales a adop- tar en distintas funciones y actividades donde se conocen las alternativas ante circunstancias repetidas.
Página 54 Procedimiento: definición detallada de pasos a ejecutar para desarrollar una actividad deter- minada.
Norma: forma en que realiza un procedimiento o proceso.
Programa: secuencia de acciones interrelacionadas y ordenadas en el tiempo que se usan para coordinar y controlar operaciones.
Proyección: predicción del comportamiento futuro, basándose en el pasado sin el agregado de apreciaciones subjetivas.
Pronóstico: predicción del comportamiento futuro, con el agregado de hechos concretos y conocidos que se prevé influirán en los acontecimientos futuros.
Control: capacidad de ejercer o dirigir una influencia sobre una situación dada o hecho. Es una acción tomada para hacer un hecho conforme a un plan.
Riesgo: proximidad o posibilidad de un daño, peligro. Cada uno de los imprevistos, hechos desafortunados, entre otros, que puede tener un efecto adverso. Sinónimos: amenaza, contin- gencia, emergencia, urgencia, apuro.
POLITICAS DE SEGURIDAD DE LA PLATAFORMA ANDROID: SELINUX
Secutiry Enhanced Linux (SELinux) [137], implementa una política impulsada por control obligatorio de acceso (MAC) para el kernel de Linux. Una decisión de diseño esencial de su arquitectura es que la toma de decisión de una política, se desvincula de la política de aplica- ción lógica. SELinux usa el módulo de seguridad de Linux (LSM) que ofrece acceso a varios puntos de aplicación de control de bajo nivel de recursos como archivos, IPC local o protec- ciones de memoria.
Cuando una operación del LSM se da, por ejemplo: se abre un archivo, el módulo SELinux solicita una decisión de política de un servidor de seguridad en el kernel que gestiona las reglas de las políticas y contiene el acceso a las decisiones lógicas. Dependiendo de la deci- sión del servidor de seguridad, el módulo de seguridad de SELinux deniega o permite la ope- ración para proceder.
En un sistema SELinux cada objeto (archivos, canales IPC, ect) y sujeto (procesos) esta eti- quetado con un contexto de seguridad que consiste en una tripleta de atributos (usuario, rol y tipo). Estos atributos determinan a que objetos un sujeto puede acceder.
El refuerzo de tipos (type enforcement) es el mecanismo primario de control de acceso en SELinux y está basado en el tipo de contexto del atributo. Por defecto, todos los accesos son negados y deben ser garantizados explícitamente a través de reglas de políticas permitir re- glasen terminología SELinux.
El atributo usuario y rol forman la base para el control de acceso Role-Bases que se basa en el refuerzo de tipos definiendo que tipo y que combinaciones de rol son válidas para cada usuario en la política.
• Políticas dinámicas:
SELinux también implementa políticas dinámicas como banderas booleanas que afectan decisiones de políticas condicionales en tiempo de ejecución. Los booleanos y las condiciones deben definir prioridad al despliegue de políticas. Las condicio- nes/booleanos nuevos no pueden ser añadidas después de que la política ha sido car- gada sin recompilar la política entera.
Ejemplos de políticas dinámicas: booleanos que cambian entre “modo cumplimien- to” y “modo permisivo”.
El mecanismo de políticas dinámicasesta implementado en forma de declaraciones if para permitir reglas en la política.
• Administradores de objetos espaciales de usuario (USOMs) (Userspace Object Managers):
Página 56 Responsables de asignar contextos de seguridad a los objetos que manejan, consul- tando el servidor de seguridad SELinux para decisiones de control de acceso y ha- ciendo cumplir estas decisiones.
Ejemplos de USOMs: X Windows System Server [138], GConf [139] , SE- PostgreSQL [140]
SEANDROID
Prototipa SELinux para el kernel de Linux en Android [141] [142]. Distribuye servicios del sistema y aplicaciones en diferentes espacios del dominio de seguridad del kernel, aislando aplicaciones entre sí por medio del servicio de Multi-level security (MLS) de SELinux [137].
• SEAndroid hace del Binder Driver de Android un Manejador de Objetos de Espacio en Kernel (KOMs) (KernelSpace Object Manager), asegurando que todo Binder IPC está sujeto a toda la aplicación de las políticas de SE Android.
• SEAndroid etiqueta los procesos de aplicación con contextos de seguridad específi- cos de SELinux que se usan luego en el refuerzo de tipos.
• Cuando se encuentra una nueva aplicación Android, los procesos son bifurcados de un proceso del sistema (Zygote) [143], el cual viene instalado con las librerías de An- droid y permite los inicios rápidos de procesos de una nueva aplicación [144]. • SEAndroid emplea un mecanismo para obtener el contexto de seguridad de aplica-
ciones en tiempo de instalación.
• Basados en los permisos que las aplicaciones solicitan o la firma del desarrollador, a las aplicaciones se les asigna un tipo de seguridad. El mapeo de la meta-información de las aplicaciones a tipos de seguridad está definido en las políticas SEAndroid. SEAndroid, además provee soporte para políticas MAC en la capa de middleware (MMAC). MMAC consiste en tres mecanismos:
• MAC en tiempo de instalación: lleva a cabo una política basada en chequeo al mo- mento de la instalación de nuevas aplicaciones y niega la instalación, cuando la apli- cación solicita una combinación definida de permisos
• Revocación de permisos: este mecanismo anula el servicio de chequeo por defecto de Android, con una decisión basada en políticas para permitir/denegar a una aplicación aprovechar un permiso garantizado
• Intención MAC: que protege con una aplicación de (listado blanco) el envío de Inten- tos (intents) a Actividades (Activities), Receptores de Broadcast (Broadcast Recei- vers) y Servicios (Services). Las reglas del (listado blanco) están basadas en el tipo de seguridad del emisor y el receptor del mensaje de Intento, así como los datos del mensaje.
POLITICAS DEL API DE ADMINISTRACION DEL DISPOSITIVO
El API de Administración del dispositivo se usa para escribir aplicaciones de administración de dispositivos que los usuarios instalan en sus dispositivos. La aplicación de administración del dispositivo hace cumplir las políticas de seguridad [145] [146].
Una vez que se instala la aplicación de administración de dispositivos, el dispositivo está sujeto a las políticas de este. El administrador puede:
- Preguntar al usuario para establecer una nueva contraseña - Bloquear inmediatamente el dispositivo
- Realizar un restablecimiento de fábrica en el dispositivo, borrar los datos del usuario (si tiene permiso)
Si el usuario no activa la aplicación de administración de dispositivos, esta se mantiene en el dispositivo pero en un estado inactivo. Así, los usuarios no serán sujetos a sus políticas. Si un usuario incumple con una política de la aplicación de administración de dispositivos, una vez está instalada, la aplicación decide cómo manejar esto.
Para desinstalar una aplicación de administración de dispositivo, los usuarios necesitan pri- mero desactivar la aplicación como un administrador del dispositivo.
Página 58
Contraseña habilitada Requiere que el dispositivo pregunte por un
PIN o contraseña.
Tamaño mínimo de la contraseña Establece el número necesario de caracteres para la contraseña.
Contraseña alfanumérica requerida Requiere que la contraseña tenga una combi- nación de letras y números. Estos pueden incluir caracteres simbólicos.
Contraseña compleja requerida Requiere que las contraseñas contengan al menos una letra, un digito y un símbolo es- pecial. Introducido en Android 3.0.
Mínimo de letras requeridas en una contrase- ña
El mínimo número de letras requeridas en una contraseña para todos los administrado- res o para uno en particular. Introducido en Android 3.0.
Mínimo de letras minúsculas requeridas en una contraseña
El mínimo número de letras minúsculas re- queridas en una contraseña para todos los administradores o para uno en particular. Introducido en Android 3.0.
Mínimo de caracteres que no son letras re- queridos en una contraseña
El mínimo número caracteres que no son letras requeridos en una contraseña para to- dos los administradores o para uno en parti- cular. Introducido en Android 3.0.
Mínimo de dígitos numéricos requeridos en El mínimo número de dígitos numéricos requeridos en una contraseña para todos los
una contraseña administradores o para uno en particular. Introducido en Android 3.0.
Mínimo de símbolos requeridos en una con- traseña
El mínimo número de símbolos requeridos en una contraseña para todos los administrado- res o para uno en particular. Introducido en Android 3.0.
Mínimo de letras mayúsculas requeridas en una contraseña
El mínimo número de letras mayúsculas re- queridas en una contraseña para todos los administradores o para uno en particular. Introducido en Android 3.0.
Tiempo de expiración de la contraseña Cuando la contraseña caducara, expresada como un delta en milisegundos desde cuando un administrador del dispositivo establece el tiempo de expiración. Introducido en An- droid 3.0.
Requerir cifrado de almacenamiento Especifica que el área de almacenamiento debe ser encriptado, si el dispositivo lo so- porta. Introducido en Android 3.0.
Deshabilitar cámara Especifica que la cámara debe ser deshabili-
tada. Esta no debe ser una des habilitación permanente, la cámara puede ser habilitada/ deshabilitada basado en el contexto. Intro- ducido en Android 4.0.
Una política de seguridad además puede requerir cifrado del dispositivo de almacenamiento como en Android 3.0 o deshabilitar la cámara como en Android 4.0.
Página 60 Un ejemplo de una aplicación de administración de dispositivos es el Android SDK Manager.
ARQUITECTURA DE LA PLATAFORMA: APLICACIONES
La plataforma Android tiene un conjunto de aplicaciones básicas incluyendo un cliente de email, un programa de SMS (Short Message Service: para enviar y recibir mensajes de texto), calendario, mapas, navegador, contactos, entre otros. Todas las aplicaciones se escriben usando el lenguaje de programación Java [147].
FRAMEWORK DE APLICACION
La arquitectura de la plataforma Android, está diseñada para simplificar la reutilización de componentes. Los desarrolladores tienen acceso completo al mismo framework de APIs usa- dos por las aplicaciones núcleo del sistema.
Esta capa está compuesta por los siguientes componentes [148] [149] [3]:
- View System (Sistema de vista): se pueden usar para construir una aplicación, in- cluyendo listas, rejillas, cajas de texto, botones e incluso navegadores web embebi- dos, entre otros componentes.
- Content Provider (Proveedor de contenido): permite que las aplicaciones accedan a datos de otras aplicaciones (por ejemplo: contactos), o que compartan su propia in- formación. Maneja un conjunto de datos de aplicación compartidos, por ejemplo: se puede almacenar información en un archivo del sistema, una base de datos SQLite en la web o cualquier ubicación de almacenamiento persistente que la aplicación pueda acceder.
Los proveedores de contenido también son útiles para leer y escribir datos que son privados para una aplicación y no compartidos.
- Telephony Manager (Administrador del teléfono): provee acceso a la información acerca de los servicios telefónicos del dispositivo. Contiene servicios y estados del te-
léfono, así como acceso a información de suscriptor. Las aplicaciones pueden recibir notificaciones sobre el cambio de estado del teléfono.
- Resource Manager (Administrador de recursos): provee acceso a recursos sin có- digo como gráficos y archivos de diseño. Ejemplos: cadenas de texto traducidas a di- ferentes idiomas, imágenes, sonidos o layouts.
- Notification Manager (Administrador de notificaciones): permite a todas las apli- caciones desplegar alertas personalizadas en la barra de estados del sistema.
- Activity Manager (Administrador de actividades): maneja el ciclo de vida de las aplicaciones y provee una navegación común.
- Location Manager: provee acceso a los servicios del sistema de localización del dispositivo, permite a las aplicaciones obtener actualizaciones de la localización geo- gráfica del dispositivo.
- Package Manager: maneja información relacionada con los paquetes de aplicación que están instalados actualmente en el dispositivo.
- Sensor Manager: permite manipular los elementos de hardware del teléfono como acelerómetro, sensor de luminosidad, sensor de presión, de proximidad, de tempera- tura, entre otros.
FRAMEWORK DE LIBRERIAS Y TIEMPO DE EJECUCION LIBRERIAS:
Dentro de las librerías de Android, se encuentran las siguientes [149] [3]:
System C Library (Sistema de librerías de C): una implementación derivada del sistema de librerías estándar de C (libc) atenta a los dispositivos que tengan Linux embebido.
Media libraries (Librerías media): basados en OpenCORE de PacketVideo [150], librerías que soportan reproducción y grabación de muchos formatos populares de audio y video, así como archivos de imágenes estáticas, como MPEG4, H.264, MP3, AAC, AMR, JPG y PNG. Surface Manager (Administrador de superficie): maneja el acceso a subsistemas de des- pliegue y a las capas de gráficos 2D y 3D de muchas aplicaciones.
Página 62 LibWebCore (Librerías Web): moderno motor de navegador web que refuerza el navega- dor de Android y una vista web integrable.
SGL: el motor de gráficos 2D.
3D libraries (Librerías 3D): una implementación basada en los APIs OpenGL ES 1.0 [151], las librerías usan la aceleración del hardware 3D o la incluida (software 3D rasterizer alta- mente optimizado).
Freetype: mapa de bits y fuente vectorial para representaciones (renderizado).
SQLite: un potente y ligero motor de base de datos relacional disponible para todas las apli- caciones.
TIEMPO DE EJECUCION ANDROID:
Android incluye un conjunto de librerías principales que proveen la mayoría del funciona- miento disponible en las librerías del lenguaje de programación Java.
Cada aplicación de Android corre en su propio proceso, con su propia instancia de la máquina virtual Dalvik. Dalvik está hecho para que cada dispositivo pueda correr muchas máquinas virtuales eficientemente. La máquina virtual de Dalvik ejecuta archivos en un formato ejecu- table dalvik (.dex), que esta optimizado para la cantidad de memoria mínima del sistema [149].
La máquina virtual está basada en registrosy corre clases compiladas por un compilador del lenguaje Java que ha sido transformado al formato (.dex) por la herramienta incluida en el sistema “dx”.
Este componente además se hace cargo de la distribución de tareas por medio de hilos y del manejo de memoria de bajo nivel.
Android está basado en la versión 2.6 de Linux para sistema de servicios principales como seguridad, manejo de memoria, manejo de procesos, red y drivers. El Kernel actúa como una capa de abstracción entre el hardware y el resto de la pila de software.
Display driver (Controlador de despliegue): en este componente se tiene en cuenta tanto el despliegue como los gráficos, las vistas y las entradas en el dispositivo.
Camera driver (Controlador de la cámara): es manejado por un servicio de cámara, acce- dido mediante la clase Camera, para configurar ajustes de captura de imagen, iniciar/ detener vista previa, sacar fotos y recuperar los marcos para la codificación del video. Para acceder al dispositivo de Cámara, se debe declarar el permiso de “CAMERA” en el manifiesto (archivo principal) de Android [152].
Bluetooth driver (Controlador de bluetooth): contiene funcionalidades como escaneo de dispositivos, conexión con dispositivos y manejo de transferencia de datos entre dispositivos. Los APIs existentes para Bluetooth permiten a las aplicaciones [153]:
- Escanear otros dispositivos Bluetooth