2 votos

Si la partición /system no se cifra nunca (ni siquiera en el cifrado de "disco completo"), ¿cómo se protege?

Parece que el sistema Android "disco completo-encrytpion" sólo se preocupa de encriptar el data o internal storage partición. Dice:

El cifrado de disco completo es el proceso de codificación de todos los datos del usuario en un dispositivo Android mediante una clave cifrada. Una vez cifrado el dispositivo, todos los datos creados por el usuario se cifran automáticamente antes de consignarlos en el disco y todas las lecturas descifran automáticamente los datos antes de devolverlos al proceso de llamada.

Me desconcierta qué valor tiene el cifrado (en reposo) de los datos del usuario, si un atacante puede simplemente modificar el contenido del /system partición, para contener un malware que exfiltre los datos o la clave de cifrado.

¿Hay alguna razón para considerar que el cifrado de Android es eficaz aunque /system ¿la partición no está encriptada?

Supongo que una respuesta implica una chain-of-trust , en relación con un cargador de arranque bloqueado.

0 votos

/system es de sólo lectura, y lo que se almacena allí se almacena allí en todos los dispositivos de la misma marca/modelo que se ejecutan en la misma versión de Android - así que ¿qué quieres proteger allí? Los "datos del sistema" (configuración, etc.) se almacenan en /data junto con los datos del usuario. Así que si eso es lo que se ha encriptado (y AFAIK lo es), está encriptado junto.

0 votos

Siga este enlace para conocer el proceso de arranque verificado de Android. Android.googlesource.com/platform/external/avb/+/master/

0 votos

@Izzy he podido recuperar perfectamente los datos de la encriptación /data partición, simplemente modificando (es decir, insertando una aplicación en /system/app ), siendo que /system no está encriptado lo hace más fácil.

3voto

Slevin Puntos 204

/boot , /system , /vendor , /vbmeta y ODM Particiones están protegidos por Arranque verificado de Android (AVB). No están encriptadas pero su integridad se verifica durante el arranque. Cualquier modificación de estas particiones detendrá el flujo de arranque y brickear el dispositivo. En este punto, sin el modo EDL, no será capaz de flashear el sistema operativo original para desbloquearlo.

El AVB verifica la imagen de la partición vbmeta utilizando la clave pública del OEM que está codificada en el cargador de arranque de Android (ABL). Entonces se calcula el hash de la imagen de arranque y se compara con el hash almacenado en vbmeta. Una vez verificada la imagen de arranque, el kernel construye el hashtree de cada partición y compara su hash de root con los que están almacenados en vbmeta. De esta manera, sólo protegiendo vbmeta, todas las demás particiones pueden ser verificadas en el arranque.

Para proteger el ABL de la manipulación (por ejemplo, sustituyendo la clave pública del OEM por la propia y renunciando al vbmeta con su clave privada, rompiendo así la cadena de confianza), los fabricantes de chips implementan el arranque seguro. En los dispositivos de Qcom, el cargador de arranque primario (PBL), que se graba en la matriz de la CPU, verifica el cargador de arranque extendido (XBL) utilizando la clave pública de Qcom que se almacena en eFuse. A continuación, el Xtended Bootloader verifica el ABL y el ABL aplica el AVB.

Cuando se desbloquea el bootloader (unlock y unlock_critical), el AVB no se aplica, pero el arranque seguro sigue siendo aplicado por el SoC. Esta cadena de confianza llega hasta el nivel de hardware haciendo inútil cualquier modificación. No hay razón para encriptar las particiones del sistema ya que esas imágenes ya son públicas. Lo que importa es la protección de su integridad.

1voto

rascalking Puntos 1422

Parece que Google está de acuerdo contigo y está eliminando el cifrado de disco completo "heredado":

Atención: El soporte para el cifrado de disco completo está desapareciendo. Si vas a crear un nuevo dispositivo, debes utilizar el cifrado basado en archivos.

El cifrado de disco completo se consideraba bastante sólido hasta 2016 debido al entorno de ejecución de confianza respaldado por hardware. Dependiendo de cómo el OEM implemente el entorno de ejecución de confianza y si el OEM utiliza el sistema Android almacén de claves sistema. Hace un grado de seguridad variable. Si por el contrario está respaldado por software entonces no tanto.

Las claves de cifrado no se encuentran en una partición sin cifrar. La clave de cifrado se almacena en los e metadatos criptográficos. La capacidad de firma del entorno de ejecución de confianza del hardware y si se implementa el sistema de almacén de claves de Android, entonces el dispositivo Android en su conjunto e incluso el núcleo de Android no tienen acceso al keymaster dentro del entorno seguro de confianza. El sistema de almacén de claves es muy interesante, pero explicar la seguridad y las operaciones que hay detrás implica una explicación de varias páginas que se respondería mejor a través de su propia pregunta. 

Los dispositivos Android que admiten una pantalla de bloqueo y que se entregan con Android 7.0 o superior tienen un entorno secundario y aislado llamado Entorno de Ejecución de Confianza. Esto permite una mayor separación de cualquier código no fiable. La capacidad se implementa normalmente utilizando hardware seguro.

Algunos ejemplos de la forma en que se puede configurar un entorno de ejecución de confianza son:

Una máquina virtual separada, un hipervisor o un entorno de ejecución de confianza especialmente diseñado, como ARM TrustZone. El entorno aislado debe proporcionar una completa separación del kernel de Android y del espacio de usuario (mundo no seguro). Esta separación es para que nada que se ejecute en el mundo no seguro pueda observar o manipular los resultados de cualquier cálculo en el entorno aislado.

Android 9.0 introdujo un entorno de ejecución de confianza respaldado por hardware llamado caja fuerte. La caja fuerte es una CPU completamente independiente, construida y certificada como segura. Ejemplos de dispositivos StrongBox son los elementos seguros integrados (eSE) o las unidades de procesamiento seguras on-SoC.

Un entorno seguro respaldado por hardware que utilice el sistema de almacén de claves de Android puede servir como protección sólida para la clave de cifrado. A menos que un tercero, como Qualcomm (2016), cometa un error de diseño en la implementación del sistema de cifrado. keymaster .

0 votos

"Encriptación de disco completo fue considerado bastante sólido hasta 2016" - ¿Podría dar una razón de por qué ya no se considera sólido? Lo pregunto en particular porque, según entiendo en los documentos de Android, el cifrado basado en archivos no se introdujo por motivos de seguridad (si no tenemos en cuenta que el FBE también separa a varios usuarios entre sí mediante el cifrado), sino porque el cifrado de disco completo no permitía que las alarmas y otras aplicaciones funcionaran justo después del arranque sin la intervención del usuario.

0 votos

En cuanto a /system no ser encriptado por FDE - la forma en que entiendo los documentos , /system sigue sin encriptarse bajo el nuevo esquema FBE, sino sólo los datos del usuario, por lo que las preocupaciones del OP siguen siendo válidas.

1 votos

@balu sí puedo, si consideras comprometer la trustzone explotando el pequeño kernel de Qualcomm que se ejecuta dentro para cargar la propia aplicación QSEE (Qualcomm Secure Execution Environment) de los atacantes dentro del entorno seguro que luego puede explotar un fallo de escalada de privilegios que nos permitirá obtener la ejecución de código y así secuestrar el espacio para utilizar un exploit que extraiga las claves KeyMaster de Qualcomm. A partir de estas claves se utilizan las claves generadas para el cifrado de disco completo. Utilizando las claves FDE para forzar la contraseña, el pin o el bloqueo, se puede descifrar el dispositivo y recuperar los datos protegidos.

0voto

alecxs Puntos 29

Una rápida comprobación en la tablet Samsung Galaxy Tab S3 SM-T820 con Android 9 Pie oficial indica que /sistema está cifrado con FDE

:/ $ df -ah
Filesystem                            Size  Used Avail Use% Mounted on
rootfs                                1.5G  9.4M  1.5G   1% /
tmpfs                                 1.7G  1.1M  1.7G   1% /dev
devpts                                   0     0     0   0% /dev/pts
none                                     0     0     0   0% /dev/cpuctl
none                                     0     0     0   0% /dev/cpuset
proc                                     0     0     0   0% /proc
sysfs                                    0     0     0   0% /sys
selinuxfs                                0     0     0   0% /sys/fs/selinux
debugfs                                  0     0     0   0% /sys/kernel/debug
tracefs                                  0     0     0   0% /sys/kernel/debug/tracing
pstore                                   0     0     0   0% /sys/fs/pstore
tmpfs                                 1.7G     0  1.7G   0% /mnt
tmpfs                                 1.7G     0  1.7G   0% /mnt/secure
/dev/block/dm-0                       3.7G  3.5G  245M  94% /system
/dev/block/bootdevice/by-name/apnhlos    0     0     0   0% /system/vendor/firmware_mnt
/dev/block/bootdevice/by-name/modem      0     0     0   0% /system/vendor/firmware-modem
/dev/block/bootdevice/by-name/dsp      12M  4.1M  7.6M  36% /system/vendor/dsp
none                                     0     0     0   0% /acct
none                                     0     0     0   0% /config
/dev/block/bootdevice/by-name/cache   193M  8.8M  184M   5% /cache
/dev/block/bootdevice/by-name/efs      16M  720K   15M   5% /efs
/dev/block/dm-1                        24G   13G   11G  56% /data
/data/knox/secure_fs/enc_user          24G   13G   11G  56% /data/enc_user
/data/knox/secure_fs/enc_media         24G   13G   11G  56% /data/knox/secure_fs/enc_media
tmpfs                                 1.7G     0  1.7G   0% /storage
/data/media                            24G   13G   11G  57% /storage/emulated
/mnt/media_rw/4280-3E71                60G  4.8G   55G   9% /storage/4280-3E71
tmpfs                                 1.7G     0  1.7G   0% /storage/self
:/ $

2 votos

Eso es dm-verity no dm-crypt (FDE). Ambos son objetivos del marco de mapeo de dispositivos del kernel de Linux, pero tienen propósitos diferentes.

0 votos

Por favor, downvote, voy a dejar la respuesta como referencia. ¿puede usted elaborar?

1 votos

El núcleo de Linux DMCrypt contra. DMVerity . Android's FDE contra. Bota verificada

PreguntAndroid.com

PreguntAndroid es una comunidad de usuarios de Android en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X