Ei, Charlie Miller! Vamos falar sobre a proteção de veículos autônomos

Um artigo recente da Wired sobre Charlie Miller (conhecido por hackear e controlar remotamente um Jeep) afirma que “conversação aberta e cooperação entre empresas” são pré-requisitos necessários para a construção de veículos autônomos seguros. Isso parece um tanto rebuscado, quando tantas empresas estão correndo para dominar o futuro da indústria automotiva, antes quase morta, mas recentemente revivida (lembram-se dos três grandes resgates?). Por mais ingênuo que pareça essa parte do artigo, o que realmente me surpreendeu foi a implicação de que a resposta para redesenhar a segurança está exclusivamente na indústria de veículos autônomos.

O conceito de segurança não se limita aos veículos autônomos portanto, não há vantagem em fingir que é esse o caso. Todos os setores da IIoT estão tentando resolver problemas semelhantes e são surpreendentemente abertos para compartilhar suas descobertas. Não estou dizendo que Miller precisa fazer uma jornada de esclarecimento através de todos os outros setores para criar a solução ideal para segurança. Estou dizendo que isso já foi feito para nós, elogios do Industrial Internet Consortium (IIC).

A CII consiste em mais de 250 empresas em vários setores - incluindo fornecedores automotivos como Bosch, Denso e TTTech - com o mesmo problema fundamental de equilibrar segurança, proteção, desempenho e, claro, custos de seus sistemas conectados. Se com fio e Miller estão procurando uma conversa aberta - está acontecendo na CII. A CII publicou a Arquitetura de Referência da Internet Industrial, que está disponível para todos gratuitamente - como em “cerveja grátis”, especialmente se o carro estiver dirigindo por você! As extensões deste documento são o Industrial Internet Connectivity Framework (IICF) e o Industrial Internet Security Framework (IISF). Estes documentos fornecem orientação desde uma perspectiva de negócios até a implementação, e o IISF é particularmente aplicável, pois aborda a Wired's breves menções para proteger os terminais de conectividade e os dados que passam entre eles.

Dê uma volta comigo e veja como podemos modificar a arquitetura do carro conectado para se proteger contra possíveis adversários. Como não temos nenhum ataque malicioso conhecido contra carros, podemos começar com o hack do Jeep de Miller. Graças a um “recurso” de backdoor na unidade principal Harmon Kardon, Miller foi capaz de executar comandos remotos desprotegidos com bastante facilidade. Por meio dessa exploração inicial, ele conseguiu reprogramar um chip conectado ao barramento CAN. A partir daí, ele tinha quase total controle do carro. Você está pensando, “apenas remova aquela interface desprotegida”, certo?

Miller não teria parado por aí, então nós também não. Supondo que ainda pudéssemos encontrar um exploit que nos concedeu acesso para reprogramar o chip ARM, então o Wired's O artigo sugere corretamente o estabelecimento de um aplicativo autenticado - talvez começando com uma inicialização segura para o kernel subjacente, aproveite a zona de confiança do ARM para o próximo estágio de software apenas crítico e implemente algum tipo de autenticação para sistemas operacionais de nível superior e processos de aplicativos. O endpoint do seu dispositivo pode começar a se parecer com uma pilha de aplicativos confiáveis ​​(Figura 1 abaixo). Só posso imaginar quanto custa essa unidade principal agora, mas para ser justo, essas são considerações válidas para executar um aplicativo confiável. O problema agora é que na verdade não nos conectamos a nada, muito menos com segurança. Não se preocupe, não vou deixar você na beira da estrada.
Figura 1. Pilha de aplicativos confiáveis ​​
Muitos desses aplicativos confiáveis ​​se conectam diretamente ao barramento CAN, o que provavelmente expande a superfície de ataque para o controle do veículo. Os dados passados ​​entre esses aplicativos não são protegidos de escritores e leitores de dados não autorizados. No caso de táxis autônomos, como Wired aponta, hackers em potencial agora têm acesso físico ao seu alvo, aumentando sua chance de assumir o controle de um aplicativo ou introduzir um impostor. Agora a questão é:os aplicativos podem confiar uns nos outros e nos dados do barramento CAN? Como o painel de instrumentos confia nos dados de temperatura externa? É realmente necessário? Talvez não e tudo bem. No entanto, tenho quase certeza de que o controle do veículo precisa confiar no LIDAR, no radar, nas câmeras e assim por diante. A última coisa com que alguém quer se preocupar é um hacker levar o carro remotamente para um passeio.

Na verdade, estamos falando sobre autenticidade de dados e controle de acesso:duas disposições que teriam mitigado ainda mais o risco contra o hack de Miller. Proteger os aplicativos legados é uma boa etapa, mas vamos considerar o cenário em que um produtor não autorizado de dados é apresentado ao sistema. Este invasor pode injetar comandos no barramento CAN - mensagens que controlam a direção e a frenagem. O CAN Bus não impede editores não autorizados de dados nem garante que os dados venham do produtor autenticado. Não estou sugerindo que a substituição do barramento CAN seja o caminho a seguir - embora não me oponha à ideia de substituí-lo por uma solução mais centrada em dados. De forma realista, com uma estrutura como Data Distribution Services (DDS), podemos criar uma arquitetura em camadas guiada pelo IISF (Figura 2 abaixo). O Barramento CAN e os componentes críticos do drive são sistemas legados efetivamente para os quais o risco de segurança pode ser mitigado pela criação de uma barreira de barramento de dados DDS. Novos componentes podem ser integrados com segurança usando DDS sem comprometer ainda mais o controle do veículo. Então, o que é DDS? E como isso ajuda a proteger meu veículo? Que bom que você perguntou.


Figura 2. Estrutura de segurança industrial da Internet protegendo terminais legados
Imagine uma rede de sensores automotivos, controladores e outros “participantes” que se comunicam ponto a ponto. Cada participante recebe apenas os dados de que necessita de outro participante e vice-versa. Com o ponto a ponto, os participantes dessa rede podem se autenticar mutuamente e, se nossos aplicativos confiáveis ​​resistirem, o mesmo acontecerá com nossa conectividade confiável. Como protegemos essas conexões ponto a ponto? TLS, certo? Possivelmente, mas com a complexidade de proteger nosso veículo, desejamos a flexibilidade para equilibrar desempenho e segurança e aplicar mecanismos de controle de acesso.

Vamos voltar um pouco e revisitar nossa conversa sobre o IICF, que fornece orientação sobre conectividade para sistemas de controle industrial. O IICF identifica padrões abertos existentes e os atribui sucintamente a funções precisas de um sistema IoT Industrial. Em sua essência, um veículo autônomo, por mais legal que pareça, é apenas um sistema IoT Industrial em um corpo aerodinâmico elegante com bancos de couro opcionais. Então, o que o IICF sugere para integrar software para um sistema IoT Industrial, ou mais especificamente, sistemas autônomos? Você adivinhou! DDS:um conjunto aberto de padrões projetados e documentados por meio de conversas abertas pelo Object Management Group (OMG). Uma solução automotiva ideal que aproveita o DDS permite que os aplicativos do sistema publiquem e assinem apenas as mensagens de que precisam (consulte a Figura 3 abaixo para ver nossa visão de uma arquitetura autônoma). Com essa abordagem centrada em dados, podemos decompor arquitetonicamente as mensagens com base na criticidade para segurança ou na necessidade de integridade de dados.


Figura 3. Arquitetura centrada em dados de veículos autônomos
E agora que estabelecemos uma solução de conectividade para nosso veículo autônomo, podemos voltar a falar sobre segurança e nossa alternativa TLS:uma solução de segurança centrada em dados para uma estrutura de mensagens centrada em dados. Com o DDS Security, os arquitetos de sistema IoT Industrial podem usar plug-ins de segurança para ajustar a segurança e as compensações de desempenho, um recurso necessário não oferecido pelo TLS (Figura 4 abaixo). Autenticar apenas tópicos de dados selecionados, mas não mais? Verificar. Criptografar apenas informações confidenciais, mas nada mais? Verificar. Na verdade, há mais. Deixando de lado corretores centralizados, o DDS Security oferece mecanismos de controle de acesso distribuído que determinam o que os participantes podem publicar ou assinar certos tópicos sem pontos únicos de vulnerabilidade. Isso significa que o aplicativo não autorizado de Miller teria a permissão negada para publicar comandos para controlar a frenagem ou direção. Ou se Miller comprometeu os dados em movimento, o assinante de dados poderia autenticar criptograficamente a mensagem e descartar qualquer coisa que não corresponda às políticas estabelecidas. Podemos dizer que nosso veículo autônomo agora está completamente seguro? Não, porque como Miller deixou perfeitamente claro, ainda precisamos de mais conversas. No entanto, podemos certamente dizer que o DDS e o D

[1] [2] 下一页