Fatores para proteger os dados do aplicativo e da nuvem

Com quantidades crescentes de dados valiosos armazenados na nuvem, é ainda mais importante que seja protegido de forma robusta. Fortes medidas de segurança em torno dos serviços de dados em nuvem, como o iCloud, beneficiam a todos: usuários finais, provedores de serviços em nuvem, como a Apple, e plataformas de ecossistema, como a Reincubate.

Mecanismos para proteger esses dados assumem várias formas, e o histórico da Apple de implementá-los tem sido bom. Este artigo examina várias técnicas que eles - e a equipe da Reincubate - vêm usando.

Armazene menos - se possível

Em primeiro lugar, armazenar menos, em vez de mais, compensa. Há exemplos disso nos quais os dados nunca foram armazenados no iCloud, por exemplo, quando os dados de reconhecimento facial do Fotos não são armazenados na Biblioteca de Fotos do iCloud, mas armazenados em cache localmente. Os artefatos de dados do HealthKit, HomeKit e TouchID da Apple são tratados de forma semelhante, assim como os dados de reconhecimento facial de tela de bloqueio do Android. Claro, isso geralmente é uma troca de conveniência e o valor de sincronizar esses dados entre os 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 serem sincronizados diretamente entre os dispositivos.

Sistemas seguros de mensagens, como Telegram ou WhatsApp, adotam uma abordagem completamente diferente. Como nenhum dado (ou pelo menos, não muito) é armazenado em seus servidores, um conjunto avançado de dados deve ser incluído em qualquer backup de um dispositivo para que um usuário seja capaz de realizar backup e restauração. De certa forma, para manter a segurança, esses fornecedores de aplicativos estão lavando suas mãos de gerenciamento desses dados e deixando-os para o usuário final, que pode optar por fazer backup de seus dispositivos localmente ou na nuvem.

Assim, existem dois extremos, e pode-se contrastar o WhatsApp - com pouco na nuvem e tudo no backup - no Facebook Messenger, que não armazena nada em um backup de dispositivo porque está prontamente disponível na nuvem e deve estar em ordem para Facebook para fornecer sua interface web.

Não há uma solução correta aqui, mas vale a pena pensar sobre: o uso de um aplicativo que hospeda esses dados exige que o fornecedor do aplicativo gerencie-o com segurança, geralmente usuários mantidos no escuro sobre o que está armazenado e como. O uso de um aplicativo que não armazena dados centralmente significa que o usuário final deve se responsabilizar pela segurança de seus próprios dados de backup - a menos que o deixem armazenado na nuvem de sua plataforma, como é o caso dos backups do iCloud e do Android do Google. Mais de 7.0 backups de dispositivos.

Curiosamente, como no gráfico abaixo, alguns fabricantes de aplicativos ocupam ambos os extremos dessa posição. O aplicativo Snapchat armazena quase todos os seus dados na nuvem, enquanto a extensão física do aplicativo - Espetáculos - armazena todos os seus dados localmente no dispositivo.

Embora não sejam amplamente lançados, os óculos do Snapchat são bastante inseguros: ao segurar o botão “snap” por sete segundos, um hacker pode emparelhá-los com um novo telefone e obter qualquer um dos snaps não criptografados que foram armazenados neles pelo legítimo proprietário. Isso representa um contraste marcante com os princípios de segurança adotados para o Apple Watch.

Criptografia forte

Isso nos leva à segunda técnica crítica: criptografia forte , idealmente com armazenamento incompleto das chaves. Se os dados forem considerados muito sensíveis para backup, de forma que possam ser acessados no caso de destruição ou substituição de um dispositivo, existem outras técnicas que podem ser usadas. Ao exigir o uso de um dispositivo específico, o recurso " Conversas secretas " do Facebook faz uso de identificadores de hardware para criptografar conteúdo. Se o dispositivo for perdido, o conteúdo torna-se praticamente irrecuperável.

Alguns sistemas empregam uma técnica semelhante na qual um token específico do dispositivo pode ser criado para garantir que apenas um número limitado de dispositivos possa acessar o conteúdo por vez. O Snapchat e o WhatsApp usam 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 um dispositivo diferente, um novo token será criado, substituindo o que estava na nuvem antes, e forçando o primeiro dispositivo a sair, pois não seria capaz de descriptografar as mensagens de entrada. Há uma vulnerabilidade óbvia a essa técnica quando usada em sistemas inseguros, ou seja, o token pode ser copiado e usado em outro lugar. Se foi necessário um argumento sobre o motivo pelo qual usar um dispositivo Android com raiz ou iOS desbloqueado é uma idéia terrível, é isso, e também explica por que é improvável que seja um cliente Web para o Snapchat em breve.

Embora seja uma coisa potencialmente perder mensagens secretas do Facebook, alguns dados são altamente sensíveis e altamente valiosos para seu proprietário. Parece contra-intuitivo, mas se o valor pessoal, se os dados são grandes o suficiente, muitas vezes é armazenado de tal forma que existem muitas maneiras possíveis para descriptografá-lo ou recuperá-lo. Isso comercializa a segurança com pouca impraticabilidade. Por exemplo, há uma massa de dados associada a contas do iCloud e do Google, incluindo - em ambos os casos - alguma forma de chave distribuída na nuvem, armazenando todas as senhas de um usuário. Não apenas isso, mas a promoção de suas contas pelo Google como um mecanismo de autenticação em outros sites com o OAuth significa que perder o acesso irrecuperável a contas como essas seria uma amarga pílula para engolir.

Como essas contas são consideradas valiosas demais para arriscar prontamente sua perda permanente, uma solução intermediária é usada quando os dados são armazenados na nuvem, mas criptografados com um token ou senha que somente o usuário mantém e que não é armazenado. É por isso que, por exemplo, ao fazer login em uma nova instalação do navegador Google Chrome, as senhas armazenadas na nuvem não estão disponíveis até que uma senha de sincronização secundária seja inserida no navegador.

Compartilhando a carga de criptografia

Tim Cook, da Apple - que é sério e fundamentalmente correto em relação à segurança - atesta sua crença nessa técnica apenas no ano passado:

Por muitos anos, usamos criptografia para proteger os dados pessoais de nossos clientes porque acreditamos que é a única maneira de manter suas informações seguras. Até colocamos esses dados fora de nosso alcance, porque acreditamos que o conteúdo do seu iPhone não é da nossa conta.

- Tim Cook em " Uma mensagem aos nossos clientes "

Além de qualquer outra coisa, isso pode ajudar os provedores de nuvem a evitar a divulgação de dados completos dos usuários aos atores do governo. Se eles forem obrigados a fornecê-lo por um mandado, eles podem fazê-lo sem expor diretamente os dados de um usuário, pois os dados exigem mais descriptografia, o que só pode ser feito com uma chave que somente o usuário final tenha.

Às vezes, como no caso da autenticação de múltiplos fatores (MFA), autenticação de dois fatores (2FA) ou verificação em duas etapas (2SV), isso significa que a chave adicional só pode ser enviada ou gerada por um determinado dispositivo. Bancos e VPNs freqüentemente usam leitores de cartões físicos ou geradores de sementes seguras , que são formas de geradores de senhas descartáveis baseados no tempo (OTP ou TOTP). Tanto o Google quanto a Apple oferecem um simples MFA baseado em SMS, bem como sistemas 2FA completos, com o Google usando HOTP / OATH e a Apple sendo proprietária.

Quando a segurança ou as agências de aplicação da lei (LEA) têm esses dados criptografados, mas não a chave para descriptografá-lo, eles podem tentar forçá-lo a usar máquinas poderosas para testar os dados contra senhas adivinhadas automaticamente. O iOS da Apple tem uma enorme vantagem sobre o Android do Google: como a Apple controla rigidamente o hardware em seus dispositivos, eles são capazes de projetar técnicas de criptografia que somente o hardware pode executar rapidamente e que outros dispositivos, como computadores, funcionam lentamente. Quando a Reincubate se tornou a primeira empresa do mundo a apoiar a descriptografia de dados a partir de 10.2 , o significado não foi apenas que a empresa foi a primeira a entender como 10.2 funcionavam - foi que fomos os primeiros a escalar a rápida decodificação da técnica inteligente da Apple. Ao fazer cada tentativa de decodificação levar alguns segundos no hardware convencional, tornou-se impraticável para hackers ou LEA a força bruta.

Segurança através da obscuridade

Não seria necessário rever essas técnicas sem abordar uma que a Apple seja particularmente boa: segurança através da obscuridade. Ao não liberar APIs públicas, documentação detalhada ou até mesmo comunicar muito sobre esses sistemas, a empresa é capaz de evitar alertar os hackers sobre potenciais vetores de ataque. Por muito tempo, o argumento contra a obscuridade foi que a divulgação e o código aberto levaram a melhores resultados de segurança, mas foi antes da descoberta de 2014 que o OpenSSL - uma biblioteca crítica de segurança de código aberto que quase tudo usa - era e quase sempre era fundamentalmente inseguro .

Por favor, entre em contato se quiser explorar formas de trabalhar com dados de aplicativos ou de nuvem ou se estiver interessado em entender melhor a dinâmica das diferentes abordagens.