¿No cifra el disco duro, pero hace imposible cambiar las cosas sin una contraseña?

1

Hace poco compré una unidad SSD y me di cuenta de que mi CPU (Celeron 1007U - no tiene instrucciones AES) no puede continuar cifrándola y la SSD no tiene cifrado de hardware incorporado. Esto me hizo darme cuenta de que si quiero utilizar todos los caballos de fuerza allí, necesito renunciar a cifrar cada bloque HDD.

Después de pensar un poco, me di cuenta de que podía mantener mi partición como "a prueba de falsificaciones" si mantenía los datos de integridad (sumas de comprobación) en un volumen separado que está cifrado. En ese caso, los datos seguirían siendo visibles pero el atacante no podria cambiarlo Excluyendo los problemas relacionados con el almacenamiento del gestor de arranque, ¿es correcto mi razonamiento? ¿Tendría realmente la posibilidad de permitirme utilizar 500MiB / s en este procesador si el SSD lo admite? En caso afirmativo, ¿conoce algún proyecto de Linux que me permita hacerlo (sistemas de archivos, complementos de mapeo de dispositivos o funciones de LVM)?

    
pregunta d33tah 01.03.2016 - 10:34
fuente

2 respuestas

2

Lo que estás preguntando no se puede lograr por varias razones.

Problema 1: ¿Qué tamaño de bloque de datos correspondería a una única etiqueta de autenticación?

  • El tamaño del bloque es el más pequeño para SSD que es 4K. Las etiquetas son más pequeñas, de 256 bits o menos, y se supone que también están almacenadas en SSD. Esto lleva a la amplificación de escritura en el lado de SSD con etiquetas de autenticación, a menos que sus escrituras estén dentro de los límites de 512 K (medio megabyte). El número proviene del hecho de que un bloque 4K puede contener 128 etiquetas, por lo que un bloque 4K lleno de etiquetas correspondería a 128 bloques de datos, cada uno de un tamaño de 4K.
  • El tamaño del bloque es nuevamente 4K, pero cada etiqueta de autenticación también ocupa 4K. Esto anula la amplificación de escritura, pero el almacenamiento requerido para las etiquetas es el mismo que para los datos, la relación es 1: 1. Terabyte de datos viene con un terabyte de etiquetas de autenticación.
  • El tamaño del bloque es más grande. Esto lleva a menos espacio necesario para las etiquetas de autenticación. El bloque de datos más grande se convierte en menos espacio que se utiliza para la autenticación, pero al mismo tiempo se deben procesar más datos para calcular las etiquetas. Esto conduce a un efecto similar a la amplificación de escritura.

Problema 2: el hash es más costoso computacionalmente que el cifrado.

  • Los algoritmos de hash utilizados en la criptografía en el pasado como SHA1 solían ser significativamente más caros en términos de cpb. El hashing moderno como SipHash y otro ruso que no puedo nombrar de memoria se están acercando mucho a los cifrados, pero aún están por encima de ellos. No serán más baratos que los cifrados.
  • Los cifrados de bloque podrían utilizarse para la autenticación. El modo LRW podría usarse, por ejemplo, pero en ese esquema cada bloque de datos pasa por dos operaciones de cifrado de bloques. Por lo tanto, no va a ser "más barato que el cifrado".
  • Los cifrados de flujo no se pueden usar para la autenticación.
respondido por el ArekBulski 05.03.2016 - 02:17
fuente
0

¿Cómo puede estar seguro de que realmente se utiliza la integridad de los datos?

Si un atacante puede escribir en datos arbitrarios y hacer que se lean, ¿cómo puede estar seguro de que el atacante no ha modificado su kernel para simplemente ignorar cualquier falta de coincidencia de integridad de los datos?

No estoy muy familiarizado con la comprobación de integridad de datos del kernel, pero si el atacante podría desactivar la comprobación de integridad de datos o modificarla de alguna manera, entonces la comprobación no importaría.

    
respondido por el Steve Sether 01.03.2016 - 17:23
fuente

Lea otras preguntas en las etiquetas