Esta página descreve como ativar os recursos de semente de criptografia de vinculação com base no veículo.
Visão geral
O objetivo principal do recurso de vinculação de semente do veículo é proteger ainda mais a privacidade do usuário, protegendo os dados do sistema de infoentretenimento veicular (IVI) contra a remoção do veículo. Isso é feito vinculando chaves de criptografia de armazenamento a outra unidade de controle eletrônico (ECU, na sigla em inglês). Assim, se o IVI for removido e colocado em outro veículo (ou executado em um banco de testes), os dados do usuário criptografados no IVI não poderão ser descriptografados.
Para vincular chaves de criptografia de arquivo, o Vold mistura uma semente específica do veículo com a derivação de chaves de criptografia
de chaves para que as chaves sejam exclusivas e vinculadas fisicamente ao veículo. A semente é uma matriz de bytes,
exposta como uma nova propriedade da camada de abstração de hardware do veículo (VHAL) pelo OEM,
STORAGE_ENCRYPTION_BINDING_SEED. As permissões dessa propriedade são restritas, de modo que
ela só pode ser consultada por daemons do sistema privilegiados.
Diagrama da arquitetura
Esta figura ilustra a arquitetura da integração vinculada ao veículo:
Figura 1. Arquitetura vinculada ao veículo.
Ativar a vinculação baseada em veículo
A vinculação da criptografia de armazenamento ao veículo precisa ser ativada explicitamente e não pode ser ativada ou desativada sem uma redefinição de fábrica. Isso significa que uma atualização over-the-air (OTA) não pode ativar o recurso sem limpar o dispositivo. Um OEM pode ativar o recurso após o upgrade se também redefinir o dispositivo para a configuração original. Por exemplo, em uma visita de manutenção.
Esse recurso é ativado com suporte à propriedade STORAGE_ENCRYPTION_BINDING_SEED
na HAL do veículo fornecida pelo fornecedor. Essa propriedade contém uma string de byte de 16 bytes de comprimento e precisa ser
permanecida em uma ECU separada do IVI. A propriedade é definida inicialmente pelo
Android Automotive OS (AAOS), que a gera usando um gerador de números aleatórios criptograficamente seguro (CSRNG, na sigla em inglês). O AAOS vai ler a propriedade em inicializações subsequentes.
A forma como o VHAL armazena o valor de STORAGE_ENCRYPTION_BINDING_SEED é específica para o fornecedor.
Temos recomendações gerais para proteger a semente:
- (Recomendado) A semente é armazenada por uma ECU no veículo que está fisicamente bem protegida. Caso contrário, é fácil extrair o IVI e a ECU do veículo.
- (Recomendado) O IVI e a ECU precisam se autenticar mutuamente para trocar a semente e impedir solicitações de spoofing da ECU.
- (Recomendado) A semente precisa ser transmitida usando um canal seguro para evitar a detecção de bus CAN.
Além disso, adicione o seguinte para garantir que o fornecedor init.target.rc em
late-fs antes mount_all --late:
# feed vehicle binding seed to vold
exec_start vold_seed_bindingO HAL do veículo precisa ser iniciado em early_hal em vez de hal now.
Não é possível acessar nenhuma propriedade do sistema persist.* em early-hal porque a
partição /data ainda não está montada.
Configurar a vinculação baseada em veículo
Se a semente da ECU não corresponder, o dispositivo será reinicializado na recuperação e solicitará que o usuário apague
a partição /data ou tente novamente.
O comportamento de solicitação e exclusão de dados pode ser alterado em builtins.cpp:
- Mude
prompt_and_wipe_dataparawipe_data. O dispositivo é excluído e reinicializado sem uma solicitação. - A mensagem de solicitação está contida em
recovery.cpp.
Figura 2. Mensagem de solicitação.
Testar a vinculação baseada em veículo
Teste simulado
Um teste simulado é fornecido em
packages/services/Car/cpp/security/vehicle_binding_util/tests.
Para realizar este teste simulado:
attest libvehicle_binding_util_test
Testes de integração
Um teste de atestado é fornecido em
packages/services/Car/cpp/security/vehicle_binding_util/tests.
Para executar este teste de integração:
atest vehicle_binding_integration_test