Este conteúdo descreve como habilitar recursos de semente de criptografia de ligação baseada em veículo.
Visão geral
O principal objetivo do recurso de semente de ligaçã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 criptografados do usuário 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 Vehicle Hardware Abstraction Layer (VHAL) pelo OEM, STORAGE_ENCRYPTION_BINDING_SEED . As permissões desta propriedade são restritas de 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 vinculação baseada em veículo
A vinculação da criptografia de armazenamento ao veículo deve ser habilitada explicitamente e não pode ser ativada ou desativada sem executar 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 é ativado pelo 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 do IVI. A propriedade é inicialmente definida pelo Android Automotive OS (AAOS), que a gera usando um Gerador de Número Aleatório Criptograficamente Seguro (CSRNG). O AAOS então 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 fisicamente bem protegido. Caso contrário, é trivial que o IVI e a ECU sejam retirados do veículo.
- ( Recomendado ) IVI e ECU devem se autenticar mutuamente para trocar a semente para evitar solicitações de falsificação para a 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 fornecedor init.target.rc no late-fs antes de 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 do sistema persist.* não pode ser acessada no early-hal porque a partição /data ainda não está montada.
Configurando vinculação baseada em veículo
Se a semente da ECU não corresponder, o dispositivo será reinicializado em recuperação e solicitará que o usuário apague a partição /data ou tente novamente.
O comportamento de solicitação e limpeza de dados pode ser alterado em builtins.cpp :
- Altere
prompt_and_wipe_dataparawipe_data. O dispositivo limpa e reinicia sem um prompt. - A mensagem de prompt está contida em recovery.cpp .
Figura 2. Mensagem de prompt
Testando vinculaçã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 de teste é fornecido em packages/services/Car/cpp/security/vehicle_binding_util/tests .
Para executar este teste de integração:
atest vehicle_binding_integration_test