Con cantidades cada vez mayores de datos valiosos almacenados en la nube, es aún más importante que estén protegidos de forma robusta. Unas medidas de seguridad sólidas en torno a los servicios de datos en la nube, como iCloud, benefician a todos: usuarios finales, proveedores de servicios en la nube como Apple y plataformas de ecosistema como Reincubate.
Los mecanismos para proteger estos datos adoptan varias formas, y el historial de Apple a la hora de implementarlos ha sido bueno. Este artículo examina varias de las técnicas que ellos, y el equipo de Reincubate, han estado usando.
Almacenar menos, si es posible
En primer lugar, almacenar menos en lugar de más da resultado. Hay ejemplos en los que los datos nunca se han almacenado en iCloud, como cuando los datos de reconocimiento facial de Fotos no se guardan en «Fototeca de iCloud», sino que se almacenan en caché localmente. Los datos de HealthKit, HomeKit y Touch ID de Apple reciben un trato similar, igual que los datos de reconocimiento facial de la pantalla de bloqueo de Android. Por supuesto, a menudo se trata de un equilibrio entre la comodidad y el valor de sincronizar esos datos entre dispositivos. Algunos sistemas usan un enfoque parcial. Por ejemplo, iMessage almacena en la nube una cantidad limitada de contenido, pero depende de que otros datos se sincronicen directamente entre dispositivos.
Los sistemas de mensajería segura como Telegram o WhatsApp adoptan un enfoque completamente distinto. Como no se almacenan datos en sus servidores (o al menos, no muchos), cualquier copia de seguridad de un dispositivo debe incluir un conjunto rico de datos para que el usuario pueda hacer copias y restaurarlas de forma útil. En cierto modo, para mantener la seguridad, esos proveedores de apps se lavan las manos de la gestión de esos datos y se la dejan al usuario final, que puede optar por hacer copias de seguridad de sus dispositivos de forma local o en la nube.
Así pues, hay dos extremos, y se puede contrastar WhatsApp, con poco en la nube y todo en la copia de seguridad, con Facebook Messenger, que no guarda nada en la copia de seguridad del dispositivo porque está disponible en la nube, y tiene que estarlo para que Facebook pueda ofrecer su interfaz web.
No hay una solución correcta, pero conviene pensarlo: usar una app que aloja estos datos exige que el proveedor de la app los gestione de forma segura, y a menudo se deja a los usuarios sin saber qué se almacena y cómo. Usar una app que no almacena datos de forma centralizada significa que el usuario final debe responsabilizarse de la seguridad de sus propios datos de copia de seguridad, a menos que deje que se almacenen en la nube de su plataforma, como ocurre con las copias de seguridad de iCloud y las copias de dispositivos con Android 7.0 o posterior de Google.
Curiosamente, como se ve en el gráfico siguiente, algunos fabricantes de apps ocupan ambos extremos de esta posición. La app de Snapchat almacena casi todos sus datos en la nube, mientras que la extensión física de la app, las Spectacles, almacenan todos sus datos localmente en el dispositivo.
Distintos enfoques de la seguridad de los datos de apps
Aunque no se han lanzado de forma generalizada, las Snapchat Spectacles son bastante inseguras: manteniendo pulsado el botón de «snap» durante siete segundos, un hacker puede emparejarlas con un teléfono nuevo y obtener cualquiera de los snaps sin cifrar que el legítimo propietario hubiera almacenado en ellas. Esto contrasta de forma notable con los principios de seguridad adoptados para el Apple Watch.
Cifrado fuerte
Eso nos lleva a la segunda técnica crítica: el cifrado fuerte, idealmente con almacenamiento incompleto de las claves. Si se considera que los datos son demasiado sensibles para guardarlos en una copia de seguridad a la que se pueda acceder si el dispositivo se destruye o se reemplaza, hay otras técnicas que se pueden usar. Al exigir el uso de un dispositivo concreto, la función «Secret Conversations» de Facebook usa identificadores de hardware para cifrar el contenido. Si el dispositivo se pierde, el contenido se vuelve prácticamente irrecuperable.
Algunos sistemas emplean una técnica similar en la que se puede crear un token específico del dispositivo para garantizar que solo un número limitado de dispositivos pueda acceder al contenido a la vez. Snapchat y WhatsApp usan cada uno una variante de esto. Al iniciar sesión en Snapchat en un dispositivo, se crea un token que comparten los servidores de Snapchat y el dispositivo. Si el mismo usuario inicia sesión en otro dispositivo, se creará un token nuevo que reemplaza al que había antes en la nube y obliga al primer dispositivo a cerrar sesión, ya que no podría descifrar los mensajes entrantes. Esta técnica tiene una vulnerabilidad evidente cuando se usa en sistemas inseguros: el token se puede copiar y usar en otro lugar. Si hiciera falta un argumento para explicar por qué usar un dispositivo Android con root o un dispositivo iOS con jailbreak es una pésima idea, es este, y también explica por qué es improbable que Snapchat tenga pronto un cliente web.
Una cosa es perder potencialmente mensajes secretos de Facebook, pero algunos datos son a la vez muy sensibles y muy valiosos para su propietario. Parece contraintuitivo, pero si el valor personal de los datos es lo bastante grande, a menudo se almacenan de forma que haya muchas maneras posibles de descifrarlos o recuperarlos. Esto sacrifica seguridad a cambio de reducir las dificultades prácticas. Por ejemplo, hay una gran cantidad de datos asociados a las cuentas de iCloud y de Google, incluido, en ambos casos, algún tipo de llavero distribuido en la nube que almacena todas las contraseñas del usuario. Y no solo eso: como Google promueve sus cuentas como mecanismo de autenticación en otros sitios mediante OAuth, perder de forma irrecuperable el acceso a cuentas como estas sería un trago muy amargo.
Dado que estas cuentas se consideran demasiado valiosas para arriesgarse a perderlas de forma permanente, se usa una solución intermedia en la que los datos se almacenan en la nube, pero cifrados con un token o una contraseña que solo conserva el usuario y que no se almacena. Por eso, por ejemplo, al iniciar sesión en una instalación nueva del navegador Chrome de Google, las contraseñas almacenadas en la nube no están disponibles hasta que se introduce en el navegador una contraseña de sincronización secundaria.
Compartir la carga del cifrado
Tim Cook, de Apple, que es serio y tiene fundamentalmente razón en materia de seguridad, dio fe de su creencia en esta técnica solo el año pasado:
For many years, we have used encryption to protect our customers’ personal data because we believe it’s the only way to keep their information safe. We have even put that data out of our own reach, because we believe the contents of your iPhone are none of our business.
— Tim Cook en «A Message to Our Customers»
Entre otras cosas, esto puede ayudar a los proveedores de la nube a evitar revelar los datos completos de los usuarios a las autoridades. Si una orden judicial los obliga a facilitarlos, pueden hacerlo sin exponer directamente los datos del usuario, ya que los datos requieren un descifrado adicional que solo se puede hacer con una clave que únicamente tiene el usuario final.
A veces, como en el caso de la autenticación multifactor (MFA), la autenticación de dos factores (2FA) o la verificación en dos pasos (2SV), esto significa que la clave adicional solo se puede enviar a un dispositivo concreto o generarse en él. Los bancos y las VPN suelen usar lectores de tarjetas físicos o generadores de semillas seguros, que son formas de generadores de contraseñas de un solo uso basados en el tiempo (OTP o TOTP). Tanto Google como Apple ofrecen MFA sencilla basada en SMS y sistemas completos de 2FA; el de Google usa HOTP/OATH y el de Apple es propietario.
Cuando los organismos de seguridad o las fuerzas del orden (LEA) tienen estos datos cifrados pero no la clave del usuario final para descifrarlos, pueden intentar un ataque de fuerza bruta con máquinas potentes que prueban los datos con contraseñas adivinadas automáticamente. El iOS de Apple tiene aquí una enorme ventaja sobre el Android de Google: como Apple controla estrechamente el hardware de sus dispositivos, puede diseñar técnicas de cifrado que solo su hardware puede realizar con rapidez y que otros dispositivos, como los ordenadores de sobremesa, realizan con lentitud. Cuando Reincubate se convirtió en la primera empresa del mundo en admitir el descifrado de datos de la versión 10.2, lo importante no era solo que la empresa fuera la primera en entender cómo funcionaba la 10.2, sino que fuimos los primeros en escalar el descifrado rápido de la ingeniosa técnica de Apple. Al hacer que cada intento de descifrado tarde varios segundos en hardware convencional, se volvió impracticable para hackers o fuerzas del orden hacerlo por fuerza bruta.
Seguridad por oscuridad
No sería adecuado repasar estas técnicas sin mencionar una en la que Apple es especialmente buena: la seguridad por oscuridad. Al no publicar API públicas, documentación detallada ni siquiera comunicar mucho sobre estos sistemas, la empresa consigue no alertar a los hackers de posibles vectores de ataque. Durante mucho tiempo, el argumento en contra de la oscuridad fue que la divulgación y el código abierto daban mejores resultados de seguridad, pero eso fue antes de que en 2014 se descubriera que OpenSSL, una biblioteca de seguridad de código abierto crítica que prácticamente todo el mundo usa, era, y casi siempre había sido, fundamentalmente insegura.
Ponte en contacto con nosotros si quieres explorar formas de trabajar con datos de apps o de la nube, o si te interesa comprender mejor la dinámica de los distintos enfoques.
