Un Data Warehouse para el estudio de la privacidad y seguridad de aplicaciones móviles

Un Data Warehouse para el Estudio de la Privacidad y Seguridad de Aplicaciones M´ oviles Alejandro P´ erez-Fuente, M. Mercedes Mart´ ınez-Gonz´ alez, Amador Aparicio, Quiliano Isaac Moro Grupo de Investigaci´ on en Ingenier´ ıa de la Privacidad de la Universidad de Valladolid [email protected] Resumen—La privacidad juega un papel sustancial en las aplicaciones m´ oviles ya que cada d´ ıa se procesa y almacena una mayor cantidad de datos en los dispositivos m´ oviles. Sin embargo, no se dispone de estudios sobre el impacto que generan las aplicaciones sobre la privacidad de sus usuarios, que estos puedan consultar para empoderarse en la protecci´ on de su privacidad. Entre las causas, la falta de repositorios f´ acilmente accesibles para los investigadores que almacenen metadatos relativos a la privacidad de las aplicaciones. En este art´ ıculo presentamos un repositorio con metadatos de aplicaciones Android capaz de aportar metadatos de calidad a quienes analizan la seguridad y privacidad de las aplicaciones m´ oviles. La calidad de los datos se garantiza desde el dise˜ no, tanto de los procesos de integraci´ on de datos, como su seguridad y la del repositorio. Actualmente, el repositorio es accesible y consta de metadatos de un total de 9068 aplicaciones. Index Terms—Seguridad, Privacidad, Warehousing, Repositorio, aplicaciones Android Tipo de contribuci´ on: Investigaci´ on original I. INTRODUCCI´ ON En la actualidad, los tel´ efonos m´ oviles son un elemento de uso cotidiano. Millones de personas tienen acceso a un tel´ efono m´ ovil que les permite navegar por internet, acceder a redes sociales... Ya no se trata solo de un medio para comunicarse mediante llamadas de voz o mensajes de texto, sino que tambi´ en se han convertido en una herramienta esencial para el trabajo, el entretenimiento y la educaci´ on. La importancia que tienen los tel´ efonos m´ oviles en la sociedad actual es innegable y todo apunta a que lo seguir´ a siendo. Entre todas las aplicaciones que utilizamos merecen especial atenci´ on las que acceden a informaci´ on personal, como fotograf´ ıas, la ubicaci´ on y la lista de contactos, y las que utilizamos para realizar actividades privadas, como pedir citas m´ edicas. En muchas ocasiones, pese a que la recopilaci´ on y utilizaci´ on de datos personales est´ a regulada por la Ley Org´ anica de Protecci´ on de Datos y Derechos Digitales [1], las aplicaciones acceden a informaci´ on sensible sin que el usuario sepa con claridad que uso se har´ a de esta [2]. Existen varios sistemas operativos de tel´ efonos m´ oviles, pero los tres principales son: Android, iOS y Windows Phone. Android, desarrollado por Google, es el sistema operativo que mayor cuota de mercado abarca, un 86,2 % [3]. Por ello, este trabajo se centra en las aplicaciones Android. Hasta donde conocemos, no hay herramientas que ayuden a detectar este problema en el ´ ambito de las aplicaciones m´ oviles sin requerir instalaci´ on en los dispositivos como es el caso de CONAN mobile [4]. Por ello, en este trabajo se propone una soluci´ on similar a las que analizan la privacidad Figura 1. Arquitectura de App-PI. en sitios web, por ej., PrivacyScore [5], pero aplicado a aplicaciones m´ oviles. Nuestra propuesta es App Privacy Impact (App-PI), un ecosistema para la evaluaci´ on del impacto de apps para dispositivos m´ oviles sobre la privacidad y seguridad de sus usuarios. Este ecosistema consta de las siguientes partes (ver Fig. 1): Repositorio y los procesos ETL1asociados: un almac´ en de metadatos de aplicaciones Android. Se utilizan para calcular el impacto en la privacidad de los usuarios [6]. API2: un acceso abierto de los contenidos del warehouse para servicios e investigadores [6]. Una serie de m´ etricas que calculen el impacto de las aplicaciones en la privacidad de los usuarios haciendo uso de la informaci´ on del warehouse. Aplicaciones para usuarios finales que implementan las m´ etricas y ofrecen servicios de usuario, permitiendo as´ ı empoderar al usuario final en la toma de decisiones respecto a su privacidad [7]. Dentro de este ecosistema, el principal objetivo del warehouse es poner a disposici´ on de investigadores y servicios toda la informaci´ on y metadatos necesarios para poder analizar el impacto de una aplicaci´ on sobre la privacidad y seguridad de sus usuarios. En este art´ ıculo nos centramos en 1ETL: Extract, Transform, Load. 2API: Application Programming Inteface. JNIC 2024 ISBN:978-84-09-62140-8 624 este componente, App-PIMD (App Privacy Impact MetaData) donde se incluye el repositorio y la API. Actualmente3, el repositorio es accesible4y consta de metadatos de un total de 9068 aplicaciones. La estructura del art´ ıculo es la siguiente: la Secci´ on II revisa otras investigaciones sobre almacenes de aplicaciones Android; la Secci´ on III muestra los distintos componentes del repositorio as´ ı como las decisiones de dise˜ no del mismo m´ as relevantes, entre las que destacamos las relativas a la seguridad desde el dise˜ no, y c´ omo contribuye a garantizar la calidad de los datos almacenados; la Secci´ on IV aporta datos sobre el contenido del repositorio y unas pruebas del mismo; la Secci´ on V realiza un an´ alisis retrospectivo de alguna de las decisiones tomadas; la Secci´ on VI presenta las conclusiones obtenidas de este trabajo; la Secci´ on VII muestra las posibles l´ ıneas de trabajo futuro que plantea este proyecto. II. TRABAJO RELACIONADO En la actualidad existen algunos almacenes de aplicaciones [8]. Entre los m´ as voluminosos se tiene el conjunto de aplicaciones de Androzoo [9] y el de AndroVault [10]. El primero de estos almacena los archivos .apk de un gran n´ umero de aplicaciones, mientras que el segundo se centra en la extracci´ on de conocimiento de aplicaciones por medio de diversos an´ alisis. Aunque almacenan una gran cantidad de aplicaciones, no hay metadatos relativos a la privacidad y seguridad de las aplicaciones. En el caso de Androzoo, en diciembre de 2023 se ha a˜ nadido la extracci´ on de metadatos de Google Play. Esto es claramente un indicador del inter´ es en el estudio de las aplicaciones m´ oviles. No obstante, su repositorio sigue siendo de car´ acter general. No tiene en cuenta los grupos de permisos, posibles puntuaciones de privacidad, o la naturaleza estructurada de algunos de los metadatos como los AOSP5. Todos ellos datos que pueden ayudar a construir herramientas que empoderen a los usuarios en la protecci´ on de su privacidad. Un proyecto que intent´ o abordar este problema fue Tacyt [11], de Telef´ onica Espa˜ na. Este pretend´ ıa clasificar millones de aplicaciones m´ oviles mediante su an´ alisis. No obstante, el proyecto fue descontinuado en 2021. Otro que s´ ı contin´ ua abierto es CONAN mobile, del INCIBE. Sin embargo, su enfoque es diferente, analiza los dispositivos en busca de amenazas. CONAN mobile requiere su instalaci´ on en nuestros dispositivos y solamente analiza aplicaciones ya instaladas en nuestro dispositivo [4]. Tambi´ en existen repositorios donde se puede encontrar el c´ odigo de las aplicaciones [12]. No obstante, debido a la naturaleza de software propietario por parte de la mayor´ ıa de aplicaciones populares como Whatsapp, Microsoft Teams y TikTok en el ´ ambito de las redes sociales, o CapCut en el de edici´ on de v´ ıdeo, estos repositorios s´ olo contienen el c´ odigo de aplicaciones de c´ odigo abierto. Esto limita mucho su potencial a la hora de realizar an´ alisis de la intrusividad en la privacidad, ya que la mayor´ ıa de usuarios utiliza las 3A fecha 26/02/2024. 4https://apkfalcon.infor.uva.es:8080 5AOSP: Android Open Source Project. aplicaciones m´ as populares, que suelen ser las de software propietario. Los repositorios de aplicaciones que almacenan informaci´ on sobre la intrusividad en la privacidad son muy reducidos [13], [14]. Generalmente estos vienen asociados a un estudio de aplicaciones concretas, lo que dificulta la generalizaci´ on de los resultados a otras aplicaciones. III. EL REPOSITORIO DE APP-PI La construcci´ on del repositorio se plantea como un servicio de consulta para aplicaciones que realizan an´ alisis para conocer el impacto sobre la privacidad y seguridad de los usuarios a partir de sus propiedades caracter´ ısticas, tal como las han definido sus desarrolladores, independientemente del dispositivo en el que se instala. En consecuencia, se dise˜ naron los componentes del ecosistema que recopilan metadatos, acorde a un modelo de warehousing. Los procesos ETL extraen metadatos de fuentes de datos. Estos datos se cargan en un repositorio, que se consulta utilizando una API (ver Fig. 1). Los datos se almacenan en una base de datos MySQL. La interacci´ on se ofrece a trav´ es de una API que redirecciona las consultas a la base de datos. Se decidi´ o no ofrecer acceso directo con consultas SQL por seguridad. La tecnolog´ ıa que soporta esta API se detalla en la secci´ on III-B. III-A. El Repositorio App-PIMD Para alcanzar el objetivo anteriormente mencionado, se perfilan distintos tipos de usuario del repositorio: Usuario general: Es el tipo de usuario m´ as frecuente y no es necesario estar registrado para trabajar con este perfil. Este tipo de usuario puede consultar los contenidos del warehouse. Tambi´ en puede solicitar la carga de nuevas aplicaciones para enriquecerlo. Usuarios expertos: Este tipo de usuario puede puntuar la intrusividad en la privacidad de las aplicaciones. De este modo, se aumenta la calidad de la informaci´ on del warehouse en este aspecto gracias a tener m´ ultiples fuentes heterog´ eneas de informaci´ on. Est´ a previsto para capturar la opini´ on verificada de expertos en privacidad y/o seguridad. La diferencia sustancial con el perfil anterior es que este tipo de usuario s´ ı puede modificar el contenido -aunque, nunca los esquemasdel warehouse mientras que el usuario general solo puede solicitar la inserci´ on de nuevos datos. Este tipo de usuario necesita estar registrado. Usuario administrador: Este tipo de usuario es el encargado de actualizar directamente el warehouse, as´ ı como asegurar la calidad de los datos del mismo, por ejemplo, llevando a cabo la carga masiva de aplicaciones. Por ello, est´ a reservado para el grupo de investigaci´ on que mantiene el warehouse. Se dise˜ na el repositorio en base a los siguientes criterios: modularidad, escalabilidad y seguridad. Los dos primeros permiten que este se pueda reutilizar y ampliar seg´ un los cambios que vayan surgiendo en el mundo de las aplicaciones Android. En cuanto a la seguridad, se plantea como un criterio imprescindible para poder conseguir que haya datos de calidad almacenados en el repositorio. Un Data Warehouse para el Estudio de la Privacidad y Seguridad de Aplicaciones M´oviles 625 Atendiendo a estos criterios, se decide utilizar una arquitectura de Data Warehouse por ser la m´ as limpia que cumple con las necesidades del repositorio. En esta, se separan los componentes de acceso al repositorio y carga de datos, llev´ andose a cabo estos por medio de la API y los procesos ETL respectivamente (ver Fig. 1). A˜ nadi´ endose de este modo seguridad al repositorio gracias a desacoplar las distintas responsabilidades en componentes. Adem´ as, hacer uso de t´ ecnicas ETL permite extraer grandes cantidades de datos de fuentes heterog´ eneas, transformarlos en un esquema com´ un y, finalmente, cargarlos en un repositorio centralizado, el warehouse. III-B. La Seguridad de App-PIMD El repositorio App-PIMD introduce estas estrategias para contemplar la seguridad desde el dise˜ no: Uso de distintos roles de usuarios que previenen cargas de datos malintencionadas que podr´ ıan afectar negativamente a la calidad de los datos. Gracias a los distintos tipos de usuario, se puede limitar la funcionalidad asociada a cada uno de estos en funci´ on de su calidad como fuente de informaci´ on. Por ejemplo, los usuarios generales que no est´ an registrados ser´ ıan una fuente potencial de datos de baja calidad si se dedicasen a subir informaci´ on falsa al warehouse. Por ello, estos no pueden actualizar de manera directa el contenido del warehouse. Sin embargo, los usuarios expertos (especialistas en privacidad y/o seguridad) s´ ı que representan una fuente de informaci´ on de calidad. Por ello, s´ ı pueden actualizar directamente los contenidos del warehouse. Se incorpora una API para el acceso al warehouse. De este modo, se protege el repositorio contra ataques de tipo SQLi [15] y, se independiza el componente de acceso haciendo que los usuarios solo puedan modificar los datos almacenados a trav´ es de las interfaces que aporta la API. Gracias a que toda la informaci´ on modificada del repositorio es gestionada por la API, se aumenta la uniformidad y calidad de los datos almacenados. Se hace uso de fuentes de datos de calidad. En referencia a los metadatos sobre el sistema operativo Android y su sistema de permisos, se usan las webs oficiales del sistema operativo: AndroidDevelopers [16], [17] y GoogleGit 6, donde se encuentra respectivamente la documentaci´ on y el c´ odigo fuente de Android. Para los metadatos de aplicaciones se usan m´ ultiples fuentes: Androzoo [9], Apkpure 7, Evozi 8... Para las medidas de intrusividad de las aplicaciones se usan tambi´ en m´ ultiples fuentes: Tosdr [18], m´ etrica App-PI [19], estudios pasados a este respecto [13], [14]... Todos los metadatos se extraen de los archivos empaquetados de la aplicaci´ on (.apk). De este modo, al extraer la informaci´ on directamente de las aplicaciones, se asegura la uniformidad entre las distintas fuentes de 6https://android.googlesource.com/ 7https://apkpure.net/es/ 8https://apps.evozi.com/apk-downloader/ datos y la calidad de estos. Adem´ as, esto permite realizar comparaciones entre datos de distintas fuentes. Se almacenan los hash SHA256 de los archivos de aplicaci´ on (.apk). Esto es muy importante ya que por medio del hash se puede comprobar si una aplicaci´ on ha sido comprometida. Por ejemplo, digamos que se tiene una versi´ on Xde la aplicaci´ on com.whatsapp obtenida de Google Play y de una p´ agina web de dudosa reputaci´ on. Si los hash de ambos archivos son diferentes, significar´ a que pese a ser la misma versi´ on de aplicaci´ on, su contenido es diferente y, por tanto, una de las dos aplicaciones ha sido comprometida. Se almacena el origen de las aplicaciones, as´ ı como de las puntuaciones que estas reciben sobre lo intrusivas que son en la privacidad. De este modo, se tiene una trazabilidad completa de todos sus metadatos, lo que permite subsanar posibles deficiencias en la calidad de los mismos. Por ejemplo, si se descubre que una fuente de informaci´ on resulta ser de baja calidad, se podr´ ıan omitir las aplicaciones de dicha fuente. Se hace uso de los protocolos y est´ andares habituales de los servicios web. Para la comunicaci´ on, se utiliza el protocolo HTTPS que garantiza la integridad y la seguridad en la transferencia de los datos gracias al cifrado de estos. En concreto, se ha utilizado una clave RSA de 4096 bits. Para la autenticaci´ on de los usuarios, el est´ andar OAuth 2.0 [20], el cual emplea la cabecera HTTP Authorization. Finalmente, para la definici´ on de la API, se utiliza el est´ andar OpenAPI 3 [21]. Todo esto facilita la interacci´ on segura entre los usuarios y el repositorio. Se han implementado protecciones necesarias para evitar posibles sobrecargas del sistema y ataques de denegaci´ on de servicio distribuidos (DDoS 9). En este respecto, se limita la cantidad de recursos m´ axima que se puede asociar a las peticiones de tal modo que nunca se supere dicho l´ ımite. Tambi´ en se han limitado la cantidad m´ axima de peticiones concurrentes permitidas en las funcionalidades especialmente pesadas, como la carga de aplicaciones nuevas al repositorio. III-C. El Warehouse y los ETL Como se ha mencionado anteriormente, el repositorio se nutre de m´ ultiples fuentes de datos heterog´ eneas para incrementar la calidad de la informaci´ on que almacena. A continuaci´ on, se describe el flujo general de datos del warehouse el cual incluye el proceso completo de carga de datos y, los distintos procesos ETL que gestionan el flujo de cada fuente de datos. Tal y como se aprecia en la Fig. 2, el warehouse almacena 3 tipos de datos diferentes provenientes de distintos tipos de fuentes de datos (HTML, APIs y archivos): Aplicaciones. Las fuentes de datos de aplicaciones son: la fuente API de Androzoo [9] y, las fuentes HTML: Apkpure, Evozi, Apkmonk 10 y Apkfollow 11. 9DDoS: Distributed Denial of Service. 10https://www.apkmonk.com/ 11https://www.apkfollow.com/es/ A. P´erez-Fuente, M. M. Mart´ınez-Gonz´alez, A. Aparicio and Q. I. Moro 626 Figura 2. Modelo ETL y flujo de datos del warehouse. De cada aplicaci´ on se almacenan metadatos identificativos de la misma como: su nombre de paquete, su hash SHA256, su versi´ on, su categor´ ıa y metadatos sobre su extracci´ on como la fuente y fecha entre otros. En referencia a los metadatos relacionados con la intrusividad en la privacidad se almacenan los permisos que esta utiliza, los que define, los grupos de permisos y las puntuaciones de intrusividad obtenidas por la aplicaci´ on ente otros. AOSP. Las fuentes de los metadatos de Android y su sistema de permisos son las p´ aginas web HTML de documentaci´ on 12 y c´ odigo del sistema Android 13. Se almacenan los permisos y grupos de permisos que declara el sistema operativo Android (ejemplo de permiso: android.permission.READ SMS). De cada permiso se almacena el nivel de protecci´ on o tipo, su identificador o nombre, en qu´ e versi´ on del sistema se incluy´ o y, el grupo de permisos al que pertenece. Adem´ as, de cada permiso de tipo dangerous se almacena una puntuaci´ on sobre el impacto en la privacidad que este tiene [22]. Estos son los metadatos que utilizan las m´ etricas que eval´ uan la privacidad [19], y que tambi´ en est´ an relacionados con la seguridad de los datos que Google incorpora en su market para informar a sus usuarios sobre la seguridad y privacidad de sus datos en las aplicaciones [23]. Validaci´ on. Las fuentes de datos que miden el nivel de intrusividad en la privacidad de las aplicaciones son: la API de Tosdr [18], los archivos de texto de estudios pasados a este respecto [13], [14], y nuestra propia API por medio de la opini´ on de los expertos. Estos datos son puntuaciones asociadas a cada aplicaci´ on concreta. Cada tipo de dato almacenado puede provenir de diversas fuentes de datos de distinto tipo HTML, API o archivo. Por tanto, tienen un proceso ETL distinto asociado. III-C1. Flujos ETL de aplicaciones: La Fig. 3 muestra el flujo de datos en el proceso ETL que carga los metadatos de una aplicaci´ on en el warehouse. La entrada es el nombre de paquete de la aplicaci´ on a descargar (ej. net.universia.uva). La categor´ ıa se extrae del market oficial de Android, Google Play. Google se protege frente a las descargas masivas de apli- 12https://developer.android.com/ 13https://android.googlesource.com/ Figura 3. Flujo de datos de subida de una aplicaci´ on al warehouse. caciones para evitar que otras personas creen markets que compitan contra ellos [9]. Para solventar las trabas que este market tiene a las extracciones autom´ aticas masivas se ha trabajado con las URL, haciendo b´ usquedas de expresiones regulares. Aunque en nuestro caso no aplicamos descargas masivas de aplicaciones a este market, los mecanismos de defensa de Google tambi´ en dificultan nuestra tarea. A continuaci´ on, se descarga el archivo empaquetado de la aplicaci´ on (.apk) de una de las distintas fuentes de datos del warehouse. En el caso de la API de Androzoo, se realiza una petici´ on a la API con el hash de la aplicaci´ on a descargar como par´ ametro. En el caso de las p´ aginas web anteriormente mencionadas, se aplica un proceso de scrapping sobre las mismas que da como resultado el enlace de descarga directo de dicha aplicaci´ on. Estos procesos de web scrapping se han implementado mayoritariamente con b´ usquedas de patrones haciendo uso de expresiones regulares sobre los links de cada p´ agina, de tal modo que se independiza de su interfaz visual. De esta manera se prolonga la vida de los scrapping desarrollados ya que, por norma general, las interfaces web son mucho m´ as cambiantes que los esquemas de los recursos (los esquemas de las URL). Una vez se tiene el archivo de aplicaci´ on empaquetado, se extrae el archivo AndroidManifest.xml el cual contiene todos los metadatos sobre permisos y grupos de permisos de forma semiestructurada (XML) [16], [17]. Tal y como se ve en la Fig. 3, el paso final es integrar la informaci´ on extra´ ıda del .apk con la categor´ ıa de la aplicaci´ on, pudi´ endose as´ ı insertar todos los metadatos extra´ ıdos en el warehouse. III-C2. Flujos ETL de AOSP: La Fig. 4 muestra el flujo de datos para cargar los metadatos de Android y su sistema de permisos y grupos de permisos. A partir del fichero AndroidManifest.xml del core/res/ del c´ odigo fuente del sistema operativo, se extraen los permisos y grupos de permisos declarados por este. Este fichero tiene la misma estructura que el AndroidManifest.xml que contienen las aplicaciones lo que facilita enormemente la extracci´ on de informaci´ on del mismo [16], [17]. A partir del identificador de los permisos y grupos de permisos, se consigue mediante scrapping en la p´ agina web de documentaci´ on del sistema operativo (Android Developers) la versi´ on de la API en que se a˜ nadieron. Una vez se tiene, se integran los datos y son insertados en el warehouse. III-C3. Flujos ETL de validaci´ on: Para cargar la informaci´ on relativa al nivel de intrusividad de una aplicaci´ on en la privacidad de los usuarios, se busca si las fuentes de validaci´ on (Tosdr [18] o los estudios pasados [13], [14]) aportan una puntuaci´ on para esta. En el caso de Tosdr se realiza por medio de una petici´ on Un Data Warehouse para el Estudio de la Privacidad y Seguridad de Aplicaciones M´oviles 627 Figura 4. Flujo de datos AOSP. a su API, mientras que en el caso de los estudios pasados se busca si estos conten´ ıan la aplicaci´ on. Si es as´ ı, se escala cada una de las puntuaciones obtenidas entre 0 y 10 y, se cargan al warehouse. Este escalado nos permite comparar las distintas puntuaciones obtenidas ya que se encuentran en un mismo rango de valores. Para las puntuaciones otorgadas por los expertos, estas se reciben por medio de la API del warehouse ya escaladas entre 0 y 10, por lo que simplemente se almacenan junto al resto. En caso de que ninguna fuente de validaci´ on tuviera informaci´ on relativa a una aplicaci´ on, siempre se seguir´ ıa teniendo la puntuaci´ on obtenida por la aplicaci´ on de la m´ etrica de App- PI [19]. III-D. La API de Acceso al Warehouse La API sigue el est´ andar OpenAPI. Se facilita la interoperabilidad del warehouse con otros sistemas de terceros gracias a la documentaci´ on web interactiva que este est´ andar aporta. La funcionalidad de la API se encuentra segmentada seg´ un el tipo de usuario. Teniendo cada uno de estos sus respectivos puntos de entrada. El punto de entrada de los usuarios generales es: https: //apkfalcon.infor.uva.es:8080/. La Fig. 5 muestra la p´ agina web https://apkfalcon.infor.uva.es:8080/docs que contiene la documentaci´ on de toda la funcionalidad permitida para este tipo de usuario, siendo las operaciones m´ as habituales: 1. Descargar los metadatos de una aplicaci´ on. Esta se realiza por medio de una petici´ on de tipo GET a la URL: https://apkfalcon.infor.uva.es:8080/get/app/ package con el nombre de paquete de la aplicaci´ on solicitada con el par´ ametro package. Por ejemplo, la Fig. 6 muestra la consultada realizada para obtener los metadatos de WhatsApp: https://apkfalcon.infor.uva.es:8080/get/app/package? package=com.whatsapp. 2. Solicitar la carga de una aplicaci´ on. Esta se realiza por medio de una petici´ on de tipo POST a la URL: https://apkfalcon.infor.uva.es:8080/post/app/ package teniendo el nombre de paquete de la aplicaci´ on solicitada en el cuerpo de la petici´ on. El punto de entrada de los usuarios expertos es: https: //apkfalcon.infor.uva.es:8080/expert/. La documentaci´ on de toda la funcionalidad permitida para este tipo de usuario Figura 5. Documentaci´ on de la funcionalidad de los usuarios generales. se encuentra en la p´ agina web: https://apkfalcon.infor.uva.es: 8080/expert/docs, siendo la operaci´ on m´ as habitual la subida de una puntuaci´ on de una aplicaci´ on. Esta se realiza por medio de una petici´ on de tipo POST a la URL: https://apkfalcon.infor.uva.es:8080/expert/post/score. Es necesario especificar en el cuerpo de la petici´ on el hash SHA256 de la aplicaci´ on que se est´ a puntuando y la puntuaci´ on escalada entre 0 y 10. Se ha utilizado el formato JSON en la implementaci´ on de la API para el intercambio de informaci´ on con los usuarios ya que es la notaci´ on m´ as utilizada en los servicios web. Adem´ as, se ha dise˜ nado para que pueda servir concurrentemente a un gran n´ umero de usuarios de forma segura, teniendo en cuenta alguno de los riesgos y vulnerabilidades del top 10 de OWASP API [24]. IV. ESTADO ACTUAL DEL REPOSITORIO El warehouse almacena datos de un total de 9068 aplicaciones, 912 permisos del sistema, 16 grupos de permisos del sistema y 5 fuentes de informaci´ on de intrusividad (ver tabla I)14. Adem´ as, se encuentra abierta la API de acceso al warehouse para que pueda ser utilizada por servicios de terceros e investigadores en el enlace https://apkfalcon.infor.uva.es:8080. Las aplicaciones contenidas en el warehouse se encuentran altamente distribuidas entre distintas categor´ ıas. La Fig. 7 muestra la distribuci´ on de aplicaciones entre el top 10 de categor´ ıas con m´ as apps. Estas aplicaciones representan un 51,15 % del contenido en el warehouse. Como se puede observar los contenidos del warehouse no se encuentran sesgados a 14A fecha 26/02/2024. A. P´erez-Fuente, M. M. Mart´ınez-Gonz´alez, A. Aparicio and Q. I. Moro 628 Figura 6. Solicitud de los metadatos de WhatsApp en Postman. Aplicaciones 9068 Permisos de Android 912 Grupos de Permisos Android 16 Medidas de Intrusividad en la Privacidad 5 Tabla I INDICADORES SOBRE EL CONTENIDO DEL REPOSITORIO. Figura 7. Distribuci´ on de aplicaciones en el top 10 categor´ ıas. ninguna categor´ ıa en concreto. En el top 3 de categor´ ıas con m´ as aplicaciones se encuentran las de educaci´ on, negocios y financieras; estos tipos de aplicaciones van dirigidas a un gran p´ ublico y, por tanto, la intrusividad en la privacidad de sus usuarios afecta a un mayor n´ umero de estos. Se ha monitorizado el tiempo que tardan algunas de las operaciones m´ as importantes del repositorio: carga masiva de Hardware Capacidad CPU 4 n´ ucleos a 2 GHz RAM 5 GB Almacenamiento 50 GB Tabla II ESPECIFICACIONES T´ ECNICAS DEL SERVIDOR. aplicaciones (8 apps/min), descarga de metadatos de una app almacenada (381 ms) y descarga de metadatos de una app no almacenada (42 ms). Los resultados que se muestran son muy prometedores, demuestran la viabilidad del proyecto en recursos de coste moderado (ver tabla II). V. DISCUSI ´ ON En esta secci´ on se realiza un an´ alisis retrospectivo de alguna de las decisiones tomadas en la secci´ on III. Despu´ es de sopesar varios tipos de dise˜ nos para la recogida y el almacenamiento de datos, se decide optar por una arquitectura de Data Warehouse. Si bien es cierto que con una arquitectura m´ as general como Data Lake se podr´ ıan cubrir las necesidades del repositorio y, adem´ as, se podr´ ıa dejar abierta la puerta a ampliaciones futuras de los tipos de informaci´ on almacenados en el mismo, esta incrementar´ ıa la complejidad del sistema de manera innecesaria para el prop´ osito planteado. Por tanto finalmente, debido a que la naturaleza de los metadatos que se almacenan es textual y estructurada, se decide utilizar la arquitectura que, cumpliendo con los requisitos de almacenamiento del proyecto, recopilar y almacenar metadatos de aplicaciones, es a su vez la m´ as Un Data Warehouse para el Estudio de la Privacidad y Seguridad de Aplicaciones M´oviles 629 f´ acil de entender y mantener, el Data Warehouse. La principal ventaja de la soluci´ on planteada es el uso de un sistema gestor de bases de datos como MySQL ya que es poco costoso en t´ erminos de infraestructura, coste econ´ omico y curva de aprendizaje para su mantenimiento. Adem´ as, en un SGBD relacional es posible realizar consultas m´ as complejas sobre la informaci´ on almacenada en el warehouse. Por ejemplo, el cruce de informaci´ on com´ un entre las distintas aplicaciones o buscar todas las aplicaciones que utilizan un cierto grupo de permisos... Mientras que la soluci´ on general basada en Data Lakes tendr´ ıa que hacer una b´ usqueda sobre el total de los datos almacenados, en la soluci´ on MySQL se aprovecha la combinaci´ on de la informaci´ on almacenada (join) para obtener una respuesta sin la necesidad de la exploraci´ on de todo el conjunto de datos. Esto incrementa la velocidad de respuesta del sistema. Como se coment´ o en la secci´ on III, se ha tenido en cuenta la seguridad del repositorio desde el dise˜ no. En este aspecto, se ha decidido utilizar una API de acceso en lugar de acceso directo a SQL. Esta decisi´ on limita las posibilidades del repositorio a las que aporta la API. No obstante, es una decisi´ on necesaria si queremos mantener un repositorio seguro con datos de calidad, ya que tener acceso directo a SQL permitir´ ıa introducir informaci´ on sin validar como puntuaciones sin escalar, aplicaciones ficticias... Aun as´ ı, todav´ ıa cabe la posibilidad de que el m´ etodo de acceso al repositorio, la API, no sea seguro. Para intentar que sea lo m´ as seguro posible se ha tenido en cuenta el top 10 de vulnerabilidades y riesgos de seguridad que hay en las APIs seg´ un la fundaci´ on OWASP [24]. Algunos de los riesgos que se mencionan en el top 10 se relacionan con: el uso no restringido de recursos o acceso no restringido a flujos sensibles, los cuales, como se ha visto en la secci´ on III han sido tratados. VI. CONCLUSIONES Pese a las dificultades inherentes al problema de integraci´ on de distintas fuentes de datos, se ha conseguido alcanzar el objetivo de poner a disposici´ on de investigadores y servicios metadatos para analizar el impacto en la privacidad de las aplicaciones. Todo ello teniendo en cuenta la seguridad del repositorio, as´ ı como la calidad de los datos desde el dise˜ no del mismo. Las ventajas de nuestra propuesta son: aportar informaci´ on sobre aquello que los usuarios puede manejar (grupos de permisos) y proporcionar informaci´ on sobre las valoraciones del impacto en la privacidad conseguidos por distintas m´ etricas, lo cual puede ser ´ util a los investigadores para realizar comparaciones. Gracias a que solo se almacenan metadatos sobre las aplicaciones, se ha conseguido almacenar toda la informaci´ on de la tabla I en un espacio inferior a 50 MB. Esto nos asegura una buena escalabilidad y viabilidad del proyecto de cara al futuro, sin la necesidad de un incremento sustancial del coste del mismo. Se espera un crecimiento en el uso del repositorio y sus contenidos por la comunidad investigadora, ya que se esta difundiendo en congresos, talleres, etc. Para que sea conocido y utilizado por terceros y permita arrojar luz y seguir entendiendo el problema de la intrusividad en la Figura 8. Gr´ afico de evoluci´ on del n´ umero de permisos solicitados. privacidad de las aplicaciones m´ oviles. Un problema del cual los usuarios finales a pesar de ser los principales afectados, siguen tomando conciencia poco a poco, es necesario insistir en la formaci´ on y creaci´ on de herramientas que contribuyan a este fin. VII. TRABAJO FUTURO El trabajo que aqu´ ı se presenta permite m´ ultiples l´ ıneas de trabajo futuro gracias a su dise˜ no. Directamente relacionadas con el warehouse surgen posibilidades de ampliar y/o complementar su funcionalidad de distintos modos: Permitir la carga de aplicaciones al warehouse por medio de su archivo empaquetado (.apk). De este modo, se permitir´ ıa a investigadores y desarrolladores subir aplicaciones que no se encuentren publicadas en las fuentes de informaci´ on mencionadas en la secci´ on III-C. Permitir consultas avanzadas para investigadores. Por ejemplo, ver todas las aplicaciones que utilizan cierto permiso. Mejoras basadas en el feedback de los usuarios. Continuar con la monitorizaci´ on del repositorio por medio de evaluaciones de rendimiento y auditor´ ıas surgidas a ra´ ız de su apertura a la comunidad investigadora para garantizar que se cumplen los objetivos de dise˜ no. Sistemas de medida y control de la calidad de los datos almacenados en el warehouse. Por otro lado, esperamos poder hacer an´ alisis acerca de la evoluci´ on del n´ umero de permisos que solicitan las aplicaciones a medida que aumente el n´ umero de usuarios. Estos estudios permiten ratificar otros ya existentes [25]. Si nos fijamos en algunas de las aplicaciones m´ as utilizadas actualmente, como Slack, Twitch, WhatsApp Business y Snapchat, tienden a aumentar el n´ umero de permisos que solicitan con el paso de las versiones, tal como se muestra en la Fig. 8. Uno de los permisos utilizado por la mayor´ ıa de estas aplicaciones que es m´ as cr´ ıtico para nuestra privacidad es A. P´erez-Fuente, M. M. Mart´ınez-Gonz´alez, A. Aparicio and Q. I. Moro 630 “android.permission.READ PHONE STATE”, el cual permite acceder al estado del tel´ efono (por ejemplo, conocer si se encuentra en una llamada telef´ onica). En nuestra opini´ on, esto representa un peligro potencial en la privacidad de sus usuarios. Este tipo de evoluciones justifica el inter´ es en el estudio del impacto en la privacidad de los usuarios de las aplicaciones y, la utilidad de un repositorio que proporcione datos de calidad que se puedan utilizar por los investigadores a este respecto. AGRADECIMIENTOS Este trabajo se incluye en las actividades del proyecto estrat´ egico de ciberseguridad “App-PI (App Privacy Impact): Un ecosistema para la evaluaci´ on del impacto de apps para dispositivos m´ oviles sobre la privacidad y seguridad de sus usuarios”, el cual se realiza al amparo de un convenio de colaboraci´ on entre la Universidad de Valladolid y la S.M.E. Instituto Nacional de Ciberseguridad de Espa˜ na M.P., S.A. para la promoci´ on de proyectos estrat´ egicos de ciberseguridad en Espa˜ na, en el marco de los fondos del Plan de Recuperaci´ on, Transformaci´ on y Resiliencia, financiados por la Uni´ on Europea (Next Generation), el proyecto del Gobierno de Espa˜ na que traza la hoja de ruta para la modernizaci´ on de la econom´ ıa espa˜ nola, la recuperaci´ on del crecimiento econ´ omico y la creaci´ on de empleo, para la reconstrucci´ on econ´ omica s´ olida, inclusiva y resiliente tras la crisis de la COVID19, y para responder a los retos de la pr´ oxima d´ ecada. REFERENCIAS [1] Espa˜ na. (2018) Ley Org´ anica 3/2018, de 5 de diciembre, de Protecci´ on de Datos Personales y garant´ ıa de los derechos digitales. [Online]. Available: https://www.boe.es/buscar/pdf/2018/ BOE-A-2018-16673-consolidado.pdf [2] P. G. Kelley, S. Consolvo, L. F. Cranor, J. Jung, N. Sadeh, and D. Wetherall, “A Conundrum of Permissions: Installing Applications on an Android Smartphone,” in Financial Cryptography and Data Security, J. Blyth, S. Dietrich, and L. J. Camp, Eds., 2012, pp. 68–79. [3] Rina, “A Comparative Analysis of mobile Operating Systems,” in International Journal of Computer Sciences and Engineering, 2018, pp. 69–73. [4] I. N. de Ciberseguridad. CONAN mobile. [Online]. Available: https://www.incibe.es/ciudadania/herramientas/conan-mobile [5] M. contributors. (2017) Privacyscore. [Online]. Available: https: //privacyscore.org/ [6] A. P´ erez-Fuente, “Data Warehouse para el estudio de la privacidad de aplicaciones m´ oviles,” Trabajo fin de Grado, Universidad de Valladolid, 2023. [7] J. Crespo Guerrero, “APKFalcon: Servicio de usuarios para la evaluaci´ on y comprensi´ on del impacto sobre la privacidad de aplicaciones m´ oviles,” Trabajo fin de Grado, Universidad de Valladolid, 2023. [8] F.-X. Geiger and I. Malavolta, “Datasets of Android Applications: a Literature Review,” ArXiv, vol. abs/1809.10069, 2018. [Online]. Available: https://api.semanticscholar.org/CorpusID:52845379 [9] K. Allix, T. F. Bissyand´ e, J. Klein, and Y. Le Traon, “AndroZoo: Collecting Millions of Android Apps for the Research Community,” in Proceedings of the 13th International Conference on Mining Software Repositories, 2016, pp. 468–471. [10] G. Meng, Y. Xue, J. K. Siow, T. Su, A. Narayanan, and Y. Liu, “AndroVault: Constructing Knowledge Graph from Millions of Android Apps for Automated Analysis,” ArXiv, vol. abs/1711.07451, 2017. [Online]. Available: https://api.semanticscholar.org/CorpusID:1736293 [11] Telef´ onica. (2018) Tacyt. [Online]. Available: https://www.movistar.cl/ web/corporaciones/tacyt [12] D. E. Krutz, M. Mirakhorli, S. A. Malachowsky, A. Ruiz, J. Peterson, A. Filipski, and J. Smith, “A Dataset of Open-Source Android Applications,” in 2015 IEEE/ACM 12th Working Conference on Mining Software Repositories, 2015, pp. 522–525. [13] M. Hatamian, N. Momen, L. Fritsch, and K. Rannenberg, “A Multilateral Privacy Impact Analysis Method for Android Apps,” in Privacy Technologies and Policy, M. Naldi, G. F. Italiano, K. Rannenberg, M. Medina, and A. Bourka, Eds., 2019, pp. 87–106. [14] S. Barth, M. de Jong, M. Junger, P. H. Hartel, and J. C. Roppelt, “Putting the privacy paradox to the test: Online privacy and security behaviors among users with technical knowledge, privacy awareness, and financial resources,” in Telematics Informatics, vol. 41, 2019, pp. 55–69. [15] H. Benita. (2019) Preventing SQL Injection Attacks With Python. [Online]. Available: https://realpython.com/prevent-python-sql-injection/ [16] Android Developers. (2023) Archivo de manifiesto de la app: permission. [Online]. Available: https://developer.android.com/ reference/android/Manifest.permission [17] ——. (2023) Archivo de manifiesto de la app: permission group. [Online]. Available: https://developer.android.com/reference/android/ Manifest.permission group [18] H. Roy. (2012) Terms of Service Didn’t Read. [Online]. Available: https://tosdr.org/ [19] A. Aparicio, M. Mart´ ınez Gonz´ alez, and V. Carde˜ noso, “M´ etrica basada en grupos de permisos para entender el impacto de las aplicaciones Android sobre la privacidad,” in 2022 17th Iberian Conference on Information Systems and Technologies (CISTI), 2022, pp. 1–5. [20] D. Hardt, “The OAuth 2.0 Authorization Framework,” RFC 6749, 2012. [Online]. Available: https://tools.ietf.org/html/rfc6749 [21] O. I. (OAI). (2022) OpenAPI. [Online]. Available: https://www. openapis.org/ [22] M. Upadhayay, A. Sharma, G. Garg, and A. Arora, “RPNDroid: Android Malware Detection using Ranked Permissions and Network Traffic,” in 2021 Fifth World Conference on Smart Trends in Systems Security and Sustainability (WorldS4), 2021, pp. 19–24. [23] Android Developers. (2021) Declara el uso de datos de tu app. [Online]. Available: https://developer.android.com/privacy-and-security/ declare-data-use?hl=es-419 [24] T. O. Foundation. (2023) OWASP API Security Project. [Online]. Available: https://owasp.org/www-project-api-security/ [25] P. Calciati, “Understanding the Evolution of Android Applications,” T´ esis Doctoral, Universidad Polit´ ecnica de Madrid, 2019. [Online]. Available: https://oa.upm.es/57886/1/PAOLO CALCIATI.pdf Un Data Warehouse para el Estudio de la Privacidad y Seguridad de Aplicaciones M´oviles 631