Um exemplo de proteção de IA na cabine usando TEE em um SoC FPGA seguro

Este artigo discute ambientes de execução confiáveis ​​- já usados ​​em uma variedade de dispositivos conectados - mostrando como o uso de TEE e um SoC FPGA pode funcionar em veículos em cabine AI.

A Parte I deste artigo, Trusted Execution Environments (TEEs) em Connected Cars, discutiu que, embora um Trusted Execution Environment (TEE) seja amplamente usado em telefones celulares e outros dispositivos conectados para proteger funções críticas, a adoção em veículos conectados é baixa. A falta de TEE pode criar vulnerabilidades no sistema. Na Parte II, tomaremos a IA na cabine como um aplicativo de exemplo e discutiremos como um moderno TEE e FPGA SoC podem ser sua plataforma segura.

Sistema AI típico de cabine

A IA na cabine faz parte de um sistema avançado de assistência ao motorista (ADAS) e é, de fato, mais popularmente implantado do que a direção autônoma. A IA na cabine utiliza câmeras ou outros sensores para fornecer orientação de segurança contextual aos motoristas e passageiros, ou fornecer opções como voz e gestos para controlar o veículo. Por exemplo, câmeras voltadas para o interior são adequadas para monitorar motoristas de caminhão para detectar embriaguez, distração, sonolência e fadiga para alertar o motorista e prevenir acidentes. Atualmente, são amplamente implantados em veículos comerciais e caminhões. A mesma tecnologia está começando a penetrar nos veículos de consumo para observar o comportamento relacionado ao motorista para fins de segurança. Câmeras alimentadas por IA também podem alertar quando crianças e animais de estimação são deixados no veículo para evitar mortes relacionadas ao calor.

Um sistema típico na cabine monitora o comportamento do motorista, verifica se os ocupantes estão usando cintos de segurança e pode ser treinado para rastrear objetos de interesse como telefones celulares, chaveiros, cadeiras de bebê, etc. O sistema precisa realizar muitas funções, incluindo cadeia de sinal de vídeo baseada em aprendizado de máquina , comunicação com outras ECUs como o ADAS central ou o sistema de infoentretenimento e suporte a atualizações de firmware.

Ele também pode realizar a detecção de ponto cego - espelhos retrovisores laterais aumentados com câmeras de formato pequeno podem ser usados ​​para executar algoritmos de ML para detectar veículos no ponto cego do motorista. Além disso, pode descarregar processamento, como autenticação de rede no veículo (IVN), do ADAS central.

Um exemplo de hardware reforçado

PolarFire SoC FPGA da Microchip é um exemplo de hardware que pode suportar este tipo de funções consolidadas, sistema de criticidade mista. Ele permite que aplicativos de IA na cabine com inferência eficiente na estrutura do FPGA e no subsistema do microprocessador executem tarefas de controle e monitoramento. Ele suporta RTOS determinístico junto com Linux avançado em processadores RISC-V quad-core de alta eficiência energética (consulte a Figura 1).

Figura 1. Plataforma de AI em cabine PolarFire SoC. A inferência de ML é executada em malha FPGA. O SoC RISC-V hospeda funções de controle e monitoramento.

Para proteger o hardware, o PolarFire SoC possui medidas de segurança integradas que incluem suporte à prova de violação além de contramedidas de análise de potência diferencial (DPA). Isso protege o chip contra exploits de canal lateral que visam extrair fluxos de bits e, portanto, evita a clonagem. Usando a infraestrutura de programação segura, a montadora tem controle total sobre o número de FPGAs que podem ser programados, protegendo assim contra o excesso de construções. O PolarFire SoC também oferece suporte à inicialização segura usando uma memória flash de inicialização segura onboard de 128 kB habilitada para SECDED.

Modelo de inferência de IA e outros ativos de dados valiosos devem ser protegidos

Neste sistema, ativos de dados valiosos incluem:

• IVN - acesso não intencional ao IVN (“ônibus CAN”) pode permitir que um adversário assuma o controle do veículo
• Informações de identificação pessoal (PII) do motorista e do passageiro - as PII devem ser ocultadas para a privacidade do consumidor
• OTA - se o código ou dados OTA forem corrompidos ou sequestrados, firmware ruim ou malicioso pode ser injetado
• Modelo de IA - o modelo de inferência é suscetível a roubo e ataque de IP
• Segredos - as chaves e bibliotecas de criptografia devem ser protegidas para garantir o algoritmo de assinatura digital (DSA) de mensagens IVN

A confidencialidade, integridade e disponibilidade (CIA) desses ativos devem ser consideradas durante o projeto.

Superfícies de ataque e ameaças a esses ativos incluem:

Superfícies de ataque	Exploits
Camadas de aplicativo e rede	Malware, estouro de buffer para explorar IVN, OTA, roubar PII
Rich OS	Um sistema operacional rico como o Linux tem uma grande superfície de ataque. Qualquer firmware não livre também apresenta opacidade e riscos. As explorações podem derrubar todo o sistema ou permitir que um adversário entre silenciosamente através do rico sistema operacional para manipular outros ativos.
Sensores	“Model Hacking” ou “Adversarial Machine Learning” é quando a memória do sensor é acessível por aplicativos não confiáveis, o malware pode perturbar a memória do sensor, resultando na operação não intencional do ADAS.
Sensores	“Inversão por modelo substituto”:quando um adversário pode controlar a entrada e observar a saída do modelo de inferência sendo capaz de ler e gravar na memória, ele pode recriar o modelo. Ele poderia usar essa cópia para aprender tendências e distribuições nos dados de treinamento ou para planejar ataques futuros.

Um exemplo de ambiente de execução confiável

Um TEE que fornece segurança por separação é uma excelente contramedida para projetar um modelo de confiança zero para proteger esses ativos de dados.

Um TEE que adota uma nova abordagem é o MultiZone® Security da Hex Five. Faz uso de primitivas de partição de memória:"proteção de memória física" PMP que é padrão em todos os RISC-V ou "unidade de proteção de memória" MPU no Arm® e níveis de privilégio na CPU (modo M e modo U para RISC- Níveis V, Handler e Thread para Arm®) para criar vários contêineres ou zonas seguras.

Uma configuração do MultiZone no PolarFire SoC pode ser semelhante à Figura 2. Cada caixa vermelha indica um bloco funcional protegido em um “contêiner” ou uma “zona”. Dentro de cada zona, apenas o código autorizado e atribuído pode acessar regiões de memória especificadas de acordo com as permissões de leitura / gravação / execução configuradas por um arquivo de política MultiZone. Os manipuladores de interrupção são atribuídos a uma zona para que ela seja executada apenas com privilégio de modo de usuário em vez de modo de kernel, para cumprir com o modelo de confiança zero.

As cinco zonas são:

1. OTA– Protege o CIA do código e dados OTA
2. Câmera - protege os dados do sensor da câmera
3. Autenticação IVN - semelhante a um HSM, esta zona protege as chaves e criptografia para DSA
4. RTOS - controla o IVN
5. Linux Enclave - Falhas do Linux serão contidas

Essas zonas são mostradas na Figura 2.

Figura 2. MultiZone cria 5 “zonas” no PolarFire SoC. Apenas MultiZone é executado no modo M, que é CPU Ring 0 em RISC-V. Cada caixa vermelha é uma zona separada por hardware definida por software .

Este exemplo de configuração mostra como um TEE e seu hardware complementar criam uma plataforma segura básica para um aplicativo de IA na cabine.

TEE é uma camada fundamental

Uma boa postura de segurança para veículos conectados deve incluir, no mínimo:

• Segurança do aplicativo
• Sistema de prevenção de detecção de intrusões (IDPS) para segurança de rede
• OTA seguro
• Ambiente de execução confiável
• Hardware com primitivas de segurança integradas, raiz de confiança

Apoiar os TEEs em nossos veículos é fundamental, não é diferente de ter TEEs em nossos telefones. Esse é um caminho para tornar nossos carros mais seguros do que nossos smartphones.



Este artigo foi coautor de Diptesh Nandi, da Microchip.

Artigos do setor são uma forma de conteúdo que permite aos parceiros do setor compartilhar notícias, mensagens e tecnologia úteis com os leitores do All About Circuits de uma forma que o conteúdo editorial não é adequado. Todos os artigos da indústria estão sujeitos a diretrizes editoriais rígidas com a intenção de oferecer aos leitores notícias úteis, conhecimentos técnicos ou histórias. Os pontos de vista e opiniões expressos nos Artigos da Indústria são do parceiro e não necessariamente da All About Circuits ou de seus redatores.