Android Q: todos os novos recursos de segurança e privacidade chegando ao Android 10

No Google I/O, aprendemos sobre as melhorias que o Android Q traz. Novos recursos e melhorias de segurança e privacidade estão presentes em todo o novo sistema operacional Android.

Cada nova versão do sistema operacional Android traz melhorias em quase todos os aspectos, desde design, recursos, APIs e muito mais. No Google I/O no início deste mês, aprendemos sobre todos os melhorias que o Android Q vai trazer, e claro, novos anúncios de privacidade e segurança não ficaram de fora da conferência. A segurança da plataforma é um dos aspectos mais importantes de um sistema operacional, especialmente para um sistema operacional que levamos conosco para todos os lugares em nossos bolsos. Se o Android não fosse seguro, não confiaríamos nele metade das funções que confiamos. Os pagamentos NFC estariam fora de questão, o compartilhamento de arquivos seria, na melhor das hipóteses, duvidoso e a conexão com outros dispositivos seria uma loucura total. Apesar do problema de longa data da fragmentação de versões, o Google fez muito bem em manter o número de problemas de segurança ao mínimo.

O Android amadureceu e se tornou um sistema operacional rico em recursos e altamente seguro. Mas é claro que sempre há espaço para melhorias. Existem muitos fatores que contribuem para essa segurança, e alguns deles estão sendo melhorados de alguma forma com o Android Q.


Criptografia

Sendo um dos métodos de segurança mais básicos, é importante que cada dispositivo suporte criptografia forte. Atualmente, muitos OEMs enviam seus dispositivos com hardware de criptografia dedicado. Embora isso seja benéfico, também é caro. Como tal, o hardware dedicado normalmente tem sido restrito a dispositivos de nível médio a alto. Isso não quer dizer que dispositivos low-end não pode suporta criptografia, mas sem criptografia acelerada por hardware a experiência geral do usuário é prejudicada devido aos tempos lentos de leitura/gravação. É aí que entra o Adiantum.

Adiantum

Em fevereiro, o Google anunciou o Adiantum como alternativa algoritmo de criptografia para telefones de baixo custo que não suportam conjuntos de instruções AES regulares. Adiantum foi projetado especificamente para funcionar sem nenhum hardware dedicado. Ele serve como uma alternativa mais leve à criptografia AES normal do Android. Benchmarks do Google diga-nos que na verdade é 5x mais rápido que o AES, com a desvantagem de comprometer ligeiramente a segurança. Isso o torna o candidato ideal para telefones de baixo custo, como aqueles com Android Go Edition. Adiantum também se destina a produtos como smartwatches e uma variedade de dispositivos da Internet das Coisas.

Até agora, Adiantum era opcional; os fabricantes poderiam habilitá-lo em dispositivos lançados com Android Pie, mas não era o algoritmo de criptografia padrão. Agora, o Adiantum está incluído nativamente como parte do Android Q. Isso significa que todos os dispositivos lançados com Q serão obrigados a criptografar os dados do usuário, sem exceções. Como resultado, os dispositivos lançados com Android Q têm garantia de criptografia de armazenamento, seja via Adiantum ou não.

Biblioteca de segurança do Jetpack

Jetpack é um conjunto de bibliotecas de suporte do Android e uma das mais novas adições está em alfa: a Biblioteca de Segurança do Jetpack. A biblioteca simplifica o processo de proteção do seu aplicativo, lidando com coisas como o gerenciamento de armazenamentos de chaves apoiados por hardware e a geração e validação de chaves.

TLS 1.3

No entanto, o armazenamento não é a única área em que a criptografia foi aprimorada. A comunicação com outros dispositivos melhorou muito, com a introdução de Suporte TLS 1.3 por padrão. TLS 1.3 é o padrão criptográfico de rede mais recente, finalizado pela IETF em agosto de 2018. O TLS 1.3 fornece mais privacidade para trocas de dados, criptografando mais handshakes de negociação. Além disso, é mais rápido que o TLS 1.2 devido ao fato de uma viagem de ida e volta inteira ser eliminada do handshake de estabelecimento da conexão. Juntamente com algoritmos modernos mais eficientes, isso proporciona um aumento de até 40% na velocidade.

TLS 1.3 no Google Chrome. Fonte: Google.

O TLS agora pode ser atualizado diretamente do Google Play porque faz parte do componente "Conscrypt". Você pode ler mais sobre isso e o Projeto Mainline aqui.

Dado que confiamos diariamente em tantas transações confidenciais em nossos dispositivos, o TLS atualizado é mais importante do que nunca. Armazenar cartões de embarque - e até carteiras de motorista digitais em algum momento no futuro - no Android significa que todos os dispositivos devem criptografar os dados do usuário da melhor maneira possível. Adiantum e a criptografia forçada abrirão caminho para que até mesmo os dados mais confidenciais sejam armazenados nos dispositivos mais baratos. Mas a criptografia não é a única maneira pela qual o Google está aumentando a segurança do Android na versão Q.


Permissões e alterações de privacidade no Android Q

Armazenamento com escopo

O armazenamento com escopo é uma nova proteção empregada para impedir que aplicativos leiam/gravem arquivos em armazenamento externo que não estejam contidos em seu próprio diretório específico do aplicativo em área restrita. O objetivo do Google é triplo: melhor atribuição de quais aplicativos têm controle sobre quais arquivos, a proteção dos dados do aplicativo e a proteção dos dados do usuário.

O Google está dobrando a API MediaStore para conteúdo compartilhado de áudio, vídeo e imagem. Por padrão, todos os aplicativos podem inserir, modificar ou excluir seus próprios arquivos do MediaStore. Imagens, MediaStore. Vídeo e MediaStore. Coleções de áudio sem necessidade de permissão. O Android Q também adiciona um novo MediaStore. Transferências coleção para armazenar conteúdo baixado pelo usuário, com a qual todos os aplicativos que usam a API MediaStore podem contribuir. Embora os arquivos armazenados em diretórios específicos do aplicativo em área restrita sejam excluídos após a desinstalação, todos os arquivos contribuídos para as coleções do MediaStore persistem após a desinstalação.

Para acessar qualquer arquivo criado por outro aplicativo, esteja o arquivo em uma das coleções do MediaStore ou fora delas, o aplicativo deve usar o Storage Access Framework. Além disso, os metadados EXIF ​​das imagens são editados, a menos que seu aplicativo tenha a nova permissão ACCESS_MEDIA_LOCATION concedida. No Android Q, os aplicativos também podem controlar em qual dispositivo de armazenamento a mídia será armazenada, consultando o nome do volume usando getExternalVolume().

O Google inicialmente impôs restrições de armazenamento com escopo em todos os aplicativos no Android Q, independentemente dos níveis de API alvo, mas após feedback, a empresa está dando mais tempo aos desenvolvedores para fazer ajustes. Os detalhes completos sobre as alterações no armazenamento com escopo podem ser encontrados nesta páginae você pode descobrir mais sobre as recomendações do Google sobre as práticas recomendadas para armazenamento compartilhado em assistindo este Google I/O falar.

Avisos para aplicativos direcionados ao nível de API < 23

As restrições de permissão não param por aí, entretanto. A instalação de um aplicativo direcionado a um nível de API inferior a 23 (Android Lollipop ou anterior) fará com que o sistema operacional exiba um aviso ao usuário se o aplicativo solicitar permissões confidenciais durante a instalação. Antes da instalação, os usuários terão a oportunidade de especificar manualmente quais permissões desejam conceder ao aplicativo antes de prosseguir. Assim, o Android Q não permite mais que aplicativos contornem as permissões de tempo de execução.

Assim como o CopperheadOS, o Android Q padrão agora permite que o usuário desative todas as permissões perigosas solicitadas antes de executar um aplicativo pela primeira vez. Isso se aplica apenas a aplicativos direcionados ao nível de API 22 ou inferior, antes da introdução das permissões de tempo de execução (no Android Marshmallow).

Eventual SYSTEM_ALERT_DEPRECATION em favor da API Bubbles

API Bubbles em ação. Fonte: Google.

A permissão de sobreposição (SYSTEM_ALERT_WINDOW) não pode mais ser concedida para aplicativos executados no Android Q (Go Edition). Para dispositivos que não sejam da Go Edition, o Google está incentivando os desenvolvedores a usarem a nova API Bubbles. API Bubbles é um recurso introduzido em AndroidQ Beta 2 que permite funcionalidades semelhantes às cabeças de bate-papo do Facebook Messenger. As notificações de aplicativos aparecem como pequenas bolhas nas bordas da tela, que se expandem quando tocadas pelo usuário. Dentro do balão, um aplicativo pode exibir uma atividade.

Essa mudança foi necessária porque permitir que aplicativos desenhem livremente sobreposições sobre outros aplicativos apresenta riscos de segurança óbvios. Os infames "Capa e espada"O exploit usou essa fraqueza extensivamente. A funcionalidade da API de sobreposição foi restrita já no Android Oreo, mas agora a edição Go do Android Q removeu totalmente o acesso à API com um versão futura para descontinuar totalmente.

Restrições de lançamento de atividades em segundo plano

Os aplicativos em segundo plano não podem mais iniciar automaticamente uma atividade enquanto o telefone está desbloqueado, independentemente do nível de API de destino. Há toda uma lista de condições sob as quais os aplicativos agora podem iniciar atividades, que você pode ler aqui. Os aplicativos em segundo plano que não atendem a essas condições e desejam iniciar uma atividade com urgência agora terão que avisar o usuário por meio de uma notificação. Se a notificação for criada com uma intenção de tela inteira pendente, a intenção será iniciada imediatamente se a tela estiver desligada – útil para alarmes ou chamadas recebidas.

Restrição de acesso à área de transferência em segundo plano

O acesso à área de transferência em segundo plano é não é mais possível. Qualquer aplicativo que não esteja em primeiro plano ou definido como método de entrada padrão não será capaz de ler sua área de transferência de forma alguma. Isso atinge especialmente aplicativos como gerenciadores de área de transferência. O Google diz que essa mudança afeta apenas aplicativos direcionados exclusivamente ao Android Q, mas nossos testes indicam que a restrição não discrimina; qualquer aplicativo que tentamos não conseguiu ver a área de transferência.

Essa mudança, é claro, faz sentido. Muitas vezes copiamos informações confidenciais para a área de transferência – coisas como senhas e detalhes de cartão de crédito – mas ainda é uma pena ver os gerenciadores da área de transferência irem pelo ralo.

Acesso à localização apenas enquanto um aplicativo estiver em uso

Novas opções de permissão de localização

Uma nova configuração habilitada pelo usuário só permite que os aplicativos cheguem à sua localização enquanto o aplicativo estiver em uso. A última versão beta do Android Q também adicionou uma notificação lembrando se você concedeu a um aplicativo acesso permanente ao local.

Funções

Funções

Uma nova API "Roles" foi adicionada. Os papéis são essencialmente grupos com acesso a permissões predefinidas. Por exemplo, aplicativos com função de galeria podem ter acesso às suas pastas de mídia, enquanto aplicativos com função de discador podem lidar com chamadas. Os aplicativos aos quais o usuário concede uma determinada função também devem ter os componentes necessários. Apps com função de galeria, por exemplo, devem ter o filtro de intenção de ação andróide.intenção.Ação.PRINCIPAL e o filtro de intenção de categoria android.intent.categoria. APP_GALLERY para aparecer como um aplicativo de galeria nas configurações.

Bloco Sensores desligados Configurações rápidas

Bloco Configurações rápidas de sensores

Há um novo bloco de configurações rápidas "Sensores desligados" que desativa as leituras de todos sensores (acelerômetro, giroscópio, etc.) em seu dispositivo para verdadeira privacidade. Este bloco de configurações rápidas fica oculto por padrão, mas pode ser ativado acessando os "blocos de desenvolvedor de configurações rápidas" nas opções do desenvolvedor.

Restrições para /proc/net

Os aplicativos não podem mais acessar proc/net, tornando serviços como o netstat inviáveis. Isso protege os usuários contra aplicativos maliciosos que monitoram os sites e serviços aos quais eles se conectam. Os aplicativos que precisam de acesso contínuo, como VPNs, precisam usar o Gerenciador de estatísticas de redeGerenciador de conectividade Aulas.

Endereços MAC aleatórios

Seu endereço MAC é um identificador exclusivo que as redes usam para lembrar qual dispositivo é qual. No Android Q, sempre que você se conectar a uma nova rede, seu dispositivo usará um novo endereço MAC aleatório. Como resultado, redes não conseguem rastrear sua localização combinando as redes WiFi às quais você se conecta com o endereço MAC do seu telefone. O endereço MAC real de fábrica do dispositivo ainda pode ser obtido por aplicativos por meio do getWifiMacAddress() comando.


Endurecimento de plataforma no Android Q

Um único bug no Android não significa que os invasores agora tenham acesso total ao sistema operacional ou que possam contornar qualquer sistema de segurança. Isto se deve em parte a uma série de salvaguardas, como isolamento de processos, redução da superfície de ataque, decomposição arquitetural e mitigação de exploração. Estas salvaguardas tornam as vulnerabilidades mais difíceis ou mesmo impossíveis de explorar. Como resultado, os invasores normalmente precisam de uma infinidade de vulnerabilidades antes de atingirem seus objetivos. No passado, vimos ataques como DRAMMER que funcionam encadeando várias explorações.

O Android Q adota proteções como essas e as aplica a áreas mais sensíveis, como mídia e componentes Bluetooth, juntamente com o kernel. Isso traz algumas melhorias marcantes.

  • Uma sandbox restrita para codecs de software.
  • Aumento do uso de higienizadores na produção para mitigar classes inteiras de vulnerabilidades em componentes que processam conteúdo não confiável.
  • Shadow Call Stack, que fornece integridade de fluxo de controle (CFI) de ponta e complementa a proteção de ponta fornecida pelo CFI do LLVM.
  • Protegendo a Randomização de Layout de Espaço de Endereço (ASLR) contra vazamentos usando eXecute-Only Memory (XOM).
  • Introdução do alocador reforçado Scudo, que torna uma série de vulnerabilidades relacionadas ao heap mais difíceis de explorar.

Isso é muito jargão de software. A essência disso é que, primeiro, os codecs de software agora são executados em sandboxes que têm menos privilégios, o que significa que é é menos provável que software malicioso consiga executar comandos que possam danificar o seu dispositivo, como no caso de PalcoFright lá em 2015.

Uma sandbox restrita para codecs de software. Fonte: Google.

Em segundo lugar, o Android agora verifica o acesso ao array fora dos limites em mais lugares, bem como estouros. Prevenir overflows e instruir os processos a falharem com segurança diminui significativamente a porcentagem de vulnerabilidades do espaço do usuário. O que isto significa é que se um programa malicioso tentar fazer com que algo trave, tentando deliberadamente obter acesso a dados que não existem, o Android agora reconhecerá isso e sairá do programa, em vez de batendo.

Em terceiro lugar, o Shadow Call Stack protege os endereços de retorno, armazenando-os em uma pilha shadow separada, tornando-os inacessíveis aos programas regulares. Os endereços de retorno normalmente são ponteiros para funções, portanto, proteger esses endereços é importante para garantir que os invasores não possam acessar funções que não deveriam.

Em quarto lugar, ASLR é um método de proteção que randomiza onde os programas são armazenados na memória, tornando-os mais difícil descobrir onde os programas estão sendo armazenados na memória com base na localização de outros programas. A memória somente eXecute fortalece isso, tornando o código ilegível.

Finalmente, Scudo é um alocador de heap dinâmico que gerencia proativamente a memória de uma forma que torna as vulnerabilidades baseadas em heap muito mais difíceis de explorar. Você pode ler mais sobre isso aqui.


Autenticação

Atualizações para BiometricPrompt no Android Q

O Google introduziu a nova API BiometricPrompt há mais de um ano, em Visualização 2 do desenvolvedor Android P. O objetivo era ser um prompt genérico do Android para métodos de desbloqueio biométrico. A ideia é que os dispositivos que suportam mais do que apenas a digitalização de impressões digitais, por ex. a digitalização da íris na linha Galaxy S da Samsung poderá usar esses métodos quando os aplicativos solicitarem verificação.

O Android Q adiciona suporte robusto para verificação facial e de impressão digital, além de expandir a API para oferecer suporte à autenticação implícita. A autenticação explícita requer que o usuário se autentique de alguma forma antes de prosseguir, enquanto a implícita não precisa de mais interação do usuário.

Fluxo implícito e explícito da API BiometricPrompt. Fonte: Google.

Além disso, os aplicativos agora podem verificar se um dispositivo suporta autenticação biométrica por meio de um simples chamada de função, permitindo que eles não percam tempo invocando um BiometricPrompt em dispositivos que não apoie isso. Um uso ideal para isso seria se os aplicativos desejassem fornecer uma configuração "Ativar login biométrico" com base no fato de um dispositivo suportar ou não autenticação biométrica.

Os blocos de construção para suporte à ID Eletrônica

No início deste ano, descobrimos evidências de que o Google está trabalhando no suporte para identificações eletrônicas no Android. No I/O, o Google nos atualizou sobre o andamento do recurso. O Google diz que está trabalhando com a ISO para padronizar a implementação de carteiras de motorista móveis, com passaportes eletrônicos em andamento. Para os desenvolvedores, o Google fornecerá uma biblioteca Jetpack para que aplicativos de identidade possam começar a ser feitos.


Linha principal do projeto no Android Q

O Projeto Mainline é um grande empreendimento do Google para reduzir a fragmentação de determinados módulos e aplicativos do sistema. O Google controlará as atualizações de cerca de 12 componentes do sistema por meio da Play Store. Já falamos detalhadamente sobre o Projeto Mainline em um artigo anterior se você estiver interessado em ler mais.


Conclusão

A segurança sempre foi uma parte essencial do desenvolvimento do Android. O Google fez um trabalho impressionante em manter o Android atualizado com os recursos de segurança mais recentes, além de fazer algumas inovações próprias. Eles continuam esse processo de desenvolvimento com o Android Q, repleto de recursos de segurança feitos para garantir que seus dados estejam mais seguros do que nunca.


Fonte 1: O que há de novo na segurança do Android Q [Google]

Fonte 2: Segurança no Android: o que vem a seguir [Google]

Fonte 3: Enfileirar as melhorias de proteção [Google]

Com contribuições de Mishaal Rahman e Adam Conway.