Dispositivos
El cifrado de disco, ¿de verdad?
BitLocker, FileVault, LUKS: lo que está activado por defecto, lo que protege de verdad y los ataques que pasan igualmente.
Última revisión:
Vi cómo vaciaban un portátil de empresa en menos de cinco minutos en una sala de control. La máquina estaba «cifrada» —el departamento de TI lo había certificado, la pegatina de conformidad estaba pegada en la parte de atrás—. Salvo que estaba en suspensión, con la tapa cerrada, metida en una bolsa en el coche del directivo durante una comida. Las claves estaban en RAM, la sesión abierta. La persona que recuperó la bolsa no tuvo que conocer la contraseña. Conectó una caja, sorteó la pantalla de bloqueo y copió lo que quiso. El disco estaba cifrado. Los datos, no.
Angle de lecture
La trampa habitual
«Mi disco está cifrado.» Es una de las frases peor entendidas de toda la seguridad informática. Quiere decir, en el 95 % de los casos, «marqué una casilla en los ajustes» o «el departamento de TI activó BitLockerSolución Microsoft de cifrado de disco integrada en Windows Pro/Enterprise. al desplegar el equipo». No quiere decir «mis datos están protegidos ahora mismo». Son dos afirmaciones distintas, y la confusión entre ambas es exactamente con lo que cuenta un atacante con acceso físico.
El cifrado de disco protege sus datos en un estado preciso y único: cuando la máquina está apagada. Eso es todo. En cuanto el sistema arranca y usted inicia sesión, las claves de descifrado se cargan en memoria RAM y cualquier archivo se vuelve legible como si el cifrado no existiera. El sistema operativo descifra al vuelo, de forma continua y totalmente transparente —ese es precisamente el objetivo: que usted no note ninguna diferencia al usarlo—. Pero esa transparencia para usted es también una transparencia para cualquiera que ponga la mano sobre la máquina en ese estado.
La pregunta correcta, por tanto, nunca es «¿está cifrado?». Es «¿en qué estado está mi máquina en el momento en que un tercero puede acceder a ella?». Apagada, en suspensión, en hibernación, con la pantalla bloqueada: estos cuatro estados ofrecen niveles de protección radicalmente distintos con exactamente el mismo cifrado activado. El discurso dominante —«active el cifrado y estará tranquilo»— escamotea todo este matiz. Y es en ese matiz escamoteado donde se aloja la práctica totalidad de las extracciones de datos exitosas sobre material supuestamente «cifrado».
La otra mitad de la trampa es creer que el cifrado defiende contra amenazas que nunca tuvo vocación de cubrir. El cifrado de disco no hace nada contra un malware que se ejecuta en su sesión: el programa malicioso lee sus archivos descifrados exactamente igual que usted. No hace nada contra el phishing, contra un robo de contraseña, contra un acceso remoto a su máquina encendida, contra una copia de seguridad en la nube mal protegida. Tampoco protege sus datos una vez que han salido del disco —archivo adjunto enviado, fichero copiado en una memoria USB, documento abierto en una aplicación que sincroniza—. El cifrado de disco responde a una sola pregunta, estrecha pero real: «alguien recupera mi material físicamente, ¿qué puede sacar de él?». Confundir esa protección puntual con una protección general es creer que la cerradura de una puerta le protege cuando la ventana está abierta.
Los cuatro estados: cuándo protege, cuándo no protege
El mismo cifrado, activado una sola vez, le protege completamente o no le protege en absoluto según el estado de la máquina. Aquí están los cuatro, del más seguro al más expuesto.
Máquina apagada (cold state). El único estado en el que el cifrado hace su trabajo íntegramente. El disco solo contiene datos cifrados, la clave no está en ninguna parte de la memoria, y quien robe el disco o la máquina no lee nada sin la frase de paso o la clave de recuperación. Es el escenario para el que se diseñó el cifrado de disco: el robo de material apagado. En ese caso preciso, FileVaultCifrado de disco integrado en macOS desde OS X Lion., BitLocker y LUKSEstándar de cifrado de disco en Linux, generalmente vía cryptsetup y dm-crypt. cumplen sus promesas.
Máquina en hibernación. La hibernación escribe el contenido de la RAM en el disco cifrado y luego corta la alimentación. Bien configurada, es casi tan sólida como un apagado completo, porque la memoria RAM se vacía y se cifra en disco. En Windows con BitLocker y PIN, la hibernación protege correctamente. En los Mac con Apple Silicon, la suspensión profunda bloquea las claves en el Secure Enclave. La trampa: muchas máquinas están configuradas para no hibernar nunca y quedarse en suspensión simple indefinidamente.
Máquina en suspensión (sleep / suspend). El estado por defecto cuando cierra la tapa. La RAM se mantiene alimentada, así que las claves de descifrado están presentes en ella, en claro. Un atacante con acceso físico puede extraerlas —por análisis forenseDisciplina que analiza las huellas digitales tras un incidente para reconstruir lo sucedido. de memoria, por ataque DMAChip criptográfico soldado a la placa base que almacena claves y certifica la integridad del arranque. sobre un puerto Thunderbolt mal bloqueado, o por cold boot— y descifrar el disco sin conocer jamás su contraseña. Es el estado más peligroso precisamente porque es el estado en el que su portátil pasa la mayor parte de su vida.
Máquina encendida, con pantalla bloqueada. Los volúmenes están montados y descifrados. La pantalla de bloqueo es una puerta de software delante de un disco ya abierto. Sortear esa pantalla no toca el cifrado en absoluto —ataca al sistema de autenticación de sesión, que tiene su propia superficie de ataque (cuentas locales, exploits de la pantalla de inicio de sesión, puertos de depuración)—. Aquí el cifrado no juega ningún papel protector.
La consecuencia práctica es brutal y contraintuitiva: la máquina que usted cree «protegida porque está cifrada y bloqueada» en su bolsa, en una reunión, en el hotel, está en el estado menos protegido que existe. Cerrar la tapa no asegura nada. Solo el apagado completo devuelve la máquina al cold state.
Póngase en el lugar del atacante dos minutos, es la única forma de entender por qué el estado importa más que el cifrado. Recupera un portátil dentro de una bolsa. Lo primero que hace: mira si está caliente, si el LED parpadea, si una pantalla se enciende al mover el ratón. Una máquina templada en suspensión es un regalo. La enchufa a la corriente para que no se apague, la coloca en una estación de análisis y trabaja sobre un objetivo cuyas claves ya están en memoria. La contraseña de sesión ni siquiera le interesa. A la inversa, una máquina fría y apagada le deja frente a un bloque cifrado: puede guardarla meses, lanzar fuerza bruta, no obtendrá nada si la frase de paso es correcta. Es exactamente esa asimetría la que la mayoría de la gente anula simplemente cerrando la tapa en lugar de apagar.
El modelo de amenaza correcto, por tanto, no es «¿corro el riesgo de que me roben el SSD desnudo?» —escenario raro, que supone que alguien desatornilla su máquina— sino «¿en qué situaciones mi máquina sale de mi control, y en qué estado está en ese momento?». Respuesta honesta para la mayoría de la gente: en reunión (bloqueada, montada), en un tren (suspensión), en el hotel durante el desayuno (suspensión), confiada a un técnico de reparación (encendida o en suspensión), incautada en una frontera (según su disciplina). En casi todos esos casos dominan la suspensión o el bloqueo, y el cifrado no juega ningún papel protector real.
Por sistema operativo: lo que está realmente implementado, y dónde se rompe
Los tres sistemas cifran. Lo que los distingue es lo que sucede al arrancar y al desbloquear —y es ahí donde se juegan las verdaderas diferencias de protección—.
macOS — FileVault 2. Cifrado XTS-AES-128 sobre los volúmenes APFS. En los Mac con chip T2 (Intel de gama alta desde 2018) y todos los Apple Silicon, las claves de hardware las gestiona el Secure Enclave y no transitan nunca por la RAM de forma expuesta. En concreto, en un MacBook serie M, cerrar la tapa desencadena un verdadero bloqueo de las claves por parte del Secure Enclave; el reinicio rápido proviene de una readquisición de la clave al desbloquear, no de una clave que se quedó en memoria. Es arquitectónicamente mucho más sólido que todo lo anterior al T2.
Detalle que sorprende a muchos usuarios de Mac: en Apple Silicon, el volumen del sistema está en realidad cifrado de forma permanente a nivel de hardware, independientemente de FileVault. Lo que FileVault añade es la exigencia de una credencial de usuario para liberar la clave al arrancar. Sin FileVault, la clave es derivable sin contraseña, y un Mac robado arranca directamente en el escritorio de una cuenta sin contraseña. Dicho de otro modo, «el disco está cifrado» es técnicamente cierto incluso con FileVault desactivado —y totalmente engañoso, porque sin FileVault el cifrado no le protege de nada—. Es el ejemplo perfecto de la brecha entre «cifrado» y «protegido». El punto débil que queda no es técnico sino organizativo: al activarlo, macOS propone almacenar la clave de recuperación en iCloud. Si usted acepta, la protección de su disco se vuelve tan fuerte como su cuenta de Apple —y no más—. Un Apple ID con phishing, y la clave va detrás.
Windows — BitLocker. El sistema más desplegado en las empresas, y el que más a menudo falla en la configuración. BitLocker puede funcionar en modo TPMChip criptográfico soldado a la placa base que almacena claves y certifica la integridad del arranque. solo: la clave se deriva del TPM 2.0 al arrancar y, si las mediciones de integridad del arranque coinciden, el disco se descifra solo, sin ninguna entrada. Es el ajuste cómodo de muchos parques grandes, porque a ningún equipo de soporte le gusta gestionar tickets de «olvidé mi PIN». Es también el agujero: una máquina robada con la batería cargada arranca y se descifra sola hasta la pantalla de inicio de sesión, y ciertos ataques (DMA, sniffing del bus entre el TPM y la CPU en hardware no seguro) recuperan la clave sin conocer nada. Algunos investigadores han extraído públicamente claves BitLocker escuchando el bus LPC o SPI entre un TPM discreto y el procesador en máquinas baratas —la operación requiere un soldador y unas pocas decenas de euros de material, no un laboratorio estatal—.
El modo TPM + PIN, en cambio, exige un código antes de la carga del sistema operativo: la clave se deriva conjuntamente del TPM y de lo que usted teclea. El PIN no abandona nunca el perímetro del arranque seguro, y sin él el TPM no libera nada. Es la única configuración de BitLocker que considero seria contra el robo de máquina. Activación por directiva de grupo (Require additional authentication at startup) o en línea de comandos como administrador: manage-bde -protectors -add C: -TPMAndPIN. Existe una variante aún más estricta, TPM + PIN + clave USB de arranque, para los perfiles muy expuestos, al precio de una ergonomía penosa en el día a día.
Linux — LUKS / dm-crypt. La capa estándar bajo Linux, y la más transparente conceptualmente: nada de desbloqueo automático silencioso por defecto, la protección reposa sobre la frase de paso introducida al arrancar. Lo que usted teclea es lo que protege, punto. LUKS2 (por defecto en Ubuntu 20.04+, Fedora 33+) usa Argon2id como función de derivación —resistente a los ataques por GPU y ASIC, al contrario que el viejo PBKDF2—. En concreto, Argon2id obliga al atacante a dedicar memoria y tiempo a cada intento de contraseña, lo que hace que la fuerza bruta masiva con tarjetas gráficas sea económicamente poco interesante; PBKDF2, en cambio, se rompía a ritmos industriales. LUKS gestiona también hasta ocho ranuras de clave (keyslots): puede tener una frase de paso humana, una clave de recuperación larga almacenada sin conexión, y un mecanismo de desbloqueo por red (Clevis/Tang) para los servidores, cada uno en su ranura, revocable de forma independiente.
La trampa clásica bajo Linux no es el cifrado del disco principal sino lo que pasa por al lado: el swap y /boot. Si su partición de intercambio no está cifrada, fragmentos de claves y de datos sensibles se filtran al disco en claro —un volcado completo de memoria puede aterrizar ahí durante una hibernación—. La partición /boot, por su parte, está tradicionalmente en claro porque el gestor de arranque debe leerla antes de cualquier descifrado; un atacante puede modificar ahí el núcleo o el initramfs (ataque llamado «evil maid») para capturar su frase de paso en el próximo arranque. La configuración LVM-on-LUKS (todo el grupo de volúmenes, swap incluido, dentro de un contenedor cifrado) resuelve el problema del swap; la firma del arranque vía Secure Boot o un /boot en una memoria USB que usted lleva encima aborda el evil maid. Verificación rápida: lsblk -f debe mostrar sus particiones sensibles como crypto_LUKS, no como ext4 desnudo.
El enfoque correcto: configurar para el estado, no para la casilla
Activar el cifrado es una decisión de cinco minutos que se toma una vez. Hacerlo realmente protector depende de tres ajustes que casi siempre se olvidan.
Primer ajuste: el bloqueo pre-arranque. En BitLocker, es el PIN (modo TPM + PIN). En LUKS, es la frase de paso al arrancar (ya por defecto). En macOS Apple Silicon, el Secure Enclave juega ese papel de forma nativa en cuanto FileVault está activo. Sin ese bloqueo antes de la carga del sistema operativo, el cifrado solo protege contra el robo del disco desnudo extraído de la máquina —no contra el robo de la máquina entera, que es sin embargo el escenario realista—. Es la diferencia entre «protegido contra alguien que desatornilla mi SSD» y «protegido contra alguien que se va con mi portátil».
Segundo ajuste: el comportamiento al cerrar la tapa. Fuerce la hibernación o el apagado en lugar de la suspensión simple para todo contexto móvil. En Windows, la hibernación tras un corto plazo de inactividad. En Linux, configure suspend-then-hibernate o desactive la suspensión en favor de la hibernación. El objetivo: que la máquina abandone por sí misma el estado en el que las claves viven en RAM, sin depender de su disciplina.
Tercer ajuste, el más saboteado: el almacenamiento de la clave de recuperación. La clave de recuperación da un acceso completo al disco sin ninguna otra verificación. Es una llave maestra. Almacenarla en iCloud en la máquina que protege, en una cuenta de Microsoft sin MFA, en un fichero de texto en el escritorio, o en un correo «enviado a uno mismo», es anular el cifrado por la puerta de atrás. La regla es simple: la clave de recuperación vive en un soporte distinto del dispositivo que protege. Copia en papel en una caja fuerte, o gestor de contraseñasAplicación que almacena y genera contraseñas únicas para cada servicio. cifrado con MFA fuerte instalado en otro dispositivo. Nunca en la máquina afectada.
Un último punto sobre la clave de recuperación que casi siempre se olvida explicar: no solo sirve para resolver un olvido de contraseña. En BitLocker, el TPM mide el estado del arranque; cualquier actualización del firmware, cambio en el orden de arranque o reinicio del BIOS modifica esas mediciones y desencadena una solicitud de clave de recuperación en el próximo encendido. Es un comportamiento normal, no un ataque —pero si la clave no está en ninguna parte, usted queda bloqueado fuera de su propia máquina tras una simple actualización de Windows algo agresiva—. De ahí la importancia de una custodia limpia: la clave debe ser recuperable por usted, en un lugar que usted controle, e inaccesible para cualquier otra persona. Esas dos exigencias tiran en sentido opuesto, y ahí reside todo el reto de su almacenamiento.
Y antes de todo eso: verifique que está realmente activo. En las máquinas reutilizadas, migradas o reaprovisionadas, el cifrado a veces se desactiva sin que nadie lo note —una reinstalación del sistema que no reactiva FileVault, un volumen añadido sin cifrar, un parque heredado de una adquisición—. sudo fdesetup status en macOS debe mostrar FileVault is On. Get-BitLockerVolume -MountPoint C: en Windows debe mostrar ProtectionStatus: On con un protector de tipo TpmPin —si solo ve Tpm, está en modo sin PIN, a corregir—. sudo cryptsetup luksDump /dev/sdaX en Linux confirma el formato (LUKS2) y la función de derivación (argon2id). Se verifica, no se supone —y se vuelve a verificar tras cada operación de mantenimiento pesada—.
Lo que esto implica en concreto
Para usted, como particular
- Verifique que el cifrado está realmente activo — Abra los ajustes hoy:
Privacidad y seguridad → FileVaulten Mac,Cifrado de unidad BitLockeren Windows. Si ve «activado», es el mínimo. Coste: cero, diez minutos. - Añada un bloqueo pre-arranque y cambie el comportamiento al cerrar la tapa — En Windows, active el PIN de BitLocker (
manage-bde -protectors -add C: -TPMAndPIN) y configure el cierre de la tapa en «hibernar» dentro de las opciones de energía. En un Mac reciente, ya lo gestiona el Secure Enclave. Coste: cero, veinte minutos. - Saque su clave de recuperación del dispositivo — Anótela en papel, guárdela en un cajón cerrado o en una pequeña caja fuerte de 30-50 €, y elimine cualquier copia digital almacenada en la propia máquina. Desmarque el almacenamiento en iCloud/Microsoft si está mínimamente expuesto. Coste: menos de 50 €, media hora.
Para usted, CISO / Dirección de TI / directivo
1. El cifrado «activado» no es un KPI útil. Sus paneles de conformidad muestran una tasa de cifrado del 98 %, y todo el mundo se queda tranquilo. Pero ¿cuántos de esos endpoints tienen un bloqueo pre-arranque? La mayoría de los grandes despliegues de BitLocker están en TPM solo, sin PIN, porque es transparente y no genera tickets de soporte. Consecuencia directa: su tasa real de protección contra el robo de portátil es el porcentaje de máquinas con PIN pre-arranque —a menudo 0 %, y no aparece en ninguna parte de sus informes—.
2. La custodia de las claves de recuperación es un punto único de compromiso. Las claves remontadas a Active Directory, Azure AD o su MDM (Intune, Jamf) son la buena práctica —a condición de que el acceso a esa bóveda esté a su vez protegido por MFA hardware y registrado para auditoría—. Consecuencia directa: si un administrador puede listar las claves de recuperación de todo el parque sin alerta ni registro, ha recreado un disco entero descifrable a partir de un solo compromiso de cuenta de administración.
3. La suspensión en movilidad anula el cifrado de facto. Sus colaboradores cierran la tapa entre dos reuniones, en el tren, en el aeropuerto. El parque pasa su vida en el estado menos protegido. Consecuencia directa: una política de cifrado sin política de apagado/hibernación forzada en movilidad protege contra el robo de disco desnudo —un escenario raro— y no contra el robo de portátil abierto o el registro en frontera, que son los escenarios reales.
Errores que se ven todo el tiempo
- BitLocker sin PIN, por defecto al desplegar. La máquina se descifra sola al arrancar. Protección contra el robo de disco desnudo únicamente, no contra el robo de la máquina.
- Clave de recuperación de FileVault en iCloud, en el Mac que protege. Comprometer el Apple ID basta para recuperar la clave. El cifrado se vuelve tan fuerte como la contraseña de iCloud.
- Máquina en suspensión antes de una frontera. «Está cifrado, solo cierro la tapa.» No: las claves están en RAM, el registro en caliente lee el disco. Apagado completo, siempre.
- Swap sin cifrar bajo Linux. El disco principal está en LUKS, el swap está en claro, y fragmentos sensibles aterrizan ahí. Verifíquelo con
lsblk -f. - Suponer sin verificar. El cifrado estaba activo hace seis meses, así que lo está hoy. Falso tras cualquier migración, reinstalación o reutilización de máquina.
Checklist accionable
- N1 Verificar que FileVault / BitLocker / LUKS está realmente activo (fdesetup status, Get-BitLockerVolume, cryptsetup luksDump)
- N1 Identificar el comportamiento actual al cerrar la tapa: suspensión, hibernación o apagado
- N1 Almacenar la clave de recuperación en un soporte distinto del dispositivo que protege
- N2 Activar un bloqueo pre-arranque: PIN de BitLocker (TPM+PIN), frase de paso LUKS, Secure Enclave en Mac
- N2 Forzar la hibernación o el apagado al cerrar la tapa en movilidad (≤ 5 min)
- N2 Verificar el cifrado del swap bajo Linux (lsblk -f) o pasar a LVM-on-LUKS
- N2 Desmarcar el almacenamiento en la nube de la clave de recuperación para los perfiles expuestos
- N3 Apagado completo sistemático antes de frontera, aduana o zona con interceptación madura
- N3 Para perfiles muy expuestos: LUKS con frase de paso fuerte, sin desbloqueo automático
- N3 Auditoría anual de la custodia corporativa: quién lee las claves, registro, MFA hardware en la bóveda
Para profundizar
Las implementaciones evolucionan rápido —verifique siempre la documentación oficial para su versión exacta—. La documentación de FileVault de Apple(opens in a new tab) detalla el papel del Secure Enclave según el hardware, y la documentación de BitLocker de Microsoft(opens in a new tab) cubre la configuración TPM + PIN por GPO. Para Linux, la página del proyecto cryptsetup(opens in a new tab) sigue siendo la referencia sobre LUKS2 y Argon2id. Y para entender por qué el apagado completo no es paranoia, el artículo de Princeton sobre los cold boot attacks(opens in a new tab) sigue vigente quince años después de su publicación.
Fuentes y lecturas complementarias
- Apple — FileVault and encrypted storage security overview [official]
- Microsoft — BitLocker documentation [official]
- cryptsetup / LUKS — project page [official]
- INCIBE — Cifrado de información y dispositivos [official]
- Halderman et al. — Lest We Remember: Cold Boot Attacks on Encryption Keys (Princeton, 2008) [paper]