Novo recurso de segurança da Apple reinicia automaticamente iPhones não desbloqueados por 72 horas

• O novo software do iPhone da Apple reinicia automaticamente o dispositivo se ele não for desbloqueado por 72 horas, dificultando o acesso aos dados em casos de apreensão prolongada ou perda
• O timer de 72 horas do inactivity reboot do iOS 18 foi confirmado por meio de um vídeo de demonstração de Jiska Classen e pela Magnet Forensics
• Após a reinicialização, o iPhone entra em um estado mais seguro, no qual as chaves de criptografia ficam bloqueadas no Secure Enclave, tornando-o mais difícil de desbloquear com ferramentas forenses baratas ou antigas
• A acessibilidade forense varia conforme os estados BFU (Before First Unlock) e AFU (After First Unlock), e a reinicialização leva o aparelho do estado “hot” de volta para o estado “cold”, mais difícil
• O recurso desacelera o acesso por ladrões e por algumas ferramentas forenses, mas Classen avalia que ele não bloqueia completamente as forças de segurança, já que três dias ainda permitem coordenar especialistas e procedimentos

---

Reinicialização automática após 72 horas sem uso

• O novo software do iPhone inclui um recurso de segurança que faz o aparelho reiniciar sozinho se ele não for desbloqueado por 72 horas
• A 404 Media relatou que alguns iPhones estavam reiniciando por motivos desconhecidos, dificultando o acesso aos dispositivos e a extração de dados por forças de segurança e especialistas forenses
• Depois disso, pesquisadores de segurança confirmaram que o iOS 18 inclui um inactivity reboot que força a reinicialização do dispositivo
• Jiska Classen, pesquisadora do Hasso Plattner Institute, publicou um vídeo de demonstração mostrando o recurso; no vídeo, um iPhone deixado sem ser desbloqueado reinicia após 72 horas
• A Magnet Forensics, que oferece produtos de perícia digital, incluindo o Graykey, ferramenta de extração de dados para iPhone e Android, também confirmou que o timer é de 72 horas

BFU e AFU definem a dificuldade da perícia

• O inactivity reboot coloca o iPhone em um estado mais seguro, bloqueando as chaves de criptografia do usuário dentro do chip Secure Enclave
• Classen avalia que, mesmo que um ladrão mantenha um iPhone ligado por muito tempo, ficará mais difícil desbloqueá-lo com ferramentas forenses baratas e antigas
• O trabalho das forças de segurança para obter dados de dispositivos de criminosos também fica mais difícil, mas esse recurso sozinho não impede completamente o acesso
  • A explicação é que três dias ainda são tempo suficiente para coordenar especialistas e procedimentos
• O iPhone tem dois estados que afetam tentativas de descobrir a senha por força bruta ou de extrair dados usando vulnerabilidades de software
  • BFU (Before First Unlock): os dados do usuário estão totalmente criptografados, e o acesso é quase impossível sem saber a senha
  • AFU (After First Unlock): alguns dados já foram descriptografados, então, mesmo com o telefone bloqueado, pode ser mais fácil extraí-los com algumas ferramentas forenses
• O pesquisador de segurança de iPhone Tihmstar também chama esses dois estados, respectivamente, de dispositivo cold e dispositivo hot
  • Muitas empresas forenses se concentram em dispositivos “hot” no estado AFU, nos quais o usuário já digitou a senha correta uma vez
  • Isso ocorre porque informações relacionadas à senha ficam armazenadas na memória do Secure Enclave do iPhone
  • Um dispositivo “cold” reiniciado é muito mais difícil de comprometer porque não é possível extrair facilmente a memória
• Há anos, a Apple vem adicionando novos recursos de segurança aos quais as forças de segurança se opõem, e essas autoridades criticam tais recursos por dificultarem seu trabalho
• Em 2016, o FBI abriu um processo para tentar obrigar a Apple a criar um backdoor para desbloquear o iPhone de um atirador em massa; depois, a startup australiana Azimuth Security ajudou o FBI a hackear aquele iPhone
• A Apple não respondeu a um pedido de comentário

[GN⁺]

Opiniões no Hacker News

• Terminais de pagamento precisam de reinicializações periódicas por causa dos requisitos PCI, e praticamente todos os terminais de ponto de venda no mercado reiniciam a cada 24 horas

  • Parece uma boa estratégia de defesa em profundidade. Hoje em dia, a maioria dos sistemas tem uma segurança de cadeia de boot bastante boa, então, após uma reinicialização, pode-se considerar que o sistema está em um estado válido e que possíveis alterações maliciosas também desapareceram
  • A Apple adotar uma abordagem parecida no iPhone parece seguir a mesma ideia, só que aplicada à proteção de dados pessoais
  • O Boeing 787 também faz isso
  • Eu reinicio meu iPhone todo fim de semana, independentemente de precisar ou não

• Seria bom se desse para reduzir essa configuração. Se você não desbloqueou o celular durante um dia, há algo estranho acontecendo, e é necessário ter suspeitas adicionais de segurança

  • Fiquei curioso para saber se dava para fazer isso com o app nativo Shortcuts e fui procurar; no começo achei que não dava porque não havia uma ação "Restart"
    No fim, eu estava olhando no lugar errado: ela é oferecida como uma opção da ação "Shut Down"
  • Um sistema que reiniciasse se não estivesse perto de um Airtag específico ou dispositivo parecido também poderia ser bom. Claro, teria que ser possível contornar isso desbloqueando o aparelho
  • Para minimizar o incômodo quando eu simplesmente não mexi no celular, algo em torno de 12 horas seria perfeito para mim
  • Dá para resolver criando uma automação de atalho que reinicie o celular todos os dias

• Esse “novo” recurso já é compatível com o GrapheneOS, cujo padrão é executar após 18 horas e pode ser ajustado como o usuário quiser. Não há um bom motivo para impor 72 horas a todos; é uma decisão de design hostil ao usuário

  • Na prática, parece que ele só entra em ação quando o telefone não foi desbloqueado com sucesso por 3 dias. Então é um recurso que a maioria dos usuários quase nem vai perceber
  • A primeira vez que vi a função de usar o flash da câmera como lanterna foi no Cyanogenmod 7. O hotspot Wi-Fi do celular também começou como um app do Cydia numa época em que os apps oficiais eram pouco úteis
    O ecossistema de hacking sempre trouxe os recursos mais legais para os celulares, mas os fabricantes tornaram cada vez mais difícil ter acesso a eles
  • No meu celular pessoal com GrapheneOS, é um recurso essencial. Como costumo usá-lo só uma ou duas vezes por dia, quase sempre que vou usar ele está recém-reiniciado
    Li que muitos exploits novos na área móvel existem apenas na memória e são bloqueados por uma simples reinicialização, e acredito que isso inclua o infame spyware Pegasus
  • Provavelmente é mais um meio-termo. Um atraso tão longo evita manchetes sensacionalistas sobre usuários irritados com reinicializações aleatórias, e também não é curto o suficiente para fazer órgãos federais reagirem publicamente e pedirem novamente a Trump um backdoor
    Ao mesmo tempo, é uma atualização discreta que não chama muita atenção fora da comunidade técnica, então pequenos criminosos talvez não se preparem direito. Se fosse um design hostil ao usuário, nem teria sido implementado
    O jeito típico da Apple é definir padrões genéricos e não incomodar o usuário, o que às vezes é bom e às vezes é ruim
  • Tenho curiosidade de saber como é usar o Graphene na prática

• Se isso for verdade, transformar em uma opção configurável seria uma melhoria trivial. 72 horas deveria ser o padrão, mas quem tiver exigências de segurança maiores deveria poder reduzir para 12 horas ou menos

  • Se fosse configurável, eu colocaria em 30 minutos e aumentaria se causasse incômodo. Já uso o celular sempre no modo Não Perturbe, então atrasar notificações por causa de reinicialização não é um problema, e também não me incomoda muito digitar a senha em vez de usar o FaceID a cada 30 minutos
  • Se for configurável, pode ser difícil fazer um hardcode disso dentro do Secure Enclave de modo que não possa ser desativado quando o celular estiver com jailbreak
  • Concordo, mas a escolha da Apple por 72 horas soa como uma forma de dar tempo à polícia. Talvez seja porque a polícia é mais organizada que os criminosos
  • Tornar isso configurável é o próximo passo lógico

• Esse recurso parece quebrar o encaminhamento de SMS entre iDevices. Descobri do jeito difícil, porque algumas notificações de entrega de encomendas não chegavam até eu desbloquear o iPhone secundário e abrir o app Mensagens

• Entendo que um celular bloqueado precise já ter tudo carregado na memória. Mas fico curioso sobre qual obstáculo técnico impede a Apple de tornar o estado bloqueado tão seguro quanto logo depois de uma reinicialização

  • No estado antes do primeiro desbloqueio, prévias de notificações, informações de contatos em chamadas recebidas e outros dados específicos do usuário permanecem bloqueados por não estarem descriptografados. Essas coisas também mudariam bastante a experiência do usuário, por isso a Apple não faz assim
  • Há uma boa explicação de como isso é implementado criptograficamente: https://www.youtube.com/watch?v=BLGFriOKz6U
  • Acho que o obstáculo é mais de experiência do usuário do que técnico

• A 404Media parece ter sido a primeira a confirmar isso. Talvez não. É um artigo para assinantes e não encontrei um link de arquivo com o conteúdo completo, mas é um veículo que faz um bom trabalho e merece apoio
  https://www.404media.co/apple-quietly-introduced-iphone-rebo...

• Reinício automático existe em celulares Samsung desde a época do Android 5 Lollipop, há 10 anos. Que bom que o avanço tecnológico finalmente chegou à Apple

  • Do ponto de vista de segurança, não é o mesmo recurso. Aquilo é mais uma gestão de desempenho, parecida com reiniciar um PC Windows antigo
    O estado BFU do Android, ou seja, antes do primeiro desbloqueio, é bem parecido com o do iPhone: os dados continuam bloqueados, notificações não chegam e apps não rodam. É preciso fazer o primeiro desbloqueio para que os apps sejam executados e as notificações cheguem, e é nesse momento que o aparelho também fica mais vulnerável a atacantes
    Uso tanto iPhone quanto Android, e meu Android atual é um modelo recente, o Z Fold 5. O Fold 5 faz reinicialização automática toda semana, mas depois de reiniciar os apps de fundo habituais sobem e as notificações funcionam normalmente
    Isso significa que o Android — mais precisamente a OneUI que a Samsung coloca sobre o Android — não faz uma reinicialização “completa” e não oferece o benefício de segurança de deixar o celular no estado BFU ou frio como a Apple faz

• Fico me perguntando por que não separar fisicamente a memória de instruções do programa e a memória de dados. Sei que há aproximações parecidas no nível de páginas, mas não vejo motivo para permitir que o kernel modifique a própria memória
  Talvez fosse possível algo como uma unidade de memória que carregasse apenas páginas assinadas

  • O que você está pedindo não é uma arquitetura de von Neumann, e sim um computador de arquitetura Harvard. Há concessões nisso
    Um ponto a considerar é que JIT é uma tecnologia muito útil, então o custo de perdê-la é bem alto; além disso, interpretadores ainda tratam memória de dados como se fosse memória de instruções de programa, o que limita o benefício dessa separação
  • Não sei a que isso responde. Já funciona desse jeito, e o kernel não consegue modificar suas próprias páginas de código. Só que ainda há muita superfície de ataque restante, como ataques que sobrescrevem ponteiros de função ou outros dados
  • O iOS já funciona assim

• Pergunta: a tela de reinicialização da Apple realmente mostra o log do dmesg?

  • Provavelmente é um Security Research Device. https://security.apple.com/research-device/
  • Acho que não na versão final; provavelmente pesquisadores de segurança estavam usando um beta de desenvolvedor com algum modo de logs detalhados ativado