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
La seguridad física existe a nivel práctico
Yo creo que la seguridad física sí que existe a nivel práctico: cifra todo el disco (incluso con el FDE de las distribuciones comunes), y tus datos están seguros.
El problema viene si te sustraen el equipo o lo pierdes de vista, y después lo recuperas. Al volver a usar el equipo es cuando estás poniendo en riesgo los datos.
Es decir, que para garantizar la seguridad de los datos al 100%, basta con que al perder de vista el equipo asumamos que está comprometido, lo reinstalemos y por supuesto restauremos nuestros datos de una copia de seguridad (porque tenemos backup, verdad?). O como tu asistente a la Blackhat, tiremos el euqipo y compremos otro.
La "seguridad del 100%" sería esa a la que estamos acostumbrados los kriptopoleros paranoicos: con la seguridad del algoritmo y una clave secreta; lo que a día de hoy, con AES, y salvo sorpresas conspiranoicas, me deja bastante tranquilo.
Otra solución pasa entonces por llevar nuestros datos siempre con nosotros y cifrados convenientemente. Lo cual con las capacidades de los pendrives actuales no es ninguna locura.
Venga, sigamos con la paranoia :-)
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
Desde luego
Es justo lo que he contestado más arriba. El artículo habla del caso en el que nos han "apiolado" el equipo para luego devolvérnoslo convenientemente troyanizado. Y también supone que estamos interesados en reutilizar el equipo recuperado (que no están los tiempos para tirar equipos, oiga :-)
Como he dicho, si asumimos que al perder el equipo de vista éste está comprometido, simplemente con no usarlo de nuevo los datos siguen seguros.
Y este escenario será precisamente el más común: cuando nos roben el portátil será seguramente para revenderlo, no para intentar sacar los datos. Y en este caso, el FDE de las distribuciones viene al pelo, y asegura completamente los datos.
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.
No solo el disco
El problema no viene de que se puede troyanizar el disco. En realidad puede troyanizarse cualquier componente de la cadena de arranque BIOS->Disco->GRUB->Initrd->Root Filesystem, lo que pasa es que los primeros niveles son bastante más complejos de modificar que los últimos (que son triviales).
La clave está en que el primer código que se ejecute no sea modificable (de ahí lo del módulo TPM y el Secure Boot con código en ROM), porque una vez que podemos garantizar que el código y los certificados de verificación están intactos, podemos iniciar una cadena de confianza de arranque, en el que cada paso verifica la integridad del siguiente, TPM -> BIOS -> GRUB -> Kernel -> Espacio de usuario. Como ya he dicho, este es exactamente el esquema del Secure Boot de Windows 8.
El problema es que el código no modificable no es muy compatible con el software libre, y de ahí el problema de estos esquemas.
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
Lo que hay en la ROM son certificados PKI
Lo que hay en ROM es un código sencillo y una serie de certificados comunes, como los de los navegadores. No he ahondado en lo referente al formato de los certificados, pero me imagino que serán X.509, como la inmensa mayoría (todos?) de los que se usan hoy en día.
No creo que hayan intentado crear un nuevo esquema de PKI, habrán usado el existente, que funciona bien y está probado.
Así que sabiendo esto, pues lo de la fuerza bruta, como que no... Si lo consiguen, habrían roto todo el esquema de PKI actual.
El RAID de los discos está en otro nivel
O está por encima de los volumenes cifrados o está por debajo:
De todos modos, este ultimo esquema (RAID5 sobre volumenes cifrados) me parece más bien un ejercicio académico que otra cosa, lo veo poco práctico.
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.........
Interesante artículo...
Interesante artículo de un zumbado que ha securizado su ordenador llevandolo hasta límites insospechados. Creo que quien haya este artículo en Kriptópolis puede encontrar interesante este otro:
https://grepular.com/Protecting_a_Laptop_from_Simple_and_Sophisticated_A...
Un saludo
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.
Articulo al respecto de Secure Boot y troyanos BIOS en LWN
Un par de cosillas:
* Hoy leo en LWN una referencia a un buen artículo sobre soporte Secure Boot en Fedora 18. En ese enlace encuentro otro a un artículo sobre un rootkit BIOS que está ahora mismo en activo
* Krenel00, no hace falta llamarme zumbao. Simplemente para cumplir la Ley de Protección de Datos en España, es muy aconsejable que los portátiles de empresa estén cifrados. No soy ningun paranoico (bueno, un poco más que el resto sí, pero mis clientes me pagan por ello :-)
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.
Claro que se puede
Normalmente estos sistemas de cifrado funcionan en modo "stack" (en Linux desde luego y probablemente en Windows tambien), es decir: sobre un dispositivo tu construyes un dispositivo cifrado, que a su vez puede utilizarse como origen para otro dispositivo cifrado, y asi...
El unico limite es tu nivel de paranoia.
Se me ocurre que en Linux es trivial hacer un dispositivo LUKS que a su vez sea utilizado como dispositivo soporte de otro dispositivo LUKS, que sea utilizado como soporte de otro dispositivo LUKS... y asi hasta que quieras: tendrías un contenedor cifrado dentro de otro, dentro de otro, y los irias abriendo de uno en uno, poniendo en cada momento la clave apropiada, como un juego de muñecas rusas.
Si con un AES ya tienes un sistema supuestamente inexpugnable, si además usas 3 metodos encadenados distintos de cifrado fuerte, uno en cada contenedor, tienes un sistema virtualmente invulnerable.
Por cierto, el tema de los discos USB: es exactamente como hago el backup diario de mi empresa y de todos mis clientes. DIsco externo USB cifrado.
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