iOS Basics
Separación de Privilegios y Sandbox
En iOS, existe una distinción de privilegios entre las aplicaciones accesibles para el usuario y los procesos fundamentales del sistema. Las aplicaciones se ejecutan bajo la identidad de usuario mobile, mientras que los procesos esenciales del sistema operan como root. Esta separación se ve reforzada por un mecanismo de sandbox, que impone estrictas limitaciones sobre las acciones que las aplicaciones pueden realizar. Por ejemplo, aunque las aplicaciones compartan la misma identidad de usuario, se les prohíbe acceder o modificar los datos de otras aplicaciones.
Las aplicaciones se instalan en un directorio específico (private/var/mobile/Applications/{ID aleatorio}) y tienen acceso de lectura restringido a ciertas áreas y funcionalidades del sistema, como los SMS y las llamadas telefónicas. El acceso a áreas protegidas desencadena una solicitud emergente de permiso del usuario.
Protección de Datos
iOS ofrece a los desarrolladores las API de Protección de Datos, construidas sobre el Procesador de Recinto Seguro (SEP) — un coprocesador dedicado para operaciones criptográficas y gestión de claves. El SEP garantiza la integridad de la protección de datos mediante una clave única específica del dispositivo, el UID del dispositivo, incrustado en él.
Al crear un archivo, se genera una clave de cifrado AES única de 256 bits, que cifra el contenido del archivo. Esta clave de cifrado, junto con un ID de clase, se cifra luego usando una clave de clase y se almacena dentro de los metadatos del archivo. Descifrar un archivo implica usar la clave del sistema para acceder a los metadatos, recuperar la clave de clase con el ID de clase y luego descifrar la clave de cifrado única del archivo.
iOS define cuatro clases de protección para la seguridad de datos, que determinan cuándo y cómo se puede acceder a los datos:
Protección Completa (NSFileProtectionComplete): Los datos son inaccesibles hasta que el dispositivo se desbloquee usando el código de acceso del usuario.
Protegido a menos que se abra (NSFileProtectionCompleteUnlessOpen): Permite el acceso al archivo incluso después de que el dispositivo esté bloqueado, siempre que el archivo se haya abierto cuando el dispositivo estaba desbloqueado.
Protegido hasta la primera autenticación del usuario (NSFileProtectionCompleteUntilFirstUserAuthentication): Los datos son accesibles después del primer desbloqueo del usuario después del arranque, y siguen siendo accesibles incluso si el dispositivo se bloquea nuevamente.
Sin Protección (NSFileProtectionNone): Los datos solo están protegidos por el UID del dispositivo, facilitando un borrado rápido de datos remoto.
El cifrado de todas las clases, excepto NSFileProtectionNone, implica una clave derivada tanto del UID del dispositivo como del código de acceso del usuario, asegurando que el descifrado solo sea posible en el dispositivo con el código de acceso correcto. Desde iOS 7 en adelante, la clase de protección predeterminada es "Protegido hasta la primera autenticación del usuario".
Los desarrolladores pueden utilizar FileDP, una herramienta para inspeccionar la clase de protección de datos de archivos en un iPhone.
El Portafolio de Claves
En iOS, un Portafolio de Claves sirve como un contenedor seguro encriptado para almacenar información sensible, accesible solo por la aplicación que la almacenó o por aquellas autorizadas explícitamente. Esta encriptación está fortalecida por una contraseña única generada por iOS, la cual está encriptada con AES. Este proceso de encriptación aprovecha una función PBKDF2, combinando el código de acceso del usuario con una sal derivada del UID del dispositivo, un componente al que solo puede acceder el chipset del enclave seguro. En consecuencia, incluso si se conoce el código de acceso del usuario, el contenido del Portafolio de Claves permanece inaccesible en cualquier dispositivo que no sea aquel donde se encriptaron originalmente.
El manejo y acceso a los datos del Portafolio de Claves son gestionados por el demonio securityd, basado en permisos específicos de la aplicación como Keychain-access-groups y application-identifier.
Operaciones de la API del Portafolio de Claves
La API del Portafolio de Claves, detallada en la documentación de Servicios de Portafolio de Claves de Apple, proporciona funciones esenciales para la gestión segura del almacenamiento:
SecItemAdd: Agrega un nuevo elemento al Portafolio de Claves.SecItemUpdate: Actualiza un elemento existente en el Portafolio de Claves.SecItemCopyMatching: Recupera un elemento del Portafolio de Claves.SecItemDelete: Elimina un elemento del Portafolio de Claves.
Forzar la contraseña del Portafolio de Claves implica atacar directamente la clave encriptada o intentar adivinar el código de acceso en el propio dispositivo, dificultado significativamente por la imposición de un retraso entre intentos fallidos por parte del enclave seguro.
Configuración de la Protección de Datos del Elemento del Portafolio de Claves
Los niveles de protección de datos para los elementos del Portafolio de Claves se establecen utilizando el atributo kSecAttrAccessible durante la creación o actualización del elemento. Estos niveles, como se especifica por Apple, determinan cuándo y cómo los elementos del Portafolio de Claves son accesibles:
kSecAttrAccessibleAlways: Accesible en todo momento, independientemente del estado de bloqueo del dispositivo.kSecAttrAccessibleAlwaysThisDeviceOnly: Siempre accesible, pero no incluido en copias de seguridad.kSecAttrAccessibleAfterFirstUnlock: Accesible después del primer desbloqueo posterior al reinicio.kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly: Igual que el anterior, pero no transferible a nuevos dispositivos.kSecAttrAccessibleWhenUnlocked: Solo accesible cuando el dispositivo está desbloqueado.kSecAttrAccessibleWhenUnlockedThisDeviceOnly: Accesible cuando está desbloqueado, no incluido en copias de seguridad.kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly: Requiere código de acceso del dispositivo, no incluido en copias de seguridad.
AccessControlFlags refinan aún más los métodos de acceso, permitiendo la autenticación biométrica o el uso de un código de acceso.
Advertencia sobre Dispositivos con Jailbreak
En los dispositivos con jailbreak, las protecciones del Portafolio de Claves se ven comprometidas, representando un riesgo de seguridad significativo.
Persistencia de los Datos del Portafolio de Claves
A diferencia de los datos específicos de la aplicación eliminados al desinstalar la aplicación, los datos del Portafolio de Claves persisten en el dispositivo. Esta característica podría permitir a los nuevos propietarios de un dispositivo de segunda mano acceder a los datos de la aplicación del propietario anterior simplemente reinstalando aplicaciones. Se recomienda a los desarrolladores borrar proactivamente los datos del Portafolio de Claves al instalar la aplicación o durante el cierre de sesión para mitigar este riesgo. Aquí tienes un ejemplo de código Swift que muestra cómo borrar los datos del Portafolio de Claves al iniciar la aplicación por primera vez:
Capacidades de la aplicación
En el ámbito del desarrollo de aplicaciones, el sandboxing juega un papel crucial en mejorar la seguridad. Este proceso asegura que cada aplicación opere dentro de su propio directorio único, evitando así el acceso a archivos del sistema o datos pertenecientes a otras aplicaciones. La aplicación de estas restricciones se lleva a cabo a través de políticas de sandbox, que forman parte del Trusted BSD (MAC) Mandatory Access Control Framework.
Los desarrolladores tienen la capacidad de configurar ciertas capacidades o permisos para sus aplicaciones, como Protección de Datos o Compartir Llaveros. Estos permisos se aplican inmediatamente después de la instalación de la aplicación. Sin embargo, para acceder a ciertos recursos protegidos, la aplicación debe obtener el consentimiento explícito del usuario en el momento del primer intento. Esto se logra mediante el uso de cadenas de propósito o cadenas de descripción de uso, que se presentan a los usuarios en una alerta de solicitud de permiso.
Para aquellos con acceso al código fuente, la verificación de los permisos incluidos en el archivo Info.plist se puede hacer mediante:
Abrir el proyecto en Xcode.
Localizar y abrir el archivo
Info.plist.Buscar claves con prefijo
"Privacy -", con la opción de ver claves/valores en bruto para mayor claridad.
Al tratar con un archivo IPA, se pueden seguir los siguientes pasos:
Descomprimir el IPA.
Localizar el archivo
Info.plistdentro dePayload/<nombreapp>.app/.Convertir el archivo a formato XML si es necesario, para una inspección más fácil.
Por ejemplo, las cadenas de propósito en el archivo Info.plist podrían verse así:
Capacidades del Dispositivo
El archivo Info.plist de una aplicación especifica las capacidades del dispositivo que ayudan a la App Store a filtrar aplicaciones según la compatibilidad del dispositivo. Estas se definen bajo la clave UIRequiredDeviceCapabilities. Por ejemplo:
Este ejemplo indica que la aplicación es compatible con el conjunto de instrucciones armv7. Los desarrolladores también pueden especificar capacidades como nfc para asegurarse de que su aplicación solo esté disponible en dispositivos que admitan NFC.
Entitlements
Entitlements son otro aspecto crítico del desarrollo de aplicaciones iOS, sirviendo como pares clave-valor que otorgan a las aplicaciones permiso para realizar ciertas operaciones más allá de las verificaciones en tiempo de ejecución. Por ejemplo, habilitar Protección de Datos en una aplicación implica agregar un entitlement específico en el proyecto Xcode, que luego se refleja en el archivo de entitlements de la aplicación o en el archivo de provisión móvil incrustado para IPAs.
Referencias
Última actualización