Se você tem acompanhado os desenvolvimentos no Android, deve ter ouvido o nome “Boot verificado” nos últimos anos. O Google introduziu o recurso de segurança no Android 4.4 (Kitkat), de uma forma totalmente não intrusiva, e vem lentamente aumentando sua visibilidade nos lançamentos mais recentes de seu sistema operacional Android.
Nos últimos dois dias, vimos notícias sobre a presença de uma " inicialização confirmada estritamente reforçada " na mais recente iteração do Google do sistema operacional móvel mais usado do mundo. O Android Nougat usará um nível mais alto de verificação de segurança quando o dispositivo for inicializado. Embora, no Marshmallow, o Boot verificado apenas tenha alertado o usuário, caso tenha detectado algo errado com a partição do sistema, o Android Nougat dará um passo além e usará o que o Google chama de "inicialização verificada estritamente reforçada", que será Não permitir que o dispositivo inicialize, caso detecte anomalias na partição, alterações feitas no gerenciador de inicialização ou a presença de código “malicioso” no dispositivo. Isso levanta a questão: "O que exatamente isso significa para os usuários?", A resposta difere para as duas categorias principais de usuários do Android (usuários casuais e avançados), e nós vamos fornecer a resposta para ambos .
Inicialização verificada estritamente reforçada
Primeiro, um pouco de conhecimento sobre Boot verificado: normalmente, quando o Android executa um teste de verificação em partições, ele faz isso dividindo as partições em blocos do 4KiB e verificando-os em uma tabela assinada. Se tudo sair, significa que o sistema está completamente limpo. No entanto, se alguns blocos forem violados, o Android informará o usuário sobre os problemas e deixará o usuário resolvê-lo (ou não).
Tudo o que está prestes a mudar com o Android Nougat e o Boot verificado com rigor garantido. Quando o Boot verificado for executado no modo Enforced, ele não tolerará falhas nas partições. Se detectar algum problema, ele não permitirá que o dispositivo inicialize e poderá permitir que o usuário inicialize em um ambiente de modo seguro, para tentar corrigir os problemas. No entanto, a inicialização verificada estritamente reforçada não é apenas uma verificação contra bloqueios de dados incorretos. Geralmente, também pode corrigir erros em blocos de dados. Isso é possível pela presença de códigos de correção de erros de encaminhamento, que podem ser usados para corrigir erros em blocos de dados. No entanto, isso nem sempre funciona, e nos casos em que isso não acontece, você está praticamente morto na água.
Bota verificada estritamente reforçada: o bom, o mau e o feio
1. O Bom
Garantir a inicialização confirmada em dispositivos Android aumentará a segurança nos dispositivos. No caso de o dispositivo ser infectado por malware, o Boot Verificado do Strictly Enforced irá detectá-lo na próxima vez que você inicializar o dispositivo, corrigi-lo ou solicitar que você faça algo a respeito.
Esse recurso também verificará a corrupção de dados e, na maioria dos casos, poderá corrigir quaisquer erros introduzidos nos dados, graças aos códigos FEC. O Google usa códigos FEC que podem corrigir um erro de bit desconhecido em 255 bits . Claro, isso parece ser um número bem pequeno, mas vamos colocar isso em perspectiva, no que diz respeito a um dispositivo móvel:
Observação: os valores abaixo são extraídos da postagem no blog do engenheiro do Google Sami Tolvanen, sobre desenvolvedores do Android.
O Google poderia ter usado códigos RS (255, 223) FEC: esses códigos teriam sido capazes de corrigir 16 erros de bits desconhecidos em 255 bits, mas a sobrecarga de espaço por causa dos 32 bits de dados redundantes teria sido de quase 15%, e isso é muito, especialmente em dispositivos móveis. Acrescente isso ao fato de que o Android é o sistema operacional predominante nos smartphones de baixo custo que vêm com memórias de 4 a 8 GB, e 15% de espaço extra com certeza parece muito.
Ao sacrificar as capacidades de correção de erros, em favor de economizar espaço, o Google decidiu usar códigos RS (255, 253) FEC. Esses códigos podem corrigir apenas um único erro desconhecido em 255 bits, mas a sobrecarga de espaço é de apenas 0, 8%.
Nota: RS (255, N) é uma representação dos códigos Reed-Solomon, que são um tipo de códigos de correção de erros.
2. O Mau
Já ouviu falar de "Há dois lados para uma moeda"? Claro que você tem. Embora as intenções do Google com o Strictly Enforced Verified Boot fossem, sem dúvida, puras como um unicórnio bebê, elas vêm com seus próprios problemas.
Quando o Check Boot verificado estritamente reforçado procura por malware, ele também verifica se há modificações ilegais no kernel, no bootloader e em outras coisas que não vou aborrecer, mas isso significa que o Android Nougat provavelmente encontrará muitos problemas com o enraizamento e Flashing Custom ROMs, porque o Boot verificado não consegue distinguir entre o código de malware indesejado e o código que desbloqueou o bootloader. O que significa que, se o seu dispositivo vier com um bootloader bloqueado, e o seu OEM não permitir o desbloqueio do bootloader, você praticamente não poderá fazê-lo. Espero que alguém descubra uma façanha para isso.
Felizmente, a maioria das pessoas que fazem root em seus dispositivos e criam ROMs personalizadas para os recursos e funcionalidades adicionais, é compatível com telefones compatíveis com o desenvolvedor, como o Nexus. Há muito a considerar em relação a esse tópico, e definitivamente não é o fim das ROMs personalizadas, pelo menos não em dispositivos que vêm com um bootloader desbloqueado, ou que permitem desbloquear o bootloader. No entanto, dispositivos como os telefones Samsung não permitem oficialmente o desbloqueio do bootloader e, nesses dispositivos, o desbloqueio do seu bootloader definitivamente será visto como “um problema” pelo Boot verificado, impedindo que o dispositivo seja inicializado.
Outro problema que surgirá com o Boot verificado estritamente reforçado é aquele que afetará até mesmo os usuários que realmente não se importam em obter privilégios de root ou instalar ROMs personalizadas. Com o tempo, à medida que você usa seu dispositivo, é provável que haja corrupção de dados naturais na memória; não devido à presença de um malware, mas simplesmente porque isso acontece. Normalmente, isso não é um problema ou, pelo menos, não é um problema tão grave como o Boot verificado irá transformá-lo. Se você tiver dados corrompidos que a inicialização verificada do Strictly Enforced não pode corrigir na inicialização, ela não permitirá que o dispositivo inicialize. Na minha opinião, esse é um problema maior e mais visível do que alguns dados corrompidos na partição do usuário.
3. O Feio
Em todos os benefícios de impor a inicialização confirmada e todos os possíveis problemas, o mais preocupante, provavelmente, é o fato de que os OEMs podem começar a usá-la indevidamente para bloquear seus dispositivos, de modo que as pessoas não possam usar o Android seja: aberto, fácil de usar e totalmente personalizável. Inicialização verificada estritamente reforçada colocará nas mãos dos OEMs, o poder de garantir que as pessoas não consigam desbloquear os bootloaders em seus dispositivos, proibindo-os de instalar ROMs personalizadas e ferramentas de aprimoramento de recursos como os Xposed Modules.
Android Nougat: uma mudança radical na maneira como o Android funciona?
Embora tenhamos certeza de que as intenções do Google eram simplesmente evitar possíveis problemas para usuários ocasionais do Android, que não sabiam o que fazer no caso de o malware ser afetado por um malware ou se a memória deles havia corrompido blocos de dados, ele pode ter fornecido OEMs e fabricante é a ferramenta perfeita para bloquear os usuários a viver com o que lhes foi oferecido, e nada mais.
É claro que alguém vai descobrir uma façanha, ou uma solução alternativa para essa situação, e nós esperamos que isso aconteça, no verdadeiro espírito do Android. Até que alguém descubra uma solução, no entanto, tudo o que nós, como usuários, podemos fazer, é garantir que compramos nossos dispositivos de fabricantes amigos do desenvolvedor.
Imagem em destaque Cortesia: Flickr
