Como domar o sistema operacional Android para veículos

Em um post anterior, pedi aos engenheiros que desenvolvem software para carros conectados e autônomos que considerassem o verdadeiro custo de usar o Linux de uma perspectiva monetária e de segurança de certificação e segurança. Um amigo me mandou um e-mail depois de ler esse post, perguntando por que eu não falei sobre as vulnerabilidades de segurança do Android e por que dei a ele um "passe de salão". A resposta curta é que acredito que podemos arquitetar um controlador de cockpit virtual que preserva os benefícios de certificação de segurança e segurança do QNX enquanto habilita aplicativos Android - que é onde o Android se diferencia - a melhor abordagem dos dois mundos. Na verdade, nosso cockpit de carro conceito (Jaguar Land Rover) na CES era baseado em QNX (Cluster e Hypervisor) e um QNX IVI com Android (Apps) sendo executado em um domínio virtual. Com o Linux você obtém as vulnerabilidades de segurança e o OpEx extra (R & D custo), mas sem diferenciação real. Com o Android, pelo menos você recebe os aplicativos populares.

Vamos primeiro discutir sobre o que meu amigo estava falando.

O gráfico Business Insider / Statista abaixo fornece uma visão independente sobre vulnerabilidades de segurança de vários sistemas operacionais:

Das 523 vulnerabilidades atribuídas ao Android no gráfico acima, 254 tinham uma pontuação de “9” ou superior no CVSS (Common Vulnerability Scoring System), indicando que essas vulnerabilidades foram consideradas extremamente críticas. De acordo com a SC Magazine, em 2016, o Google Android teve mais vulnerabilidades do que outros sistemas operacionais no mundo dos celulares. Os gráficos abaixo, baseados nas estatísticas mais recentes do CVE do NIST (Instituto Nacional de Padrões e Tecnologia), demonstram que o número de CVEs Android ou Linux é maior do que o dos CVEs QNX até o final de 2017.

Dito isso, as implementações do Android podem variar entre os fornecedores de telefones celulares. Em diferentes graus, alguns deles adicionam inúmeras modificações, feitas por engenheiros qualificados, para melhorar a postura de segurança do Android. A BlackBerry lidera o pacote com a implementação Android mais segura de todos os fornecedores. No entanto, isso é um trabalho difícil e requer muitos engenheiros altamente qualificados e especialistas em segurança. As perguntas são: “quais problemas devem ser considerados ao implantar o Android em veículos?”.

Android não é livre

Algumas pessoas consideram o Android “Livre”. Vamos considerar o mérito dessa crença. Aplicativos ricos e fáceis de usar estão no centro da proposta de valor do Android. Como acontece com todos os aplicativos de alto valor (mercado do Android, Google Maps, Google Earth, Pesquisa por voz, Pesquisa local etc.), esses aplicativos para Android exigem licenciamento, o que significa que há custos associados a eles.

A renderização segura do Android exige engenheiros qualificados e especialistas em segurança que melhorem a postura de risco de segurança. Isso leva tempo, esforço e, por fim, sérios investimentos em P & D.

Com relação às aplicações automotivas, existem outras complicações que levantam questões:

• A marca comercial Android só pode ser usada com dispositivos compatíveis com o documento de definição de compatibilidade e o conjunto de testes de compatibilidade do Google.

• Nem todos os aplicativos para Android são executados em todas as plataformas.

• Não está claro se o OEM, ou o Google, controlará a interface do usuário do veículo, os recursos da plataforma e a verificação do aplicativo.

• Os OEMs permitirão que o Google acesse os dados do barramento CAN do veículo? Esses dados são valiosos e o acesso a esses dados pode justificar a disponibilização de um sistema operacional gratuitamente. Tais dados, por exemplo, podem ser usados ​​para mapeamento, condução autônoma e preferências do usuário.

• Como mencionado acima, assim como acontece com os telefones celulares, o ônus está no OEM para implementar recursos de segurança que impeçam a interação entre o Android ou seus aplicativos e os subsistemas críticos para a segurança no veículo.

Portanto, além das taxas de licença, o investimento em engenharia de segurança, suporte, otimização e manutenção necessário para o Android deve ser considerado. Muitas vezes, a 3 rd partido empresa de serviços Android ou uma equipe in-house deve ser montado para fornecer serviços caros.

Freqüência de lançamentos do Android

Existem duas importantes considerações de manutenção no contexto automotivo. Primeiro, o Android precisa de atualizações mensais regulares, como os telefones celulares. Será que um OEM precisa atualizar carros no campo, digamos, todo mês, durante sua vida útil (em média, cerca de 11 anos)? Além disso, para referenciar novamente a experiência do telefone celular, vimos vários lançamentos principais e sub-lançamentos de Marshmallow, Nougat, Oreo e agora P, em menos de dois anos (detalhados na tabela abaixo). Além disso, cada uma dessas versões só recebe suporte por 2 anos. Na indústria automotiva, leva de dois a três anos para desenvolver um produto e guiá-lo pelo início da produção (SOP) e outros cinco a seis anos de produção de plataforma. Claro, pós-produção, o carro pode facilmente estar na estrada por mais 5-15 anos.

Nome de códigoVersão #Data de lançamento inicial

Marshmallow [12]6,0 - 6,05 de outubro de 2015

Nougat [13]7,0 - 7,122 de agosto de 2016

Oreo8,0 - 8,121 de agosto de 2017

Android P98 de maio de 2018 (beta)

Qual é o custo dessas atualizações e atualizações, e a responsabilidade potencial de um risco não corrigido?

Segurança

Agora, voltemos ao tópico dos CVEs e sua interseção com as tendências automotivas. Se você tem seguido as tendências automotivasno mercado, você sabe que as ECUs estão se consolidando em menos controladores de domínio. Por exemplo, Controladores de Cockpit Virtual (VCCs), nos quais as ECUs de infotainment e de painel de instrumentos são consolidadas para serem executadas em uma plataforma de computação de Controlador de Domínio de SoC de alto desempenho, economizam custos e reduzem a complexidade. No entanto, para que um VCC funcione adequadamente, o sistema precisa de recursos reais do hipervisor tipo 1 que possam isolar funções críticas de segurança (conjunto de instrumentos) e não críticas de segurança (IVI) umas das outras. Alguns OEMs decidiram usar um sistema completo de infotretenimento para automóveis Android Automotive, integrado a um controlador de cockpit, rodando em um único SoC, que também suporta o Instrument Cluster certificado para segurança, como mostrado no diagrama aqui. Acreditamos que essa ideia é suscetível a vulnerabilidades de segurança.

Do ponto de vista da segurança, o Android introduz uma grande superfície de ataque ao sistema de software de um veículo. Um painel digital de instrumentos deve ser certificado para a segurança ISO 26262 ASIL B, enquanto que as unidades de infotainment não possuem nenhum requisito de certificação de segurança. Como descrito acima, é muito provável que os sistemas baseados no Android requeiram atualizações e patches frequentes devido a um alto número de vulnerabilidades (CVEs). A certificação de segurança ISO 26262 exige que as atualizações de software do subsistema de infoentretenimento não afetem o subsistema de grupos de instrumentos críticos para a segurança. No entanto, se todas as funções de infoentretenimento forem executadas no Android, qualquer atualização de segurança (CVE) que impacta um driver compartilhado (por exemplo, áudio, gráficos etc.) ou recurso pode representar um risco que os OEMs e seus fornecedores de Nível 1 devem resolver com uma atualização de software . Para tornar a situação acima ainda mais complicada, o Android não foi arquitetado com virtualização ou para coexistência em um Controlador de Domínio da cabine consolidado. Isso significa complexidade adicional no sistema.

Vamos considerar uma nova maneira de abordar isso com ênfase na segurança e proteção, deixando espaço para a diferenciação da marca. Que tal um sistema bem arquitetado que isola funções críticas e não críticas de segurança usando domínios de máquina virtual (VM) e restringe o acesso e a funcionalidade de uma VM Android (por exemplo, executa aplicativos Android para consumidores) para reduzir o risco à função de segurança? Ao restringir o acesso e a funcionalidade, a grande superfície de ataque exposta pelo Android é reduzida. Tudo isso, enquanto fornece os recursos para evitar um produto "eu também". O Blackberry QNX desenvolveu essa solução.

Na solução BlackBerry, as interfaces de conectividade, como USB, Bluetooth, Wi-Fi, assim como os barramentos, como o barramento CAN e outros recursos, incluindo arquivos de navegador e mídia, são “de propriedade” e controlados pela VM QNX mais segura. Ao mesmo tempo, o designer do sistema pode usar os recursos de tela do QNX para gerenciar o que e como o conteúdo é exibido, independentemente de onde o conteúdo está sendo gerado (Android VM, QNX VM ou outro).

Então, para responder à pergunta do meu amigo sobre por que eu não era tão crítico do Android quanto do Linux, acredito que existe uma solução, como a arquitetada pela QNX, para construir um controlador de cockpit virtual onde se obtém a segurança e os benefícios da certificação de segurança do QNX, ao mesmo tempo em que habilita aplicativos valiosos do Android, que é onde o Android se diferencia. Por outro lado, o perfil CVE da AGL, conforme descrito no meu post anterior, fala por si.

Nenhum sistema no mundo pode reivindicar segurança total para sempre. A segurança é como uma corrida em que você precisa ficar constantemente à frente de maus atores. Brincar nas águas barrentas da AGL não só o impede de se diferenciar da multidão, mas, na verdade, pode impedi-lo.

À medida que as montadoras procuram consolidar funções de domínio como infotainment, telemática e clusters de instrumentos digitais em um controlador de cockpit virtual, o QNX SDP 7.0 oferece o melhor sistema operacional em tempo real que suporta plataformas de computação de 64 bits para o ARMv8 e Intel x86 -64 arquiteturas, juntamente com os verdadeiros recursos de virtualização de hipervisor tipo 1, para um carro conectado com segurança e certificado. A plataforma de software fundacional do BlackBerry QNX dá às montadoras a liberdade de escolher qualquer aplicativo de plataforma de carro (Android Apps, Apple CarPlay, Baidu CarLife) para produtos em todo o mundo, enquanto mantém domínios críticos de segurança do carro isolados de forma segura. Por fim, o BlackBerry QNX não quer possuir os dados do OEM nem controlar a interface de usuário diferenciadora da marca.

fonte: BlackBerry