Com quantidades cada vez maiores de dados valiosos armazenados na nuvem, é ainda mais importante que eles sejam protegidos de forma robusta. Medidas de segurança fortes em serviços de dados na nuvem, como o iCloud, beneficiam todos: usuários finais, provedores de serviços em nuvem como a Apple e plataformas de ecossistema como a Reincubate.
Os mecanismos para proteger esses dados assumem várias formas, e o histórico da Apple na implementação deles tem sido bom. Este artigo examina várias das técnicas que ela, e a equipe da Reincubate, vêm usando.
Armazene menos, se possível
Primeiro, armazenar menos em vez de mais compensa. Há exemplos em que os dados nunca foram armazenados no iCloud, como os dados de reconhecimento facial do app Fotos, que não ficam na Biblioteca de Fotos do iCloud, e sim em cache local. Os artefatos de dados do HealthKit, do HomeKit e do TouchID da Apple são tratados de forma semelhante, assim como os dados de reconhecimento facial da tela de bloqueio do Android. Claro, muitas vezes isso é uma troca entre conveniência e o valor de sincronizar esses dados entre dispositivos. Alguns sistemas usam uma abordagem parcial. Por exemplo, o iMessage armazena uma quantidade limitada de conteúdo na nuvem, mas depende de outros dados sincronizados diretamente entre os dispositivos.
Sistemas de mensagens seguras, como o Telegram ou o WhatsApp, adotam uma abordagem completamente diferente. Como nenhum dado (ou pelo menos não muito) é armazenado nos servidores deles, um conjunto rico de dados precisa ser incluído em qualquer backup do dispositivo para que o usuário consiga fazer backup e restaurar de forma significativa. De certo modo, para manter a segurança, esses fornecedores de apps lavam as mãos quanto ao gerenciamento desses dados e deixam a cargo do usuário final, que pode optar por fazer backup dos dispositivos localmente ou na nuvem.
Assim, há dois extremos, e dá para contrastar o WhatsApp, com pouco na nuvem e tudo no backup, com o Facebook Messenger, que não armazena nada no backup do dispositivo porque tudo está disponível na nuvem, e precisa estar para que o Facebook ofereça sua interface web.
Não existe uma solução certa aqui, mas vale pensar a respeito: usar um app que hospeda esses dados exige que o fornecedor do app os gerencie com segurança, e os usuários muitas vezes ficam sem saber o que é armazenado e como. Usar um app que não armazena dados de forma centralizada significa que o usuário final deve assumir a responsabilidade pela segurança dos próprios dados de backup, a menos que deixe que eles sejam guardados na nuvem da própria plataforma, como acontece com os Backups do iCloud e com os backups de dispositivos do Android 7.0+ do Google.
É interessante que, como no gráfico abaixo, alguns criadores de apps ocupam os dois extremos dessa posição. O app Snapchat armazena quase todos os seus dados na nuvem, enquanto a extensão física do app, o Spectacles, armazena todos os seus dados localmente no dispositivo.
Diferentes abordagens de segurança para dados de apps
Embora não tenham sido amplamente lançados, os Snapchat Spectacles são bastante inseguros: ao manter pressionado o botão de “snap” por sete segundos, um hacker consegue pareá-los com um novo telefone e obter qualquer um dos snaps não criptografados que o legítimo proprietário armazenou neles. Isso contrasta fortemente com os princípios de segurança adotados no Apple Watch.
Criptografia forte
Isso nos leva à segunda técnica fundamental: criptografia forte, idealmente com armazenamento incompleto das chaves. Se os dados forem considerados sensíveis demais para um backup que possa ser acessado caso o dispositivo seja destruído ou substituído, existem outras técnicas que podem ser usadas. Ao exigir o uso de um dispositivo específico, o recurso “Secret Conversations” do Facebook usa identificadores de hardware para criptografar o conteúdo. Se o dispositivo for perdido, o conteúdo se torna praticamente irrecuperável.
Alguns sistemas empregam uma técnica semelhante, em que um token específico do dispositivo pode ser criado para garantir que só um número limitado de dispositivos acesse o conteúdo por vez. O Snapchat e o WhatsApp usam, cada um, uma variação disso. Ao fazer login no Snapchat em um dispositivo, um token é criado e compartilhado entre os servidores do Snapchat e o dispositivo. Se o mesmo usuário fizer login em outro dispositivo, um novo token será criado, substituindo o que estava antes na nuvem e forçando o primeiro dispositivo a sair da conta, pois ele não conseguiria descriptografar nenhuma mensagem recebida. Há uma vulnerabilidade óbvia nessa técnica quando usada em sistemas inseguros: o token pode ser copiado e usado em outro lugar. Se fosse preciso um argumento para explicar por que usar um Android com root ou um dispositivo iOS com jailbreak é uma péssima ideia, este é ele, e também explica por que é improvável que haja um cliente web do Snapchat tão cedo.
Perder mensagens secretas do Facebook é uma coisa, mas alguns dados são ao mesmo tempo altamente sensíveis e altamente valiosos para o proprietário. Parece contraintuitivo, mas, se o valor pessoal dos dados for grande o bastante, eles costumam ser armazenados de maneira que haja muitas formas possíveis de descriptografá-los ou recuperá-los. Isso troca segurança por menos impraticabilidade. Por exemplo, há uma enorme quantidade de dados associados a contas do iCloud e do Google, incluindo, nos dois casos, alguma forma de chaveiro distribuído na nuvem que guarda todas as senhas do usuário. Além disso, como o Google promove suas contas como mecanismo de autenticação em outros sites com OAuth, perder de forma irrecuperável o acesso a contas como essas seria um trago amargo.
Como essas contas são consideradas valiosas demais para arriscar sua perda permanente, usa-se uma solução intermediária, em que os dados são armazenados na nuvem, mas criptografados com um token ou uma senha que só o usuário guarda e que não é armazenada. É por isso que, por exemplo, ao fazer login em uma instalação nova do navegador Chrome do Google, as senhas armazenadas na nuvem só ficam disponíveis depois que uma senha secundária de sincronização é inserida no navegador.
Dividindo o peso da criptografia
Tim Cook, da Apple, que é sério e fundamentalmente está certo sobre segurança, atestou a crença deles nessa técnica apenas no ano passado:
For many years, we have used encryption to protect our customers’ personal data because we believe it’s the only way to keep their information safe. We have even put that data out of our own reach, because we believe the contents of your iPhone are none of our business.
— Tim Cook em “A Message to Our Customers”
Entre outras coisas, isso pode ajudar os provedores de nuvem a evitar a divulgação dos dados completos dos usuários a agentes governamentais. Se forem obrigados a fornecê-los por mandado judicial, eles podem fazê-lo sem expor diretamente os dados do usuário, pois os dados exigem uma descriptografia adicional, que só pode ser feita com uma chave que somente o usuário final possui.
Às vezes, como no caso da autenticação multifator (MFA), da autenticação de dois fatores (2FA) ou da verificação em duas etapas (2SV), isso significa que a chave adicional só pode ser enviada a um dispositivo específico ou gerada por ele. Bancos e VPNs costumam usar leitores físicos de cartão ou geradores seguros de sementes, que são formas de geradores de senhas de uso único baseadas em tempo (OTP ou TOTP). Tanto o Google quanto a Apple oferecem MFA simples por SMS, além de sistemas completos de 2FA, com o do Google usando HOTP/OATH e o da Apple sendo proprietário.
Quando agências de segurança ou de aplicação da lei (LEA) têm esses dados criptografados, mas não a chave do usuário final para descriptografá-los, elas podem tentar quebrá-los por força bruta, usando máquinas poderosas para testar os dados com senhas adivinhadas automaticamente. O iOS da Apple tem uma enorme vantagem sobre o Android do Google nesse ponto: como a Apple controla rigorosamente o hardware dos seus dispositivos, ela consegue projetar técnicas de criptografia que só o seu hardware executa rapidamente e que outros dispositivos, como computadores de mesa, executam devagar. Quando a Reincubate se tornou a primeira empresa do mundo a oferecer suporte à descriptografia de dados do 10.2, o importante não foi apenas ser a primeira a entender como o 10.2 funcionava: fomos os primeiros a escalar a descriptografia rápida da técnica inteligente da Apple. Ao fazer cada tentativa de descriptografia levar alguns segundos em hardware convencional, a força bruta se tornou impraticável para hackers ou LEA.
Segurança por obscuridade
Não seria adequado revisar essas técnicas sem abordar uma em que a Apple é particularmente boa: a segurança por obscuridade. Ao não lançar APIs públicas, documentação detalhada, nem sequer comunicar muito sobre esses sistemas, a empresa consegue evitar alertar hackers sobre possíveis vetores de ataque. Por muito tempo, o argumento contra a obscuridade era que a divulgação e o código aberto levavam a melhores resultados de segurança, mas isso foi antes da descoberta, em 2014, de que o OpenSSL, uma biblioteca de segurança de código aberto essencial usada por praticamente tudo, era, e quase sempre foi, fundamentalmente inseguro.
Entre em contato se quiser explorar formas de trabalhar com dados de apps ou da nuvem, ou se tiver interesse em entender melhor a dinâmica das diferentes abordagens.
