En 2015, con mil millones de teléfonos Android activos, sólo el 0,15% había instalado aplicaciones potencialmente peligrosas (PHA’s) dentro de Google Play. Un 0,5% había instalado software malicioso en tiendas no autorizadas.
En 2016, con 2.000 millones de sistemas Android, este índice descendió hasta el 0,04%. En 2017, hasta el 0,02%.
¿Qué nos dicen estos datos? Según la propia Google, que es más fácil que un meteorito golpee la Tierra que descargarse una PHA. Que Google realiza unos 500 millones de exploraciones diarias buscando cualquier forma de software malicioso. Estamos vigilados, es evidente. Y, qué menos, también estamos protegidos.
Comunicación, implementación, verificación
Pero, ¿cuántas horas y departamentos están implicados en blindar la seguridad de un smartphone? Como nos apunta Rubén Díaz Vega, Ingeniero Software y Manager en Integración Android para BQ, no hay una pauta estricta. Dentro del skill del producto todos los departamentos operan en paralelo y «en torno a un 20% de los equipos de Hardware y Software trabajan de forma directa o indirecta en la seguridad de los dispositivos».
Durante el proceso de desarrollo del producto, «el departamento de Mecánica ha diseñado el dispositivo; Hardware ha seleccionado el sensor y el panel que integrará. Nosotros integramos drivers para que funcione a nivel de software, QA se encarga de verificar que no se den falsos positivos o falsos negativos, y después contamos con un QA técnico que se encarga de las evaluaciones técnicas y de pasar todo tipo de certificaciones (como el CTS de Google), etc., revisando que todos los componentes funcionan correctamente»
Las pruebas llevadas a cabo por el equipo ingenieril son bastante específicas, nada de tests de estrés, «ya que las vulnerabilidades son muy específicas y los puntos de ataque también lo son. No obstante, en nuestro departamento de calidad se comprueban todas las features de seguridad de Google. Éstas incluyen una certificación específica, dentro de la certificación de Android, centrada únicamente en asegurar la seguridad en todo el software del dispositivo, desde el Kernel de Linux hasta el API de aplicaciones».
Se valida, por ejemplo, el correcto funcionamiento del sensor de huellas y su correcta integración en el subsistema de seguridad del procesador. Este departamento también se responsabiliza de garantizar «que una actualización OTA no se envía si no está firmada con las claves privadas de BQ o si no ha pasado por todos los procesos de verificación».
Y a estas pruebas se suman aquellas que distribuye gratuitamente (y exige) Google para todos los sistemas Android. La Suite de pruebas de compatibilidad o CTS. Como ya hemos explicado en otras ocasiones, esta suite verifica las API, se compone de miles de pruebas por módulos y suele llevar dos días completos de testing.
Una vez validado y aprobado aún tendrá que pasar otros tantos controles. A saber: el GTS (Google Market Suite) determina la compatibilidad para cargar la tienda y el CTS Verifier realiza pruebas en modo manual, para comprobar la operatividad de ese modelo de teléfono en concreto.
En esta serie de pruebas de hardware y software también está implicada la seguridad. Como apunta Rubén Díaz, «el propio CTS de Android tiene un submódulo específico para verificar la seguridad en todo el software del dispositivo». Y, sin ellas correctamente certificadas, el teléfono no puede aparecer con el logo de Android en la caja.
Buscando responsables
Entonces, si se nos cuela un virus desde una nueva app de la Google Play Store, ¿de quién es la culpa? «Es muy complicado que se nos cuelen virus con las aplicaciones de Play Store. Google es muy cuidadoso en este punto», apunta Rubén.
«En el caso de que suceda algo así, son muchos los agentes involucrados que deben actuar: si ese virus llega por una vulnerabilidad en Android, Google tendrá que liberar un parche para solucionarlo. Luego el fabricante del móvil deberá trabajar para enviar una actualización con ese parche a los smartphones afectados».
¿Y el usuario? En la cadena de mando, él tiene la última palabra. Nosotros debemos vigilar y mantener actualizado el dispositivo en la última versión y evitar modificaciones en el firmware, como rootearlo. Si un usuario desbloquea las credenciales del superusuario, accede al root, transita una store alternativa y empieza a descargar cualquier app —los clásicos .apk sin firmar—, los problemas son responsabilidad directa del mismo.
En los tutoriales nos explican cómo podemos acceder a estas credenciales. Sabemos que podemos hacerlo accediendo a Ajustes > Información del teléfono (Acerca del teléfono) y pulsar 7 veces seguidas sobre el ‘Número de compilación’, un build number que incluye datos de la versión del SO, la rama de código de la versión, fecha y tipo de versión exacta aplicada por parte del desarrollador del teléfono. Pero tal vez ignoramos las implicaciones que ofrece esa “puerta trasera”.
Cuando instalamos una app también estás instalando un gestor de permisos. El usuario elige a qué nivel abrir o no abrir esa puerta. «Si bajas sólo aplicaciones de PlayStore, los permisos están controlados, a nivel de Linux, cada aplicación corre en un proceso, etcétera», señala Rubén. Cuando hacemos una foto en WhatsApp por primera vez te piden permiso para acceder a la cámara, por ejemplo. Todo está controlado».
En todo caso, los fabricantes son responsables de integrar los parches de seguridad de Google lo antes posible; los usuarios han de dar el “ok final”. ¿Y dónde es más habitual encontrar una brecha, en el software de los subsistemas o a través del propio OS?
«Por su tamaño, en el propio sistema operativo. Por ello Google publica boletines de seguridad mensuales con parches que todo fabricante debe incluir en las siguientes actualizaciones. De aquí la importancia de estar siempre actualizado». BQ, por su parte, está comprometida a actualizar los dispositivos con los parches de seguridad hasta 90 días después de que Google los libere.
Trabajo en equipo
El fabricante y sus departamentos de Ingeniería y Seguridad ocupan un lugar capital en la cadena de comunicación: integran el AOSP (Android Open Source Project), pero además colaboran en el mantenimiento y testeo.
Como apuntaba Elena Kovakina para Wired, analista de malware en Android, «existe una idea equivocada de que en Android Security sólo observamos las aplicaciones que se envían a Google Play». Google Play Protect y otros servicios de detección recopilan datos generales, «incluso con terceros como bancos», simulando distintos escenarios de ataque.
De hecho, esta minería de datos se lleva a cabo con el terminal offline. En el informe citado en la cabecera, de las casi 39 millones de aplicaciones potencialmente peligrosas detectadas, el 35% se detectó en terminales sin conexión a Internet. 10 millones de intentos de vulnerar el sistema bloqueados sin necesidad de acceder a redes. ¿Cómo? Mediante el paquete de medidas de protección de Google Play Protect. Evidentemente, esta recolección suma todo tipo de datos.
Esta capa de seguridad adicional se sirve de dos grandes fortalezas: Inteligencia Artificial (machine learning) y algoritmos criptológicos ya implementados. Google Play Protect se actualiza periódicamente, sin necesidad de esperar a una actualización OTA.
Hasta el 60,3% de los PHAs identificados fueron llevados a cabo gracias al machine learning, una inteligencia que evoluciona y mejora con cada actualización. Google Play Protect es el antivirus total: al ser nativo de la plataforma, su impacto y consumo de recursos sobre la CPU es ínfima. Además, los plazos de comunicación se acortan, frente a dar soporte a bases de datos de terceros.
Al otro lado del escenario está el fabricante del procesador (CPU/GPU y demás componentes del system-on-chip). En el caso de BQ, el responsable es Qualcomm: «BQ tiene comunicación directa tanto con Qualcomm como con Google, de manera que todo el feedback que obtenemos de nuestros propios procesos de calidad, nuestros programas beta y nuestros usuarios finales, se reporta y se trabaja directamente con ellos».
Pero esta comunicación no comprende todas las líneas de desarrollo: «muchas features de seguridad sólo recaen sobre Qualcomm. Ellos y nadie más debe poseer el código fuente de esas features de seguridad. Nosotros simplemente lo integramos y nos responsabilizamos de hacer que funcione».
Si, por ejemplo, una feature bloquea el terminal tras “demasiados intentos de desbloqueo con huella”, «Qualcomm no quiere que puedas modificar los parámetros para subir de 10 a 1.000 intentos», comprometiendo así la cadena de certificaciones y poniendo en peligro los fundamentos de seguridad del sistema.
¿Necesitamos un Avast (u otro antivirus) en el smartphone?
La mejor forma de fortalecer la seguridad no es a través de un antivirus. Como ya apuntamos en Xataka hace dos años (¿Es realmente necesario instalar un antivirus en Android?), «los antivirus perjudican en gran medida el rendimiento de tu Android y tienen más desventajas que ventajas».
En cambio, otras medidas sí son efectivas y necesarias, como las redes de conexión privada (VPN) ante una red Wi-Fi abierta. «Cuando utilizas una VPN, la información sale cifrada de tu dispositivo y sólo puede ser descifrada en el punto de acceso de tu VPN. Tu información personal viaja cifrada a través de la red WiFi abierta a la que estás conectado», nos recuerdan desde BQ.
Las redes abiertas deben redirigir siempre a una pasarela de login. Si nos conectamos y dan acceso inmediato, debemos sospechar. Sencillamente, porque «el https debe estar certificado». Tal vez un VPN ralentice la navegación. Recordemos que el tráfico no va directo hasta el servidor, sino que viaja al servidor del VPN. Más bits, más viajes. Pero más seguridad, al fin y al cabo.
Existen ayudas muy atractivas: NordVPN redirige y encripta el tráfico para obtener una conexión cifrada y segura. Orbot es un proxy gratuito que usa Tor para encriptar el tráfico de Internet. Apps como Secure Mail usan encriptación por contraseña. Signal proporciona cifrado de extremo a extremo para asegurar todas las comunicaciones.
Mirando a un horizonte (seguro)
No todo es de color de rosa, más bien de rojo: el ransomware subió hasta un 150% durante 2017. El reto de acelerar las metodologías siempre estará presente. Aunque no sería práctico en términos de usuario, la computación cuántica puede mandar al traste el SHA-2 y la encriptación 40-512 bits, porque los sistemas alcanzarán un nuevo techo en operaciones por segundo. Uno que podrá hacer saltar por los aires modelos actuales.
La seguridad es reactiva y el usuario tendrá que formar parte de esta cadena, mediante identificación de dos pasos, navegadores seguros, VPN en redes WiFi, etcétera. Por suerte, los sistemas cerrados son más seguros. Android (y el core de Linux, por extensión) plantea ventajas frente a un PC convencional: «manteniéndote actualizado, no modificando el firmware original y descargando sólo aplicaciones de sitios confiables» estaremos presumiblemente protegidos.
De facto, somos el eslabón más débil de cadena: los usuarios no tenemos por qué ser expertos en ciberseguridad.
En nuestras pautas para evitar el criptojacking no podemos aportar mucho más: «utilizar navegadores confiables, como Chrome o Firefox, y no acceder a páginas web catalogadas como “no seguras”. Por ejemplo con SafeBrowsing Google mantiene una base de datos enorme de páginas web con contenido malicioso. Gracias a su API pública, cualquier aplicación puede consultar una URL antes de mostrarla al usuario, advirtiéndole en el caso de que no sea fiable. Sólo Chrome muestra en torno a 1 millón de avisos al mes», nos informa Rubén Díaz.
Y del reconocimiento de huella dactilar a los escáneres de retina, incluso sudor o faciales, los modelos de seguridad del futuro más inmediato no hará sino desarrollar nuevas capas.
La seguridad del futuro pasará por «procesadores también más seguros que añadirán más funcionalidad a los desarrolladores para implementar nuevas funcionalidades. También aparecerá una nueva algoritmia o implementaciones basadas en machine learning que usará patrones de uso del móvil para identificar a su dueño. Y llegará un nuevo hardware biométrico, como ha sido el caso del FaceID en el iPhone X».