No puedo abrir una de mis particiones LUKS en Raspberry PI debido a la restricción de memoria. Ya descubrí que la sugerencia en este caso esrecrear la partición en el dispositivo más lento, que accederá a ella(en este caso la Raspberry PI).
Sin embargo, me preocupa la posible disminución del nivel de seguridad (probablemente, con menos potencia informática, se utilizará una clave más débil).
Esto es lo que dice la documentación de cryptsetup sobre el problema:
Nota: La iteración de la frase de contraseña la determina cryptsetup dependiendo de la potencia de la CPU. En un dispositivo lento, esto puede ser más bajo de lo que desea. Recientemente comparé esto en una Raspberry Pi y resultó en aproximadamente 1/15 del recuento de iteraciones para una PC típica. Si la seguridad es primordial, es posible que desee aumentar el tiempo dedicado a la iteración, a costa de un desbloqueo más lento más adelante. Para Raspberry Pi, usando
cryptsetup luksFormat -i 15000 <target device>le brinda un recuento de iteraciones y un nivel de seguridad igual al de una PC promedio para la iteración de frases de contraseña y de claves maestras. En caso de duda, verifique el recuento de iteraciones con
cryptsetup luksDump <target device>y ajuste el recuento de iteraciones en consecuencia creando el contenedor nuevamente con un tiempo de iteración diferente (el número después de '-i' es el tiempo de iteración en milisegundos) hasta que se cumplan sus requisitos.
Ahora, no estoy seguro de qué pasará si sigo el consejo anterior.
- ¿La partición será tan segura como en una PC?(si el número de iteraciones es correcto), ¿solo más lento?
- Si es más lento, ¿solo el desbloqueo es más lento o las lecturas/escrituras posteriores son tan rápidas como sin la iteración adicional? (Si es así, ¿por qué? ¿Es porque al desbloquear solo desciframos la clave que luego se usará para descifrar el contenido de la partición?)
- ¿Seguirá consumiendo menos memoria que la partición creada en una PC rápida? (En otras palabras: quiero recrear la partición para poder usarla con Raspberry PI. Con los valores predeterminados será utilizable, pero menos segura. ¿Seguirá siendo utilizable con el mayor número de iteraciones, o no? ¿Otra vez consume demasiada memoria?)
Respuesta1
Primero tenga en cuenta que la documentación de LUKS que estaba leyendo fue escrita para LUKS1 y ahora está algo desactualizada. Todo lo que citó (por ejemplo, recuento de iteraciones) es específico del algoritmo PBKDF2, que su particiónen realidad no usa.
LUKS2 admite dos algoritmos para convertir su frase de contraseña en una clave: el tradicional PBKDF2 y el más nuevo Argon2. Este último es lo que LUKS usa ahora de forma predeterminada, y es el único que tiene una cantidad mínima (ajustable) de memoria necesaria. Eso no es lo mismo que "recuento de iteraciones".
Sin embargo, me preocupa la posible disminución del nivel de seguridad (probablemente, con menos potencia informática, se utilizará una clave más débil).
No estás ajustando la intensidad de la clave, estás ajustando la intensidad de la clave.proteccion.
Los parámetros que está modificando están destinados a proteger contra alguien que intente atacar la frase de contraseña que está ingresando; evitan ataques de fuerza bruta (es decir, probar varias frases de contraseña seguidas) al hacer que el proceso de derivación de claves sea increíblemente lento.
Sin embargo, la clave producida siempre es igual de fuerte por sí sola (es tan buena como cualquier otra clave AES) y nadie se molestaría en atacarla directamente.
Si es más lento, ¿solo el desbloqueo es más lento o las lecturas/escrituras posteriores son tan rápidas como sin la iteración adicional? (Si es así, ¿por qué? ¿Es porque al desbloquear solo desciframos la clave que luego se usará para descifrar el contenido de la partición?)
Cada vez que desbloquea el volumen, LUKS convierte su frase de contraseña en una clave de cifrado utilizando una "función de derivación de clave" (un KDF) para que el proceso sea más resistente a los ataques de fuerza bruta. LUKS1 siempre usó 'PBKDF2', que es resistente por significa ser lento de calcular (pero no impone ningún requisito de memoria), mientras que LUKS2 además admite 'Argon2', que en su lugar requiere una cierta cantidad de RAM.
La derivación de la clave solo ocurre una vez en el momento del desbloqueo; el resto (cifrado de datos real) no necesita incluir ninguna frase de contraseña.
(En otras palabras: quiero recrear la partición para poder usarla con Raspberry PI. Con los valores predeterminados será utilizable, pero menos segura. ¿Seguirá siendo utilizable con el mayor número de iteraciones, o no? ¿Otra vez consume demasiada memoria?)
No necesita volver a crear la partición en absoluto, porque ni siquiera la clave derivada de la frase de contraseña se utiliza para cifrar sus datos directamente: solo cifra losmaestroclave almacenada en el encabezado del volumen LUKS.
Esta es la razón por la que es posible cambiar rápidamente la frase de contraseña sin necesidad de volver a cifrar todo el disco (o incluso tener varias frases de contraseña) y, de la misma manera, LUKS le permite cambiar los parámetros de KDF con la misma facilidad.
Si los parámetros predeterminados de Argon2 usan demasiada memoria, simplemente dígaselo a LUKS:
cryptsetup luksConvertKey --pbkdf "argon2i" --pbkdf-memory <num_kilobytes> <device>Si no puede usar Argon2 en absoluto, aún puede decirle a LUKS que use PBKDF2 en su lugar:
cryptsetup luksConvertKey --pbkdf "pbkdf2" --iter-time <milliseconds> <device>En lugar de milisegundos (que dependen del dispositivo), puede especificar directamente el número de PBKDF2iteracionesque desea (que siempre da el mismo resultado sin importar en qué dispositivo lo haga): el valor predeterminado en una PC es alrededor de un millón:
cryptsetup luksConvertKey --pbkdf "pbkdf2" --pbkdf-force-iterations <count> <target>
Las mismas opciones son aceptadas por luksChangeKey(al cambiar la frase de contraseña), de hecho parece quenecesidadque se especificará cada vez que cambie la frase de contraseña.