# Arquitetura do iOS: do boot ao Secure Enclave

> As camadas do iOS, a cadeia de boot seguro, o sandbox por contêiner, assinatura de código com AMFI e como o Keychain protege credenciais com o Secure Enclave.

- Autor: Marcelo Silva
- Publicado em: 2026-10-08
- Tema: Segurança
- Série: Segurança Mobile, parte 3 de 11 (https://marcelxsilva.dev/series/seguranca-mobile/)
- URL: https://marcelxsilva.dev/artigos/arquitetura-do-ios/

Quase toda vulnerabilidade de app iOS também é, no fundo, uma quebra de alguma garantia da plataforma: um dado lido fora do contêiner do app, um binário rodando sem estar assinado, uma chave que deveria ficar presa a um coprocessor e vazou para fora dele. O [artigo sobre a arquitetura do Android](https://marcelxsilva.dev/artigos/arquitetura-do-android/) já percorreu esse caminho do lado Google. Este artigo faz o mesmo do lado Apple: as camadas do sistema, o caminho do boot, como um app fica isolado e como a plataforma garante que só código confiável roda.

## As camadas do iOS

A documentação da Apple descreve o sistema em quatro camadas, cada uma construída sobre a de baixo:

```text
┌──────────────────────────────────────────────┐
│ Cocoa Touch                                   │
│ UIKit, interface, multitarefa, toque          │
├──────────────────────────────────────────────┤
│ Media                                         │
│ Core Graphics, Core Animation, AV Foundation  │
├──────────────────────────────────────────────┤
│ Core Services                                 │
│ Core Foundation, Core Data, rede, iCloud      │
├──────────────────────────────────────────────┤
│ Core OS (Darwin)                              │
│ Kernel XNU, Secure Enclave, segurança, drivers│
└──────────────────────────────────────────────┘
```

Um app nunca fala direto com o hardware: toda interação passa por essas camadas, o que é também um mecanismo de segurança, já que concentra o controle de acesso num conjunto conhecido de interfaces, em vez de deixar cada app decidir como tocar o hardware por conta própria.

## Core OS: Darwin e o kernel XNU

A base de tudo é o **Darwin**, o sistema operacional de código aberto que sustenta o iOS (e o macOS). No centro dele está o **XNU**, um kernel híbrido que combina duas tradições diferentes: o microkernel **Mach**, responsável pelas abstrações mais baixas (processos, threads, memória virtual, comunicação entre processos por portas), e uma camada **BSD**, construída por cima do Mach, que expõe a interface POSIX que a maioria do código de mais alto nível espera encontrar.

Para segurança, esse arranjo importa porque é o XNU quem garante o isolamento entre processos: cada app roda com seu próprio espaço de memória, e é o kernel, não o app, quem decide o que um processo pode ou não fazer.

### Secure Enclave

Separado do processador principal, boa parte dos aparelhos Apple tem um coprocessador dedicado, o **Secure Enclave**, com sua própria pequena execução de kernel, memória e gerador de números aleatórios. Cada chip sai de fábrica com uma chave única (UID) queimada no silício, gerada pelo próprio gerador de números aleatórios do Secure Enclave nos modelos mais recentes: o Secure Enclave usa essa chave para cifrar e decifrar dados, mas nunca a expõe, nem para o próprio sistema operacional, nem para a Apple. É esse coprocessador quem verifica o código (Face ID, Touch ID) e quem participa da cifragem do que fica guardado no [Keychain](https://developer.apple.com/documentation/security/keychain-services), tema do fim deste artigo.

## O boot seguro

A cadeia de boot do iOS existe para garantir uma coisa: que cada estágio só roda depois de o anterior confirmar sua assinatura.

1. **Boot ROM**: o primeiro código a rodar, gravado no chip durante a fabricação. Ele confia implicitamente em si mesmo (é a raiz da cadeia) e guarda a chave pública da autoridade certificadora raiz da Apple.
2. **iBoot**: o Boot ROM verifica a assinatura do iBoot antes de carregá-lo. Em aparelhos mais antigos, um estágio intermediário chamado **LLB** (Low-Level Bootloader) entra entre os dois.
3. **Kernel**: o iBoot, por sua vez, verifica e carrega o kernel XNU.

Se qualquer verificação falhar, o aparelho não prossegue normalmente: dependendo do estágio, ele entra em modo DFU ou em modo de recuperação, em vez de rodar um sistema potencialmente adulterado. É a chamada [cadeia de boot seguro](https://support.apple.com/guide/security/secb3000f149/web) da Apple, e ela é o motivo pelo qual rodar um sistema modificado num iPhone exige quebrar essa cadeia (o que é, essencialmente, o que um jailbreak faz).

## O sandbox de apps

Assim como no Android cada app ganha um UID próprio, no iOS cada app roda dentro de um **contêiner**: uma pasta própria no sistema de arquivos, fora da qual ele não consegue ler nem escrever sem permissão explícita.

A diferença de mecanismo está em como essa regra é imposta. O kernel XNU tem um framework de controle de acesso obrigatório baseado no TrustedBSD (o mesmo tipo de infraestrutura usada pelo SELinux no Android, embora implementações diferentes), e um módulo carregado nesse framework, o `Sandbox.kext`, aplica o perfil de sandbox de cada processo. Diferente do Android, onde cada app pode ter permissões bem distintas umas das outras, a maioria dos apps de terceiros compartilha o mesmo perfil genérico de contêiner; o que muda de um app para o outro não é o perfil em si, são os **entitlements**.

### Entitlements

[Entitlements](https://developer.apple.com/documentation/bundleresources/entitlements) são a lista de privilégios extras que um app recebe além do sandbox padrão: acesso a notificações push, a grupos de apps compartilhados, a domínios associados, e assim por diante. Eles ficam embutidos na própria assinatura de código do app, o que significa que um entitlement não pode ser adicionado depois sem invalidar a assinatura original: é a Apple, através do processo de assinatura, quem autoriza cada um deles para aquele app específico.

## Assinatura de código e AMFI

No Android, um APK sem assinatura simplesmente não instala. No iOS a exigência vai além da instalação: **o kernel recusa carregar para execução qualquer código não assinado**, não só na instalação do app. Essa verificação é feita por um subsistema chamado [AMFI (Apple Mobile File Integrity)](https://www.theiphonewiki.com/wiki/AMFI), ligado ao framework de controle de acesso do kernel (o mesmo MACF usado pelo sandbox): sempre que um binário é carregado para rodar, o AMFI confirma a assinatura, e também os entitlements embutidos nela, antes de permitir.

Esse é o motivo pelo qual rodar ferramentas de instrumentação dinâmica (como o Frida, visto num [artigo anterior desta série](https://marcelxsilva.dev/artigos/analise-dinamica-e-instrumentacao/)) num iPhone sem jailbreak exige um passo a mais: reassinar o app com o Frida Gadget embutido, de forma que o binário modificado ainda carregue uma assinatura válida, em vez de tentar burlar a checagem do AMFI.

### A App Store como camada adicional

Isso cria uma diferença estrutural importante em relação ao Android: fora de contextos especiais (desenvolvimento, distribuição empresarial interna, TestFlight), um iPhone sem jailbreak só roda apps assinados pela Apple, o que, na prática, significa apps que passaram pela [revisão da App Store](https://developer.apple.com/app-store/review/). Essa revisão funciona como uma camada de controle adicional, que não existe da mesma forma no Android, onde instalar um APK de fora da loja é uma opção padrão do sistema, ativada pelo usuário.

## Keychain e dados protegidos

Para armazenamento de credenciais, o iOS tem um mecanismo dedicado, o [Keychain](https://developer.apple.com/documentation/security/keychain-services), separado do armazenamento comum de arquivos do app. Cada item do Keychain é cifrado, e a chave usada nessa cifragem combina a UID gravada no Secure Enclave com o código de desbloqueio do aparelho (PIN ou senha), através de uma derivação de chave (PBKDF2). Isso tem uma consequência direta: nem a Apple consegue recriar essa chave sem o código do usuário, e tentar adivinhar o código por força bruta esbarra em atrasos crescentes impostos pelo próprio Secure Enclave entre tentativas malsucedidas.

O mesmo princípio, dado protegido por uma chave que depende de hardware e do desbloqueio do aparelho, também cobre a [proteção de dados (Data Protection)](https://support.apple.com/guide/security/sece6d6c1874/web) aplicada a arquivos comuns, quando o app opta por essa classe de proteção.

## Juntando as peças

Olhando de cima, o modelo de segurança do iOS se apoia em garantias parecidas com as do Android, embora os mecanismos sejam diferentes:

| Garantia | Mecanismo | O que quebra |
|---|---|---|
| Um app não lê os dados do outro | Contêiner por app, imposto pelo kernel via TrustedBSD/Sandbox.kext | Jailbreak, dado salvo fora do contêiner com permissão aberta |
| Um app só faz o que a Apple autorizou | Entitlements embutidos na assinatura | Reassinatura com entitlements adicionados sem revisão |
| Só código assinado roda | AMFI, verificado pelo kernel a cada execução | Jailbreak, boot arguments que enfraquecem o AMFI |
| O sistema não foi adulterado | Cadeia de boot seguro (Boot ROM → iBoot → kernel) | Bootloader explorado, exploit de boot encadeado |
| Credencial não sai do aparelho sem o código do usuário | Chave derivada do UID do Secure Enclave + código de desbloqueio | Força bruta (mitigada por atraso), extração do Secure Enclave em si |

Assim como no Android, boa parte dos testes do MASTG para iOS é, no fundo, verificar se o app usa essas garantias do jeito certo, ou se depende de alguma coisa que a plataforma não promete de verdade.