Como posso proteger o software no Pi para uso comercial?

Gostaria de usar o Raspberry Pi em um produto comercial, mas gostaria de impedir a engenharia reversa do software no dispositivo. O software em questão seria escrito em Ruby. Suponho que o usuário final tenha acesso físico ao cartão SD e seja inteligente o suficiente para obter acesso root ao Pi.

A meu ver, as opções podem incluir:

• Criptografar parte (ou todo) do cartão SD
• Ofuscar o código Ruby ou compilá-lo no bytecode (JRuby ou Rubinius)

A criptografia seria a melhor solução, mas não consigo pensar em uma maneira de descriptografar sem pedir a chave do usuário. A ofuscação de código é definitivamente possível, mas menos segura em minha mente.

É possível criptografar uma parte do cartão SD sem solicitar ao usuário uma chave para descriptografá-lo? Ou existe uma maneira melhor de garantir que o código esteja acessível apenas no dispositivo desejado?

É claro que é possível descriptografar arquivos / containers criptografados / etc. sem pedir uma senha. É suficiente armazenar a senha (criptografada) no cartão SD e usá-la para descriptografar seus dados. Por exemplo, uma openssldemonstração fácil pode ser:

openssl enc -a -e -salt -aes-256-cbc -pass pass:abc123 -in /tmp/plaintext.txt -out /tmp/ciphertext.enc

openssl enc -d -a -aes-256-cbc -pass pass:abc123 -in /tmp/ciphertext.enc

A criptografia seria realizada durante a instalação do software no Pi, e a descriptografia seria realizada em tempo de execução, possivelmente na RAM. Por exemplo, a senha pode ser uma combinação de algum número de sequência pseudo-aleatória (conhecido por você) e o número de série do Pi específico obtido de a cat /proc/cpuinfo. Então você precisa encontrar um local adequadamente oculto para armazenar esse número pseudo-aleatório, que é para todos os efeitos " a senha " e, portanto, o ponto fraco de todo o mecanismo de criptografia. Por exemplo, um setor sobressalente no SD seria a escolha típica, mas você pode até incorporá-lo a um de seus executáveis.

De qualquer forma, sua melhor opção é criptografar e compilar seu software, para adicionar diferentes camadas de ofuscação ao seu software.

Por fim, se o seu software precisar de uma conexão com a Internet, você pode fazer o Pi solicitar a senha todas as vezes. Você ainda precisará ocultar a senha dentro da conexão, também precisará usar httpse proteger contra ataques de resposta, usando o horário atual saltpara a criptografia.

Você tem muitas opções (baratas) para tornar seu software seguro. Mas você precisa saber que, se o seu software atingir um limite de popularidade bem definido, ele será quebrado, com certeza, mesmo se você investir quantias substanciais em proteção.

Na prática, se o código e as chaves estão em uma máquina de cartão SD, eles vão ser capazes de de-compilá-lo, eles vão ser capazes de descobrir as chaves e eles vão ser capazes de extrair os dados sensíveis.

É como criptografar filmes, um DVD deve incluir todas as informações necessárias para descriptografar o filme para que possa ser exibido ao espectador, para que todos os mecanismos de proteção contra cópia de filmes estejam condenados.

O melhor que você pode fazer é mudar a economia da engenharia reversa do seu produto.

Vale a pena a criptografia e / ou ofuscação?

Agora, estabelecemos que não há como se proteger completamente, as perguntas se tornam

1. Qual a probabilidade de isso acontecer?
2. Qual é o valor para outra pessoa do seu algoritmo e dados?
3. Qual é o custo para eles comprarem uma licença para usar seu software?
4. Qual é o custo para eles de replicar seu algoritmo e dados?
5. Qual é o custo para eles da engenharia reversa de seus algoritmos e dados?
6. Qual é o custo para você proteger seu algoritmo e dados?

Se estes produzem um imperativo econômico significativo para proteger seus dados / algoritmo, você deve tentar fazê-lo. Por exemplo, se o valor do serviço e o custo para os clientes forem altos, mas o custo da engenharia reversa do seu código for muito menor do que o custo de desenvolvê-lo, então as pessoas poderão tentar.

Então, isso leva à sua pergunta

• Como você protege seu algoritmo e dados?

Ofuscação

A opção que você sugere, ofuscar o código, mexe com a economia acima - ela tenta aumentar significativamente o custo para eles (5 acima) sem aumentar muito o custo para você (6). O problema é que, como na criptografia de DVD, está fadado ao fracasso e, se houver um diferencial suficiente entre 3, 4 e 5, então alguém o fará.

Outra opção pode ser uma forma de esteganografia , que permite identificar quem descriptografou seu código e começou a distribuí-lo. Por exemplo, se você tiver 100 valores flutuantes diferentes como parte de seus dados, e um erro de 1bit no LSB de cada um desses valores não causasse problemas no seu aplicativo, codifique um identificador exclusivo (para cada cliente) nesses bits . O problema é que, se alguém tiver acesso a várias cópias dos dados do aplicativo, seria óbvio que isso difere, facilitando a identificação da mensagem oculta.

Proteção

A única opção realmente segura é fornecer uma parte crítica do seu software como serviço , em vez de incluí-lo em seu aplicativo.

Conceitualmente, seu aplicativo coletava todos os dados necessários para executar seu algoritmo, empacotava-os como uma solicitação para um servidor (controlado por você) na nuvem ; seu serviço calculava seus resultados e os passava de volta ao cliente, o que mostraria.

Isso mantém todos os seus dados e algoritmos proprietários e confidenciais em um domínio que você controla completamente e remove qualquer possibilidade de extração de um cliente.

A desvantagem óbvia é que os clientes estão vinculados à sua prestação de serviços, estão à mercê dos seus servidores e de suas conexões à Internet. No lado positivo, eles estão sempre atualizados com as correções de erros. Infelizmente, muitas pessoas se opõem ao SaaS exatamente por esses motivos.

Este seria um grande passo a ser dado, e pode ter um custo enorme 6 acima, mas é a única maneira que posso ver para manter seu algoritmo e dados completamente seguros .

Recentemente, inventei uma solução muito elegante para esse problema insolúvel. Foi inspirado neste quadrinho do xkcd:

Portanto, a solução é chamada de super cola . Se houver um cartão SD de super cola no PI, será quase impossível extrair o cartão sem danificá-lo.

Você pode até usar um disco SSD externo, criptografado com uma senha armazenada no SD e se sentir seguro!

A compilação no bytecode seria o melhor repelente. Quanto à criptografia, o software pode ser armazenado no volume TrueCrypt, mas apenas se o usuário não obtiver acesso root; simplesmente não há como armazenar a senha com segurança, pois a memória / disco pode ser despejada a qualquer momento para inspeção. Mesmo a ajuda de dispositivos seguros (cartões inteligentes) não faria muito se o software fosse executado onde o usuário possui uma infinidade de utilitários Linux. Tanto quanto sei, a inicialização segura não é uma opção no R-Pi, o que impediria o usuário mexer no sistema operacional.

Se você deseja fazer uma aplicação comercial verdadeira, o Pi, como está em sua forma de usuário final, não é bom para você!

Você terá que projetar sua própria PCB, usar o processador que está no Pi, por exemplo, e incorporar uma memória flash na PCB.

1. Escreva um firmware apropriado para o BCM que gerou um único código de logon com base em algum algoritmo extremamente secreto que só pode ser usado nos próximos 10 segundos.
2. Compile seu próprio kernel com seu software proprietário e ative alguns recursos do Linux que permitem montar raiz a partir de um arquivo criptografado no flash, que contém outra partição criptografada com o seu software. (Proteção dupla)
3. O firmware do BCM gerará uma chave de autenticação altamente secreta, uma vez desativada, com base em algoritmos ou chaves públicas inteligentes e a passará para o kernal linux personalizado, que carregará a partição raiz criptografada e fará mais algumas coisas criptográficas durante a inicialização para carregar sua unidade de software criptografada dentro da imagem criptografada.

DICAS

• É importante fornecer chaves de autenticação com 256/512 bytes de comprimento usando mais símbolos do sistema (HEX) e menos caracteres (ASCII)
• Não use AES, TKIP, pois é facilmente rachado
• Atualmente, a criptografia Whirlpool está entre as mais complicadas de decifrar usando as chaves 256/512
• Mesmo que um hacker possa remover a unidade flash ou despejar o conteúdo. seu software é criptografado duas vezes.
• Se eles interceptarem a chave de autenticação, será muito difícil sair do firmware (porque o BCM pode impedir despejos de firmware)
• Alguns flash rom inteligentes também têm um recurso para evitar despejos de memória cheia.
• Se você estiver projetando um PCB, implementará (como Dell e Apple) um chip de segurança que fornece todos os seus dados e chaves de criptografia e evita tentativas de força bruta. Alguns Dell têm uma autodestruição para uso militar. Se você digitar a senha do BIOS incorretamente duas vezes, ele limpará as unidades com bombas dispersas. Você pode implementar o mesmo se detectar manipulações de chave de autenticação.

Fim do dia. O Raspberry Pi é destinado a fins educacionais para crianças aprenderem a usar o Linux e escreverem alguns programas.

Não é adequado para uso comercial de alto perfil. Você precisa criar seu próprio dispositivo e criar seus próprios sistemas de proteção. Porque se você e mais ninguém sabe como proteger suas informações de propriedade, as chances de alguém as hackear usando uma exploração ou bruto conhecido são de 0,001%

ALTERNATIVAS

• Escreva seu software para que ele possa ser compilado e implantado no sistema de destino em um formato binário. Exemplo de EXE para Windows que roda em .NET, JAR para Java ou (Não tem certeza no linux, C ++?)
• Lembre-se, quanto melhor a segurança que você deseja, mais dinheiro você gastará nela. Não há exceções.

Uma das soluções é usar o endereço MAC do RaspberryPi, que é quase exclusivo para um determinado Pi. Verifique este endereço dentro do seu código e forneça a versão compilada. Isso tornará a engenharia reversa difícil.

Para as pessoas que copiam cegamente o cartão SD para um novo, não funcionará para eles em outro Pi. Isso afastará a grande maioria das pessoas que roubam seu software. Outros que são espertos o suficiente para quebrar isso podem ser espertos o bastante para refazer o software, não são numerosos e não acho que prejudiquem suas vendas.

Você pode usar uma solução baseada em piggy-back: Proteção serial de software para Raspberry Pi

Por que não adicionar um flash baseado em SPI à sua placa de operadora e armazenar seu código? Estou considerando esta opção para o meu próprio produto. Caso o SD seja corrompido, desejo que o usuário final possa escrever um novo, que inclua um raspbian personalizado, e o código para montar o flash SPI e executar o executável.

Outra opção é armazenar uma chave de criptografia no seu RTC. A maioria dos chips RTC possui algum armazenamento e pode ser pré-programada com a chave que permite desbloquear e montar o executável a partir do SD ou do SPI flash.

Acredito que todas as CPUs usadas no intervalo do Raspberry Pi suportam uma inicialização segura por conta própria. Acredito que seja necessário 12 volts para atualizar os 4,8,16,32 ou 64K de flash interno ou EEPROM que o pi em si não possui. A partir deles, você pode configurar o Trustzone com seu código para que todas as coisas boas não possam ser vistas. Também entendo que ambas as formas de RAM estática são estáveis ​​apenas para um determinado número de reescritas. Meu primeiro passo seria ter uma CPU sobressalente e tentar atualizar esta memória de inicialização segura por algumas horas ou dias. Eventualmente, todos os bits são corrigidos para que ninguém mais possa modificar seu código e, dependendo do produto real, você pode solicitar periodicamente uma identificação de dois fatores (como bancos) para que o produto cuspe um código e o código de reativação seja enviado para O endereço de e-mail. Se você modificar um pouco o pi, Acredito que o ARM também tenha um CPUID, portanto existem vários níveis de segurança que você pode usar. Quero dizer, você também pode oferecer um SMS para um número específico. Muitas maneiras.