Sobre el Cifrado Completo de Disco ("Full Disk Encryption")

Enviado por jorgegv en

Foros: 

Por Jorge González Villalonga

La semana pasada llegaba las portadas de muchos medios informáticos la noticia de que Barnes & Noble había decidido retirar de la venta un artículo titulado "Learn to Hack". Esto provocó, como era de esperar, que el susodicho artículo (disponible en http://www.tuxradar.com/content/learn-hack/) tuviese una difusión mucho mayor.

En dicho artículo se mencionaba la fragilidad de los sistemas de cifrado parcial de disco ofrecidos por algunas distribuciones (Fedora, Ubuntu, por ejemplo) de Linux. En dichos esquemas, la partición del sistema operativo y programas no está cifrada, pero se cifra la partición /home, donde los usuarios guardan sus datos personales.

Partimos de la base de que si ciframos un disco es para que en caso de que nos roben o se extravíe el equipo, los datos valiosos que contenga (dejemos que cada uno defina "valiosos" como prefiera) no caigan en manos de quien no los debe tener. Es decir, intentamos proteger los datos de un ataque al equipo en el que el atacante tiene acceso físico al equipo.

Con esta premisa, el artículo explicaba cómo este método de protección parcial de datos era ineficaz: el atacante que nos ha robado el equipo puede desconectar el disco duro, conectarlo a otro equipo, poner un programa especial en el arranque de la máquina (un troyano) que se encargue de conectar automáticamente con el ordenador del atacante, y volver a dejarnos el equipo disponible como si nada hubiese pasado (y un escenario mucho más plausible aún: esto nos puede pasar en un rato en el que perdemos de vista nuestro equipo, sin que ni siquiera nos demos cuenta de que nos lo han sustraído)...

Con este ataque, el atacante solo tiene que esperar a que el usuario vuelva a iniciar sesión en su ordenador (ahora "troyanizado"), y a que introduzca la clave para desbloquear el dispositivo cifrado. Una vez hecho esto, el atacante, a través de la conexión remota del troyano, puede acceder sin problemas a los datos prohibidos, ya que estos están disponibles para el usuario, los acaba de desbloquear.

Este ataque puede ampliarse a otro tipo de troyanos, como uno que pida la clave de forma idéntica que el sistema para luego enviarla por red al atacante (una especie de "phishing local").

En fin, la conclusión es que si tenemos una parte del disco abierta, el sistema entero está comprometido si lo perdemos de vista.

Solución 1: el Cifrado Completo de Disco ("Full Disk Encryption")

La supuesta solución a este tipo de ataques es usar la solución de Cifrado Completo de Disco que incluyen las distribuciones desde hace tiempo. Este esquema hace que solo una pequeña partición (normalmente /boot, cuyos contenidos además, suelen ser prácticamente idénticos en todas las instalaciones de una misma versión de distribución) esté disponible sin cifrar, y el resto del disco se configura como un volumen LUKS cifrado. Sobre este volumen se definen después los volúmenes lógicos necesarios para la partición root, el espacio de swap
(también cifrado), etc. En el mismo arranque de la máquina, el propio sistema pide la clave para abrir el dispositivo LUKS, de forma que si no la proporcionamos, el kernel ni siquiera es capaz de montar la partición raíz, y por tanto no arranca. Aparentemente estamos seguros con este esquema, no?

La realidad es que no. Este esquema tiene el mismo problema que el del cifrado parcial: tenemos una parte del disco que es accesible y modificable sin clave, y es precisamente la partición /boot. ¿Y cómo podemos instalar un troyano en la partición boot? Pues usando la imagen "initrd" que todos los sistemas de arranque de Linux usan hoy en día: un sistema Linux en miniatura que se ejecuta en memoria y que es el que muestra las bonitas pantallas de inicio de Ubuntu y Fedora, y además entre otras cosas, el que se encarga de pedirnos la clave para desbloquear el volumen LUKS que da acceso al sistema de ficheros raíz.

Es cierto que incluir un troyano en el "initrd" no es tan sencillo como ponerlo directamente en la partición raíz, pero no es mucho más complicado: el formato del "initrd" está perfectamente documentado y las herramientas para reconstruirlo son libres (por supuesto!). De hecho, cada vez que actualizamos el kernel de nuestra distribución, el initrd se reconstruye con los módulos y la configuración del nuevo kernel instalado.

Así que seguimos como antes: ni siquiera con Cifrado Completo de Disco estamos a salvo de un ataque con acceso físico al equipo.

Solución 2: Firma digital de imágenes initrd

Una posible solución al problema anterior podría ser la siguiente: si la imagen initrd está firmada con una clave pública, y si GRUB soportase imágenes initrd firmadas, GRUB podría comprobar la firma y rechazar el arranque en caso de que el initrd hubiese sido manipulado.

GRUB no tiene este soporte aún, pero sería interesante proponerlo a los autores como una funcionalidad deseable. Si GRUB guarda una serie de certificados válidos para firmar initrd's (los de los fabricantes, p.e. RedHat, Ubuntu, Debian, etc.), al menos tendríamos una forma de validar la imagen initrd y contar con un entorno seguro. Esto originaría sin embargo otros problemas, como por ejemplo la imposibilidad de arrancar kernels compilados por el usuario, etc.

Sin embargo, este sistema también está viciado. El propio GRUB (o algo de su código al menos) se almacena en una zona del disco que necesitamos que esté disponible sin cifrar: el MBR (master Boot Record). Aunque tuviésemos el /boot cifrado, o las imágenes initrd firmadas digitalmente, nada impide al atacante sustituir el gestor de arranque del MBR por otro código que contenga el código "troyanizado", o que ejecute initrds sin firmar.

Como vemos, a medida que vamos tirando del hilo se va reduciendo el espacio sin cifrar (o firmar digitalmente) del disco a proteger. Sin embargo, hemos llegado al mínimo imprescindible: 1 sector, el MBR. También es cierto que a medida que el espacio de disco sin cifrar o autenticar se reduce, aumenta la complejidad del ataque y la experiencia necesaria de quien lo tiene que ejecutar, pero el hecho es que sigue siendo posible.

La conclusión es que para tener el disco completamente protegido, debemos cifrarlo (o firmarlo digitalmente) de forma TOTAL para evitar su modificación, incluido el MBR. No nos vale el "Full Disk Encryption" y necesitamos, por tanto, ir un paso más atrás en el proceso de arranque del sistema: la BIOS.

Solución 3: Cifrado hardware de disco completo ("Hardware Based Full Disk Encryption")

Desde hace unos años, los discos duros tienen la capacidad de cifrar los datos antes de escribirlos en el soporte magnético. En teoría estos cifrados son potentes, y muchos fabricantes los ofrecen de serie. La BIOS se encarga normalmente de pedir la clave que desbloquea el disco y de enviarla al aparato, que a partir de entonces se comporta como un disco normal, sin pérdida de rendimiento, pero manteniendo los datos cifrados en el soporte.

Aunque hace algún tiempo hubo noticias de algún fabricante prometiendo que sus discos usaban AES como método de cifrado hardware, cuando en realidad estaban usando un simple XOR, parece que actualmente estos sistemas son seguros.

¿Seguro? Pues no del todo. Volvemos a estar en una tesitura parecida a las anteriores: el atacante puede haber "troyanizado" la propia BIOS (es complejo, pero puede hacerse, la inmensa mayoría de las BIOS actuales son actualizables por software), de forma que puede a su vez infectar el gestor de arranque, y entonces volvemos a estar en el problema anterior (GRUB troyanizado).

Para evitar el problema de la BIOS troyana, debemos protegerla.

Solución 4: Entorno Seguro de Arranque

Básicamente consiste en un entorno en el que el sistema de arranque (el equivalente a la BIOS) está firmado digitalmente, y el propio sistema de arranque se niega a ejecutarse en caso de haber sido manipulado. Las claves públicas y el código que realiza la verificación del entorno de arranque se encuentran disponibles en un chip que no se puede actualizar (idealmente ROM).

Finalmente, a base de tirar del hilo, hemos llegado a la solución al problema: un sistema que permite la verificación de todo el proceso de arranque porque su código y claves están en ROM y no pueden ser manipuladas.

En cualquier caso, incluso aunque los fabricantes de Linux se encargasen de poner en los módulos hardware sus propios certificados, este esquema impediría la instalación de kernels a medida compilados por nosotros mismos, y en general el "cacharreo" con nuestros propios sistemas.

Conclusión

Parece que la conclusión obligatoria es que si queremos tener total seguridad con nuestros datos, todo pasa por disponer de un entorno hardware cuyo código no se pueda modificar. Sin embargo, este entorno hardware se da de tortas con la filosofía del software libre, todo debe poder abrirse y modificarse a nuestro gusto.

De hecho este esquema, que a nosotros nos ha servido para garantizar la seguridad de nuestros datos, puede usarse también para propósitos perversos. Este mismo esquema es el usado por Microsoft en Windows 8, con su tecnología "Secure Boot", para evitar que se instale en el equipo otro software que no sea de Microsoft (incluyendo Linux). Solo tiene que convencer a los fabricantes de placas base para que en sus módulos hardware solo incluyan claves de Microsoft.

Una posible solución a esto sería disponer de placas base en el que nosotros pudiésemos cambiar las claves de firma a base de cambiar el chip donde están almacenadas y que esos chips fuesen de un solo uso (como las antiguas PROM). Pero por otro lado, ¿quién nos garantiza que el programa o aparato que grabe esos chips no introduce además su propio certificado, que a su vez permite arrancar código troyanizado, lo que puede pervertir el gestor de arranque, y con eso acceder al disco... etc. etc.?

La solución más práctica desde mi punto de vista es, como siempre, la de compromiso: ¿Cuánto valen mis datos como para que alguien invierta dinero en craquear mi equipo? ¿Valen 300 EUR que vale contratar a un experto en Linux un par de horas para saltar el "Full Disk Encryption" de las distribuciones Linux? ¿Valen los 20.000 EUR (por ejemplo) que pueda valer contratar a alguien experto que pueda troyanizar una BIOS? ¿Valen los (posibles) varios millones de euros necesarios para disponer de un equipo capaz de sustituir el modulo TPM de una placa con Secure Boot?

De la respuesta a estas preguntas deberemos sacar nuestras propias conclusiones sobre el tipo de cifrado que necesitamos. Porque, recordemos, la seguridad absoluta no existe (desgraciadamente).

 

Copyright Jorge González Villalonga 2012

Este artículo está bajo una licencia de Creative Commons Reconocimiento-NoComercial-CompartirIgual 3.0 Unported.

Lo he disfrutado

Plas, plas, plas. Buen artículo.

Resumiendo creo que podría decirse que: la seguridad física no existe.

Poner protecciones adicionales simplemente es retrasar o encarecer el acceso a los datos, pero si se tiene acceso físico eventualmente se podrá llegar a ellos. Si se detecta que alguien ha estado "trapicheando" con tu ordenador, no puedes confiar más en él. Deberías hacer una reinstalación completa, y volver a empezar de cero.

Algun hacker que iba a la BlackHat le retuvieron el portátil durante 4 horas en el aeropuerto, de mientras le hacian preguntitas. Cuando le devolvieron el portátil sacó el disco duro, formateó de forma segura y lo tiró todo: "tengo todo cifrado pero me pueden haber cambiado el firmware del teclado, por lo que no puedo confiar más en mi portátil", dijo.

Solo puedo repetir: la seguridad física no existe. http://xkcd.com/538

De acuerdo totalmente

Muy bueno el artículo. Hay un verdad en seguridad y es que si hay acceso físico a un equipo hay acceso total a los datos, podrá ser más costoso o menos llegar a ellos, pero se podrá acceder.

La cuestión es que si alguien se toma la enorme molestia de robar el equipo a una persona concreta para llegar a sus datos, puedes estar seguro de que dispondrá de los recursos necesarios para poder leerlos.

Creo que para los demás (casi todos nosotros), un buen compromiso es dificultar en lo posible el acceso teniendo en cuenta que si nos roban un equipo probablemente sea para sacarse unos euros vendiendo el hardware.

una cosa

una cosa, todo esto no se evitaría manteniendo el portátil a la vista????? Para que nadie te lo levante??

Eso es como decir que el DNIe no es seguro porque alguien puede ver que clave escribes y robártelo. Eso implicaría inseguridad en el sistema de autenticación pero no del propio DNIe

Todos los huevos en la misma cesta

La carencia de todos los sistemas que se mencionan es que el PC en cuestión tiene todos los componentes para arrancar localmente. Tampoco sería tan complicado precisar de un componente externo que, además, validase la integridad del anterior. Parece que todo el ataque ha de pasar por troyanizarnos el disco y no nos podemos fiar de las comprobaciones de firma por que a su vez los distintos componentes que emplearíamos pueden haber sido comprometidos, pero siempre llegamos al disco. Si podemos garantizar que no ha sido alterado desde que lo paramos en principio podemos considerarnos a salvo, puesto que la cantidad de código para meternos un keylogger al nivel de arranque parece requerir que lo tengan que meter ahí.

Así pues. ¿qué tal protección por hardware del disco en sí, a nivel de controladora?. El disco puede llevar su propio teclado y obligarnos a desbloquearlo (incluso abriendo la máquina) antes de permitir incluso que sea reconocido por la BIOS.

Estas cosas, al menos en versión USB, ya existen en el mercado (por ejemplo los dotforce http://www.dotforce.es/prodottoDettaglio.php?idprodotto=43) y se trataría de adaptar la idea a este entorno.

Para que la operación fuera más "user friendly" el disco podría disponer de un teclado conectable para ubicarlo fuera de la caja o hacer opcional la activación del código de bloqueo (desde la última sesión confiable).

Por otro lado podemos también disponer de métodos de comprobación externos. Podríamos obtener una firma del disco desmontándolo del sistema en cuestión y montándolo en otro que también la validaría antes de volver a arrancarlo. Por supuesto eso implica operaciones de montaje y desmontaje del disco pero ya haría falta troyanizar dos equipos independientes para colarnos el gol.

Me gusta tu idea. Seguramente

Me gusta tu idea. Seguramente sería caro, pero tendría su público y no nos arriesgaríamos a los efectos coolaterales de que Secure Boot cope el mercado. No me extrañaría nada que de prosperar, en un futuro no muy lejano sea tan difícil comprar una placa sin Secure Boot como hoy lo es comprar un ordenador sin windows.

Y aún mejor sería poder desencriptarlo con un archivo llave que conectarías usando un pendrive.

El pendrive con el archivo llave lo llevarías siempre contigo, y para encender el ordenador bastaría con conectarlo a un puerto usb propio del disco duro y encender el ordenador.

Cierto, pero

Entiendo que el objetivo de atacar la BIOS, MBR, etc. está en al final acabar grabando en el disco, puesto que difícilmente nos van a meter el troyano en otra parte. Hombre, habría que comprobar que no hubiera un segundo disco o dispositivo de arranque ajeno dentro, pero entiendo que eso ya es más visible. De hecho incluso proteger la carcasa de manera que no pueda abrirse sin dejar huella o disparar alarmas también sería un punto.

cifrado del disco entero.

Yo tengo una duda sobre el cifrado entero del disco.

A ver como lo explico, bueno seré muy directo.

Si en un disco donde tienes dos particiones C: y D: (está claro que hablo de windows). y cifro el disco entero y por problemas tengo que formatear la partición C pero no la D. ¿cómo haría esto? ¿funcionaría el encriptado o podría ver lo encriptado en D cuando meta la clave?. Lo digo porque , cifré entero el disco teniendo dos particiones y he formateado una de ellas pero no he tocada la de datos y ahora una vez que he reinstaldo el s.o en c e instalado de nuevo truecrypt metiendo la clave y aceptando dicha clave no puedo ver la partición D. No sé si al encriptar el disco entero y formatear una partición provoca que no se pueda recuperar lo que hay en D. ¿alguien me dice si estoy en lo cierto o se puede hacer ésto que comento?

Fuerza bruta en la rom?

Muy buen articulo

tanto rollo para que al final la contraseña sea "dios" o "12345" jejeje
en el caso de ripli, supongo que lo ideal es desencriptar el disco duro antes de formatear pero...

si tengo los discos duros en raid 5 y 1 de ello me falla, se podria recuperar la informacion sabiendo la clave?

y en el caso que se usara el metodo de una rom para encriptar, se podria sacar la clave por fuerza bruta?

Saludos.

Salu2:Euphoria

Muy buena informacion

Me gusta mucho el tema, la seguridad en los datos siempre es importante.

Yo soy el conspiparanoico de mi clase, si estoy estudiando, y cada vez que les comento algo que he leido se quedan de piedra o me dicen "Anda ya, paranoico".

Todo esto que se ha dicho, lo tendre en cuenta cuando me pase a linux e intente hacer un sistema seguro.

Saludos.

Habiendo acceso físico, no hay seguridad que valga.

Cuando el sistema está comprometido físicamente, no hay ninguna seguridad que sirva de nada.

Supongamos que tenemos un terrorista que tiene información cifrada en su disco. ¿Qué haría yo? Pues... se me ocurre que, sin que se diera cuenta, lo primero que haría sería quitarle el disco y copiar todo su contenido. Después de eso simplemente insertaría un keylogger en el HARDWARE, que es algo muy fácil de hacer.

Si por algún motivo eso no fuera posible... digamos que porque no hay tiempo o porque la clave se pide por ejemplo mediante una pantalla táctil con botones que cambian de lugar, o lo que sea... podríamos por ejemplo reemplazarle el disco completo por otro que llevaríamos preparado con software que simulara la pantalla que pide la clave. Una vez pedida esa clave la guardaría en lugar seguro... mejor si dejo copias en muchos lugares diferentes o de ser posible la transmitiría a un lugar remoto.

Hecho esto simularía algún tipo de error para mantener ocupado al delincuente mientras llega la policía a arrestarlo.

Pues no veo como va a ser fácil

Eso que dices de que insertar un Keylogger en el hardware es muy fácil, hombre pues como concepto en principio no lo veo. Por lo que dices más adelante entiendo que te refieres a substituir todas las tripas implicadas de su equipo por un montaje que simule todo el proceso de arranque de manera que no sospeche nada. Tampoco lo pondría en la lista de cosas fáciles aunque no sería imposible. A la que nuestro hacker tuviera una identificación en dos niveles no tendríamos idea de como simular la segunda sin haber pasado la primera (puesto que no la habríamos visto).

Además todo eso pasa por que podamos manipular su equipo sin que se entere, sin que se de cuenta de que le hemos abierto la tapa y trasteado las tripas.

Es más si suponemos que nuestro hacker está en modo paranoico, igual antes de dar los datos correctos se identifica mal adrede un número indeterminado de veces para ver si la respuesta del sistema es la esperada o no.

Me edito:
Igual te refieres a los cacharros que se conectan al conector del teclado interceptándolo. Esos efectivamente son triviales de insertar, pero no pasan desapercibidos a cualquier inspección ocular. Tampoco sería aplicable en caso de portátiles.

Cuando digo keylogger, me

Cuando digo keylogger, me refiero a un keylogger por hardware. Se puede hacer con un chip del tamaño de la uña de tu dedo meñique que puedes comprar por 1 o 2 euros. Basta con soldarlo al lugar adecuado para que registre en su memoria lo que tecleas al encender el equipo. En un portátil se puede conectar adentro. En un equipo de escritorio se puede conectar por ejemplo dentro del mismo teclado.

Con respecto a "sustituir todas las tripas"... no hace falta llegar a tanto. Basta con desenchifar el disco duro y reemplazarlo por otro. Es una tarea que se hace en 1 minuto si llevas el disco nuevo preparado. El disco nuevo en lugar de contener tu sistema operativo habitual tiene un programa que simula su funcionamiento pero lo único que hace es registrar la clave que estas tecleando. Si la identificación es en dos niveles basta con simular los dos niveles, aceptando cualquier clave como válida.

Finalmente, suponiendo que nuestro "delincuente" tiene un precinto de seguridad inviolable con el que descubriría si le hemos toqueteado el ordenador... cosa que veo poco probable pero supongamos que es así... ¿qué tal si le instalamos una cámara oculta que grabe lo que teclea?

Recuerda que estamos hablando de espiar a alguien teniendo todos los recursos necesarios. Estamos en el supuesto de que hemos identificado a un delincuente peligroso (ahora están de moda los terroristas así que supongamos que es un terrorista), y necesitamos acceder a su información. Apenas tengamos los datos ya podemos arrestarlo así que no tenemos que preocuparnos de que una cámara permanezca oculta durante meses. Basta con que se vaya a tomar una caña al bar de la esquina para que te infiltres en su casa, instales el keylogger, la cámara, o el nuevo disco duro, y salgas corriendo.

Apenas vuelva a su casa y encienda el PC para consultar el mail, tienes lo que necesitas y ya puedes caer con 20 policías a arrestarlo.

Hombre asi si

Si le grabas en vídeo lo que teclea ya no hay nada que decir. Lo tienes. No es una solución muy tecnológica pero si es efectiva.

Respecto a eso de soldar... bueno, creo que te refieres entonces a cosas como esta

http://www.spionproduct.com/computer-technique/keylogger/-/chip-keylogge...

insertada en un teclado externo. No veo posible instalar algo parecido dentro de la propia caja y menos en un portátil.

Lo del disco eso si lo veo complicado. Entendemos que nuestro hacker es un tipo que se preocupa de su seguridad y por tanto no estará usando una distribución estandard de su sistema operativo. Si se lo ha tuneado un poco y ha puesto varias capas de seguridad no podremos saber que espera él que le aparezca en pantalla (bueno si tenemos la cámara si, pero entonces ya no nos importa). Aunque claro, del mismo sitio de donde nosotros sacamos la cámara el puede sacar algo como esto XDD

http://pdm.com.co/images/Humor/Body%20Laptop.JPG

Estas hablando de comprar

Estas hablando de comprar algo hecho. Yo hablo de los recursos que puede tener la policía por ejemplo, o cualquiera que esté verdaderamente interesado en obtener una cave. No es complicado diseñar un keylogger para conectar a cualquier hardware. Me refiero a conectarlo adentro directamente a los circuitos.

Pero bueno, lo importante del asunto es que podemos discutir durante horas sobre algoritmos de cifrado pero el punto débil estará siempre en la parte humana (lección que aprendieron tarde los alemanes conla enigma).

Si aplicas el "método de la fuerza bruta" con el humano, tienes una altísima probabilidad de obtener la clve en pocas horas.

Parece Cándido la Solución de tu Caso Delicadísimo

Saludos Fraternos!!!
Tu caso lo abordaría así:

El terrorísta del que hablas esta entrenado para no perder, conoce lo que le puede pasar si falla en la misión, para que ésto no ocurra se ha entrenado en desconectar de manera pasiva el Keyloggers oculto, sabe que la combinación de teclas de programas ocultos lo desactiva con un reconocimiento de wdams justo en la octava del push, es lo primero que debe hacer, ahora bien, se asegura de llevar dos HD para hacer el cambiazo como los tarjeteros de los bancos, y asi te quedas con el disco falso, usa ingenieria social al decirte "ya perdí"!!, su otro compañero desaparece con el disco auténtico... la misión es un éxito...la vida del que atrapes no importa....si en el HD ORIGINAL que ya no está éxiste información de códigos de lanzamientos de misiles tomahaws ATR34-X con Transceptor remoto de activación sin retorno estamos perdidos, sólo que los discos duros de alta seguridad que se instalan en centros de laboratorios nucleares contengan borrados automáticos a traves de sensores de contacto tactíl y exitación calorífica...vas al terminal clonado o a tu PALM último modelo con lector touch screen y metes la yema de tu dedo pulgar la clave...el terrorista no ha borrado tu clave táctil´y no la conoce esa técnología es tuya, como Tesla SÓLO TÚ LO SABES, así que borra la clave que ademas el HD TIENE GPS Y lo buscamos con nuestro rastreador el "Ojo de Orus" Atrapamos al tipo deseando descifrar las claves.... encriptadas con algorítmo de cifrado Imaginario infinito.....ahora te daras cuenta si es que éres curioso por que el terrorista trajo 2 HD asi que eso ya te lo dejo para que descifres el caso....ó acaso desconoces lo que és Criptoanalisis....Ahora si el tiempo no apremia, la oposición del tiempo es el reposo paralizamos toda la red del mundo...como el relato bíblico, el libro de los muertos ó el libro de las transmutaciones ó del transito Maya, y todo se paralizará nos obedecerán los DATOS.........

No lo créo!!!

Ya está en boga la extracción de datos por led ultravioletas y otros rayos de pruebas betta que dan lectura-wirelles en corridas remotas, disipan la luz transformadas en campos magnéticos imantando el pegamento para extraer lo que encuentran en el disco duro (DH), eso en software, y en hardware hay rumores de investigadores autodidáctas CON LABORATORIOS CLANDESTINOS TAL VEZ que usan avanzadas de hidrógeno para crear copias fantasmas de toda tu PC...EN VANGUARDIA...Dicen por ahí que cifrando el texto ya nos escapamos de lo que puede ocurrir mientras viaja el mensaje...pero me he puesto a pensar que un delincuente informático rigurosamente Inteligente buscara formas de penetrar al lugar donde piensa que por derecho divino le "pertenece"...así que mejor hay que estar alertas para dar un mejor servicio, si es que trabajamos en algo de securitymacrored...Saludos

Cifrado completo del disco

Y que pasa si arranco el portátil cifrado desde un pendrive, hago una medición de la partición /boot y compruebo si ha sido modificada. Si no ha sido modificada, arranco otra vez normalmente introduciendo la clave sin miedo

keylogger

Lo que ocurre es que yo te robo la clave con mi keylogger casero conectado directamente a la placa madre de tu PC, fabricado con un chip que vale $2 y tiene el tamaño de una uña ;)

Y si eso no funciona, puede que la cámara oculta que te hemos puesto logre ver qué teclas presionas.

Y finalmente, tal vez funcione atacar por fuerza bruta al punto más débil: te atacamos directamente a ti con unos cuantos palos a ver si hablas.

No existe la solución 4

Al leer la frase "el propio sistema de arranque se niega a ejecutarse en caso de haber sido manipulado", me ha venido la memoria la Guía del Autoestopista Galáctico, cuando a Arthur le quieren extraer el cerebro y sustituirselo por otro electrónico. "¡Yo notaría la diferencia!", protesta Arthur, pero le responden: "No, no la notarías. Te programaríamos para que no la notaras". Evidentemente tiene razón anv1 cuando dice "habiendo acceso físico, no hay seguridad que valga". No existe la solución 4.

Encriptación de disco duro externo

Buenas,

Muy interesante tú artículo, me pregunto si se puede aplicar tus comentarios a un disco duro externo, en el que por ejemplo encriptas con bit locker o si es posible encriptar un archivo encriptado, es decir, bit locker más truecrypt.

Saludos y gracias.

Y el problema cambia de lugar

En ese caso, un posible atacante irá a por otro punto débil, por ejemplo mediante un troyano que capture las contraseñas, o un keylogger físico. Es como fortalecer tanto los eslabones de una cadena que al final compensa atacar el candado o los goznes de la verja.

opinar

Texto puro

  • No se permiten etiquetas HTML.
  • Las direcciones de las páginas web y las de correo se convierten en enlaces automáticamente.
  • Saltos automáticos de líneas y de párrafos.
By submitting this form, you accept the Mollom privacy policy.