Este conteúdo descreve como habilitar recursos de semente de criptografia de ligação baseada em veículo.
Visão geral
O objetivo principal do recurso de semente de vinculação do veículo é proteger ainda mais a privacidade do usuário, protegendo os dados no sistema de informação e entretenimento no veículo (IVI) contra a remoção do veículo. Isso é feito vinculando as chaves de criptografia de armazenamento a alguma outra unidade de controle eletrônico (ECU), de modo que, se o IVI for removido e colocado em outro veículo (ou executado em uma bancada de teste), os dados do usuário criptografados no IVI não poderão ser descriptografados.
Para vincular chaves de criptografia de arquivo, Vold mistura uma semente específica do veículo com derivação de chave de criptografia de chave para que as chaves sejam únicas e vinculadas fisicamente ao veículo. A semente é uma matriz de bytes, exposta como uma nova propriedade de camada de abstração de hardware de veículo (VHAL) pelo OEM, STORAGE_ENCRYPTION_BINDING_SEED . As permissões desta propriedade são restritas de tal forma que só podem ser consultadas por daemons de sistema privilegiados.
Diagrama de arquitetura
Esta figura ilustra a arquitetura da integração vinculada ao veículo:
Figura 1. Arquitetura vinculada ao veículo
Ativando a vinculação baseada em veículo
A vinculação da criptografia de armazenamento ao veículo deve ser explicitamente habilitada e não pode ser ativada ou desativada sem realizar uma redefinição de fábrica. Isso significa que uma atualização Over-the-Air (OTA) não pode ativar o recurso sem também limpar o dispositivo. Um OEM pode optar por habilitar o recurso na atualização se também redefinir o dispositivo de fábrica. Por exemplo, em uma visita de serviço.
Esse recurso é habilitado por meio do suporte à propriedade STORAGE_ENCRYPTION_BINDING_SEED no HAL do veículo fornecido pelo fornecedor. Esta propriedade contém uma cadeia de bytes de 16 bytes de comprimento e espera-se que seja mantida em uma ECU separada da IVI. A propriedade é inicialmente definida pelo Android Automotive OS (AAOS), que a gera usando um Gerador de Números Aleatórios Criptograficamente Seguro (CSRNG). O AAOS lê a propriedade nas inicializações subsequentes.
Como o VHAL armazena o valor de STORAGE_ENCRYPTION_BINDING_SEED é específico do fornecedor. Temos recomendações gerais para proteger a semente:
- ( Recomendado ) A semente é armazenada por uma ECU no veículo que está fisicamente bem protegido. Caso contrário, é trivial que o IVI e a ECU sejam retirados do veículo.
- ( Recomendado ) IVI e ECU devem autenticar-se mutuamente para trocar a semente para evitar solicitações de falsificação da semente da ECU.
- ( Recomendado ) A semente deve ser transmitida usando um canal seguro para proteger contra o sniffing do barramento CAN.
Além disso, adicione o seguinte para garantir o init.target.rc do fornecedor em late-fs antes mount_all --late :
# feed vehicle binding seed to vold exec_start vold_seed_binding
O veículo HAL deve ser iniciado em early_hal em vez de hal now . Qualquer propriedade de sistema persist.* não pode ser acessada no early-hal pois a partição /data ainda não está montada.
Configurando a vinculação baseada em veículo
Se a semente da ECU não corresponder, o dispositivo reinicializará na recuperação e solicitará que o usuário apague a partição /data ou tente novamente.
O comportamento de prompt e limpeza de dados pode ser alterado em builtins.cpp :
- Altere
prompt_and_wipe_dataparawipe_data. O dispositivo limpa e reinicia sem um aviso. - A mensagem de prompt está contida em recovery.cpp .
Figura 2. Mensagem de prompt
Testando a ligação baseada em veículo
Teste simulado
Um teste simulado é fornecido em packages/services/Car/cpp/security/vehicle_binding_util/tests .
Para executar este teste simulado:
attest libvehicle_binding_util_test
Teste de integração
Um teste atest é fornecido em packages/services/Car/cpp/security/vehicle_binding_util/tests .
Para executar este teste de integração:
atest vehicle_binding_integration_test