• Saltar al contenido principal
  • Saltar a la barra lateral principal
  • Saltar al pie de página

Una al Día

Boletín de noticias de Seguridad Informática ofrecido por Hispasec

Usted está aquí: Inicio / Destacadas / Sobre la colaboración entre Google y Apple para el seguimiento de infecciones COVID-19 mediante Bluetooth.

Sobre la colaboración entre Google y Apple para el seguimiento de infecciones COVID-19 mediante Bluetooth.

13 abril, 2020 Por Pablo López Bonilla 4 comentarios

Recientemente, los dos gigantes tecnológicos han puesto en marcha una iniciativa conjunta para el seguimiento semi-descentralizado de infecciones y mejorar la gestión de la crisis sanitaria por parte de las autoridades gubernamentales pertinentes. Se trata de la liberación de una API que los gobiernos pueden integrar en sus aplicaciones y que va en la línea de la aplicación TraceTogether, empleada por el gobierno de Singapur desde hace meses.

A continuación, se explican algunos detalles técnicos del funcionamiento del modelo y se problematizan tangencialmente algunas de las dudas concernientes a la seguridad y la privacidad de los usuarios que acarrea este modelo.

Entendiendo el modelo.

El objetivo fundamental del modelo es permitir, de forma semi-descentralizada, el aviso entre infectados y personas de riesgo por exposición, así como la agilización del manejo de datos por parte de las autoridades sanitarias competentes.

Para ello, varias personas instalan una aplicación. Cuando una de ellas es diagnosticada con COVID-19 puede enviar datos a un servidor con información identificativa. El resto de personas que tienen instalada la aplicación, reciben una notificación indicando que estuvieron cerca de un dispositivo cuyo dueño ha avisado de ser positivo en COVID-19. (El radio varía en función de la potencia del Bluetooth y esto puede ser un vector de ataque como se comprobará más adelante)

En todo este proceso, se toman gran cantidad de medidas para intentar preservar el anonimato y la privacidad de los usuarios, a través de los mecanismos que intentaremos explicar a continuación.

Detalles técnicos de la comunicación (Criptografía).

En primer lugar, con la instalación de una aplicación, se genera una «clave única de trazado» asociada al dispositivo en cuestión. Para la generación de esta clave de 32 bytes, se toman en cuenta componentes del sistema, haciendo hincapié en la impredictibilidad e imposibilidad de replicación para asegurar la privacidad y el anonimato. Además, se almacena de forma segura en el dispositivo, de forma local.

De esa primera clave, se deriva una segunda clave de 16 bytes, que se regenerará cada 24 horas, llamada «clave de trazado diario«. Al conjunto de claves diarias, derivadas de la clave de trazado principal, se le denomina «claves de diagnóstico» y jugarán un papel fundamental en la mecánica del modelo, como veremos más adelante.

Mientras el Bluetooth está activado, se aprovecha la comunicación para enviar, en los paquetes asociados al protocolo, un fragmento de información denominado «Identificador de proximidad». Este fragmento es intercambiado entre los dispositivos con Bluetooth activado y es el responsable en primera instancia de la identificación temporal de los dispositivos. Por mor de la privacidad, se trata de una clave de 16 bytes que no puede ser correlacionada con ningún usuario si no se está previamente en posesión de su clave de trazado diario, por lo que se hace francamente difícil realizar ataques por suplantación o ‘replay’. Además, esta clave cambia cada 15 minutos.

Es importante resaltar que, como puede apreciarse, no se incluyen funcionalidades relativas a la localización GPS en ningún momento. Lo único que existe es una transmisión de este fragmento de información en un radio de comunicación cercana vía Bluetooth. Finalmente, los identificadores de proximidad recibidos, son procesados y almacenados exclusivamente de forma local.

Detalles técnicos del envío de información (Cliente – Servidor)

Cuando un individuo comparte voluntariamente su diagnóstico – lo que acarrea algunas dudas como expondremos en la sección dedicada a tal efecto – lo que ocurre es una subida de las claves de diagnóstico (recuérdese, el conjunto de claves diarias que se han ido generando) a un servidor determinado.

Los clientes instalados en otros dispositivos que estén participando en el seguimiento, peticionan al servidor y comprueban si algunas de esas claves existentes sirven para derivar los Identificadores de Proximidad que tienen almacenados localmente.

En caso de que exista un match, el algoritmo de diagnosis, (encargado de valorar si un determinado contacto puede ser calificado ‘de riesgo’, en virtud del tiempo de exposición) pide permisos para continuar el flujo de ejecución en caso de que proceda.

La notificación llega así a los nuevos usuarios y se replica el proceso, es decir, esos nuevos usuarios notificados tienen la posibilidad de «compartir su estado» y suscribir al servidor la información con las claves de diagnóstico generadas.

Algunos apuntes sobre seguridad y privacidad. Ataques plausibles.

En la bibliografía manejada, que adjuntaremos al final del artículo, no hemos encontrado menciones a algunos puntos que consideramos relevantes para el modelado de la amenaza y la valoración de los riesgos asociados tanto al modelo abstracto como a algunos detalles técnicos.

En este sentido, cabe preguntarse acerca de cómo se almacena la información en los servidores. Dado que se propone un modelo semi-descentralizado que permita establecer una arquitectura nodal – modular, lo que resulta en una velocidad y agilidad claramente superiores a otros modelos, existe el riesgo de que la gestión de los servidores que almacenen las claves contra las que los clientes matchean, no sea la mejor posible o carezca de una homologación criptográfica a todos los niveles.

Sí que se menciona que la integridad corre a cargo de firmas SHA-256, pero se delega en las implementaciones particulares la gestión de los distintos servidores. Se entiende no obstante, que serán las autoridades sanitarias competentes las encargadas del control de los datos.

Así mismo, se proponen tiempos prudenciales para albergar dicha información y se aconseja no almacenar metadatos de las comunicaciones, pero, de nuevo, no parece estar implementado de forma intrínseca en el código, sino que se apela a las buenas prácticas de los gestores de los servidores.

Por otro lado, existen algunos escenarios en los que el modelo puede verse vulnerado. Por ejemplo, dado que el algoritmo de diagnosis que determina si procede o no considerar como ‘de riesgo’ el contacto con otros dispositivos, toma no sólo como variable el tiempo de exposición, sino también, por las particularidades de la tecnología Bluetooth, la cercanía de los dispositivos, un atacante podría generar falsos contagios amplificando su señal via hardware de modo que, usuarios que se encontraran a una gran distancia, seguirían siendo igualmente notificados, pese a ser físicamente imposible que se hayan contagiado de ese usuario. Es más, hasta donde hemos visto, la bibliografía no contempla un escenario en el que un atacante comparta su estado de «infectado» sin estarlo, alertando de manera fraudulenta a todos los demás.

¿Cómo comprobar si un usuario que alerta de su contagio está realmente contagiado? Para hacerlo, se requeriría aportar información compulsada oficial (lo que acaba con el modelo descentralizado al tener que acudir a instancias centralizadas oficiales) e identificativa (lo que acaba con el modelo de anonimato y respeto a la privacidad). En la bibliografía se propone un perfilado de usuarios en función de si están infectados o estuvieron expuestos, pero se delega nuevamente en el usuario la transmisión final con el servidor.

Obviamos, por exceder el ámbito temático de este boletín, todas las consideraciones que tienen que ver con el uso de datos sensibles por parte de los gobiernos, pero adjuntamos un escrito del responsable europeo de protección de datos apoyado en la GDPR.

Bibliografía empleada:

https://www.apple.com/covid19/contacttracing/

https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ContactTracing-BluetoothSpecificationv1.1.pdf

https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ContactTracing-CryptographySpecification.pdf

https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ContactTracing-FrameworkDocumentation.pdf

https://github.com/DP-3T/documents/blob/master/DP3T%20White%20Paper.pdf

https://tracetogether.zendesk.com/hc/en-sg/articles/360043543473-How-does-TraceTogether-work-

Acerca de Pablo López Bonilla

Ha escrito 53 publicaciones.

  • View all posts by Pablo López Bonilla →
  • Blog

Compártelo:

  • Twitter
  • Facebook
  • LinkedIn
  • Reddit
  • Telegram
  • WhatsApp

Publicaciones relacionadas

Publicado en: Destacadas, General Etiquetado como: Apple, coronavirus, Covid19, Google, Privacidad, TraceTogether

Interacciones con los lectores

Comentarios

  1. NetVicious dice

    13 abril, 2020 a las 6:44 pm

    Lo del GPS que dicen es de risa.

    En las últimas versiones de Android para que una aplicación tenga acceso al bluetooth te obliga también a que dicha App tenga acceso obligatorio al GPS también. Esto ha sido un cambio hecho por Android aduciendo que por bluetooth se puede geolocalizar un dispositivo y así por lo menos que el usuario sea consciente de ello, y ya de paso le damos posición más exacta.

    Personalmente lo veo como un error mayúsculo porque por wifi también te pueden geolocalizar de la misma manera. Podrían dar un simple aviso y ya está, pero no dar aún más facilidades.

    Responder
    • Pablo López Bonilla dice

      14 abril, 2020 a las 9:56 am

      Buenos días, NetVicious.

      En primer lugar, muchas gracias por tu comentario y por ayudarnos a mejorar.

      Según la documentación de desarrollador de Android, es cierto que el uso de Bluetooth en una aplicación exige declarar el permiso ACCESS_FINE_LOCATION. Supongo que te refieres a eso. Efectivamente, puede comprobarse aquí: https://developer.android.com/guide/topics/connectivity/bluetooth#Permissions

      Sin embargo, pensamos que una cosa es que exista la posibilidad técnica de geolocalizar, dado que la aplicación cuenta con permisos para ello y otra distinta es hacer uso de esa posibilidad técnica en la implementación.

      Atendiendo a la bibliografía que se adjunta en el artículo, no hemos visto que el modelo proponga ni necesite hacer uso de geolocalización. Los documentos técnicos de colaboración entre Google y Apple inciden mucho en el uso del protocolo sin transmisión alguna de este tipo de información.

      Sin embargo, nos parece acertado seguir tu crítica y estar de acuerdo en que es poco razonable esperar siempre implementaciones honestas. Si no hay limitación técnica, es razonable esperar que existan implementaciones que hagan uso de esa información, aún cuando no esté indicado ni en los protocolos ni en los documentos técnicos propuestos. Creemos que lo dejamos constar así en las conclusiones finales.

      Un saludo cordial y gracias.

      Responder
  2. Fern dice

    13 abril, 2020 a las 8:59 pm

    Hola a tod@s, simplemente magistral.

    Un cordial saludo.

    Responder
    • Pablo López Bonilla dice

      14 abril, 2020 a las 9:57 am

      Muchísimas gracias, Fern.

      ¡Un saludo!

      Responder

Deja una respuesta Cancelar la respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

Barra lateral principal

Buscar

Síguenos

siguenos en twitter

UAD360 EDICIÓN 2022

https://www.youtube.com/watch?v=go_CSWK56yU

Populares de UAD

  • Vulnerabilidad zero-day en AWS Glue
  • Campañas de phishing utilizan Flipper Zero como cebo
  • Tamagotchi para hackers: Flipper Zero
  • Evasión de CloudTrail en AWS a través de API no documentada
  • Técnica permite modificar ficheros PDF con firma digital

Entradas recientes

  • Vulnerabilidad zero-day en AWS Glue
  • Evasión de CloudTrail en AWS a través de API no documentada
  • Parches de enero 2023: Microsoft corrige 98 vulnerabilidades
  • UAD se abre a la comunidad
  • Campañas de phishing utilizan Flipper Zero como cebo
  • Vulnerabilidades críticas en productos de Synology
  • Más de dos docenas de errores de WordPress explotados por un nuevo malware de Linux
  • Correo electrónico
  • Facebook
  • LinkedIn
  • RSS
  • Twitter

Footer

UAD

UAD nació a raíz de un inocente comentario en un canal IRC hace 24 años. A través de los archivos, un lector curioso puede ver cómo ha cambiado (o no) la seguridad de la información desde entonces.

Aviso Legal

  • Aviso Legal
  • Términos y Condiciones
  • Política de Privacidad
  • Política de Cookies

Copyright © 2023 · Hispasec Sistemas, S.L. Todos los derechos reservados

Este sitio web utiliza cookies propias y de terceros para fines analíticos y para mostrarte publicidad (tanto general como personalizada) relacionada con tus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación (por ejemplo, páginas visitadas), para optimizar la web y para poder valorar las opiniones de los servicios consultados por los usuarios. Para administrar o deshabilitar estas cookies haz clic en: Configurar Cookies


Rechazar todo Aceptar Todo
Configurar Cookies

Resumen de privacidad

Este sitio web utiliza cookies para mejorar su experiencia mientras navega por el sitio web. De estas, las cookies que se clasifican como necesarias se almacenan en su navegador, ya que son esenciales para el funcionamiento de las funcionalidades básicas del sitio web. También utilizamos cookies de terceros que nos ayudan a analizar y comprender cómo utiliza este sitio web. Estas cookies se almacenarán en su navegador solo con su consentimiento. También tiene la opción de optar por no recibir estas cookies. Pero la exclusión voluntaria de algunas de estas cookies puede afectar su experiencia de navegación.
Necesaria
Siempre activado
Las cookies necesarias son absolutamente esenciales para que el sitio web funcione correctamente. Estas cookies garantizan funcionalidades básicas y características de seguridad del sitio web, de forma anónima.
CookieDuraciónDescripción
cookielawinfo-checkbox-analytics11 monthsEsta cookie está configurada por el complemento de consentimiento de cookies de GDPR. La cookie se utiliza para almacenar el consentimiento del usuario para las cookies en la categoría "Análisis".
cookielawinfo-checkbox-functional11 monthsLa cookie está configurada por el consentimiento de cookies de GDPR para registrar el consentimiento del usuario para las cookies en la categoría "Funcional".
cookielawinfo-checkbox-necessary11 monthsEsta cookie está configurada por el complemento de consentimiento de cookies de GDPR. Las cookies se utilizan para almacenar el consentimiento del usuario para las cookies en la categoría "Necesario".
cookielawinfo-checkbox-others11 monthsEsta cookie está configurada por el complemento de consentimiento de cookies de GDPR. La cookie se utiliza para almacenar el consentimiento del usuario para las cookies en la categoría "Otro.
cookielawinfo-checkbox-performance11 monthsEsta cookie está configurada por el complemento de consentimiento de cookies de GDPR. La cookie se utiliza para almacenar el consentimiento del usuario para las cookies en la categoría "Rendimiento".
viewed_cookie_policy11 monthsLa cookie está configurada por el complemento de consentimiento de cookies de GDPR y se utiliza para almacenar si el usuario ha dado su consentimiento o no para el uso de cookies. No almacena ningún dato personal.
Analítica
Las cookies analíticas se utilizan para comprender cómo interactúan los visitantes con el sitio web. Estas cookies ayudan a proporcionar información sobre métricas, el número de visitantes, la tasa de rebote, la fuente de tráfico, etc.
GUARDAR Y ACEPTAR
 

Cargando comentarios...