Saltar a contenido

Index

No se almacenan datos confidenciales fuera de la aplicación

Descripción

Para garantizar el almacenamiento adecuado de datos confidenciales, como credenciales de usuario, tokens de sesión y PII, los datos confidenciales no deben almacenarse fuera del contenedor de la aplicación o del almacenamiento de credenciales del sistema.

Los datos confidenciales pueden quedar expuestos a través de mecanismos IPC inseguros o filtrarse involuntariamente al almacenamiento en la nube, copias de seguridad o caché de teclado. Por lo tanto, el riesgo de perder el dispositivo móvil o que sea robado debe tener en cuenta escenarios de acceso físico.

Recomendación

iOS

En iOS, los desarrolladores pueden aprovechar la API de protección de datos de iOS para proteger los datos confidenciales. La API se basa en el Secure Enclave Processor (SEP) para proporcionar procesamiento criptográfico seguro y administración de claves.

A los archivos se les puede asignar una clase de protección que ofrece diferentes niveles de protección:

  • Protección completa (NSFileProtectionComplete): Una clave derivada del código de acceso del usuario y el UID del dispositivo protege esta clave de clase. La clave derivada se borra de la memoria poco después de que se bloquea el dispositivo, lo que hace que los datos sean inaccesibles hasta que el usuario desbloquee el dispositivo.

  • Protegido a menos que esté abierto (NSFileProtectionCompleteUnlessOpen): Esta clase de protección es similar a la protección completa, pero si el archivo está abierto cuando se desbloquea, la aplicación puede continuar accediendo al archivo incluso si el usuario bloquea el dispositivo. Esta clase de protección se utiliza cuando, por ejemplo, se descarga un archivo adjunto de correo en segundo plano.

  • Protegido hasta la primera autenticación del usuario (NSFileProtectionCompleteUntilFirstUserAuthentication): Se puede acceder al archivo tan pronto como el usuario desbloquee el dispositivo por primera vez después del arranque. Se puede acceder a él incluso si el usuario bloquea posteriormente el dispositivo y la clave de clase no se elimina de la memoria.

  • Sin protección (NSFileProtectionNone): La clave para esta clase de protección está protegida solo con el UID. La clave de clase se almacena en el "Effaceable Storage", que es una región de memoria flash en el dispositivo iOS que permite el almacenamiento de pequeñas cantidades de datos. Esta clase de protección existe para el borrado remoto rápido (eliminación inmediata de la clave de clase, lo que hace que los datos sean inaccesibles).

Todas las claves de clase excepto NSFileProtectionNone se cifran con una clave derivada del UID del dispositivo y el código de acceso del usuario. Como resultado, el descifrado solo puede ocurrir en el propio dispositivo y requiere el código de acceso correcto.

Desde iOS 7, la clase de protección de datos predeterminada es "Protegido hasta la primera autenticación del usuario".

El Keychain también puede almacenar pequeños bits de datos, como claves de cifrado y tokens de sesión. El acceso al Keychain se realiza mediante una API personalizada como:

  • SecItemAdd
  • SecItemUpdate
  • SecItemCopyMatching
  • SecItemDelete

Los datos almacenados en el Keychain están protegidos a través de una estructura de clases similar a la estructura de clases utilizada para el cifrado de archivos. Los elementos agregados al Keychain se codifican como un plist binario y se cifran con una clave AES de 128 bits por elemento en Galois/Counter Mode (GCM). Tenga en cuenta que los bloques de datos más grandes no deben guardarse directamente en el Keychain; ese es el propósito de la API de protección de datos. Puede configurar la protección de datos para los elementos del Keychain configurando la clave kSecAttrAccessible en la llamada a SecItemAdd o SecItemUpdate. Los siguientes valores de accesibilidad configurables para kSecAttrAccessible son las clases de protección de datos del Keychain:

  • kSecAttrAccessibleAlways: Siempre se puede acceder a los datos del elemento del Keychain, independientemente de si el dispositivo está bloqueado.
  • kSecAttrAccessibleAlwaysThisDeviceOnly: Siempre se puede acceder a los datos del elemento del Keychain, independientemente de si el dispositivo está bloqueado. Los datos no se incluirán en iCloud ni en una copia de seguridad local.
  • kSecAttrAccessibleAfterFirstUnlock: No se puede acceder a los datos del elemento del Keychain después de un reinicio hasta que el usuario haya desbloqueado el dispositivo.
  • kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly: No se puede acceder a los datos del elemento del Keychain después de un reinicio hasta que el usuario haya desbloqueado el dispositivo una vez. Los elementos con este atributo no migran a un nuevo dispositivo. Por lo tanto, estos elementos no estarán presentes después de restaurar desde una copia de seguridad de un dispositivo diferente.
  • kSecAttrAccessibleWhenUnlocked: Solo se puede acceder a los datos del elemento del Keychain mientras el usuario desbloquea el dispositivo.
  • kSecAttrAccessibleWhenUnlockedThisDeviceOnly: Solo se puede acceder a los datos del elemento del Keychain mientras el usuario desbloquea el dispositivo. Los datos no se incluirán en iCloud ni en una copia de seguridad local.
  • kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly: Solo se puede acceder a los datos en el Keychain cuando el dispositivo está desbloqueado. Esta clase de protección solo está disponible si se establece un código de acceso en el dispositivo. Los datos no se incluirán en iCloud ni en una copia de seguridad local.

Los AccessControlFlags definen los mecanismos con los que los usuarios pueden autenticar la clave (SecAccessControlCreateFlags):

  • kSecAccessControlDevicePasscode: Acceder al elemento mediante un código de acceso.
  • kSecAccessControlBiometryAny: Acceder al elemento mediante una de las huellas dactilares registradas en Touch ID. Agregar o eliminar una huella dactilar no invalidará el elemento.
  • kSecAccessControlBiometryCurrentSet: Acceder al elemento mediante una de las huellas dactilares registradas en Touch ID. Agregar o eliminar una huella dactilar invalidará el elemento.
  • kSecAccessControlUserPresence: Acceder al elemento a través de una de las huellas dactilares registradas (usando Touch ID) o por defecto al código de acceso.

Android

En Android, los desarrolladores pueden aprovechar varias capacidades para almacenar datos, como Shared Preferences, SQLite, almacenamiento interno y externo, pero también pueden filtrar datos a través de un mecanismo como registros (logging), copias de seguridad, caché...

Shared Preferences es una API de uso común para el almacenamiento de datos que se puede declarar con permisos de lectura para todos (world-readable). El uso inseguro de la API de Shared Preferences puede exponer datos.

SQLite es otra forma común de almacenar datos y no está encriptada. Los desarrolladores deben preferir alternativas encriptadas como SQLCipher que ofrezcan una mayor privacidad de los datos.

El almacenamiento interno está en contenedores de forma predeterminada y otras aplicaciones del dispositivo no pueden acceder a él. Sin embargo, es posible configurar los modos inseguros MODE_WORLD_READABLE y MODE_WORLD_WRITEABLE, que están ambos obsoletos.

El almacenamiento externo es legible por todos y no debe usarse para almacenar datos confidenciales. Es importante tener en cuenta que los datos almacenados fuera del contenedor de la aplicación /data/data/<package-name> no se eliminarán cuando se desinstale la aplicación.

Android KeyStore y KeyChain proporcionan un almacenamiento seguro de datos. KeyStore utiliza una clave pública para crear un secreto de cifrado para cifrar datos. KeyChain se usa para almacenar claves privadas en todo el sistema y requerirá que el usuario establezca un PIN o contraseña.

Enlaces

Estándares

  • HIPAA_CONTROLS:
    • SECURITY251
    • SECURITY212
    • SECURITY213