La evaluación de un dispositivo móvil seguro para un entorno de defensa gubernamental suele comenzar en el nivel equivocado. Las aplicaciones de mensajería se comparan en función de su protocolo criptográfico, el «Double Ratchet» de Signal frente a alternativas propietarias, mientras que el sistema operativo subyacente se da por sentado. Para un modelo de amenazas que incluye plataformas comerciales de spyware (por ejemplo, «Pegasus» de NSO Group, «Graphite» de Paragon, etc.) diseñadas específicamente para explotar iOS y Android a gran escala, eso es un error. El sistema operativo es la superficie de ataque contra la que se diseñan estas herramientas, lo que hace que el protocolo de la capa de la aplicación resulte en gran medida irrelevante si la plataforma subyacente se ve comprometida.
Las opciones para implementar teléfonos móviles seguros suelen clasificarse en tres categorías arquitectónicas:
Modos de restricción de funciones en iOS/Android de serie (modo de bloqueo de Apple, modo de protección avanzada de Android): desactivan una serie definida de funciones propensas a ataques (análisis de archivos adjuntos en mensajes, compilación JIT en el navegador, conexiones de accesorios USB con el dispositivo bloqueado) en la misma versión del sistema operativo y el mismo núcleo que utilizan todos los demás usuarios.
Derivados de Android reforzados o de arranque dual (versiones basadas en AOSP con una capa de seguridad personalizada, una política impuesta por MDM o una partición bloqueada): Estos dispositivos ofrecen una superficie de ataque reducida, pero siguen heredando el código base subyacente de AOSP y su historial de vulnerabilidades.
Arquitecturas distintas Android/iOS: una familia de sistemas operativos completamente diferente, sin código base, núcleo ni pila de controladores compartidos con los kits de explotación desarrollados para Android o iOS.
Consulta nuestra lista de los teléfonos más seguros para el sector público y las empresas para una comparación completa de plataformas específicas en estos niveles, incluyendo el Bittium Tough Mobile 2C, el Purism Librem 5, el IntactPhone y el Glacier Guardian,
El Sotera SecurePhone se sitúa en el tercer nivel: ejecuta Integrity-178B de Green Hills Software, un RTOS con certificación EAL 6+ según Criterios Comunes —el nivel de garantía más alto alcanzado por cualquier sistema operativo móvil disponible en el mercado, y utilizado en aviónica crítica para el vuelo (B-2, F-16, F-22, F-35), en sistemas de la NASA y el Departamento de Defensa de EE. UU. (DOD). Y lo que es quizás más importante, no comparte código fuente alguno con Android ni con iOS.
A continuación encuentras cuatro escenarios en los que esa distinción arquitectónica y no la solidez del cifrado en la capa de aplicaciones, determina el resultado.
El spyware «click cero» no requiere la interacción del usuario. Lo que sí requiere es un servicio de escucha accesible desde el exterior o una carga útil analizable (imagen, archivo adjunto, paquete mutado) que active una vulnerabilidad en el sistema operativo o en una aplicación con accesos. Es la clase de ataque en la que se basan Pegasus y Graphite, y es independiente de la aplicación de mensajería que utilice el objetivo.
La pila de red del SecurePhone no expone ningún puerto de escucha abierto y no acepta conexiones iniciadas desde el exterior; todas las sesiones se inician desde el dispositivo, y las llamadas y mensajes entrantes se transmiten a través del canal de salida existente del dispositivo hacia la infraestructura de Sotera. Esto fue verificado de forma independiente por Netragard durante una prueba de penetración realizada en 2022, que confirmó que no se produjo ningún descifrado, repetición ni extracción de claves con éxito en los dos SecurePhones sometidos a prueba.
Una versión reforzada de AOSP puede restringir qué aplicaciones pueden vincularse a qué puertos e imponer límites de permisos más estrictos, pero el núcleo subyacente y la pila de controladores permanecen iguales. Esto significa que cualquier vulnerabilidad de día cero que los afecte seguirá afectando a la versión reforzada de AOSP. Por otro lado, el «Modo de bloqueo» (Lockdown Mode) y el AAPM reducen determinadas rutas de código propensas a ataques (visualización previa de archivos adjuntos, FaceTime con remitente desconocido), pero dejan intacto el resto del sistema operativo y sus servicios en escucha.
La vulnerabilidad de la superficie de ataque de un componente —como un códec, un controlador o una biblioteca de análisis sintáctico— solo queda contenida si la arquitectura impone el aislamiento con ese nivel de detalle. A modo de comparación, BlastDoor de Apple desinfecta un subconjunto de procesos relacionados con la mensajería. El SecurePhone instaura el aislamiento mediante 92 particiones a nivel de hardware en el núcleo, que abarcan todos los controladores y aplicaciones del dispositivo (no solo un subconjunto), utilizando controladores reescritos y compartimentos dedicados de saneamiento/sala limpia para todos los datos entrantes no fiables: un flujo fijo que se ejecuta de forma incondicional, no como un modo opcional.
La pregunta que debe plantearse sobre cualquier dispositivo Android reforzado de la competencia es si el aislamiento se extiende a los controladores del núcleo y a los componentes del sistema, o solo a los perfiles de usuario o contenedores empresariales a nivel del sistema operativo. Las arquitecturas de arranque dual, en particular (por ejemplo, una separación reforzada entre uso personal y laboral), suelen seguir compartiendo un gestor de arranque y una capa de firmware entre ambos entornos.
Un protocolo sólido a nivel de aplicación solo es relevante si las claves que lo sustentan se gestionan adecuadamente, por lo que conviene comprender ambos aspectos conjuntamente. El SecurePhone cifra sus mensajes con las mismas primitivas que utiliza Signa: el protocolo Double Ratchet y el acuerdo de claves X3DH. Sus sesiones de voz obtienen las claves de ese mismo canal y las cifran con AEAD AES-256-GCM, mientras que su transporte de red utiliza exclusivamente TLS 1.3, sin ningún mecanismo para negociar una versión inferior de TLS, lo que descarta por completo los ataques de degradación.
El detalle que realmente determina el riesgo en este caso es la custodia de las claves: el SecurePhone genera claves privadas en el propio dispositivo, dentro de un espacio de direcciones virtual dedicado al gestor de claves, y nunca las exporta ni las deposita en custodia. Un dispositivo comprometido o dado de baja se retira en lugar de cambiarle la clave, por lo que no existe una ruta centralizada de cambio de claves a la que un adversario pueda dirigirse. La infraestructura de certificados se aprovisiona por dispositivo en fábrica, con la CA almacenada en frío en un HSM conforme a la norma FIPS 140-4 Nivel 4.
En un modelo de amenaza de Estado-nación, el origen del hardware forma parte de la superficie de ataque. Sotera se abasteció de sus PCBAs a través de un ODM más de cuatro años antes de que comenzara el desarrollo del software, y estas se enviaron como hardware ARM sin programar, sin que se tuviera conocimiento alguno del software de Sotera ni de la finalidad del dispositivo. Todo el proceso de programación, verificación y soldadura de fusibles se lleva a cabo en una única instalación estadounidense con acceso controlado y documentación de la cadena de custodia. La integridad del firmware se comprueba en cada arranque; cualquier discrepancia detiene la ejecución en lugar de recurrir a un plan alternativo.
Se trata de un modelo de garantía diferente al del fortalecimiento de software aplicado a hardware genérico con una cadena de suministro OEM estándar; vale la pena preguntar a cualquier proveedor de Android fortalecido en qué punto de su cadena de suministro se establece realmente la confianza a nivel de hardware, frente a dónde simplemente se da por sentada.
Nada de esto determina por sí solo qué dispositivo es el más adecuado; eso depende de los requisitos de la misión, las necesidades de interoperabilidad y lo que ya esté acreditado para tu entorno. Los escenarios anteriores pretenden cuestionar dónde hay que fijarse realmente: no en qué aplicación o qué algoritmo de cifrado, sino en qué sistema operativo ejecuta el dispositivo, cómo se aplica el aislamiento a nivel del núcleo, dónde residen las claves privadas y cómo se verifica la procedencia del hardware antes de que el dispositivo llegue a tus manos.