Quão fácil é quebrar a proteção contra cópia a seguir? [fechadas]

Question

Estou tentando proteger contra cópia algum trabalho, que é um cartão SD inicializável que inicializa um kernel Linux em um dispositivo ARM (Raspberry Pi). Eu estou usando essa abordagem:

1. A abordagem usa um initrd para montar um sistema de arquivos raiz criptografado.
2. O initrd gera a senha do sistema de arquivos de acordo com o CID do cartão SD. (uma função hash é usada, ainda não foi decidida sobre md5 ou sha1). O Initrd tentará montar o sistema de arquivos usando essa senha gerada.
3. Agora, aqui está a parte mais interessante / suspeita: O initrd em si é criptografado usando uma função C personalizada, basicamente cada byte é XOR'ed usando um gerador pseudo-aleatório feito sob encomenda. O kernel é modificado para ter a mesma função de criptografia, que funciona como decodificador.
4. O sistema em si é despojado, por isso não há como usar um teclado ou armazenamento externo. Um único aplicativo é executado em tela cheia.

Então, depois que o gerenciador de inicialização carrega o kernel e o initrd, o kernel descriptografa o initrd e executa seu script de inicialização, que irá gerar a senha e montar o sistema de arquivos raiz.

Minha pergunta é: Como seria fácil quebrar essa configuração (para descriptografar o sistema de arquivos raiz e fazê-lo inicializar a partir de qualquer cartão SD)? Quais são as partes mais fracas? Quão fácil é descompilar o kernel e encontrar essas funções de criptografia personalizadas?

EDIT: Aqui estão algumas correções para que você não perca tempo com as coisas óbvias:

1. O dispositivo raiz será criptografado com LUKS (aes256) e a chave será gerada por alguma função HMAC usando o CID do cartão SD e um pouco de sal.
2. O algoritmo pseudo-aleatório para criptografia initramfs será de fato RC4, apenas a chave será gerada usando alguma função personalizada, porque se eu apenas armazenar a chave em uma matriz de bytes, torna-se simples recuperá-la (sim, isso é segurança através da obscuridade, mas parece não haver outro caminho).
3. Eu entendo que se usar um emulador de cartão SD alguém pode fazer uma cópia deste sistema iniciar, mas está tudo bem comigo, porque é muito difícil e ninguém pode fazer isso (também ninguém vai querer lidar com emuladores)

Answer 1

How easy it would be to break this setup (to decrypt the root filesystem and make it boot from any sd card)?

Como é difícil "quebrar" sua configuração depende do número de bits de entropia em qualquer método que você esteja usando para assinar / criptografar o próprio sistema de arquivos (pois isso determina o número total de combinações exclusivas que podem ser usadas para força bruta a senha).

What are the most weakest parts?

Sem dúvida, usando um CID predefinido como senha, bem como usando uma função personalizada de geração de números pseudo-aleatórios.

O CID de um cartão SD só é supostamente para ser somente leitura, mas não é incomum encontrar dispositivos de memória flash não compatíveis neste dia e idade. Algumas pessoas demonstraram a capacidade de substituir > o CID por certos cartões SD . Isso tornaria mais fácil a força bruta da senha, especialmente se alguém estiver apenas emulando um cartão SD após clonar o seu (o que é algo que você pode querer considerar).

Finalmente, usar qualquer tipo de gerador de números pseudo-aleatórios já possui algumas falhas intrínsecas, precisamente porque é não aleatório - há uma razão pela qual é chamado de pseudo-aleatório . Talvez seja melhor usar um gerenciador de inicialização criptografado pré-feito (como o TrueCrypt ou o LUKS, ambos trabalhando no Raspberry Pi) e evitar para fazer quaisquer modificações manuais no kernel.

How easy is to decompile the kernel and find those custom encrypting functions?

É muito difícil descompilar qualquer coisa. Por outro lado, a desmontagem de um aplicativo compilado geralmente é trivial e há muitas ferramentas que podem ser usadas para auxiliar na montagem de engenharia reversa em outra linguagem de nível superior. Se um invasor tiver acesso até mesmo a um kernel compilado, analisar algo como um gerador de números pseudo-aleatórios provavelmente é trivial, a menos que o código seja ofuscado de propósito.

TL, DR : não reinvente a roda quando se trata de criptografia e segurança, siga o exemplo. Existem várias opções de criptografia de disco completo que já estão disponíveis e demonstraram funcionar bem no Raspberry Pi. Eu evitaria usar o CID do cartão SD como uma espécie de "senha" - mesmo que não possa ser alterado, existem maneiras de falsificar esse valor.

A proteção contra cópia já está incluída na especificação do cartão SD como CPRM .

    

Answer 2

Alguém habilidoso não teria muita dificuldade em resolver isso. Seria relativamente fácil inicializar o cartão SD em um emulador e depois ler as chaves da memória RAM. Então eles postam uma versão sem a proteção contra cópia para o Pirate Bay (etc.), e é isso.

Como alternativa, use o emulador para injetar o shellcode no sistema emulado em execução. Em seguida, use o sistema em execução para copiar os rootfs descriptografados (ou leia as chaves usando dmsetup table --showkeys , etc.)

Uma pesquisa rápida revela a existência de emuladores de Raspberry Pi , portanto, parte do trabalho já foi feito.

Você tem outro problema, em particular este:

Kernel is modified to have the same encrypting function, which works as decryptor.

Qualquer um que você distribuir isso tem direito ao código-fonte do kernel, sob os termos da GPL. Então você não precisaria desmontá-lo, você poderia usar apenas diff para encontrar a função extra.

(Não que encontrá-lo através da desmontagem seria tão difícil, como você pode, por exemplo, verificar contra um kernel de estoque)

Eu não estou completamente familiarizado com o código de inicialização do Raspberry Pi, mas se você puder reflash o gerenciador de inicialização com uma chave de criptografia embutida (que é passada para o kernel), pelo menos não no cartão SD, por isso, evitaria uma tentativa de inicializá-lo em um emulador.