Autenticação de dongle de hardware de dispositivo Linux em sistemas de nível superior

A IoT industrial é o monitoramento, programação e automação de sistemas de engenharia de instalações industriais, edifícios, instalações comerciais. Sensores de vários parâmetros, medidores e controladores coletam dados desses objetos, por exemplo, temperatura e umidade na sala do servidor, leituras de medidores de água em prédios de apartamentos, o nível de dióxido de carbono nas salas. Os controladores processam essas informações e enviam tudo para a "nuvem".

A Wiren Board fabrica controladores Linux para IoT industrial. Os dispositivos coletam dados de poços de petróleo e agências bancárias, monitoram o microclima em servidores e supermercados. Os controladores se integram aos sistemas de nível superior dos parceiros da empresa. Os sistemas autenticam dispositivos - eles entendem que estão conversando com seus sensores, e não com os de outras pessoas, e então eles autorizam. Nesse estágio, surge um problema - existem milhares de controladores, centenas de clientes, mas não existe um sistema de integração único. Métodos tradicionais simples, como pares de login / senha, são vulneráveis ​​a ataques e inconvenientes para implantar.



Portanto, a empresa desenvolveu autenticação em sistemas de nível superior usando chaves de hardware - com base na criptografia assimétrica padrão usando um elemento protegido por hardware para armazenar chaves. Agora, não é necessário um sistema de integração unificada - a autenticação e a autorização estão protegidas e funcionam de imediato. Evgeny Boger lhe dirá como fazer isso: como eles escolheram o “chip criptográfico”, como o parafusaram no hardware e no Linux, como as bibliotecas e os softwares comuns foram criados para serem amigos dele. Ênfase particular na implantação: a introdução da inicialização do dispositivo na produção, a introdução do suporte para vários softwares de nível superior, incluindo os de terceiros e fechados.

Sobre o palestrante: Eugene Boger ( evgeny_boger ) - CTO e co-fundador do Wiren Board. Envolvido em sistemas embarcados e, especialmente, Linux embarcado.

Os problemas

Para começar, o que estamos fazendo e de onde veio esse problema. Nós da Wiren Board projetamos e fabricamos equipamentos na Rússia. Costumava ser chamado de M2M, mas agora - IoT industrial. Esta é a automação de sistemas de engenharia de construção, monitoramento e programação. Resumidamente, todo o trabalho se parece com isso: sensores de vários parâmetros, atuadores, contadores e controladores (edge-computing ou IoT-gateway) coletam dados diferentes dos objetos, processam-nos, executam a lógica local e os reúnem em um grande sistema de despacho, monitoramento ou controle .



Não temos um ecossistema inteiro, ao contrário de alguns concorrentes. Fabricamos equipamentos que se integram a vários sistemas de nível superior de nossos parceiros. Existem muitas empresas parceiras e elas compartilham responsabilidades. Sem bons meios técnicos, a integração não funcionará - simplesmente não pode ser negociada.

Existem duas soluções simples para resolver esses problemas. O primeiro é fornecer o nome de usuário / senha ao cliente , como todos fazem, e o segundo é gerar e costurar o "segredo" no local de trabalho . Ambas as opções não nos agradaram - vou lhe dizer o porquê.

Soluções simples

A primeira solução é emitir um nome de usuário e senha para o cliente . Todos nós fazemos isso até recentemente.

Para autenticar um dispositivo que envia dados para algum sistema, você pode criar uma chave secreta - logon / senha condicional ("segredo"). Será comum em controladores e em um sistema de nível superior que coleta dados de vários controladores.

Um par de nome de usuário / senha (um "segredo" comum)) deve, de alguma forma, ser dado ao cliente - a empresa ou a pessoa. Alguém deve gerar um par secreto, enviá-lo por e-mail, autenticar o cliente pelo número da conta. Este é o procedimento padrão - baixa tecnologia.

Problema . É que temos muitos desses sistemas. Nosso cliente, e ele pode enviar dados para o sistema de nosso parceiro. Essa é uma interação complexa entre todas as partes envolvidas.

Além do problema de muitos sistemas, existem outros.

• Entrega ruim e entrega ao cliente .
  
• Logins e senhas são armazenados no servidor . Se também armazenarmos hashes, isso nos protegerá um pouco dos vazamentos. Mas, mesmo assim, surge uma sensação desagradável quando as chaves secretas de todos os controladores de clientes são armazenadas no servidor. Alguns deles podem lidar com tarefas críticas: iluminação externa, monitoramento de plataformas de petróleo.
  
• Sincronização entre serviços .
  
• Recuperação de perdas . Não está claro o que fazer em caso de perda, quando o cliente apagou a memória do controlador - em que memória devo escrever? Você tem que repetir tudo de novo.
  
• Proteção contra cópia de detalhes . Existem sistemas de monitoramento pagos que fornecem ao cliente um serviço e cobram taxas de assinatura. Não quero que o cliente final seja capaz de ignorar o sistema através de nós - pague uma vez, mas use dois.
  

A segunda solução é gerar e costurar um "segredo" na produção . Esta é uma melhoria na solução anterior.

O esquema é o seguinte: nós, como fabricantes de controladores, pré-geramos nomes de usuário e senhas para todos, os costuramos em nosso sistema e os inserimos em equipamentos. Logins e senhas do equipamento não podem ser lidos nem alterados. Isso é melhor que a opção anterior, porque não requer interação entre as pessoas.

Os problemas Todos os problemas permanecem, exceto o primeiro, mas o principal é a sincronização entre os serviços e a intranet . Existem muitos serviços e não está claro como sincronizá-los - por isso, não conseguimos implementar a segunda solução. Temos clientes que usam equipamentos em suas redes fechadas. Lançamos um novo controlador, vendemos para um cliente e seu sistema está fechado. Está configurado, funciona uma vez e é difícil transmitir os "segredos" ainda mais. Relatar em lotes? Tudo é complicado nas organizações, embora tecnicamente simples.

Ambas as soluções não nos agradaram. Por isso, decidimos seguir um caminho diferente. Mas antes disso, eles decidiram delinear metas e objetivos comuns.

Tarefas e Objetivos

Primeiras tarefas comuns.

Autenticação Essa é uma maneira de entender quem está falando com o sistema de nível superior, quem se conecta exatamente ao sistema de despacho.

A autenticação não é conceder ou delimitar direitos de acesso, mas uma maneira de entender quem está falando conosco.

A tarefa de enviar dados . Nossos controladores são computadores Linux projetados para uma tarefa especial. Precisamos deles para enviar dados para sistemas de nível superior, conectar via VPN. Ao mesmo tempo, queremos que o despacho funcione “pronto para uso” - sem as configurações e a interação de nossos clientes e usuários finais do sistema conosco e com os clientes.

Outras tarefas . Essa é uma conexão confiável, criptografia de canal de dados, mas um problema separado é a autorização . A tarefa de autorização está associada a serviços externos e é dividida em três partes.

• Serviço de fabricante gratuito . Forneça acesso pelo número de série do dispositivo.
  
• Listas brancas de números de série para o serviço de nossos parceiros - vincule compras e acessos à conta do cliente.
  
• Licenças Permitir ou negar acesso com base nas opções especificadas no certificado.
  

Metas são o que queremos alcançar quando resolvemos problemas.

Emissão e entrega ao cliente . Sem a participação de pessoas - as informações são costuradas pelos robôs na produção.

Recuperação de perdas . Queremos que não haja perda de detalhes secretos.

Entrega da produção aos serviços . Queremos ficar sem ele, para que você não precise entregar nada aos serviços. Ao lançar novos equipamentos, não queremos atualizar os bancos de dados de todos os serviços que devem autenticar esses dispositivos.

Armazenamento no servidor . É aconselhável não armazenar nada lá.

Sincronização entre serviços e intranet . Também é aconselhável não sincronizar nada - porque não armazenaremos nada.

Proteção contra cópia de detalhes . Queremos algo secreto, para o qual o dinheiro é levado, era impossível copiar e receber gratuitamente.

Assinatura digital corre para o resgate

A assinatura digital eletrônica (EDS) é uma tecnologia em torno da qual tudo funciona para nós.

É como uma assinatura comum, apenas digital. É fácil verificar o EDS, mas difícil de falsificar. As verdades familiares da criptografia, que têm décadas.

Uma assinatura eletrônica é algo que pode ser contado por uma mensagem se você souber a chave privada secreta (chave privada). Se você conhece a chave pública (chave pública), é fácil verificar se a assinatura eletrônica da mensagem está correta. O nome é claro - o público costuma informar a todos, e o segredo é apenas para quem assina.

Todas as assinaturas e chaves são apenas números.

No nosso caso, são 32 bytes de dados, que funcionam na “mágica” matemática. O Math garante que a assinatura seja fácil de verificar, mas difícil de falsificar.

Usamos a assinatura ECDSA-256 + SHA-256:

• e = HASH(m) - a função de hash criptográfico converte irreversivelmente a mensagem m no número e;
  
• private key (dA) - número aleatório;
  
• public key (QA) - gerada a partir de uma chave privada, mas não vice-versa;
  
• signature (r,s) = sign(private key, e) - assinatura;
  
• verify(public key, signature, e) - verificação da assinatura.
  

Autenticação EDS. Primeira tentativa

O que pode ser feito para nossa tarefa usando esse mecanismo complicado, que funciona em uma direção de maneira simples e na outra difícil?

Emissão e entrega ao cliente . Geramos uma chave privada aleatória para cada dispositivo na produção. Não contamos a ninguém, porque nem o conhecemos e escrevemos no dispositivo.

Entrega da produção aos serviços . Em seguida, usamos apenas a chave pública deste dispositivo para autenticação nos serviços. Nos serviços, armazenamos apenas uma lista de chaves públicas em vez de senhas.

Algoritmo de verificação de integridade padrão:

• o serviço envia uma mensagem aleatória m para o controlador;
  
• controlador: sign(private key, m) ;
  
• o controlador envia uma assinatura para o serviço;
  
• serviço: verify(public key, signature, m) .
  

A única coisa que decidimos dessa maneira é que não armazenamos mais "segredos" comuns em nossos serviços de forma aberta ou em cache. Não é isso que queremos.

Autenticação EDS. Segunda tentativa

Não queremos armazenar algo em serviços. Para conseguir isso, podemos forçar nossos dispositivos a enviar suas chaves públicas para o serviço.

Na última etapa, resolvemos dois problemas. O primeiro - verificamos que eles deram a chave do serviço . Temos uma chave pública, o que significa que também criamos uma chave privada. A segunda - garantimos que o dispositivo possua uma chave privada , que fica em algum lugar na unidade flash USB. Se o dispositivo puder assinar algo, ele possui uma chave privada.

Agora o dispositivo também enviará a chave pública para o serviço. Como verificar se ninguém o interceptou, não o falsificou e se tudo funciona?

Verificando a chave pública . Nós nos criamos outra chave pública. Ele será a nossa chave como fabricante. Esta é a chave raiz "chave privada raiz + chave pública". Com essa chave secreta raiz em produção, assinaremos a chave pública do dispositivo e armazenaremos essa assinatura no dispositivo. O dispositivo deve enviar sua chave pública e assinatura da sua chave pública ao serviço. Agora o serviço pode verificar a chave pública do dispositivo. Se for assinado com a chave privada raiz, emitimos essa chave.

Somente o fabricante - podemos criar e armazenar uma assinatura no dispositivo, mas verifique tudo.

Publicamos a chave pública no site na seção "Contatos". Qualquer pessoa pode pegá-lo e verificar a chave pública do dispositivo que o enviou ao serviço. Em seguida, você pode verificar se o próprio dispositivo possui sua própria chave privada.

O algoritmo geral se parece com isso.

• (once) random root private key ;
  
• factory: random device private key ;
  
• factory: sign(root private key, device public key) = signature_1 ;
  
• device->service: device public key + signature_1 ;
  
• service: verify(root public key, signature_1, device public key)?
  

Resultado da segunda tentativa

Resolvemos o problema com a entrega ao cliente - as informações são costuradas no local de produção e nada precisa ser restaurado .

É importante que resolvamos o problema de fornecer "segredos" aos serviços de nível superior , porque tudo o que precisa ser armazenado no serviço é a chave pública do fabricante. A chave inteira tem 33 bytes. Com a ajuda e a mágica matemática, você pode continuar a fazer uma conexão de handshake e verificar se o dispositivo possui a chave privada correspondente.

No servidor , armazenamos apenas a chave do fabricante (chave pública raiz).

Não temos sincronização entre serviços e a intranet , sobre a qual já falamos. Além disso, não temos proteção contra a cópia de detalhes .

A única coisa que esquecemos é a autenticação . O dispositivo enviou uma chave privada, e verificamos se fizemos e emitimos, e verificamos se o dispositivo é o proprietário. Mas não sabemos que tipo de dispositivo é esse e produzimos milhares deles.

Portanto, aplicamos um truque chamado "Certificado".

Autenticação e Certificados

Nesta etapa, em toda a mágica matemática com assinaturas e suas verificações, adicionamos informações adicionais - um certificado . Para fazer isso, registramos na fábrica não apenas a chave pública (chave pública do dispositivo), mas a chave com informações adicionais.

Informações adicionais em nosso caso.

• Data de fabricação e fabricante.
  
• Modelo e configuração de hardware.
  
• O número de série pelo qual o dispositivo pode ser autenticado.
  
• Opções: hardware e software. Configurações diferentes podem não diferir fisicamente uma da outra, mas o certificado conterá informações sobre o que o cliente pagou.
  
• Nome do cliente e número da conta.
  

Assinaremos todas essas informações juntamente com a chave pública com nossa chave produtora - chave pública raiz. Depois disso, as informações serão enviadas para os serviços e eles poderão garantir que estão corretas. Como esses são os nossos serviços e os de nossos parceiros, eles confiam em nós.

Status da meta

As informações também são costuradas na fábrica e a entrega aos serviços não é necessária. No servidor, armazenamos apenas a chave do fabricante.

Recuperação de perdas . Costuramos todas as informações dos certificados na memória flash do dispositivo. Teoricamente, ele pode ser excluído acidental ou intencionalmente, mas não há nada secreto nessas informações no certificado. Mesmo a assinatura em si não é secreta - há uma chave pública e a assinatura com a nossa chave. O único segredo do certificado é o volume de vendas de dispositivos com opções diferentes.

O certificado pode ser armazenado na fábrica e enviado ao cliente se ele o tiver perdido. Os clientes raramente apagam especificamente a área de serviço da memória. Geralmente, fazemos isso durante o procedimento de recuperação do dispositivo: o dispositivo chegou do cliente, passou completamente pela inicialização, tudo foi apagado, foi baixado novamente e o certificado foi copiado do banco de dados de fábrica.

Não temos recuperação de perdas, proteção contra cópia e sincronização entre serviços .

No estágio de autenticação, recebemos e verificamos o certificado. Entendemos que tipo de dispositivo é - sabemos o fabricante, modelo e número de série, o que ele pode e não pode.

Entrar

O certificado permite armazenar informações para autorização.

Serviço de fabricante gratuito . Conhecendo o número de série do dispositivo, você pode dar acesso a todos. Nos nossos serviços, damos acesso a todos os nossos clientes básicos.

Listas brancas de números de série . Para o serviço de nossos parceiros, você pode criar uma tabela com uma lista branca de números de série: "O cliente Vasily comprou de nós dois controladores com esses números de série associados à sua conta"

Licenças Você pode vender algo com antecedência e, em seguida, permitir ou negar o acesso com base nas opções especificadas no certificado - um controlador com uma licença para o sistema X.

Não existe uma base comum entre serviços, fabricante ou fabricante de sistemas. Tudo funciona exclusivamente com informações do controlador assinado por nós, como fabricante, quando é autenticado no sistema.

Certificado intermediário

Outro problema técnico que resolvemos na estrada. No esquema que acabei de falar, existe um certificado raiz do fabricante - chave privada raiz. É fisicamente necessário toda vez que você cria um dispositivo. Mas se houver muitos dispositivos, essa chave precisará de acesso constante para um círculo limitado de pessoas. Isso é ruim, porque se você o perder, precisará atualizar as chaves públicas em todos os serviços e não deve chegar aos invasores. Esses são grandes problemas organizacionais. Mas existe uma solução.

Introduzimos chaves intermediárias em um lote de dispositivos que não são tão assustadores de perder.

Fizemos o mesmo, apenas a corrente é mais longa.



Com um certificado do fabricante, assinamos a chave intermediária. Fisicamente, este é um "flash drive", que é dado ao capataz na fábrica por um dia. O hardware limita o número de dispositivos que uma chave pode assinar. No meio do esquema, adicionamos um certificado intermediário, caso contrário nada mudou.

Keystore seguro

Em tudo isso, não temos proteção suficiente para a chave privada do dispositivo - esse ainda é um arquivo localizado em uma unidade flash USB. Um invasor pode copiá-lo, mas provavelmente o perderá ou abrirá acidentalmente o acesso.

No caso ideal, seria bom proteger a chave privada do dispositivo contra cópia - coloque-a em uma caixa preta.

A caixa preta realiza 4 operações:

• dentro de si gera uma chave mediante solicitação, mas não fornece;
  
• dá a chave pública;
  
• Assina uma mensagem
  
• verifica a assinatura.
  

Para verificar a assinatura, você só precisa de uma chave pública, portanto, três operações são suficientes.

No meu entendimento, essa deve ser uma solução de hardware, preferencialmente separada do processador. Existem várias opções, a melhor delas é um processador de criptografia especial dentro do SoC ou como um chip separado.

A primeira opção de caixa preta que analisamos é o módulo CAAM nos processadores NXP i.mx 6, 7, 8 que usamos. O problema é que ele é implementado programaticamente na ROM de inicialização do processador.

Pode conter erros que podem ser encontrados e até explorados por outras funcionalidades do processador. Há alguns anos, um módulo foi encontrado neste módulo que permitia ignorar a verificação de assinatura ao baixar o firmware. Essa não é a funcionalidade de que precisamos, mas o sedimento permanece. Outro problema é que é difícil importar processadores com este módulo para a Rússia, pois eles precisam preencher a papelada.

Portanto, pegamos um chip separado. Eu admito sinceramente, contei com o fato de que, se não pudermos trazê-lo para a Rússia, criaremos algo - o chip é pequeno, custa US $ 1. Mas tudo saiu bem - eles encontraram o chip Microchip ATECC , que já possui todos os papéis.

Microchip ATECC608A

Este é um pequeno chip separado que custa um centavo. O chip é conectado via I2C - duas "pernas" do processador, que você também pode compartilhar com outros periféricos. O chip tem uma pinagem padrão. Usamos o chip nas primeiras versões do equipamento e simplesmente o soldamos em cima de outro chip com o mesmo protocolo e pinagem, porque é padrão.

O chip pode fazer o que precisamos com esse chip: ler assinaturas, chaves de loja e muito mais.



Características

• 16 slots de teclas;
  
• pode ler assinaturas ECSDSA, hashes, MACs e criptografar AES, pode DH;
  
• possui um gerador de números aleatórios e contadores criptográficos;
  
• Caixas: SOIC-8, DFN6;
  
• protocolos: I2C, fio único;
  
• ~0.7$@1000pcs.
  

Como trabalhar com um microcircuito

Existe documentação decente para isso , mas sob o NDA. Se você escrever imediatamente para gamma.spb.ru, eles o entregarão em duas semanas. Se em outra empresa - após 3 meses. Escrevemos para duas empresas e, quando tínhamos feito tudo, outro revendedor de Microchip nos respondeu.

Existem poucas appnotes e elas são piores que a média. Há software no GitHub - uma biblioteca com HAL. É engraçado - a documentação está sob a NDA e o software que está escrito nela está no GitHub. O software não suporta Linux, mas suporta o Raspberry Pi e o Atmel MK - isso é um pouco diferente. Os desenvolvedores acreditam que em todos os equipamentos existe apenas um barramento I2C, por exemplo, as pernas são chamadas como no Raspberry Pi.

Há integração com o OpenSSL - ele não funciona bem, mas funciona. Não há exemplos no Linux e nenhum trabalho com personalização .

Personalização de chips

A personalização é a maior dor de cabeça do chip.

O problema é que o chip pode fazer muitas coisas. Possui 16 slots nos quais 16 chaves são armazenadas: dados do usuário ou chaves públicas ou armazenamento temporário para outros slots - há muitas opções.

Você precisa, de alguma forma, restringir o acesso aos slots, e também existem muitas opções de configuração: restringir por senha, por autenticação em outro slot, no momento do acesso às fábricas.


Na tabela, o tipo de chave, acesso de leitura e gravação, o relacionamento entre os slots - SlotConfig, KeyConfig.

Na máscara de bits (16 bits) de cada chave que usamos, existem números diferentes em todos os lugares.

O mais triste é que a zona de configuração é única, o que define as funções dos slots. Desarrumamos 50 fichas antes de fazer tudo certo. O chip só funciona após o bloqueio da configuração . Separadamente, há um bloqueio para slots individuais

Não há documentação nos exemplos ou no software. Há documentação para bits individuais, mas tudo é complicado lá. Em todos os exemplos do Microchip, está escrito: "Faça o download de um bloco desse tipo e, de alguma forma, funcionará para você, como no exemplo do envio de dados para a Amazon".

Demorou muito tempo, mas no processo eles criaram um utilitário interessante.

Utilitário Atecc-util

Este é um utilitário de console que pode executar a maioria das funções do chip e permite que você trabalhe um pouco mais fácil. Está disponível no GitHub sob uma licença MIT.

O utilitário usa CryptoAuthLib. Ela sabe como trabalhar de forma mais amigável com a zona de configuração, como trabalhar com SHA, MAC, ECDSA, DH. A interface é compatível com lotes, porque criamos o utilitário para uso em scripts em primeiro lugar. O fato de uma pessoa poder causar isso é uma característica secundária. O utilitário pode fazer uma lista - um plano de comandos: "Primeiro, personalize esta zona e depois escreva essa chave".

Um exemplo de chamada de utilitário é bastante legível por humanos.

 atecc - b 10 - c 'serial' - c 'read-config /tmp/config.dump' 

O utilitário é construído no Linux, no AMD64 - está no pacote Debian.

Outras ferramentas de personalização

Temos uma placa do Excel para ler os bits. Se você nos mostrar uma digitalização NDA com Microchip, nós a forneceremos.



Cobrimos tudo com testes, pois existem muitas opções em que você pode esquecer um pouco e algum comando de serviço lê sua chave privada. Testes testam o dispositivo real. Eles se voltam para o microcircuito e verificam a configuração correta no dispositivo: esse slot pode ser lido, pode ser feita uma assinatura?

Paralelamente aos bits, criamos uma lista de garantias que esse dispositivo deve satisfazer e verificamos como tudo funciona. Usamos a estrutura dos morcegos - uma coisa muito interessante. Parece assim.


Lista de testes para um exemplo. Os superiores são passados, mas os inferiores não.

Configurações nos dispositivos

Para nós mesmos, usamos apenas dois slots para a tarefa que estou falando. Em ambos, armazenamos a chave privada do dispositivo. A diferença é que o primeiro está associado a um certificado permanente , que foi emitido em 1970 por 200 anos.

Isso se deve ao fato de que no tempo da IoT nem sempre é sincronizado. A infraestrutura de certificado envolve a verificação da validade de um certificado. Se a sincronização nos dispositivos estiver interrompida, algum serviço vital poderá falhar, por exemplo, VPN.

Portanto, um slot é infinito - permanente . É gerado uma vez e não muda ao longo da vida útil do dispositivo. Para essa chave, um certificado é gerado por 200 anos - para redes fechadas.

Outro slot está sendo atualizado. A vida útil máxima do certificado é de um ano. Isso é feito apenas no caso de algo ser comprometido. Uma chave de dispositivo atualizável privada é gerada quando o período de validade do certificado do dispositivo expira. Usado para autenticação em redes abertas, atualizado uma vez por mês ou menos, junto com um certificado.

Para os usuários, geramos várias combinações , incluindo vários slots para chaves ECDSA privadas. Os usuários podem gerar suas chaves em um slot separado se não confiarem em nossa chave privada. Para isso, você precisa confiar apenas no Microchip. Os usuários podem ler assinaturas, fazer criptografia - demos tudo o que o chip pode fazer.

Até agora, infelizmente, ninguém usou, mas esperamos que sim.

Infraestrutura: Chaves Intermediárias

Eu já disse que em algum momento implementamos certificados intermediários para não brilhar com um certificado raiz que não deve ser perdido. Ele nunca aparece em uma fábrica.



Certificados fisicamente intermediários são um chip ATECC508A. Difere ligeiramente de 608, mas em 508 há funcionalidades úteis para chaves, mas em 608 não está mais lá.

O chip é conectado através de um adaptador USB-I2C. Este é o USBISP com o firmware tiny-usb-i2c - um programador que pode ser instalado em uma ponte USB-I2C. Certificados intermediários assinam certificados de dispositivo com sua chave privada.

Duas características do microcircuito foram úteis para nós.

Slot de proteção por senha de hardware . O chip pode ser programado para ler a assinatura somente se duas condições forem atendidas:

• quando o dispositivo está preso em um computador;
  
• senha digitada.
  

Damos ao capataz da produção uma chave e uma senha intermediárias para vários controladores. Portanto, você precisa roubar a chave e a senha para obter acesso. Temos essa oportunidade de graça, mas melhora a segurança do sistema.

Limite de hardware para o número de usos . O contador criptográfico interno só pode aumentar. Quando atinge um limite predeterminado uma vez, o microcircuito não assina mais nada.

OpenSSL no cliente

Vamos considerar como tudo funciona no cliente. Temos o OpenSSL no controlador. Nós não inventamos nada - isso é TLS comum, PKI comum. Além disso, precisávamos de uma biblioteca cliente. Na grande maioria do software Linux, é usado para uma conexão segura.

Pegamos o código do Microchip, adicionamos um pouco, suportamos o novo OpenSSL
1.1 Como resultado, ele sabe como trabalhar com uma chave de hardware - o hardware suporta senhas para chaves privadas.

Parece algo assim.

 openssl req -new -engine ateccx08 -keyform engine -key ATECCx08:00:04:C0:00 -subj "/CN=wirenboard-AP6V5MDG" -out device AP6V5MDG.csr 

Esta é uma chamada para o OpenSSL regular e uma instrução para usar o módulo de mecanismo apropriado. A chave é definida aqui: endereço, modelo e os últimos dois bytes é o número do slot usado. Tudo é transmitido como se fosse um arquivo-chave, mas não é um arquivo - você precisa acessar o dispositivo.

SSL no servidor

Qualquer SSL funciona no servidor, incluindo o OpenSSL. Não são necessárias modificações e construções personalizadas no lado do servidor. Tudo o que é necessário no servidor é poder verificar a cadeia de pacotes de certificados (dispositivo cert + certificado intermediário) e armazenar nossa chave pública , que publicamos no site - Wiren Board ROOT CA.

O TLS padrão diz que ambas as partes devem se autenticar. — — . — handshake.

: . , . letsencrypt SSL, , .

, — MQTT.

MQTT: mosquitto

IBM. .

Mosquitto — , , Linux. , OpenSSL engine ( ) «keyfile», . , 20 .

bundle.



.

 mosquitto_sub -h mqtt.wirenboard.com -p 8884 -cert /etc/ssl/device/device_bundle.crt.pem --key 'engine:ateccx08:ATECCx08:00:04:C0:00' --capath /etc/ssl/certs/ -t /# -v 

. — -cert . bundle- — . --key . .

, --capath , . SSL-, letsencrypt.

.

 root@wirenboard-AXXVJI62:~# cat /etc/mosquitto/conf.d/bridge-hw.conf connection wb_devices_cloud.wirenboard-AXXVJI62 address contactless.ru:8884 bridge_capath /etc/ssl/certs/ bridge_certfile /etc/ssl/device/device_bundle.crt.pem bridge_keyfile engine:ateccx08:ATECCx08:00:04:C0:00 notifications true notification_topic /client/wirenboard-AXXVJI62/bridge_status topic/# both 1 ""/dient/wirenboard-AXXVJI62 

Mosquito- .

Mosquitto — .

 per _listener_settings true listener 8884 0.0.0.0 cafile/etc/mosquitto/certs/WirenBoard_Root_CA.crt certfile /etc/letsencrypt/live/contactless.ru/fullchain.pem keyfile/etc/letsencrypt/live/contactless.ru/privkey.pem require.certificate true use_identity_as_username true password_file /etc/mosquitto/passwd.conf allow_anonymous false acl_file /etc/mosquitto/ad.conf :~$ cat /etc/mosquitto/acl.conf pattern write /client/%u/# pattern read /client/%u/# 

— .

• Root CA letsencrypt- — . .
  
• Mosquitto. username MQTT.
  
• , , , (CN) wirenboard-AXXVJI62, , .
  
• per_listener_settings: , / (>1.5.5).
  

MQTT- Wiren Board IoT Cloud Platform.

Openvpn

OpenVPN , , . , .

OpenVPN , . , : bundle, , engine.

 openvpn --capath /etc/ssl/certs/ --cert /etc/ssl/device/device_bundle.crt.pem --key engine:ateccx08:ATECCx08:00:04:C0:00 

letsencrypt.

 ca /etc/openvpn/WirenBoard_Root_CA.crt cert /etc/letsencrypt/live/vpn1.wirenboard.com/fullchain.pem key /etc/letsencrypt/live/vpn1.wirenboard.com/privkey.pem 

— . - .

Nginx

. Nginx , , , SSL. nginx web-, reverse-proxy. — nginx.

nginx , HTTP-, . , : Common Name, , . , 400.

 ssl_client_certificate WirenBoard_Root_CA.crt; ssl_verify_client on; 

nginx . — , HTTP. Linux- nginx , SSL, , OpenSSL.

wget , bash , HTTP- TLS . 10 .

 server { listen 8080; location / { proxy_pass https://example.com; proxy_ssl_name example.com; proxy_ssl_server_name on; proxy_ssl_certificate/etc/ssl/device/device_bundle.crt.pem; proxy_ssl_certificate_key engine:ateccx08;ATECCx08:00:04:C0:00; } } 

Wiren Board 6 , . , .

web- cloud.wirenboard.com OpenVPN . Grafana InfluxDB, MQTT. saymon.info — (MQTT) .

, - , , Grafana, MQTT-, , , . — .

, , : — OpenSSL , — . !

InoThings Conf 2019 . YouTube- 2019 . Telegram. , , IoT.