Este guia descreve as práticas recomendadas pelo Google para aplicar patches de segurança que são avaliados pelo conjunto de testes de compatibilidade do Android (CTS). Ele é destinado aos fabricantes de Equipamentos OEM compatíveis com Android (fabricantes) que terão suporte por mais de três anos como veículos, TVs, conversores e eletrodomésticos. Este guia não é destinado a usuários finais (por exemplo, proprietários de veículos).
Agradecimentos e exonerações de responsabilidade
Este guia não vincula o Google ou outros fabricantes de forma legal ou contratual e não tem a intenção de ser um conjunto de requisitos. Em vez disso, este guia é um auxílio instrutivo que descreve práticas recomendadas.
Feedback
Este guia não tem o objetivo de ser completo. revisões adicionais sejam planejadas. Enviar feedback para fabricantes-guide-android@googlegroups.com.
Glossário
| Termo | Definição |
|---|---|
| ACC | Compromisso de compatibilidade com o Android. Anteriormente conhecido como Acordo de antifragmentação do Android (AFA, na sigla em inglês). |
| AOSP | Android Open Source Project |
| ASB | Boletim de segurança do Android |
| BSP | Pacote de suporte da placa |
| CDD | Documento de definição de compatibilidade |
| CTS | Conjunto de teste de compatibilidade |
| FOTA | firmware over the air |
| GPS | sistema de posicionamento global |
| MISRA | Motor Industry Software Reliability Association |
| NIST | Instituto Nacional de Padrões e Tecnologia |
| OBD | diagnósticos integrados (OBD-II é uma melhoria em relação ao OBD-I em termos de padronização). |
| Driver OEM | fabricante de equipamento original |
| SO | Sistema operacional |
| SEI | Instituto de engenharia de software |
| SoC | system on chip |
| SOP | início da produção |
| SPL | Nível do patch de segurança |
| TPMS | sistema de monitoramento da pressão dos pneus |
Sobre o SO Android
O Android é uma pilha de software completa de código aberto, baseada em Linux, projetada para uma variedade de dispositivos e formatos. Desde seu primeiro lançamento em 2008, o Android se tornou o sistema operacional mais popular (SO), que capacita mais de 1,4 bilhão de dispositivos em todo o mundo (2016). Aproximadamente 67% desses dispositivos usam Android 5.0 (Lollipop) ou versão mais recente a partir de março de 2017 (números mais recentes estão disponíveis no No Android painel). Embora a grande maioria dos dispositivos seja de smartphones e tablets, o Android está crescendo em smartwatches, TVs e dispositivos de infoentretenimento veicular (IVI, na sigla em inglês).
O número de apps Android disponíveis na Google Play Store chegou a mais de 2,2 milhões (2016). O desenvolvimento de apps Android é apoiado pelo Programa de compatibilidade do Android, que define um conjunto dos requisitos no Documento de definição de compatibilidade (CDD) e oferece ferramentas de teste pelo conjunto de teste de compatibilidade (CTS). Os programas de compatibilidade do Android garantem que qualquer app Android possa ser executado em qualquer dispositivo compatível com os recursos necessários para o app.
O Google lança novas versões do SO, atualizações de segurança do SO e informações sobre vulnerabilidades descobertas regularmente. O boletim de segurança do Android precisa ser analisado pelos fabricantes para a aplicabilidade dessas atualizações aos produtos com suporte ao SO Android. Para uma revisão da segurança, compatibilidade e sistemas de build do Android, consulte:
- Proteger um dispositivo Android
- Atualizações e recursos de segurança
- Pacote de teste de compatibilidade
- Codinomes, tags e números de build
Sobre os veículos conectados (produtos canônicos de longa duração)
Os veículos começaram a ser conectados com a introdução do rádio AM na década de 1920. De o número de conexões externas físicas e sem fio começou a crescer à medida que os reguladores as montadoras recorreram a eletrônicos para facilitar o diagnóstico e a manutenção (por exemplo, porta OBD-II), melhorar segurança (por exemplo, TPMS) e atingir metas de economia de combustível. A seguinte onda de conectividade apresentamos recursos de conveniência para o motorista, como entrada remota sem chave, sistemas telemáticos e recursos avançados de infoentretenimento, como Bluetooth, Wi-Fi e projeção de smartphone. Hoje, conectividade e sensores integrados (por exemplo, GPS) ajudam na segurança e na direção semiautônoma sistemas.
À medida que o número de conexões de veículos aumenta, a área da possível superfície de ataque do veículo também aumenta. As conexões trazem consigo uma coleção semelhante de preocupações de segurança cibernética, assim como os eletrônicos de consumo. No entanto, embora reinicializações, atualizações diárias de patch e comportamentos inexplicáveis sejam o padrão eletrônicos, eles são inconsistentes para produtos com sistemas críticos para a segurança, como veículos.
Os fabricantes precisam adotar uma abordagem proativa para garantir a postura contínua de segurança e proteção de um produto no campo. Em resumo, os fabricantes precisam estar cientes das vulnerabilidades de segurança conhecidas no produto e adotar uma abordagem baseada em riscos para resolvê-las.
Garantir a segurança a longo prazo
Um veículo conectado geralmente tem uma ou mais unidades de controle eletrônico (ECUs) que incluem várias componentes de software, como SO, bibliotecas, utilitários etc. Os fabricantes devem rastrear esses componentes e identificar vulnerabilidades conhecidas publicadas com análise proativa, incluindo:
- Avaliar regularmente o produto em relação a Vulnerabilidades e Exposições Comuns (CVE, na sigla em inglês) no seu banco de dados.
- Coleta de informações sobre falhas de segurança relacionadas ao produto.
- Testes de segurança.
- Analisando ativamente os Boletins de segurança do Android.
Exemplo de atualizações de SO e patch de segurança (IVIs com Android):
Figura 1. Exemplo de lançamento das principais atualizações de SO e segurança durante o ciclo de vida do veículo.
| # | Etapa | Atividades |
|---|---|---|
|
① |
Desenvolvimento da filial | O fabricante seleciona uma versão do Android (Android X). Neste exemplo, "Android X" se torna a base do que será enviado no veículo dois anos antes do início inicial da produção (SOP). |
| 2 | Lançamento | Alguns meses antes do Android X se tornar a primeira versão do SO enviada no produto, as atualizações
de segurança são extraídas dos boletins de segurança do Android (ASBs, na sigla em inglês) e, possivelmente, de outras fontes consideradas
valiosas pelo fabricante. y2 = o segundo boletim de segurança para a versão X do Android,
aplicado (revertido) pelo fabricante para o Android X. Essa atualização é enviada no produto e
o relógio de produção começa a passar no Ano Zero com o Android X.y2.
Neste exemplo, o fabricante decidiu não enviar a versão anual mais recente do Android X+1. Os motivos para enviar a versão mais recente incluem a adição de novos recursos, o tratamento de novas vulnerabilidades de segurança e/ou o envio de serviços do Google ou de terceiros que exigem a versão mais recente do Android. Motivos contra frete com o lançamento mais recente é a falta de tempo inerente ao veículo o processo de desenvolvimento e lançamento necessário para integrar, testar e validar as mudanças, incluindo conformidade com todos os requisitos regulatórios e de certificação. |
| ③ | Atualização completa do SO | Após o SOP, o fabricante lança a atualização do SO Android X+2, que são duas versões do Android
após a versão usada para o produto inicial (Android X0). Atualizações de segurança do ASB estão disponíveis
para o nível da API (a partir da data de envio), então a atualização sai como X+2.y0 aproximadamente 1,25
anos após a SOP. Essa atualização do SO pode ou não ser compatível com produtos em campo. Se for,
um plano pode ser criado para atualizar os veículos implantados.
A menos que outros contratos comerciais estejam em vigor, a decisão de fazer uma atualização completa do SO é totalmente a critério do fabricante. |
| 4 | Atualização de segurança | Dois anos após o início da vida útil de produção do veículo, o fabricante corrige o
SO Android X+2. Essa decisão é baseada na avaliação de risco do fabricante. O fabricante
escolhe a terceira atualização de segurança ASB para a versão X+2 como base da atualização. Os produtos
que recebem a atualização de segurança agora estão no nível do patch de segurança do Android e do SO (X+2.y3).
Embora os fabricantes possam selecionar patches de segurança individuais de qualquer ASB, eles precisam corrigir todos os problemas necessários no boletim para usar o nível de patch de segurança do Android (SPL, na sigla em inglês) associado ao boletim (por exemplo, 2017-02-05). Ele é usado pelo fabricante a responsabilidade de executar o backport e a liberação de segurança para o produto com suporte. |
| ⑤ | Atualização completa do SO | Uma repetição da etapa 3 (atualização completa do SO), a segunda atualização completa do SO leva o produto ao
Android X+4, três anos após o início da vida útil de produção do veículo. O fabricante agora é
equilibrar os novos requisitos de hardware de uma versão recente do Android com os de hardware de
para o produto e o usuário se beneficia de um SO Android atualizado. O fabricante lança um
sem atualizações de segurança, então o produto agora está no SO (X+4.y0) + Patch de segurança do Android.
Nível
Neste exemplo, devido a limitações de hardware, o X+4 é a última versão principal do Android que será fornecida para esse produto, embora a vida útil esperada de mais de seis anos para o veículo ainda exija suporte de segurança. |
| 6 | Atualização de segurança | Repita a etapa 4 (atualização de segurança). O fabricante tem a tarefa de assumir a segurança do ASB atualizações de uma versão muito mais recente do Android (X+6) e a portabilidade de algumas ou de todas de volta ao Android X+4. É responsabilidade do fabricante mesclar, integrar e realizar as atualizações (ou contrato com terceiros). Além disso, o fabricante deve estar ciente de que os problemas de segurança em versões do Android que não têm mais suporte não são abordados em ASB: |
| ⑦ | Atualização de segurança | Oito anos depois do ciclo de vida de produção de um veículo, quatro lançamentos do Android desde o lançamento última atualização do SO na Etapa 5 (Atualização completa do SO) e dez anos desde que o Android X foi especificado, o a responsabilidade de selecionar e fazer backport de patches de segurança fica inteiramente sobre o fabricante, versões anteriores a três anos do lançamento público no nível da API. |
Práticas recomendadas de segurança
Para dificultar os comprometimentos de segurança, o Google recomenda e emprega o uso de ferramentas melhores práticas de segurança e engenharia de software, conforme descrito em Implementar a segurança.
Diretrizes de segurança
As práticas recomendadas de segurança incluem:
- Use as versões mais recentes das bibliotecas externas e dos componentes de código aberto.
- Não inclua funcionalidades de depuração intrusivas nas versões de lançamento do SO.
- Remova as funcionalidades não utilizadas (para reduzir a superfície de ataque desnecessária).
- Use o princípio de privilégio mínimo e outras Práticas recomendadas de desenvolvimento de apps Android.
Diretrizes para desenvolvimento de software
Práticas recomendadas para o desenvolvimento seguro de software para o ciclo de vida do sistema incluem:
- Realize o modelagem de ameaças para classificar e identificar recursos, ameaças e possíveis mitigações.
- Faça uma análise de arquitetura/design para garantir um design seguro e confiável.
- Realize revisões de código regulares para identificar antipadrões e bugs o mais rápido possível.
- Projete, implemente e execute testes de unidade de cobertura com alta cobertura de código, incluindo:
- Teste funcional (incluindo casos de teste negativos)
- Testes de regressão regulares (para garantir que os bugs corrigidos não reapareçam)
- Teste de fuzz (como parte do pacote de testes de unidade)
- Usar ferramentas de análise de código-fonte estático (scan-build, lint etc.) para identificar possíveis problemas.
- Use ferramentas dinâmicas de análise de código-fonte, como AddressSanitizer, UndefinedBehaviorSanitizer e FORTIFY_SOURCE (para componentes nativos), para identificar e mitigar possíveis problemas durante o desenvolvimento do sistema.
- Ter uma estratégia de gerenciamento para o código-fonte do software e a configuração/versão de lançamento.
- Ter uma estratégia de gerenciamento de patches para geração e implantação de patches de software.
Política de backport de segurança
No momento, o Google oferece suporte ativo para backports de segurança de vulnerabilidades de segurança descobertas e relatadas por três (3) anos a partir da lançamento público do nível da API. O suporte ativo consiste no seguinte:
- Receber e investigar relatórios de vulnerabilidade.
- Criar, testar e lançar atualizações de segurança.
- Forneça lançamentos recorrentes de atualizações de segurança e detalhes do boletim de segurança.
- Faça a avaliação de gravidade de acordo com as diretrizes estabelecidas.
Depois de três anos a partir da data de lançamento pública da API, o Google recomenda o seguinte: diretrizes:
- Use um terceiro (como o fornecedor do SoC ou do kernel) para oferecer suporte de backport para atualizações de segurança do SO com mais de três anos desde o lançamento da API.
- Usar terceiros para realizar revisões de código usando os ASBs fornecidos publicamente. Embora ASBs identificar vulnerabilidades da versão com suporte no momento, o fabricante pode usar informações para comparar as atualizações recém-lançadas com as versões anteriores. Esses dados podem ser usados para realizar análises de impacto e gerar patches semelhantes para versões do SO com mais de três anos desde o lançamento da API.
- Quando apropriado, faça upload de atualizações de segurança para o Android Open Source Project (AOSP).
- O fabricante precisa coordenar o processamento de atualizações de segurança para o código específico do fornecedor, como o código proprietário específico do dispositivo.
- O fabricante precisa participar da notificação sobre a prévia para parceiros com base em NDA do boletim de segurança do Android.
grupo (exige a assinatura de contratos legais como o NDA do Desenvolvedor). Boletins devem
incluem:
- Anúncios
- Resumo dos problemas por nível de patch, incluindo CVE e gravidade
- Detalhes da vulnerabilidade, quando apropriado
Outras referências
Para instruções sobre programação segura e práticas de desenvolvimento de software, consulte:
- Motor Industry Software Reliability Association (MISRA).
- Ferramentas e métodos do Instituto de Engenharia de Software (SEI, na sigla em inglês).
- Instituto Nacional de Padrões e de tecnologia (NIST).
Práticas recomendadas para produtos
O Google recomenda o uso das seguintes práticas recomendadas.
Diretrizes gerais de lançamento
Geralmente, é recomendável que qualquer produto conectado seja lançado com a versão mais recente do SO, e o fabricante deve tentar usar a versão mais recente do SO antes de lançar o produto. Embora o bloqueio da versão seja necessário para melhorar a estabilidade antes do teste e da validação, o fabricante precisa equilibrar a estabilidade do produto obtida de versões mais antigas do SO com versões mais recentes do SO. com menos vulnerabilidades de segurança conhecidas e proteções de segurança aprimoradas.
As diretrizes recomendadas incluem:
- Devido aos longos tempos de lead inerentes ao processo de desenvolvimento dos veículos, os fabricantes pode precisar iniciar com a versão n-2 ou anterior.
- Manter a conformidade com a Compatibilidade do Android para cada versão lançada do SO Android com um uma campanha OTA.
- Implementar um produto compatível com o Firmware over the air (FOTA) do Android para um produto rápido e fácil de usar atualizações. O FOTA deve ser feito usando práticas recomendadas de segurança, como assinatura de código e conexão TLS entre o back-office do produto e da TI.
- Envie vulnerabilidades de segurança do Android identificadas de forma independente para a equipe de segurança do Android.
Observação: o Google considerou notificações específicas para o tipo de dispositivo ou setor nos boletins de segurança do Android. No entanto, como o Google não conhece o kernel, drivers ou chipsets para um determinado dispositivo (veículo, TV, wearable, telefone etc.), O Google não tem uma forma determinista de rotular qualquer problema de segurança com um tipo de dispositivo.
Diretrizes do ciclo de vida do produto
O fabricante precisa fazer todos os esforços para usar a versão mais recente do SO ou as atualizações de segurança da versão em uso durante as melhorias do ciclo de vida do produto. As atualizações podem ser feitas durante períodos atualizações periódicas de produtos ou hotfixes para resolver problemas de qualidade e/ou outros. As práticas recomendadas incluem:
- Crie um plano para lidar com atualizações de driver, kernel e protocolo.
- Use um método adequado para fornecer atualizações aos veículos implantados.
Documento de definição de compatibilidade (CDD)
O CDD descreve os requisitos para que um dispositivo seja considerado compatível com o Android. O CDD é público e está disponível para todos. Você pode fazer o download das versões do CDD do Android 1.6 até a versão mais recente em source.android.com.
Para atender a esses requisitos de um produto, siga estas etapas básicas:
- O parceiro assina o Compromisso de compatibilidade do Android (ACC) com o Google. Uma solução técnica O consultor (TSC) é então atribuído como um guia.
- O parceiro conclui a análise do CDD para a versão do SO Android do produto.
- O parceiro executa e envia os resultados do CTS (descritos abaixo) até que eles sejam aceitáveis. para compatibilidade com o Android.
Conjunto de teste de compatibilidade (CTS)
A ferramenta de teste do conjunto de teste de compatibilidade (CTS) verifica se a implementação de um produto está compatíveis com Android e que os patches de segurança mais recentes estejam incluídos. O CTS é público, de código aberto e disponível para todos. Você pode fazer o download das versões do CTS do Android 1.6 até a versão mais recente em source.android.com.
Cada versão do software Android lançada para o público (imagens de instalação de fábrica e atualização de campo) precisa comprovar a compatibilidade com o Android usando os resultados do CTS. Por exemplo, se o dispositivo executar o Android 7.1, a versão correspondente mais recente do CDD 7.1 e do CTS 7.1 deve ser referenciada quando um imagem de build da intent de lançamento é criada e testada. Recomendamos que os fabricantes usem o CTS cedo e com frequência para identificar e corrigir problemas.
Fluxo de trabalho do CTS
O fluxo de trabalho do CTS envolve a configuração ambiente de testes, execução de testes, interpretação de resultados e compreensão do código-fonte do CTS. As diretrizes a seguir têm como objetivo ajudar os usuários do CTS, como desenvolvedores e fabricantes, usar o CTS de maneira eficaz e eficiente.
- Execute testes com frequência. O CTS foi projetado como uma ferramenta automatizada que integra ao seu sistema de build. A execução frequente do CTS pode ajudar a encontrar defeitos de maneira rápida e degradação do software ou regressões.
- Faça o download e examine o código-fonte do CTS. O código-fonte completo do CTS é um software de código aberto que qualquer pessoa pode fazer o download e usar. O código-fonte baixado pode ser totalmente criado e executado. Quando um teste falha no dispositivo, examinar a seção relevante do código-fonte pode ajudar a identificar o motivo.
- Instale a CTS mais recente. Novas versões do Android podem atualizar o CTS com correções de bugs, melhorias e novos testes. Verifique Downloads do CTS com frequência e atualize seu programa CTS conforme necessário. O fabricante e o Google precisam concordar com a versão do CTS para o lançamento do produto, já que o produto precisa ser congelado em algum momento enquanto o CTS continua sendo atualizado.
Passe no CTS
Para um produto compatível com Android, o Google garante que os relatórios do CTS do dispositivo e do Verificador do CTS os resultados dos testes são aceitáveis. Em princípio, todos os testes precisam ser aprovados. No entanto, um teste que falha por outros motivos que não o dispositivo não estar em conformidade com os requisitos de compatibilidade do Android está sujeito a análise pelo Google. Durante esse processo:
- O fabricante fornece ao Google os patches CTS, validações de patches e justificáveis para provar o argumento.
- O Google examina o material enviado e, se aceito, atualiza os testes de CTS relevantes para que o dispositivo será aprovado na próxima revisão do CTS.
Se um teste do CTS falhar repentinamente após a aplicação de um patch de segurança, o fabricante precisará modificar o patch para que ele não quebre a compatibilidade OU mostrar que o teste está errado e fornecer uma correção para o teste (conforme descrito acima).
O CTS continua aberto para revisões de correções de testes. Por exemplo, o Android 4.4 continua aceitando correções (consulte https://android-review.googlesource.com/#/c/273371/).
Perguntas frequentes
P: Quem é responsável por aplicar atualizações de segurança a uma implementação específica do Android?
A: O fabricante que fornece o dispositivo diretamente é responsável. Esta entidade não é O Google, que publica atualizações de segurança no AOSP, e não em um dispositivo específico (como um veículo).
P: Como o Google lida com problemas de segurança no Android?
A: O Google investiga continuamente os problemas e desenvolve possíveis correções, que são disponibilizadas para todos os níveis de API com suporte como parte do processo de atualização de segurança regular. Desde agosto de 2015, o Google mantém uma cadência regular de publicação de boletins e links para atualizações em source.android.com. O Google também publica atualizações de segurança como parte das principais versões do SO. Consulte também a política de backport de segurança.
P: Se um fabricante integrar todos os patches do AOSP de um ASB, mas não integrar os patches do fornecedor do BSP mencionado no mesmo boletim, ele ainda poderá aumentar o nível de segurança (por exemplo, aplicar o patch correspondente à plataforma/build)?
A: Para declarar um nível de patch de segurança do Android (SPL), o fabricante precisa resolver todos os problemas necessários publicados no boletim de segurança do Android (incluindo boletins anteriores) e mapeados para um SPL específico do Android. Por exemplo, um fabricante que usa Boletim de segurança de março de 2017 (SPL, na sigla em inglês) abordou todos os problemas obrigatórios documentados no boletim de março de 2017 para esse SPL e todas as atualizações anteriores, incluindo atualizações específicas do dispositivo para todas as atualizações anteriores do Android Security Boletins, incluindo as atualizações específicas para dispositivos associadas à SPL de 05/02/2017.
P: O que acontece quando o fabricante não concorda com as atualizações de segurança fornecidas pelo fornecedor do BSP OU quando as atualizações de segurança exigidas por um ASB não são fornecidas pelos fornecedores?
A: Um ASB descreve vulnerabilidades de segurança (enumeradas por uma lista de CVEs) e geralmente fornece testes de segurança correspondentes. O objetivo é garantir que as vulnerabilidades listadas não possam mais ser reproduzidas em um dispositivo e que ele possa passar nos testes de segurança associados. Sendo assim, o problema é não se trata de uma atualização de segurança fornecida pelo Google ou por um fornecedor terceirizado, mas sim de uma fabricante atestando que o dispositivo não está vulnerável à lista de CVEs no ASB. O fabricante pode usar as atualizações de segurança fornecidas ou, se tiver uma mudança mais adequada para o dispositivo, use essa mudança.
Por exemplo, considere um caso em que o Google resolve uma vulnerabilidade de segurança do AOSP usando mudança de código que permite ao componente permanecer totalmente funcional e em conformidade com o CDD. Se o fabricante determinar que o componente não é necessário no dispositivo ou não é obrigatório pelo CDD (ou testes de certificação relacionados), o fabricante poderá remover o componente para reduzir as necessidades de manutenção futuras e reduzir a superfície de ataque. Embora o fabricante não tenha usado a atualização de segurança fornecida, garantiu que o dispositivo não ficasse vulnerável à CVE documentada no boletim de segurança. No entanto, em desviar da atualização de segurança recomendada, o fabricante corre o risco de resolver o problema, introduzir novas vulnerabilidades de segurança ou reduzir a e a funcionalidade do build final.
Embora trabalhemos com todos os parceiros de SoC para garantir que todos os problemas em um ASB sejam corrigidos, recomendamos que os fabricantes façam um contrato de manutenção com os fornecedores de SoC para o ciclo de vida de um dispositivo. SoCs podem parar de fornecer um chipset antes do desejado, portanto, estabelecer acordos prévios para selecionar o chipset do dispositivo é uma parte importante do processo de inicialização do dispositivo.
Por fim, nos casos em que é impossível adquirir diretamente ou criar de forma independente uma correção para um problema documentado em um ASB, um fabricante pode manter o SPL do Android anterior e ainda adicionar as novas correções disponíveis ao build. No entanto, essa prática acabará por levar a problemas com o build porque o Android garante que o nível mais recente do patch de segurança esteja disponível nos dispositivos). O Google recomenda trabalhar com seu SoC com antecedência para evitar essa prática.
P: Se o fabricante determinar que um item de ASB não é aplicável ao produto, ele ainda precisa ser aplicado ou corrigido para atender aos outros requisitos do Google ou ser aprovado no CTS?
R: Não é necessário aplicar patches para declarar um nível de patch de segurança do Android (SPL). O fabricante precisa atestar que o build não é vulnerável ao problema.
Um exemplo é quando um componente que está recebendo patches não existe no sistema do fabricante ou é removido do sistema do fabricante para resolver um problema. Nesse caso, o sistema pode estar em conformidade sem exigir que o fabricante aplique um patch.
Isso é fundamentalmente diferente de um fabricante que, por exemplo, quer corrigir e não aplicar outros patches aplicáveis que causariam a falha de um teste de segurança. Em Nesse caso, presume-se que a SPL não foi atendida.