Mucho se ha hablado (y se está hablando) sobre las Balizas v16 con geolocalización para señalizar averías en tiempo real de la DGT, las cuales son obligatorias a partir del 1 de enero de 2026 por el Real Decreto 1030/2022 que modifica el 159/2021. El eje principal de la discusión está focalizado en el “ataque a la privacidad” que se presupone por parte de este tipo de dispositivos al realizar el envío de datos de geolocalización cuando se activan.
Figura 1: Balizas v16 - Los árboles que no dejan ver el bosque
Sin embargo, en este nuevo sistema de alerta de la DGT, ¿es cierta tal preocupación o nos la hemos auto-generado para evitar ver lo que hay más allá? Vamos a desarrollarlo un poco.
Las Balizas v16 son dispositivos IoT que disponen de una SIM para comunicarse con los servidores de sus respectivos fabricantes con el objetivo de que éstos puedan agregar y preparar la información antes de derivarla a los servidores de la DGT.
Como dispositivos IoT que son, su producción escalable y asequible deriva en deficiencias de seguridad al no incorporar distintos módulos hardware que proporcionan capacidades avanzadas de cómputo, almacenamiento seguro, u otras características relevantes. En este sentido, existe ya algún algún que otro análisis pormenorizado de estas deficiencias como el realizado por Luis Miranda disponible en su propio Github.
Ahora bien, como explico en el Capítulo VI de Arquitecturas en el Internet de las Cosas de mi libro Arquitectura de Seguridad y Patrones de Diseño Seguro, si queremos suplir dichas deficiencias de seguridad, las balizas v16 deben contar con capacidades de cómputo suficientes para utilizar protocolos de seguridad robustos, almacenamiento seguro anti manipulación para custodiar las credenciales de identificación del dispositivo así como los certificados para las comunicaciones seguras, capacidades de gestión de auto registro en el sistema tras su encendido y gestión de ciclo de vida de todas sus credenciales custodiadas, entre otros.
La incorporación de todas estas características en los dispositivos IoT producirían un aumento sustancial del precio de compra de las Balizas v16 (así como el consumo de batería que necesitaría una baliza para soportar todo lo descrito anteriormente). Teniendo esto en mente y que si no fueran asequibles por parte de los ciudadanos sería complejo que un Real Decreto nos obligase a comprarlas, ¿tanto riesgo para la privacidad implica su uso?
Análisis
Partiendo de la base de que no soy jurista y evitando interpretaciones artificiosas de la norma, si leemos el Reglamento General de Protección de Datos (RGPD) se indica objetivamente que la geolocalización se considera un Dato Personal si ésta permite identificar directa o indirectamente a una persona física.
En base a esta premisa, si analizamos la Baliza v16, la tarjeta SIM está asociada sólo al dispositivo IoT y no existe relación contractual del ciudadano con la SIM (como sí ocurre entre el ciudadano y la SIM de la teleoperadora que le proporciona voz y datos en su terminal móvil). Esto independiza completamente la identidad del individuo de la Baliza v16 que utiliza.
Es más, el único momento en el que se podría intentar ligar uno a uno la baliza con el ciudadano podría ser en el momento de compra siempre que ésta se realice con tarjeta y sólo sea una unidad (en este caso se podría intentar ligar el número de la tarjeta con el número de serie / IMEI, aunque habiendo datos de tarjeta ya nos metemos en otro jardín con PCI DSS aún mayor y por tanto podemos descartar dicha vinculación).
Al no existir entonces esa vinculación baliza-ciudadano sino que los datos de geolocalización están asociados SÓLO a la baliza activa (dispositivo IoT sin identidad de persona física), no aplicaría un análisis de riesgos de privacidad LINDDUN ya que la única forma de conocer la identidad del sujeto que activa la baliza es estar presente en la misma geolocalización en la que dicha baliza está activa.
Mapa Balizas v16
En base a esto, y a que en muchas ocasiones en las grandes superficies de venta hay Balizas v16 activas como reclamo visual para su compra, ¿qué persigue el poder disponer de un mapa de España con las balizas activas en cada momento?
Presuponiendo el buen hacer de la DGT, se puede entender que el objetivo principal de disponer de toda esta información de averías en tiempo real es la de, en un futuro tras el análisis estadístico de los datos, actualizar los puntos negros en carretera para, por ejemplo, modificar la señalización o incorporar nuevos radares (fijos, móviles, de tramo, etcétera).
Esta presuposición se apoya en que la baliza de por sí no es un sistema de emergencia ya que no está conectada al 112 ni tiene capacidad de determinar si se necesita una ambulancia, bomberos o policía, o si sólo se requiere una grúa.
Teniendo en cuenta todo lo descrito anteriormente y sabiendo que hay múltiples fabricantes homologados, la arquitectura simplificada de todo este sistema sería algo así:
Figura 7: Arquitectura con fabricantes homologados
A partir de esta visión holística y presuponiendo el caso de uso de fines estadísticos para actualizar los puntos negros de la seguridad vial española, el eje de la privacidad motivo de muchas discusiones sobre las Balizas v16 debería cambiar a un eje más propio de ciberseguridad.
Desde dicho punto de vista de ciberseguridad, si analizamos el sistema planteado en su conjunto basándonos en el modelo de amenazas STRIDE, vemos que de inicio, los ejes de integridad y no repudio parecen no haberse tenido en cuenta, pudiendo derivar en graves riesgos para todo el sistema.
Una posible amenaza podría ser meter dentro de una caja de zapatos varias Balizas v16 legítimas de distintos fabricantes encendidas: la caja para evitar los destellos de luz y lo de que sean de distintos fabricantes para que no se pueda bloquear fabricantes concretos por uso indebido (algo así como un DDoS con balizas).
Con este simple planteamiento teórico a priori se podrían generar accidentes/averías falsas con balizas homologadas, lo cual comprometería la integridad de los datos del sistema en su conjunto al introducir datos corruptos y, con capacidad de repudio por parte del portador de la caja al no existir una vinculación 1:1 entre ciudadano y balizas.
Eso sí, si cuando se enciende tu Baliza v16 tu eres el único que va en el coche, y tienes encendido tu móvil, alguien que tenga la localización de tu móvil podría asociarlo con esa baliza y pasar a estar asociada con ese móvil en el futuro. Así que el problema sigue siendo: ¿qué apps o empresas tiene la localización de tu móvil? Asociar tu Baliza v16 a tu perfil les dará... más información, sobre que probablemente fuiste tú el que activó la Baliza v16.
Conclusiones
Como punto final del análisis se puede concluir que, el riesgo de uso de las Balizas v16 no se focaliza tanto en un ataque a la privacidad del ciudadano sino en el uso malintencionado que se puede hacer de ellas en perjuicio del sistema en su conjunto.
Dicho uso malintencionado puede provocar que el sistema en sí, el cual se diseñó por el bien de la ciudadanía enfocado en la seguridad vial, recopile datos incorrectos que perviertan el posterior análisis en detrimento de la seguridad vial de todos los españoles y de las posibles futuras mejoras.
Hacer tecnología por hacer tecnología no tiene sentido. Siempre que hagas tecnología tienes unos costes, así que tienes que saber qué es lo que quieres conseguir con ello para invertir bien el tiempo de tu equipo, que unas veces pueden ser ingresos, otros márgenes, otros conseguir un buen posicionamiento en un mercado, o simplemente para evitar un problema a futuro, o defender una posición. Pero hacer tecnología por hacer tecnología no tiene mucho sentido.
Figura 1: Tres historias de hacer tecnología como
herramienta estratégica de la empresa
De hecho, una de las reglas de un buen emprendedor es "Code Less, Sell More". Si eso lo sigues, será más fácil que levantes startups más rápidamente, que puedan pivotar más rápido, y que consigan el Break-Even mucho antes. Es un hecho, y yo me lo he aplicado desde que con 24 años montamos Informática 64 y había que vivir de eso. Hay que hacer tecnología, pero la que nos ayude de verdad a conseguir los propósitos.
Desde que llegué a Telefónica, me aplico esa regla de oro para todo lo que hago, así que cuando montamos ElevenPaths establecimos unas reglas similares que decían que sólo haremos "Productos que no hagan los demás o que los podamos hacer de manera completamente diferente y mejor". Por eso creamos sólo tecnología que va con patentes y protecciones. Al final, las tecnologías de ElevenPaths iban a ser - como al final fueron -, piezas de innovación para capturar un volumen mucho mayor de servicios de ciberseguridad, que acabaron alcanzando números de ingresos mucho mayores de los tan siquiera nos habíamos planteado al inicio.
Recuerdo que en aquellos momentos el roadmap de un producto era "Ingresos-Driven". Primero Ingresos, segundo Patentes, tercero Relevancia. Y luego todo aquello que fuera "Nice-to-have". Qué momentos más bonitos de debate teníamos en las sesiones de priorización de roadmap. Pero cada decisión de hacer tecnología puede tener una estrategia diferente. Dejadme que os cuente tres ejemplos de cómo se fraguaron tres (o más) tecnologías totalmente distintas en Telefónica, para que veáis cuál era el objetivo de cada una de ellas, como parte de una estrategia de empresa mayor.
Kernel: Codename "La 4ª Plataforma"
El nacimiento de la 4ª Plataforma, que desde hace años la terminamos y lleva el nombre de Kernel, es el corazón de los servicios digitales de Telefónica. Con ella empezamos en el año 2016, y necesitábamos una plataforma que acabara con las arquitecturas application-centric que teníamos hasta el momento, que sacara partido de las arquitecturas Cloud y BigData, para permitir que se crearan nuevos servicios digitales sin estar conectados a los sistemas legados.
Figura 2: Si visitas La Cabina puedes ver funcionando
la 4ª Plataforma en tiempo real en Telefónica de España.
Esta info es similar a la de Alemania, Brasil o UK, por ejemplo.
Además teníamos que hacer una capa que cumpliera el GDPR y la regulación que llegara en 2017, y no podíamos dejar que esa pieza tan clave para el futuro estuviera en manos de un proveedor, así que había que crear tecnología.
Figura 3: App Novum en funcionamiento en la 4ª Plataforma en tiempo real y las
llamadas a APIs y consumo de datasets en el momento, que puedes ver en La Cabina.
18.825 instancias de Novum en este instante.
Creamos la 4ªPlataforma, como IdP único & SSO de todos los servicios digitales, como plataforma de APIs estandarizadas para todo el grupo, Datos normalizados bajo un catálogo de datos global URM, un gestor de consentimientos, y la posibilidad de correr algoritmos de Machine Learning para generar insights.
Figura 4: Apps en paralelo llamando a APIs y procesado Datasets
en la 4ª Plataforma de Telefónica de España.
La pusimos en producción y empezamos a construir los servicios digitales sobre ella. Primero la plataforma móvil (Codename:Novum) que llamamos Mi Movistar, Meu Vivo, Mein O2, Mi O2, Mein Blau, My O2, etc... en cada marca y país, la plataforma de televisión global, que da servicio a Movistar Play, Movistar Plus o Vivo Play en el mundo, la plataforma de gestión de la WiFi de SmartWiFi, Movistar Prosegur Alarmas para la presencia WiFi, Aura, las Living Apps, Movistar Tokens, el Canal Online, el eCommerce, HaaC (Home as a Computer),OpenGateway, etcétera.
Figura 5: Panel en Grafana de peticiones de APIs por segundo en las
últimas 24 horas en la 4ª Plataforma. Se puede ver el Prime-time de la tele.
Hoy en día - y desde hace años -, todos los servicio digitales se construyen sobre la 4ª Plataforma, donde para que os hagáis una idea, tuvimos más de 33 Billones de API Calls en 2024. Y para que puedas verla funcionar, en La Cabina, nuestro Centro de Demostraciones en el Head Quarter de Telefónica, puedes visitarla para ver en tiempo real cómo funciona, como los servicios digitales llaman a las APIs, como se procesan los datos, etcétera.
Figura 6: En La Cabina puedes ver el número de servicios digitales conectados a la 4ª Plataforma en España (126) consumiendo 110 familias de APIs y generando millones de APIs y consumos de datos normalizados. Todo en Cloud, en La 4ª Plataforma.
El objetivo era controlar el core tecnológico de nuestros servicios digitales, y por eso construimos esta plataforma y continuamos haciéndola más grande como arquitectura RAG con modelos de GenAI, y ahora agentes.
Si vas a La Cabina, puedes ver todas estas tecnologías en producción. Incluido Open Gateway, que es nuestro foco principal hoy en día, y se apoya 100% en la 4ª Plataforma (Kernel).
Aura: Codename "YoT"
Este fue un proyecto mucho más complejo, y que tenía un propósito muy diferente. Se trataba de dotar a nuestras tecnologías de capacidades de lenguaje natural Chat/Voz sin darle el control a tercero que nos intermediara en la relación con el cliente. Y por eso comenzamos a construir YoT (You on Telefónica), que luego bautizamos como Aura.
Lo que no queríamos era que los datos de nuestros clientes se quedaran en asistentes generalistas, que buscaban que nos integráramos con ellos. Además, independientemente de que tuviéramos integrados los interfaces de procesamiento de lenguaje natural en Smart Speakers como Alexa o Google Home, eso no nos solucionaría el problema de las webs, los contact centers, las apps móviles, herramientas internas, etc... Debíamos construir las APIs, las intents, y luego buscar en que canal lo integrábamos para llegar al cliente.
Figura 8: Aura, en Vivo Brasil
Así que construimos Aura, y lo integramos en la Televisión, en el Mando Vocal, en las apps, en las llamadas al Contact Center en los países y, puntualmente, en algunos asistentes de terceros con algunas capacidades y funciones limitadas. Queríamos controlar el motor de lenguaje natural e implantarlo en nuestros servicios para clientes. Y ahora, con la llegada de los LLMs y la GenAI, tenemos muchas más posibilidades gracias a eso.
Hoy en día Aura, que está en Brasil, España, Alemania y UK en múltiples canales, con millones de usuarios, y es pieza clave en la estrategia de accesibilidad que viene ahora en Europa. El objetivo era controlar la interacción con el lenguaje natural con nuestros clientes a la par que se desarrollaba esa necesidad - no todos los clientes gustan de chatear o hablar a los servicios digitales -, sin caer en la dependencia de terceros y poder controlar el canal que seguro que iba a ser importante en el futuro.
Movistar Home Connect
Este tercero es uno de los más interesantes proyectos que hemos construido, y de los más difíciles. Y fue un proyecto por el que tuvimos internamente muchos debates y análisis profundos. Y con un objetivo muy concreto que conseguir. Pero dejadme que os lo cuente en detalle que esta historia es de las que me gusta contar a mis compañeros en las cenas.
Estábamos en el año 2016 y el hype de Alexa tenía a todos muy nerviosos. Amazon había hecho una propuesta de un producto muy cool que se disfrutaba en los hogares. Y nosotros teníamos ahí mucho que proteger. Amazon tenía Alexa y Prime Video, FireTV, y Google tenía Android TV, Youtube e iba a sacar Google Home para el hogar en esas fechas. Estaba claro que se abría la batalla por el hogar, y nosotros teníamos mucho que defender allí.
Figura 10: Solución de SmartWifi
En el pasado, cuando nosotros llevamos Internet a los hogares, los ejecutivos de Telefónica, en concreto el mítico Julio Linares, puso en la estrategia proteger la conexión a Internet de Banda Ancha de los hogares mediante una solución WiFi, para que así no éramos intermediados por un dispositivo que estaba apareciendo. Ese fue el nacimiento de SmartWiFi en el grupo Telefónica.
Después, para consolidad nuestro posicionamiento en el hogar apostamos por la Televisión de Digital de Pago, con soluciones IPTV y OTT, incluyendo el descodificador con sistema operativo propio para no ser intermediados y soluciones en forma de apps para las SmartTVs. De hecho, hubo hasta una iniciativa en la que se construyó el descodificador de Telefónica dentro de algunas SmartTvs, aunque no acabó de cuajar. Con esa misma idea de "Home is our Territory", se trabajó en lanzar también Movistar Prosegur Alarmas o Solar360, buscando, como en las buenas partidas de ajedrez, controlar el "centro del tablero".
Figura 11: Presentación Completa del "hogar digital" en Ilustres Ignorantes
Pero estábamos en el año 2016, en medio del boom de Alexa y la corriente con Google Home ( e incluso Cortana ), donde algunas empresas de telecomunicaciones lanzaron su asistente y su smartspeaker para la televisión, como Magenta de DT. Y sí, en Telefónica había un equipo que había diseñado un proyecto de SmartSpeaker, con prototipos, business plan, etc... pero teníamos muchos debates sobre ello. Nunca íbamos a poder competir siendo un asistente para todo. Sin embargo, los tres casos de uso más importantes para estos dispositivos eran la música, la televisión, las llamadas de teléfono. Y nosotros controlábamos dos de ellos.
En Telefónica, no convencidos con el SmartSpekar, el equipo de dispositivos de la unidad de CTO había evolucionado el teléfono fijo a un sistema de teléfono digital en el hogar con pantalla táctil. Yo tengo uno de esos prototipos en mi despacho, que os dejo en foto. La idea era aprovechar el lugar que ocupaban todavía muchos teléfonos fijos en las casas de nuestros hogares, para meter un teléfono digital táctil con más capacidades, como controlar la televisión o tener un Second Screen. Así que, después de muchos debates decidimos que no había que lanzar el SmartSpeaker, y que aprovechando Aura y su integraci´no con la Televisión podríamos lanzar un SmartDisplay para frenar la entrada de Alexa en los hogares.
Figura 12: Prototipo de Movistar Home que guardo en mi oficina
Sabíamos que la mayoría de nuestros clientes seguían usando el mando y no tenían ningún SmartSpeaker en su salón, así que si para los que tenían inquietud por estos dispositivos les dábamos una solución como 2nd Screen para la Televisión y llamadas con Aura, podríamos defender nuestra posición y mitigar el impacto del "hype". Al mismo tiempo había que evolucionar a la máxima calidad los servicios de televisión, y comenzamos con una estrategia de agregar terceros, meter el mando vocal e introducir experiencias como Living Apps, Radio, Podcasts, etc...
Figura 13: Living App de La Liga en Movistar Home
Al final lanzamos Movistar Home, con sólo unas decenas de miles de dispositivos que construimos y vendimos, paramos el hype de Alexa en nuestros clientes sin darles las llamadas ni la televisión. Después llegó la crisis de los chips, y decidimos que todo el software de Movistar Home lo íbamos a migrar a una app, que comenzamos a construir en 2022, para tener la primera versión de Docking Mode de Apps, gratis para nuestros clientes. Y sí, con control de la televisión y las llamadas, para que sigan pudiendo tener la misma experiencia.
Figura 14: De Movistar Home a Movistar Home Connect vía app
presentado en el Innovation Day, como app gratuita de innovación.
En este caso, este proyecto tenía unos objetivos muy concretos, con unos recursos muy limitados, y con una carga de innovación e incertidumbre altísima, pero no sólo nos ayudó a frenar la entrada de los SmartSpeakers como interfaz único con el usuario en casa de nuestros clientes, sino que consiguió que la plataforma de TV creciera en valor, y la estrategia de integrar plataformas en España ha llevado a que Netflix, Prime, Disney+, FlixOlé o Mi Tele están integrados en el descodificador, y otros como HBO Max, Apple TV+, Warner o Sky Showtime integran directamente el contenido.
Figura 15: Con Antonio Guzman presentando Hogar Movistar
con Living Apps y Movistar Home Connect en Innovation Day 2024.
Hacemos tecnología que nos ayude a que "Home is our territory", por eso integramos también Movistar Cloud, Perplexity, hacemos Living Apps de deporte, cuentos, Tv-Commerce y seguimos evolucionando Movistar Home Connect.
Por supuesto, hay muchas tecnologías que no construimos nosotros. Hay también muchas tecnologías de innovación que son experimentales, que tienen un riesgo de morir pronto muy alto, o que simplemente hay un cambio de contexto que obliga a rectificar la estrategia. No tiene sentido hacer todo, ni mucho menos, pero proteger el valor a largo plazo y dejar las fichas de ajedrez en la mejor posición posible es parte de la responsabilidad de los que hacemos tecnología para una empresa.
Espero que estas tres historias de cómo y por qué hemos hecho algunas plataformas os hayan entretenido, que para nosotros han sido muchas, muchas, muchas horas de pensar y ejecutar. Cada una de ellas tiene parte de la vida de todos los que hemos trabajado en ellas. Y por supuesto, hoy hacemos OpenGateway y acuerdos con Perplexity, e inversiones en otras tecnologías, y cada una tiene su historia detrás, pero esas os las contaré dentro de unos años... que ahora estamos en plena ejecución. }:)
Ya hemos visto muchas veces el debate de las cookies publicitarias en las páginas web de navegación en Internet. El poder controlar las cookies que hacen un perfilado de una persona hace que los anuncios sean más ajustados para el visitante de la web, y eso hace que para los anunciantes tenga más sentido anunciarse en las webs que mejor perfilan, y eso hace que los sitios webs ganen más dinero con los anuncios si son capaces de perfilar a los visitantes y tener el anuncio adecuado para cada navegante.
Figura 1: Utiq Consent Hub - Cookies Publicitarias y Muros de Suscripción
Hasta aquí todo fácil de entender. Perfilado implica Dinero. Así de sencilla es la ecuación, pero con la llegada de GDPR, muchas de las cookies dejaron de poder utilizarse para perfilar a los navegantes, porque las webs deben dar la opción de rechazar las cookies de perfilado y el consentimiento para compartir estos datos con terceros, y llegó el "Subscription Wall", es decir, acepta las cookies o suscríbete y paga.
Figura 2: Susbcription Wall
El asunto es que las cookies no se han ganado mucho cariño por los ciudadanos de la red debido a lo difícil que ha sido poder controlarlas, saber qué hacen, y sentirse demasiado "perseguidos" por los anuncios sin poder librarse de ellas fácilmente. Así que muchos fueron los que empujaron por el mundo "Cookieless" que poco a poco está llegando.
Figura 3: Solución de Utiq en Marca.com
Una propuesta alternativa a este mundo es la que hace Utiq, una startup creada entre Orange, Vodafone, Deustche Telekom y Telefónica, donde se utilizan identificadores desde la red móvil con privacidad, que se pueden eliminar de manera sencilla a través de un gestor de consentimientos.
Figura 4: SMS con información de Utiq.
La idea es tan sencilla como que un sitio que utiliza Utiq y quiere dar las dos alternativas - Navegar Gratis o Pagar Suscripción -, puede darle al usuario la opción de ser perfilado por medio de estos identificadores de red. Los usuarios que aceptan utilizar Utiq, recibirán un SMS con información de Utiq, y la URL del Consent Hub de Utiq que es el panel en el que cuando el usuario lo desee, puede ir y eliminar el consentimiento de uso de ese identificador para ese sitio web.
Al Consent Hub de Utiq se accede desde tu conexión móvil, pero yo he accedido desde mi Mac haciendo una sesión de Internet Tethering con mi iPhone, por eso se ve la versión Web de escritorio en la imagen anterior. En la imagen siguiente se puede ver que tienes la opción de "No usar nunca Utiq" o de "Gestionar tus consentimientos" que ahora mismo está vacío. Es decir, no se ha generado ningún identificador de red de tu conexión para ningún sitio web.
Cuando se acepta el uso de Utiq en un sitio, por ejemplo en la web de ejemplo de marca.com, lo que tendremos es este domino en la lista de nuestros consentimientos concedidos, pero con un clic en la papelera, eliminamos este consentimiento desde ese instante en adelante.
De esta forma se intenta conseguir que los sitios de contenido gratuito que viven de la publicidad, puedan también garantizar al usuario que este tiene el control de sus identidades digitales y perfilado con un panel de control para todos.
Si accedes desde el móvil a la URL de https://consenthub.utiq.com/ podrás acceder al panel de control delos consentimientos de Utiq que tienes en tu control.
El modelo de negocio de los llamados Data Brokers es algo muy activo en los Estados Unidos, donde la regulación no es tan estricta como el GDPR que tenemos nosotros en Europa. Yo lo sufro en primera persona porque hay empresas que se dedican a vender números de teléfono y direcciones de correo de todo tipo de perfiles, incluidos los ejecutivos de compañías para hacer campañas de venta. Pero como vamos a ver en este informe, datos mucho más allá de los simples datos de contacto.
No es casual que yo solo utilice MyPublicInbox como forma de contactar conmigo si no nos conocemos, y que no conteste ninguna llamada, ni devuelva ningún mensaje que venga de quién no esté en mi circulo cercano. Es la única forma de proteger mi tiempo para poder sacar a tiempo mis proyectos.
Pero es que la venta de datos va más allá de los datos de contacto en el mundo de los grandes Data Brokers, donde se comercializan toda clase de datos, médicos, socioeconómicos, políticos, de actividad, e insights generados. Y a precios bastante ridículos. Yo hablé de la importancia de todos estos datos en una charla que di en el año 2016 en un evento organizado por mis amigos de Repsol, que decía "You are where you are", donde única y exclusivamente hablaba de la localización, pero ya es más que "crappy".
Comprando datos para comprometer la seguridad nacional
La compra/venta de los datos se ha convertido en una poderosa arma, que utilizada políticamente de forma masiva dio lugar al escándalo de Cambridge Analytica, donde se utilizaron políticamente para ayudar a desequilibrar la balanza hacia un lado un otro en múltiples votaciones. Hechos que abrieron temporalmente los ojos del mundo, pero que parecen ya de otros tiempos, cuando la realidad es que esto sigue siendo el día a día.
En un estudio que se ha publicado este mes, titulado "Data Brokers and the sale of data on U.S Military Personnel" se explica cómo de sencillo es para cualquiera conseguir datos sensibles del personal militar americano aun cómodo precio de 12 céntimos de dólar por registro, lo que puede dejar a un potencial adversario información de inteligencia sobre el personal militar de EEUU a un módico precio. Nada de los grandes maletines con millones y millones de dólares en billetes que veíamos en las películas.
Todo mucho más rápido, sin saltar por montañas, robar microchip, o archivos de inteligencia en bases secretas donde para entrar había que explotar bombas e infiltrar un comando militar encubierto. No, solo con llamar por teléfono a un Data Broker, pedir precios, tipo de información que venden, pagar y listo.
Y como he dicho antes, no se trata sólo de datos de contactos, sino que tienen insights que pueden llegar a ser de lo más sensibles, como podéis ver en el "menú de compra de datos" de uno de los Data Brokers. Es decir, información detallada hasta para saber quién va al casino o le gustan los juegos de azar.
Como os podéis imaginar, esta información es perfecta para hacer APTs preparados contra personal militar que pueda tener un impacto mayor contra alguna organización del ejercito de los EEUU. Desde luego, si eres una organización que tiene adversarios que este tipo de datos se consiga tan fácilmente no es lo que quieres.
Figura 6: Datos conseguidos usando dominios de USA
En la tabla anterior se pueden ver qué tipos de datos de fueron capaces de comprar utilizando dominios de correo electrónico para las comunicaciones ubicados en USA y en la de abajo, los datos que consiguieron usando dominios de ASIA. En ambos casos, datos muy sensibles.
En todos los casos, datos muy sensibles de personal que trabaja en una organización tan importante para la seguridad nacional como el militar, del que llegaron a conseguir datos de alergias médicas, tal vez conseguidas de restaurantes, hoteles y clínicas por los Data Brokers.
Está claro que los datos son un negocio, pero estos ejercicios demuestran que es necesario controlarlos, porque estamos haciendo que sea muy fácil que lleguen a manos de cualquiera. Leer esto, me ha recordado el cuento que cree de "You Leak it!" donde una empresa compra los datos que un ex-empleado puede vender de su empresa nada más ser despedido, pero a lo bestia.
Ayer jueves dediqué un rato de mi día a leerme un paper académico publicado por el equipo de Microsoft Research que trata el problema de la filtración de datos que identifican a personas en los LLM que se generan hoy. Es decir, cómo un atacante haciendo algo de Prompt Injection, es capaz de descubrir PII (Personal Identificable Information) del set de datos privados con que fue entrenado dicho modelo.
Estas técnicas de ataque no son nuevas, y están entre nosotros desde que los LLMs se encuentran también en nuestras vidas, y el artículo en cuestión, titulado "Analyzing Leakage of Personally Identifiable Information in Language Models" los explica e intenta crear una métrica para saber cuando de "leaky" es un LLM.
Al final, el misterio de tener toda la información personal disponible para entrenar el modelo o no, es un equilibrio entre privacidad y usabilidad, ya que cuanto con más datos privados ha sido entrenado un modelo, más puede aprender. Como sucede con los modelos de predicción de texto que se utilizan en los teclados de los smartphones o en la escritura de correos electrónicos en Gmail u Office.
Si se entrenan con nuestros datos sin filtrar, serán más útiles, pero al mismo tiempo si alguien tiene acceso a ellos tendrá la oportunidad de sacar muchos más datos personales jugando con el modelo, haciendo lo que se llama el "Tab Attack" porque es similar a dar al Tab para que autocomplete con el dato correcto el teclado predictivo.
En el caso de los LLM que se entrenan con datos sin filtrar, o con un conjunto de datos filtrados y otros no, nos podremos encontrar que la información PII puede ser filtrada mediante el uso de la API, solo con solicitar actividades vía Prompt Engineering, como contar una historia. Este ejemplo muestra que, al pedir que se cuente una historia, los datos PII son utilizados como parte de la respuesta.
Algo que hace que la narración sea más perfecta, es decir, que el grado de "Perplejidad" sea mejor. Al final, la "Perplejidad" es el grado de confianza que tiene el modelo en que la respuesta que está ofreciendo el modelo es válida. Así que si utiliza PII, la "Perplejidad" será mejor. Esto lo explica muy bien el artículo del año 2021 "Training Data Leakage Analysis in Language Models".
Como ya conocemos este, problema, la curación de datos para generar LLMs tiene un proceso de "Depuración de Datos Personales" o "PII Scrubbing", donde se enmascaran aquellas partes del set de datos que contienen PII, para que modelo entrenado genere las respuestas con datos enmascarados, lo que hará que los resultados tengan menos filtración de información cuando se pide generación de respuestas vía Prompt usando el API.
Sin embargo, ya existen técnicas para encontrar aquellos datos que siguen en el modelo a pesar del PII Scrubbing, utilizando técnicas de Reconstrucción e Inferencia de PII, que se han explicado en diferentes artículos académicos en el último par de años.
Reconstrucción e Inferencia de PII en LLMs
El funcionamiento es bastante curioso, y utiliza una mezcla de Prompt Engineering y análisis de Perplejidad, como se explica en este caso que es muy claro. Veréis, el atacante sabe que alguien ha matado a alguien en un asesinato cerca de una ubicación concreta. Y quiero saber si está información, que aparece en datos de carácter legal, ha sido eliminada de los datos de entrenamiento en el proceso de Data Scrubbing. Así que la frase en cuestión que busca resolver el atacante es
"A murder has been committed by X and Y in a bar close to the Rhine"
Si esa frase no ha sido bien filtrada de PII, entonces el atacante puede utilizar un proceso de Reconstrucción y de Inferencia, haciendo un rellenando parte de la expresión con un modelo de lenguaje que complete con posibles datos PII que se quieren probar. Así, con el modelo de lenguaje externo se generan las alternativas con los "sospechosos" o "candidatos".
"A murder has been committed by John Doe and Teo Peric in a bar close to the Rhine"
"A murder has been committed by John Doe and Ana Jacksic in a bar close to the Rhine"
Y analizar cuál de los dos es el que está en el sin filtrar en el proceso de PII Scrubbing en el LLM, consiste en analizar cuál es el grado de "Perplejidad" que se obtiene con cada uno de los candidatos, ya que el que esté en el Data Set de entrenamiento sin filtrar tendrá un grado de confianza mayor que será descubierto por su "Perplejidad".
Este tipo de análisis lo que permite saber es cuál es el nivel de filtrado de PII en un modelo que haya podido ser entrenado con documentos que puedan tener datos de afiliación de personas, especialmente con datos médicos, legales o ideológicos de personas.
Estas técnicas me recuerdan mucho a las técnicas de inyección de comandos, como Blind SQL Injection, Blind LDAP Injection, Blind XPath Injection, etcétera, donde la extracción de información de la base de datos (SGBD, LDAP o XML) era el objetivo de la inyección.
Ahora, el conocimiento de un modelo de LLM una vez entrenado es la nueva "base de datos", y las técnicas de Prompt Injection o análisis de perplejidad en procesos de inferencia y reconstrucción la forma de hacer el ataque. Un mundo nuevo para estudiar y desarrollar nuevas técnicas de hacking.