Existem esquemas de chaves LUKS mais avançados, por ex. 2 de 3 chaves necessárias?

Question

Parece que as duas principais opções de criptografia LUKS são:

1. Arquivo-chave USB (consulte link )
2. Digitando uma senha

Ambos têm pontos fracos. O primeiro pode ser superado roubando o drive USB. No segundo caso, um keylogger poderia ser usado, ou eu poderia ser forçado a entregar a senha.

Seria possível criar um esquema de criptografia que exigisse as duas opções? Então, se eu recebesse uma injunção para fornecer a senha, eu poderia destruir a unidade USB (por exemplo, queimá-la no fogão); Por outro lado, se alguém roubasse meu drive USB, eles precisariam obter minha senha também.

Parece que a ideia existente do slot-chave LUKS é que fornecer uma chave para qualquer slot desbloqueará o dispositivo, não que seja necessário fornecer uma chave para todos , ou diga "2 de 3" slots de chaves (isto é, o último pode ser realizado de maneira criptograficamente segura usando um campo de Galois).

(Além disso, por acaso estou em um sistema OpenSuSE, então, por favor, mantenha as respostas independentes de distro ou algo que possa funcionar no SuSE.)

    

Answer 1

Eu não acho que algo assim exista logo de cara, mas deve ser possível. Vou juntar algumas referências para você.

Primeiro, há / etc / crypttab - normalmente você especifica um arquivo de chave ou senha no terceiro slot, mas algumas distribuições permitem que você especifique uma opção no quarto campo chamado keyscript (debian e opensuse suportam isto: link . Este script (que deve estar em "/ lib / cryptsetup / scripts" iirc) pode usar o terceiro campo (o que normalmente seria apenas o arquivo de chaves ou senha) como um argumento. O trabalho do keycript é enviar a chave de decodificação real para stdout, que cryptsetup então usa como a chave luks da maneira normal.

Segundo, é provável que você precise escrever o código-chave. netkeyscript (no github) é um exemplo de um script de chaves que escuta em um soquete multicast UDP para a senha; aqui está outro exemplo mais detalhado de um script de chave personalizado, completo com uma implementação em sh : link . Como você codifica o keycript (que eu só vou chamar de multifactor ) eu deixo como um exercício para você;)

Em terceiro lugar, a divisão secreta. você pode usar uma ferramenta de código aberto chamada "ssss" (google para "ssss-split") para dividir a senha luks da maneira que você descreve. digamos que você a divida em 3 partes (a, b, c) e exija 2 delas. armazene "a" no drive usb, "b" em um cofre e "c" você armazena com o computador (partição não criptografada), ou o que for. É claro que você não quer que "c" seja exposto, então criptografe-o com um esquema de sua escolha usando uma senha que você possa lembrar, e chame essa senha " c0 " e o " c " criptografado em sua disco é " c' ". Agora sua criptografia será parecida com

root  /dev/disk/<blah blah>  /dev/<usb>:/path/to/a+$/dev/<blah>:/path/to/c'  keyscript=multifactor

o que você realmente terá para o terceiro campo dependerá, é claro, do que o seu manuscrito está disposto a aceitar

Idealmente, o keycript deve ser capaz de determinar que ele precisa de sua entrada para descriptografar uma ou mais chaves (por exemplo: c' - > c neste caso), mas você pode usar o terceiro campo para especificar isso como desejado. No meu exemplo acima, usei um $ para indicar isso.

Não tenho certeza se é possível fazer o prompt do script de entrada, possivelmente no stderr, já que qualquer saída no stdout é tomada como a senha do luks. Seria bom se houvesse um retorno sensato.

De qualquer forma, boa sorte e feliz hacking:)

    

Answer 2

Resposta curta: Não.

Você pode ter várias chaves em diferentes espaços, mas isso não está relacionado à sua pergunta.

Por segurança, eu mantenho uma soma de verificação para os ramdisks e o cryptsetup é vinculado estaticamente, e eu os verifico automaticamente toda vez que eu inicializo.

UPDATE

A soma de verificação é armazenada no FS criptografado, você não pode modificá-lo até montar essa partição.

Ou seja, a menos que você seja explorado remotamente ou seus programas binários, por exemplo, ramdisk / cryptsetup no rootfs esteja sendo modificado, isso é seguro. (BTW: Meu rootfs é criptografado, somente o kernel / ramdisk está nu lá, é por isso que eu os verifico apenas, mas me preparo para a velocidade de carregamento lenta com um CPU / HDD lento)