Telefónica Open Gateway y las APIs de Camara

En unos minutos me voy a subir al escenario para hablar de Open Gateway en el auditorio que tenemos en el estand de Telefónica. Hubo noticias previas a este lanzamiento, así que os hablé un poco de ellas en el artículo de Codename "NaaS" (Network as a Service), aunque es verdad que no es solo eso, y que tenía un poco más de miga que quería explicaros justo después de que se hiciera público en las presentaciones principales de la GSMA. Pero como cuando salga este artículo ya habrá sido anunciado, aprovecho y os lo explico.

Figura 1: Telefónica Open Gateway y las APIs de Camara

Al final lo que perseguimos con Open Gateway es poner en el centro de la construcción de nuestras capacidades a los Desarrolladores, a los Programadores, a los Developers, a las Startups que hacen Innovación, para que puedan configurar todas las capacidades de Telefónica - y de cualquier otra telco - como lo hacen con cualquier otra capacidad que necesitan para construir un servicio digital. Como os decía en el artículo de Codename: NaaS, la idea fundamental es democratizar el acceso a todas nuestras capacidades a todos los creadores de tecnología digital. No solo para los que son lo suficientemente grandes como para hacer proyectos a medida con todas las "telcos", algo que solo grandes empresas OTT se permiten.

Figura 2: Telefónica Open Gateway

Con este proyecto, empujado desde la GSMA, lo que se pretende es disponibilizar las capacidades que estamos desplegando en nuestras redes a todos los creadores de tecnología para que creen los servicios digitales del futuro, usando las capacidades que deseen bajo demanda, personalizando la experiencia que sea mejor en cada momento es algo que nos permitirá ver más innovación, desde más rincones del mundo, y de forma más acelerada.

Figura 3: Open Gateway es una iniciativa de GSMA

Y para hacerlo, tenemos que hacer cosas que tradicionalmente no hemos hecho, que os paso a contar por aquí.

1.- API First: Queremos apificar todas nuestras capacidades. Esto significa que todo lo que hoy en día ofrecemos como servicios a medida, o mediante configuración manual utilizando herramientas, tiene que ser "API First". Si una capacidad no se puede configurar con APIs, entonces no podrá ser utilizada por desarrolladores.

3.- On-Demand & Real-Time: Por supuesto, queremos que las capacidades de la red y de la industria telco estén preparadas para que se pueda configurar todo bajo demanda, con pago por uso y en tiempo real, como se hace en todas las demás capacidades que utilizan los servicios digitales en la cloud, donde pueden configurar, memoria, microprocesador, GPUs, procesos, bases de datos, almacenamiento, etcétera, en tiempo real, bajo demanda, y con pago por uso.

Figura 4: APIs "Developer-Ready"

4.- Estandarizadas: Y esto es muy importante, no queremos que cada una de las empresas telco creen una API diferentes, sino que todas funcionen de la misma manera. Es decir, hay un comité de estandarización de APIs con las características anteriores, en la GSMA que se encarga de hacer todas esas APIs y estandarizarlas en lo que se conoce como CAMARA.

Figura 5: APIs estandarizas bajo CAMARA

Si una API está bajo el paraguas de CAMARA quiere decir que funcionará igual en todas las telcos, y para el programador será transparente si uno de sus usuarios está conectado a una red de Telefónica o de otra compañía, podrá configurar en tiempo real servicios de la telco para cada una de las sesiones de sus usuarios, de forma única, y con la misma APIs.

5.- No Lift & Shift: No se trata de hacer un Lift & Shift de las APIs que vienen out-of-the-box en los dispostivos que nosotros incorporamos en nuestras redes, sino APIs refinadas que hagan todas las funciones que se necesiten para gestionar una capacidad "One Single-Line of Code", añadiendo la capa de autenticación, seguridad y privacidad por diseño. En nuestro caso, basadas en Telefónica Kernel.

Figura 6: APIs estandarizas bajo CAMARA

6.- Developer Communites: No se trata de construir una nueva comunidad de desarrolladores alrededor de Open Gateway, sino de poner las capacidades de Open Gateway en los lugares donde están los desarrolladores, es decir, en Microsoft Azure, en Amazon AWS, en Vonage, en Google Cloud, y en cualquier plataforma de desarrollo que tenga comunidades y ofrezcan capacidades para construir tecnología a los programadores, a los creadores digitales.

Figura 7: APIs disponibles vía EAPs en Azure, AWS, Vonage, GCP

Y para hacer todo esto, hemos estado trabajando con Microsoft Azure, con Google Cloud, con Amazon AWS, con Vonage, además de internamente para construir el primer conjunto de APIs, y tener los primeros casos de uso.

Figura 8: Early Adopters Program

Así, hemos lanzado un Early Adopters Program para que desarrolladores que quieran probar las primeras APIs puedan solicitarlo. También con Amazon y Vonage, que han abierto con nosotros, con Telefónica, una Call for Early Adopters que quieran probar nuestras APIs, que tienes abiertas en la web.

Figura 9: Call for Early Adopters que quieran probar nuestras APIs

Por supuesto, hemos trabajado también en el tercer frente, que es ayudar a tener los primeros casos de uso con varios servicios digitales. Algunos son  PoCs, otras son demos y otras son casos de uso que van a producción, pero como aún estamos en esa fase de EAP, ninguna de las APIs tiene un coste aún, porque estamos en la fase de pre-lanzamiento comercial, así que tendremos que seguir trabajando.

Just the beginning

Como este es un proyecto muy ambicioso, de convertir toda la red de Internet en una plataforma, sí, toda la red que forman todas las telcos - por ahora más de una veintena de telcos nos hemos sumado a CAMARA, lo que suman un plataforma para APIs que conecta miles de millones de dispositivos -. Y sobre los que se podrán configurar cosas. Una forma de hacer una "Programable Network" para los desarrolladores. Permitir a un desarrollador tener la red en su compilador, usarla, configurarla, adaptarla.

Figura 10: Casos de uso con APIs CAMARA

Estamos solo en el primer paso, pero cuando estás innovando, y creando cosas nuevas, siempre estás en el primer paso, y eso te trae nervios, excitación y alegría. Hemos hecho muchas cosas, y no quiero condensarlas en un único artículo, así que os iré contando más cosas de Open Gateway, de las APIs, de los casos de uso que tenemos, de las llamadas de Early Adopters Program, y de todo lo que estamos y vamos a hacer alrededor de esto en los próximos artículos. Es un camino largo, así que nos dará tiempo a charlar sobre ello muchas veces.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Weaponizar ChatGPT para robar contraseñas WiFi y crear malware

ChatGPT tomó a Internet por sorpresa después de que OpenAI lo liberara al mundo hace poco más de dos meses y la opinión pública de cara a su lanzamiento ha sido bastante reveladora. Ya que al igual que muchos otros usuarios que están emocionados por su potencial, creo que este podría ser el momento en que comience a comprenderse realmente la capacidad revolucionaria de la IA en materia de ciberseguridad.

Figura 1: Weaponizar ChatGPT para robar contraseñas WiFi y crear malware

Aunque en términos generales se le describe como un chatbot, ChatGPT es mucho más que eso. Puede generar textos, explicar temas complejos, actuar como traductor, resolver problemas lógicos, participar activamente en una conversación y completar tareas complejas con una precisión asombrosa, sin mencionar su capacidad para escribir código.

Figura 2: Libro de "Hacking redes WiFi: Tecnología, Auditorías y Fortificación".

de Ferran Verdés Castelló en 0xWord

Es precisamente en esta última y controvertida característica en la que nos enfocaremos por el momento, ya que la demo principal pretende demostrar cómo puede “weaponizarse” a esta inteligencia artificial para abusar de su potencial como creadora de malware.

Weaponizando ChatGPT para robar contraseñas WiFi 

OpenAI es consciente de que los usuarios malintencionados pueden abusar de ChatGPT e IA similares. Para contrarrestar esto, han introducido filtros para detectar actividad que violaría los términos y condiciones. De tal manera que, si se le formulan preguntas como la siguiente, es casi seguro que declinará siempre la petición.

Figura 3: Negativa de ChatGPT de brindar código

Como podemos notar, se fracasa en la búsqueda de obtener fragmentos de código que la IA tilda como “ilegales” y “poco éticos”. Sin embargo, formulando preguntas más precisas y atómicas se comienzan a conseguir cosas interesantes.

Figura 4: Filtrando los perfiles wifi en forma de lista

Se obtiene un comando funcional que filtra los perfiles de redes wifi almacenados en el equipo y los presenta en forma de lista. Sin embargo, la función “SelectString” utiliza como parámetro de filtrado una frase de dependencia idiomática, lo cual mermaría la funcionalidad del código en equipos configurados en un idioma diferente al español.

Figura 5: Error del bot al generar código

Se le solicita realizar un cambio al código y en efecto, lo hace, pero no de la manera correcta, pues aún implementa en él frases en español, así que de nuevo se pide una corrección.

Figura 6: Corrección de código

Más tarde, se busca la iteración de la función por cada perfil WiFi para lograr extraer las contraseñas de cada una de las redes wifi almacenadas en el equipo con las que alguna vez se estableció una correcta conexión. Todo esto en texto plano y en función de su SSID.

Figura 7: Implementación de ciclo for para iterar instrucción por cada elemento de la lista

Una vez que se obtiene satisfactoriamente la generación de un archivo de texto a nivel local con las contraseñas WiFi, se busca su exfiltración hacia un servidor remoto controlado por el atacante. Sin embargo, se experimentan problemas con la compatibilidad de los comandos en diferentes entornos.

Figura 8: Solución a error de compatibilidad

Posteriormente en pruebas manuales, se identifica el detonante del error durante el despliegue de una petición POST hacia el servidor remoto. Lo cual se solventa codificando la estructura de la petición en Base64 previo a su lanzamiento con “Invoke-Expression”

Figura 9: Codificación de comando en base64 y posterior ejecución con Invoke-Expression

Una vez que la programación del malware está terminada, la dinámica de infiltración y ejecución del código malicioso en la máquina objetivo se centrará en un escenario de Red Team. En el cuál por obviedad, el tiempo para el despliegue de un ataque es un factor crucial para el éxito o el fracaso de la operación. Así que como vector de ataque inicial, se aprovecharán las bondades de los ataques HID con un USB Maligno.

Figura 10: Libro de "Empire: Hacking Avanzado en el Red Team" 
de Pablo González y Sebastián Castro en 0xWord.

Subsecuentemente las pulsaciones de teclas están programadas para dar apertura a una ventana de “Ejecutar”, seguido del referenciamiento hacia el malware, que será ejecutado en memoria a través de IEX de PowerShell en la máquina víctima. El cuál se encargará de extraer todas las contraseñas de las redes WiFi almacenadas en el equipo Windows en un archivo de texto, lo enviará al atacante en texto plano y borrará el archivo de la máquina víctima. Todo esto en solo un par de segundos.

PoC de distribución de malware con WiFi maliciosa

Resulta interesante mencionar que el malware generado puede ser guardado en cualquier formato (en este caso en texto plano con el nombre de: wifi-stealer.txt), y sin problema Powershell interpretará el contenido del archivo, pues se estará ejecutando en una de sus instancias y porque su contenido se ha escrito haciendo uso de su sintaxis. Para fines de la prueba de concepto, configuré una nueva red con el nombre y la contraseña que se muestran a continuación.

Figura 11: Red de prueba configurada para la POC

Más tarde conectamos el sistema Windows víctima a la red, con la finalidad de que la contraseña de la red WiFi “ElLadoDelMal” sea almacenada junto a todas las demás redes con las que alguna vez se estableció conexión.

Figura 12: Máquina Windows establece conexión con la red

El ataque HID solo demora dos segundos y al terminar, obtenemos en el equipo atacante un archivo de nombre “output.txt”, que contiene el historial en texto plano de todas las contraseñas WiFi de las redes a las que la víctima se ha conectado.

Figura 13: Fichero con las contraseñas extraídas

Si visualizamos su contenido desde la terminal de Kali Linux de manera paginada con “more”, nos encontramos con el nombre de la red y la contraseña en texto plano.

Figura 14: Contraseña de la red de prueba en texto plano

Cabe destacar que el bot no solo tiene la capacidad de generar código, sino también de procesar cualquiera ingresado por el usuario y transformarlo de acuerdo con sus deseos y necesidades. Lo cual implicaría cientos de mutaciones funcionales de una misma pieza de malware.

Figura 15: Prueba de concepto Wifi-Stealer

Finalmente, de ChatGPT podemos concluir tres cosas:

1.- Que no debemos confiar al cien por ciento en sus respuestas, porque como toda tecnología emergente dependiente de los datos, a veces falla, en especial si previamente accedió a información incompleta o desactualizada. Sin embargo, es de esperarse que el bot se vuelva más inteligente a medida que los usuarios encuentran las maneras más eficientes y certeras de realizar sus peticiones para obtener los mejores resultados.

Figura 16: Pentesting con Kali Silver Edition
de Pablo González en 0xWord

2.- Que sus lineamientos morales pueden bypassearse con algo parecido a la ingeniería social pero dirigida a su motor de procesamiento del lenguaje natural. Simplemente fragmentando el problema general y planteándole resoluciones a manera de retos modulares.

Figura 17: ChatGPT negando escribir malware a propósito

3.- Y que, aunque sea una tecnología revolucionaria, que apareció para cambiar totalmente el juego del malware entre “el gato y el ratón” no vino para sustituir el oficio de los hackers, sino para ser uno más de los "juguetes peligrosos" en su arsenal, pues, aunque ChatGPT sea casi una criatura digital omnisciente, siempre necesitará quien le haga las preguntas correctas.

¡Saludos!

Autor: Raphael Molina

Contactar con Raphael Molina

Descifrando las cartas de María Stuart I de Escocia

La tecnología y sus avances no dejan de sorprendernos día a día. Y por una vez, no vamos a hablar exclusivamente de un avance conseguido utilizando Inteligencia Artificial sino que esta vez vamos a hablar de criptografía e Historia. En este caso concreto nos centraremos en la persona de María I de Escocia, ya que se han descubierto más de 50 cartas cifradas dirigidas al embajador francés de la época. 

Figura 1: Descifrando las cartas de María I de Escocia

Imagen: "Recreación de María I de Escocia con un ordenador" por Dall-e

Este ensayo, titulado "Deciphering Mary Stuart's lost letters from 1578-1584" nos muestra el gran impacto sobre nuestro conocimiento histórico y sus personajes que descubrimos cuando combinamos tecnología y conocimiento humano para comprender y descifrar algunos de los documentos dejados para la posteridad. 

Figura 2: Libro de Cifrado de las comunicaciones digitales:
de la cifra clásica a RSA 2ª Edición de 0xWord

Estas se encontraron en la Biblioteca Nacional de Francia y se han descifrado usando técnicas por ordenador y análisis contextual manual, y en este artículo vamos a intentar explicar el proceso seguido para realizar este interesantísimo trabajo y conocer más del sistema de cifrado que utilizaron. Si te gusta la criptografía, el libro de "Cifrado de las comunicaciones digitales: de la cifra clásica a RSA (2ª Edición)" de 0xWord es el que debes comprarte.

María I de Escocia

María I de Escocia, resumiendo “mucho”, accedió al trono muy joven, sólo a los seis días de nacer. Su vida no fue precisamente fácil ya que se vio involucrada en una serie de eventos bastante desafortunados como el asesinato de su esposo, ver a su hijo en la cárcel, abdicar en favor de él, etcétera. Pero quizás el evento que más le afectó, y con razón, fue su encarcelamiento durante 19 años en Inglaterra por conspirar contra la reina Isabel I (muchos católicos como María I de Escocia pensaban que Isabel I no era legítima heredera ya que su padre Enrique VIII había roto completamente con la Iglesia Católica).

Figura 3: Retrato de María I de Escocia

Durante este periodo de encarcelamiento, mantuvo contacto con diferentes personas en Francia e Inglaterra. El problema es que durante este periodo también fue objeto de varias conspiraciones que finalmente acabaron con su vida, en 1587. Esta complicada relación con la monarquía inglesa, los poderes católicos, sus contactos en Francia, etcétera, está reflejada en toda su correspondencia y estas cartas son muy importantes para comprender estas relaciones y los motivos reales detrás de su ejecución final. Por ello descifrar las cartas (María I de Escocia enviaba su correspondencia importante cifrada) son clave para entender toda la historia detrás de este gran personaje histórico.

Descifrando las cartas

Esta investigación se centra en descifrar precisamente la serie de cartas recientemente encontradas enviadas al Embajador de Francia, Michel de Castelnau. Estas cartas están totalmente cifradas, sin ningún elemento que ofrezca datos como la fecha, la persona que la escribe, el destinatario, etcétera. 

Figura 4: "Deciphering Mary Stuart's lost letters from 1578-1584"

El primer paso descifrarlas ha sido transcribir los documentos que sólo contienen gráficos a un formato legible para programas de ordenador. No era tarea fácil ya que hablamos de 150.000 símbolos en total y, además, no se podía usar OCR. Por lo tanto, desarrollaron una aplicación específica para el proyecto llamada CrypTool2.

Figura 5: Software CryptTool2 creado específicamente para sustuir

los símbolos gráficos por otros legibles para el ordenador.

Una vez digitalizados estos símbolos y convertidos a caracteres legible por una máquina, se aplicó un análisis y descifrado por ordenador utilizando esa herramienta. Este primer paso permitió descubrir o identificar el idioma original de los textos (en este caso francés pero podría haber sido inglés o italiano) y recuperar diferentes fragmentos de éste.

Se identificaron elementos homófonos, símbolos utilizados para nombres, lugares o los meses del año. También se encontraron patrones recurrentes (algo importante en el proceso de cualquier descifrado) e incluso errores en estos patrones por fallos humanos durante la utilización de las tablas de cifrado y descifrado.

Figura 6: Ejemplo de descifrado después de identificar a los homófonos

Durante siglos, el principio básico de los cifrados permaneció igual: cada letra del alfabeto se sustituía por un símbolo, es decir, un cifrado por sustitución. Pero desde el siglo X, los árabes desarrollaron métodos efectivos para romper códigos basados en el análisis de frecuencia. Más adelante, para evitar la ruptura de códigos basada en el análisis de frecuencia, se introdujeron cifrados homofónicos, en los que, para las letras más comunes, se ofrecía una elección de varios símbolos (también conocidos como homófonos como se ha mencionado anteriormente) para cifrar esa letra. 

Los homófonos hacían que el cifrado fuera más difícil de romper y se incluía una nomenclatura que consistía en una lista de símbolos para palabras, nombres o sílabas frecuentemente usados. Los investigadores de este ensayo tenían claro que el cifrado era homofónico pero el problema principal estaba en que no conocían el idioma del texto original y además encontraron algunas características que hacían que el cifrado en estas nuevas cartas fuera un tanto especial.

El cifrado María-Castelnau

Los Archivos Nacionales Británicos tienen muchas claves de cifrados utilizados por María I de Escocia y sus colegas. Estas claves fueron capturadas o reconstruidas a partir de mensajes interceptados. De hecho, el famoso cifrado de Babington (la conspiración que llevó a la muerte por ejecución de María I de Escocia) era del tipo monoalfabético con una pequeña nomenclatura propia.

Pero, por otro lado, la mayoría de los otros cifrados encontrados en esos archivos eran homofónicos con una nomenclatura centrada en nombres, lugares y palabras comunes del francés o el inglés. Además, se usaban símbolos gráficos y marcas que se colocan debajo o arriba de la letra para modificar su sonido o incluso darle una pronunciación específica (esto se denominan símbolos diacríticos).

Figura 7: Parte del cifrado María-Castelnau

Pero lo curioso es que el cifrado reconstruido con estas nuevas cartas no aparece en ninguna de las otras cartas mencionadas anteriormente (aunque si comparten características fundamentales como la homofonía). De hecho, en este nuevo cifrado empleado en estas cartas aparecen símbolos como caracteres que representan el valor nulo o “especiales” que sirven para indicar una repetición o incluso la eliminación de un símbolo concreto (el último, por ejemplo). 

Esto es especialmente interesante porque estamos hablando de símbolos que modifican el texto escrito, es decir son caracteres especiales que realizan una función específica sobre el texto (al más puro estilo de la Máquina de Turing con comandos que hacen avanzar o retroceder en la cinta). No está claro si este método alternativo de cifrado fue inventado por María I de Escocia o por algunos de sus colegas.

¿De qué se hablaba en estas nuevas cartas?

Uno de los temas principales que encontramos en estas nuevas cartas cifradas es el esfuerzo continuo de María Stuart I de Escocia en crear canales seguros con Castelnau, para poder contactar con sus aliados en Francia. Las cartas también mencionan la posible boda entre el Duque de Anjou y la Reina Isabel, mientras que María I de Escocia defiende el matrimonio, también le advierte a Castelnau sobre sus dudas de la sinceridad por parte inglesa y sus planes para debilitar a Francia. 

Figura 8: Ejemplo de una de las cartas originales con el texto cifrado.

Además, María I de Escocia muestra una gran animadversión hacia el Conde de Leicester y otros miembros de la facción puritana, a quienes acusa de fomentar conspiraciones en su contra. Por otro lado, las cartas también hablan de las negociaciones para la liberación de María I de Escocia y su restablecimiento en el trono escocés (y sus quejas sobre sus condiciones de cautiverio). En el documento original de esta investigación se encuentra un resumen completo de todas y cada una de las cartas descifradas.

¿Y cómo eran esos canales de comunicación confidenciales o seguros?

Además de estos canales seguros, otro punto importante era también la distracción, ya que en paralelo a estos canales cifrados había una comunicación normal bajo la supervisión de Sir Francis Walsingham (el “maestro de espías” y némesis de María I de Escocia). Uno de los mensajeros más destacados era por ejemplo Claude de Courcelles, pero este no fue el único y además había continuos intentos de reclutar a nuevos mensajeros.  En las cartas también se menciona la posible infiltración de mensajeros pagados por Walsingham para poder interceptar las cartas y revelar a los componentes de la cadena de comunicación.

Figura 9: Sir Francis Walsingham

Un punto importante que se menciona en las cartas y que afecta al funcionamiento de estos canales de comunicación es el cambio de embajador francés por Châteauneuf (en vez de Castelnau). Esto llevo a que María I de Escocia ya no se comunicara más por canales oficiales, sino que solamente utilizaría los confidenciales aumentando las sospechas de la existencia de estos y que finalmente fueron descubiertos e interceptados.

Conclusiones

Esta investigación de las cartas descubiertas ha permitido obtener un mejor conocimiento sobre la vida de María I de Escocia sobre su periodo de cautiverio. Pero además estas revelaciones también influyen sobre la historia en general que ocurrió alrededor de su imagen y el efecto en otros acontecimientos posteriores. Y esto es sólo una primera aproximación, la gran cantidad de información revelada es enorme y requerirá de más tiempo de análisis y comparación con el resto de otra correspondencia para encontrar nuevas evidencias o datos que aporten más información a este personaje histórico y todo lo que le rodeaba.

Figura 10: Libro de "Microhistorias: anécdotas y curiosiades de la historia
de la informática (y los hackers)" de Fran Ramírez y Rafel Troncoso 0xWord.

Este ensayo es un ejemplo más de la importancia de la tecnología hoy en día pero también destacar la gran contribución del análisis humano detrás de esta investigación, hoy que prácticamente todo se hace ya con Inteligencia Artificial. Y si te gustan estas historias del impacto tecnológico y su evolución histórica (además de historias de hackers) recuerda que tenemos este libro que escribimos con mucho cariño mi colega Rafael Troncoso y yo llamado “Microshistorias: anécdotas y curiosidades de la Informática”, de 0xWord. 

Happy Hacking Hackers!!! 

Autor: Fran Ramírez, es investigador de seguridad y miembro del equipo de Ideas Locas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps", también de "Machine Learning aplicado a la Ciberseguridad” además del blog CyberHades. Puedes contactar con Fran Ramirez en MyPublicInbox.

 Contactar con Fran Ramírez en MyPublicInbox

Mis eventos, Conferencias y Charlas para esta semana: Mobile World Congress, 4YFN, Microsoft Tech Security Day & Horizonte

Para hoy sábado, ya enfilando mi viaje para Barcelona, os traigo la lista de actividades para esta primera semana de Marzo, donde principalmente voy a estar en la Ciudad Condal, haciendo muchas cosas, pero con alguna cosa más por medio. Estas son las citas para esta semana.

 

Figura 1: Mis eventos, Conferencias y Charlas para esta semana:

Mobile World Congress, 4YFN, Microsoft Tech Security Day & Horizonte

Por supuesto, desde el domingo por la mañana tengo agenda de actividades en Barcelona con motivo del Mobile World Congress, pero no todas son públicas. 

28 a 1 de Marzo: Mobile World Congress

La primera cita que será pública será la charla en el Agora de Telefónica para dar una explicación de lo que hemos estado trabajando este año, y lo que estamos haciendo nuevo. Mucho de ello tiene que ver con lo que ya os conté de NaaS.

Figura 2: Telefonica Keynote en MWC

Será el Lunes 28 de Febrero a las 11:45 de la mañana, así que si estás por el MWC y te apetece verla, más que encantado de que estés con nosotros. El encargado de abrir la sesión será Mark Evans, y estaremos Jason Zander de Microsoft, el gran David Carmona, Pablo Benito y yo.

Figura 3: Ponentes de la Keynote de Telefónica en MWC

Luego, a lo largo del día, hablarán David del Val, Richard Benjamins, Yaiza Rubio, Irene Gómez o Carlos Ruisánchez entre otros. Toda la lista de charlas que tendremos durante el Mobile World Congress las tienes en la web que hemos creado para el evento, que estaremos en tres ubicaciones: Agora, 4YFN y GSMA.

Figura 4: Todas las ponencias de Telefónica en el MWC

Además, puedes seguir todas las charlas del Ágora desde la Living App de Agora en Movistar+, y desde el escenario digital del stand virtual de Telefónica en el MWC que tienes en AltSpaceVR. Tienes todos los detalles en la web del MWC de Telefónica.

Figura 5: Net For Dev en el 4YFN

De entre todas las charlas que damos, yo además estaré en la keynote del 4YFN para hablar de innovación sobre la red, así que la hemos titulado esa charla "Net for Dev", y será el Martes 28 de Febrero a las 10:40 en el auditorio principal del 4YFN.

2 de Marzo: Microsoft Security Tech Days en Barcelona

El jueves 2 de Marzo comienzan los Microsoft Security Tech Days, que tendrán lugar el día 2 de Marzo en Barcelona - tras la resaca del Mobile World Congress - y el 22 de Marzo en Madrid. Y son totalmente gratuitos y te puedes apuntar ahora mismo que las plazas son muy reducidas.

Figura 6: Microsoft Security Tech Days en Madrid y Barcelona

En el evento participa Microsoft, de la mano del Presidente de Microsoft Ibérica, el gran Alberto Granados, que además de dirigir una de las operaciones de Microsoft más bonitas de Europa, tiene un pasado de desarrollador en la casa, y de trotamundos, ya que ha estado liderando proyectos por todo el mundo. Da gusto oírle hablar.

Figura 7: Alberto Granados y Alberto Pinedo de Microsoft Ibérica

como ponentes de los Microsoft Security Tech Days

Pero estará bien acompañado por Alberto Pinedo, que tiene el rol de National Technology Officer, o lo que es lo mismo, la persona responsable de acompasar desde Microsoft todos los proyectos y preocupaciones que como país tenemos. Un rol tan importante en la estandarización de las tecnologías, como en el avance de nuestra sociedad acercando posturas de administración pública, sociedad y una empresa tan relevante para todos como Microsoft.

Figura 8: Pre-registro para el CyberSecurity Tech Day en Barcelona

2 de Mazo de 2023.

Además de ellos, tendremos también a ESET, Paradigma y Plain Concepts, que hablarán de Threat Intelligence para completar las soluciones de seguridad con las que se cuenta en las plataformas de Cloud Computing de Microsoft Azure, de la transformación digital de las empresas para crear Modern Apps que sena Cloud Native y que no adolezcan de problemas de seguridad clásicos en los sistemas legados, y de cómo construir soluciones a prueba de balas con las tecnologías de seguridad en Microsoft Azure en entornos de Cloud.

Figura 9: ESET, Plain Concepts & Paradigma en los

Microsoft Security Tech Days

Y también me toca a mí, que hablaré de Innovación en Seguridad, del mundo de la Inteligencia Artificial, las tecnologías Web3, el Cloud Computing y el trabajo que durante años hemos hecho en ElevenPaths - ahora parte de nuestra querida Telefónica Tech - para adaptarnos constantemente a los nuevos entornos, las nuevas tecnologías y las nuevas estratagemas de los tipos malos.

2 de Marzo: Horizonte

Y tras acabar mi periplo por Barcelona, regreso a Madrid, para participar junto a Iker Jiménez en su programa Horizonte, que se lo he prometido. Ya sabéis que he ido un par de veces para hablar de los Virtual Replicants y de las cámaras de Super High Definition, y este jueves que viene volveré a participar. Así que si pones la televisión para ver el programa me verás por ahí.

asas

Ver esta publicación en Instagram

Una publicación compartida de Chema Alonso (@chemaalonso)

Y eso es todo, que además de todas esas cosas, también escribiré en el blog todos los días, y haré muchas otras cosas, pero eso ya lo sabéis. Si alguna de las que hago públicamente os interesa, feliz por ello, y nos vemos en ellas.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Blade Runners: Cómo crear un Test de Voight-Kampff para DeepFakes (Parte 3 de 3)

Para esta última parte, vamos a ver tres investigaciones más para detectar Virtual Replicants, luego veremos cómo estamos haciendo la herramienta del Test de Voight-Kampff para detectar DeepFakes, con dos vídeos de ejemplo, y por último veremos algunas pinceladas de qué tenemos por delante. A ver si os gusta este mundo en el que estamos entrando.

Figura 21: Blade Runners: Cómo crear un Test de Voight-Kampff para DeepFakes

Imagen: Boceto de la máquina Voight-Kampff (Parte 3 de 3). Fuente:

Wikipedia. Autor: De Bernard Goldbach from Cashel, Ireland - Smell Fear, CC BY 2.0,  

Vamos ver, antes de ver la herramienta en funcionamiento, tres estudios más que dan nuevas herramientas para reconocer el uso de una DeepFake, vamos a ello.

2018 - Gray Histograms

En el año 2020 se publicó el artículo académico "Detecting DeepFake Videos: An analysis of three techniques", donde se ponía en práctica el uso de tres parámetros conjuntamente para saber si un vídeo es o no una DeepFake. En este caso se usaban de forma combinada los artefactos que dejan como huellas las herramientas de generación de DeepFakes (CNN+RNN), el Blink de los párpados de las personas, y una de la que no hemos hablado hasta el momento, la evolución de los histogramas en escala de grises en cada uno de los fotogramas.

Figura 22: Detecting DeepFAke Videos.

An Analysis of Three Techniques.

Todas estas técnicas, podrían utilizarse en un análisis forense de vídeos, pero también en tiempo real. En el análisis hecho en este artículo se puede ver cómo, en los resultados obtenidos con el dataset utilizado, generó buenos resultados en el análisis de histogramas de tonos de gris.

Figura 23: Resultados de las tres técnicas

La técnica de análisis de Histograma de grises, se basa en otro artículo, publicado en el año 2018, titulado "Detecting GAN-Generated Imagery using Color Clues", que aplicaba esta técnica imagen a imagen, buscando cómo se generan los histogramas en las imágenes hechas con técnicas de DeepFakes.

Figura 24: Detecting GAN-Generated Imagery using Color Clues

Según el estudio, las imágenes generadas por herramientas GAN no tienen zonas de saturación, aunque tengan fondos de color blanco, lo que es un buen indicio para detectar la DeepFake.

2018 - Head Poses

Otra de las técnicas utilizadas, es la relativa al análisis de estructuras físicas de las poses de la cabeza. Reconstruir una cara con movimientos en tres dimensiones es un problema de triangulación complejo para ser realizado en imágenes rasterizadas. Es decir, las imágenes generadas por GAN se basan en imágenes rasterizadas, pero no realizan primero una triangulación volumétrica de la cabeza para resolver el problema.

Figura 25: Exposing Deep Fakes using inconsistent Head Poses

Haciendo una aproximación contraria, es decir, triangular las imágenes de todas las posiciones, permite detectar cuándo la estructura volumétrica ha cambiado de un fotograma a otro, generando una alerta de seguridad que permita detectar una DeepFake.

Figura 26: Detección de un Head Pose inconsistente la volumetría de una DeepFake

Como se puede ver en la imagen, se puede triangular volumétricamente en tiempo real una imagen para poder detectar las incosistenncias que se generan en las DeepFakes.

2020 - Exposing GAN-generated Faces Using Inconsistent Corneal Specular Highlights

En el año 2020 se presentó un modelo entrenado con reflejos en iris reales y falsos creados con DeepFakes, donde se comprueba la simetría del reflejo extraído además de su forma comparándolo con el resto de reflejos del modelo generado anteriormente.

Figura 27: Exposing GAN-Gnerated Faces Using Inconsistent Corneal Specular Highlighs

Este modelo detecta el reflejo en la luz en el iris de las personas y busca las DeepFakes, ya que las imágenes generadas por GANs generan reflejos diferentes a los de un reflejo real, y es un indicio relevante para detectar a los Virtual Replicants.

Figura 28: Los puntos de reflejo en ojos reales tienen una similitud superior al 60%

Como se puede ver, se miran lo ojos, se revisan los puntos de reflejo y se comprueba si son similares en los dos ojos. En los ojos reales, los puntos coinciden en más de un 60%. Si el ratio de coincidencia es bajo (<30%) entonces son sintéticos.

3.- Test de Voight-Kampff para DeepFakes

Para acabar de tener nuestro Test de Voight-Kampff para DeepFakes, estamos creando una herramienta que procesa las imágenes de una sesión de Microsoft Teams, desde la Webcam, o de un vídeo, y procesa todos los análisis que hemos ido viendo. Aún no tenemos todos implementados, pero estamos en ellos, y cuando estén terminados liberaremos la herramienta. En este primer vídeo podéis ver cómo funciona con personas reales.

Figura 29: Demo del Test de Voight-Kampff con humanos

En ese primer vídeo hemos visto cómo se aplica a humanos de verdad, a través de una sesión de Microsoft Teams o en vídeo, y en el siguiente vais a ver cómo funciona de igual forma con vídeos de DeepFakes, de las muy conocidas, para ver cómo funcionan.

Figura 30: Demo del Test de Voight-Kampff con DeepFakes

Como véis, aún no tenemos todos los tests implementados en la herramienta, y además nos quedan muchas más cosas por añadir que aún están en fase de investigación, como la personalización, o todo el tratamiento del audio, la conversación, y las nuevas técnicas que se van publicando día a día. Como habéis podido ver, no todos los tests son concluyentes, y cuando hay post-producción algunos de los artefactos de las herramientas de generación de DeepFakes desaparecen, pero este es el juego del gato y el ratón. Mejores herramientas de generación de DeepFakes obligan a mejores herramientas de detección de DeepFakes. Os iremos contando más cosas según podamos.

Autores: Chema Alonso, Pablo González, Fran Ramírez

******************************************************************************************

- Blade Runners: Cómo crear un Test de Voight-Kampff para DeepFakes (Parte 1 de 3)

- Blade Runners: Cómo crear un Test de Voight-Kampff para DeepFakes (Parte 2 de 3)

- Blade Runners: Cómo crear un Test de Voight-Kampff para DeepFakes (Parte 3 de 3)

******************************************************************************************

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)