Esta página descreve como ativar recursos iniciais de criptografia de ligação baseada em veículo.
Visão geral
O objetivo principal do recurso de semente vinculativa 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 remoção do veículo. Isso é feito vinculando 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 testes), os dados criptografados do usuário no IVI não possam ser descriptografados.
Para vincular chaves de criptografia de arquivos, Vold mistura uma semente específica do veículo com a derivação de chave de criptografia de chave para que as chaves sejam exclusivas e fisicamente vinculadas 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 ela só possa ser consultada 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.
Habilitar 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 ligada ou desligada 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 ativar o recurso na atualização se também redefinir o dispositivo para os padrões de fábrica. Por exemplo, em uma visita de serviço.
Este recurso é habilitado com suporte à propriedade STORAGE_ENCRYPTION_BINDING_SEED no HAL do veículo fornecido pelo fornecedor. Esta propriedade contém uma sequência de bytes de 16 bytes de comprimento e espera-se que seja persistida em uma ECU separada do IVI. A propriedade é inicialmente definida pelo Android Automotive OS (AAOS), que a gera usando um Gerador de Números Aleatórios Criptograficamente Seguro (CSRNG). AAOS então lê a propriedade nas inicializações subsequentes.
A forma como o VHAL armazena o valor de STORAGE_ENCRYPTION_BINDING_SEED depende 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 para a semente da ECU.
- ( Recomendado ) A semente deve ser transmitida usando um canal seguro para proteção contra detecção 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 HAL do veículo deve ser iniciado em early_hal em vez de hal now . Qualquer propriedade de sistema persist.* não pode ser acessada no early-hal porque a partição /data ainda não está montada.
Configurar 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 solicitar e limpar dados pode ser alterado em builtins.cpp :
- Altere
prompt_and_wipe_dataparawipe_data. O dispositivo é apagado e reinicializado sem aviso prévio. - A mensagem de prompt está contida em recovery.cpp .
Figura 2. Mensagem de prompt.
Testar 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