Segurança do iOS

Segurança do iOSiOS 9.3 ou posterior

Maio de 2016

2Segurança do iOS – White Paper | Maio de 2016

Conteúdo

Página 4 Introdução

Página 5 Segurança do SistemaCadeia de inicialização segura Autorização do Software do Sistema Enclave Seguro Touch ID

Página 10 Criptografia e Proteção de DadosRecursos de Segurança do Hardware Proteção de Dados de ArquivosCódigos Classes de Proteção de DadosProteção de Dados das ChavesAcesso às senhas salvas do SafariBolsas de chavesCertificações e programas de segurança

Página 19 Segurança de AplicativosAssinatura de código de aplicativos Segurança do processo de execução Extensões Grupos de Aplicativos Proteção de Dados em aplicativos Acessórios HomeKitHealthKit Notas SegurasApple Watch

Página 29 Segurança de Rede TLS VPN Wi-Fi Bluetooth Início de Sessão Único Segurança do AirDrop

Página 33 Apple PayComponentes do Apple PayComo o Apple Pay usa o Elemento SeguroComo o Apple Pay usa o controlador NFCProvisão de cartões de crédito e débitoAutorização de pagamentosCódigo de segurança dinâmico específico por transaçãoPagamentos por proximidade com o Apple PayPagamentos com o Apple Pay dentro de aplicativosCartões de fidelidadeSuspensão, remoção e apagamento de cartões


Página 40 Serviços de Internet ID Apple iMessage FaceTime iCloud Chaves do iCloud Siri ContinuidadeSugestões do Spotlight

Página 55 Controles do DispositivoProteção por códigoModelo de emparelhamento do iOSExigência de configuraçõesGerenciamento de Dispositivo Celular (MDM) iPad Compartilhado Apple School ManagerRegistro de DispositivosApple Configurator 2Supervisão Restrições Apagamento Remoto Modo Perdido Bloqueio de Ativação

Página 62 Controles de PrivacidadeServiços de LocalizaçãoAcesso a dados pessoaisPolítica de privacidade

Página 64 ConclusãoUm compromisso com a segurança

Página 65 Glossário

Página 67 Histórico de Revisão do Documento


A Apple criou a plataforma iOS tendo a segurança como fator fundamental. Quando decidimos criar a melhor plataforma móvel possível, utilizamos décadas de experiência como base para construir uma arquitetura totalmente nova. Levamos em consideração os riscos à segurança do ambiente de computadores de mesa e definimos uma nova abordagem para segurança na criação do iOS. Desenvolvemos e incorporamos recursos inovadores que reforçam a segurança móvel e protegem todo o sistema por padrão. Como resultado, o iOS é um grande avanço em segurança para dispositivos móveis.

Todos os dispositivos iOS combinam software, hardware e serviços criados para tra-balhar juntos para máxima segurança e experiência transparente ao usuário. O iOS protege não apenas o dispositivo e os dados armazenados, mas todo o ecossistema, incluindo tudo o que os usuários fazem localmente, em redes e em serviços essenciais de Internet.

O iOS e os dispositivos iOS oferecem recursos avançados de segurança, além de serem fáceis de usar. Muitos desses recursos são ativados por padrão para que departamen-tos de TI não precisem realizar configurações extensas. E os recursos básicos de segu-rança, como criptografia de dispositivos, não são configuráveis. Assim, os usuários não podem desativá-los por engano. Outros recursos, como o Touch ID, melhoram a experi-ência do usuário tornando a segurança do dispositivo mais simples e intuitiva.

Este documento fornece detalhes sobre como a tecnologia e os recursos de segurança são implementados na plataforma iOS. Ele também ajudará empresas a combinar a tecnologia e os recursos de segurança da plataforma iOS com as suas próprias políticas e procedimentos para atender às suas necessidades de segurança específicas.

Este documento está organizado nos seguintes temas:

• Segurança do sistema: o software e o hardware de segurança integrados que servem de plataforma para o iPhone, iPad e iPod touch.

•Criptografiaeproteçãodedados:a arquitetura e o design que protegem os dados do usuário caso o dispositivo seja perdido ou roubado ou se uma pessoa não autori-zada tentar usá-lo ou modificá-lo.

• Segurança de aplicativos: os sistemas que permitem que os aplicativos sejam execu-tados com segurança e sem comprometer a integridade da plataforma.

• Segurança de rede: protocolos de rede padrão do setor que fornecem autenticação e criptografia segura de dados em transmissões.

• Apple Pay: implementação da Apple para pagamentos seguros.

• Serviços de Internet: infraestrutura com base em rede da Apple para o envio de mensagens, sincronização e backup.

• Controles do dispositivo: métodos que permitem o gerenciamento de dispositivos iOS, impedem o uso não autorizado e ativam o apagamento remoto caso o dispositi-vo seja perdido ou furtado.

• Controles de privacidade: recursos do iOS que podem ser usados para controlar o acesso aos Serviços de Localização e dados do usuário.

Introdução

Chave do DispositivoChave do Grupo

Certificado de Raiz da Apple

Mecanismo de Criptografia

Núcleo

Partição do SO

EnclaveSeguro

ElementoSeguro

Partição do Usuário(criptografada)

Classe Proteção de Dados

Isolamento do Aplicativo

Sistema de Arquivos

Software

Hardware e Firmware

Diagrama da arquitetura de segurança do iOS com uma visão geral das várias tecnologias discutidas neste documento.


A segurança do sistema é concebida para que tanto o software quanto o hardware de todos os componentes essenciais de dispositivos iOS estejam seguros. Isso inclui o pro-cesso de inicialização, as atualizações de software e o Enclave Seguro. Essa arquitetura é essencial à segurança no iOS e nunca atrapalha a usabilidade do dispositivo.

A firme integração entre hardware e software em dispositivos iOS garante a confiabili-dade de cada componente do sistema e valida o sistema como um todo. Desde a ini-cialização até as atualizações de software do iOS e aplicativos de terceiros, cada passo é analisado e verificado para ajudar a garantir que o hardware e o software estejam funcionando juntos de maneira ideal e usando os recursos adequadamente.

Cadeia de inicialização seguraCada etapa do processo de inicialização contém componentes assinados criptografica-mente pela Apple para garantir a integridade e prosseguir somente após a verificação da cadeia de confiança. Isso inclui gerenciadores de inicialização, núcleo, extensões do núcleo e firmware de banda base.

Quando um dispositivo iOS é ligado, o processador de aplicativo executa imediatamen-te o código da memória somente de leitura conhecida como ROM de Inicialização. Esse código imutável, conhecido como raiz de confiança do hardware, é colocado durante a fabricação do chip e é implicitamente confiável. O código da ROM de Inicialização contém a chave pública da AC de Raiz da Apple, usada para verificar se o Gerenciador de Inicialização de Baixo Nível (LLB) está assinado pela Apple antes de permitir que ele seja carregado. Esse é o primeiro passo na cadeia de confiança, onde cada passo garante que o próximo está assinado pela Apple. Ao finalizar as suas tarefas, o LLB veri-fica e executa o gerenciador de inicialização do estágio seguinte, o iBoot, que, por sua vez, verifica e executa o núcleo do iOS.

Essa cadeia de inicialização segura garante que os níveis mais baixos do software não estão alterados e permite que o iOS seja executado apenas em dispositivos validados da Apple.

Em dispositivos com acesso celular, o subsistema de banda base também utiliza o seu próprio processo similar de inicialização segura com o software assinado e chaves veri-ficadas pelo processador de banda base.

Em dispositivos com um processador A7 ou um processador posterior da série A, o coprocessador do Enclave Seguro também utiliza um processo de inicialização segura que garante que o seu software separado esteja verificado e assinado pela Apple.

Se uma das etapas desse processo de inicialização não puder ser carregada ou verificar o processo seguinte, a inicialização é interrompida e o dispositivo exibe a tela “Conectar ao iTunes”. Isso é chamado de “modo de recuperação”. Se a ROM de Inicialização não puder carregar ou verificar o LLB, ela entra no modo DFU (Atualização do Firmware do Dispositivo). Em ambos os casos, o dispositivo precisa ser conectado ao iTunes via USB e restaurado aos ajustes padrão de fábrica. Para obter mais informa-ções sobre como entrar no modo de recuperação manualmente, consulte https://support.apple.com/pt-br/HT1808.

Segurança do Sistema

Acesso ao modo de Atualização do Firmware do Dispositivo (DFU) A restauração de um dispositivo depois que ele está no modo DFU o retorna a um estado sabidamente bom, com a certeza de que apenas código não modificado e assinado pela Apple esteja presente. O modo DFU pode ser acessado manualmente: conecte o dispositivo a um computador usando um cabo USB e mantenha os botões Início e Repouso/Despertar pressionados. Depois de 8 segundos, solte o botão Repousar/Despertar, mantendo o botão Início pres-sionado. Nota: nada será exibido na tela enquanto o dispositivo estiver no modo DFU. Se o logotipo da Apple aparecer, o botão Repouso/Despertar foi pressionado por tempo demais.

https://support.apple.com/pt-br/HT1808


Autorização do Software do SistemaA Apple lança atualizações de software regularmente para abordar questões de segu-rança e fornecer novos recursos. Essas atualizações são fornecidas simultaneamente para todos os dispositivos compatíveis. Os usuários recebem notificações de atualiza-ção do iOS no dispositivo e através do iTunes. As atualizações são entregues via rede sem fio, estimulando a adoção rápida das correções de segurança mais recentes.

O processo de inicialização descrito acima ajuda a garantir que apenas o código assi-nado pela Apple possa ser instalado em um dispositivo. Para impedir que os disposi-tivos retornem a versões mais antigas, carentes das atualizações de segurança mais recentes, o iOS usa um processo chamado de Autorização do Software do Sistema. Se fosse possível voltar a versões mais antigas, um invasor que conseguisse se apossar de um dispositivo poderia instalar uma versão mais antiga do iOS e explorar uma vulnera-bilidade já corrigida na versão mais recente.

Em dispositivos com um processador A7 ou um processador posterior da série A, o coprocessador do Enclave Seguro também utiliza a Autorização do Software do Sistema para garantir a integridade de seu software e impedir instalações de versões mais antigas. Consulte “Enclave Seguro”, abaixo.

As atualizações de software do iOS podem ser instaladas através do iTunes ou por uma conexão de rede sem fio (OTA) no dispositivo. Com o iTunes, uma cópia completa do iOS é transferida e instalada. As atualizações de software OTA transferem apenas os componentes necessários para finalizar uma atualização, melhorando a eficiência da rede, ao invés de transferir todo o sistema operacional. Além disso, as atualizações de software podem ser armazenadas em cache em um servidor de rede local que esteja executando o serviço de cache no OS X Server, de maneira que os dispositivos iOS não precisem acessar os servidores da Apple para obter os dados de atualização necessários.

Durante uma atualização do iOS, o iTunes (ou o próprio dispositivo, no caso de atu-alizações de software OTA) conecta-se ao servidor de autorização de instalações da Apple e envia a ele uma lista de medições criptográficas de cada parte do pacote a ser instalado (LLB, iBoot, núcleo e imagem do sistema operacional, por exemplo), um valor antirreprodução aleatório (nonce) e o ID exclusivo do dispositivo (ECID).

O servidor de autorização verifica a lista de medições apresentada e a compara com versões em que a instalação é permitida. Caso encontre uma correspondência, ele adiciona o ECID à medição e informa o resultado. O servidor passa um conjunto com-pleto de dados assinados como parte do processo de atualização. A adição do ECID “personaliza” a autorização para o dispositivo solicitante. Ao autorizar e assinar somente as medições conhecidas, o servidor garante que a atualização aconteça exatamente conforme fornecida pela Apple.

A avaliação da cadeia de confiança do tempo de inicialização verifica se a assinatura provém da Apple e se a medição do item carregado do disco, em conjunto com o ECID do dispositivo, corresponde àquilo coberto pela assinatura.

Esses passos garantem que a autorização seja para um dispositivo específico e que uma versão antiga do iOS de um dispositivo não possa ser copiada para outro. O nonce impede que um invasor salve a resposta do servidor e a use para adulterar um dispositivo ou alterar o software do sistema de outra maneira.


Enclave SeguroO Enclave Seguro é um coprocessador fabricado nos processadores A7 ou processado-res posteriores da série A da Apple. Ele usa memória criptografada e inclui um gerador de números aleatórios de hardware. O Enclave Seguro fornece todas as operações crip-tográficas para o gerenciamento principal da Proteção de Dados e mantém a integrida-de da Proteção de Dados mesmo se o núcleo tiver sido comprometido. A comunicação entre o Enclave Seguro e o processador do aplicativo é isolada em uma caixa de correio ativada por interrupção e buffers de dados de memórias compartilhadas.

O Enclave Seguro executa uma versão da família de micronúcleos L4 personalizada pela Apple. O Enclave Seguro utiliza sua própria inicialização segura e pode ser atualizado por meio de um processo de atualização por software personalizado que é separado do processador do aplicativo.

Cada Enclave Seguro recebe, durante a fabricação, o seu próprio UID (ID Exclusivo), que não pode ser acessado por outras partes do sistema e não é de conhecimento da Apple. Quando o dispositivo é inicializado, uma chave transitória trançada ao seu UID é criada e usada para criptografar o espaço de memória dedicado ao Enclave Seguro no dispositivo.

Além disso, os dados salvos pelo Enclave Seguro no sistema de arquivos são criptogra-fados com uma chave trançada ao UID e um contador antirreprodução.

O Enclave Seguro é responsável pelo processamento dos dados de impressão digital do sensor Touch ID, determinando se há correspondência entre as impressões digitais registradas e permitindo o acesso ou compras em nome do usuário. A comunicação entre o processador e o sensor Touch ID ocorre através de um barramento de inter-face periférico serial. O processador encaminha os dados para o Enclave Seguro, mas não pode lê-los. Eles são criptografados e autenticados com uma chave de sessão que é negociada usando a chave compartilhada do dispositivo, fornecida para o sensor Touch ID e para o Enclave Seguro. A troca da chave de sessão usa o envolvimento de chave AES com ambos os lados, fornecendo uma chave aleatória que estabelece a chave de sessão e usa criptografia de transporte AES-CCM.

Touch IDO Touch ID é o sistema de detecção de impressão digital que torna o acesso seguro ao dispositivo mais rápido e fácil. Essa tecnologia lê dados de impressões digitais de qual-quer ângulo e, com o passar do tempo, aprende mais informações sobre a impressão digital de um usuário, pois o sensor continua a expandir o mapa de impressão digital conforme nós de sobreposição adicionais são identificados a cada uso.

O Touch ID faz com que o uso de um código mais longo e complexo seja mais prático porque os usuários não precisarão digitá-lo com tanta frequência. O Touch ID também supera a inconveniência de um bloqueio baseado em código, não pela sua substituição, mas por fornecer acesso seguro ao dispositivo dentro de limites e restrições de tempo conscienciosos.

Touch ID e códigosPara usar o Touch ID, os usuários devem configurar o dispositivo para que um código seja exigido para desbloqueá-lo. Quando o Touch ID escaneia e reconhece uma impres-são digital registrada, o dispositivo é desbloqueado sem solicitar o código. O código sempre pode ser usado ao invés do Touch ID, e ele será exigido nas seguintes circuns-tâncias:

• O dispositivo acabou de ser ligado ou reiniciado;

• O dispositivo não foi desbloqueado por mais de 48 horas;


• O código não foi utilizado para desbloquear o dispositivo nos últimos seis dias e o Touch ID não desbloqueou o dispositivo nas últimas oito horas;

• O dispositivo recebeu um comando de bloqueio remoto;

• Depois de cinco tentativas malsucedidas de correspondência a uma impressão digital;

• Ao configurar ou registrar impressões digitais novas com o Touch ID.

Quando o Touch ID está ativado, o dispositivo é bloqueado imediatamente quando o botão Repouso/Despertar é pressionado. Quando a segurança é feita apenas por código, muitos usuários definem um período de tolerância para evitar a digitação do código sempre que o dispositivo for usado. Com o Touch ID, o dispositivo é bloqueado sempre que entra em repouso, exigindo uma impressão digital ou, opcionalmente, o código ao despertar.

O Touch ID pode ser treinado para reconhecer até cinco dedos diferentes. Com um dedo registrado, as chances de uma correspondência aleatória com outra pessoa são de 1 em 50.000. No entanto, o Touch ID permite apenas cinco tentativas malsucedidas de correspondência de impressão digital antes que o usuário precise digitar o código para obter acesso.

Outros usos para o Touch IDO Touch ID também pode ser configurado para aprovar compras da iTunes Store, App Store e iBooks Store para que os usuários não precisem digitar a senha de um ID Apple. Quando uma compra é autorizada, ocorre uma troca de tokens de autenti-cação entre o dispositivo e a loja. O token e o nonce criptográfico são mantidos no Enclave Seguro. O nonce é assinado com uma chave do Enclave Seguro compartilhada por todos os dispositivos e pela iTunes Store.

O Touch ID também pode ser usado com o Apple Pay, a implementação da Apple para pagamentos seguros. Para obter mais informações, consulte a seção Apple Pay deste documento.

Além disso, aplicativos de terceiros podem usar as APIs fornecidas pelo sistema para pedir que o usuário autentique usando o Touch ID ou um código. O aplicativo rece-be uma notificação apenas quanto ao êxito da autenticação; ele não pode acessar o Touch ID ou os dados associados à impressão digital registrada.

Os itens das chaves também podem ser protegidos pelo Touch ID, sendo liberados pelo Enclave Seguro apenas pela correspondência de uma impressão digital ou pelo código do dispositivo. Os desenvolvedores de aplicativos também possuem APIs para verificar se um código foi definido pelo usuário e, portanto, apto a autenticar ou des-bloquear itens das chaves usando o Touch ID.

Com o iOS 9, os desenvolvedores podem exigir que as operações da API do Touch ID não usem a senha de um aplicativo ou o código do dispositivo como alternativa. Além da capacidade de recuperar uma representação do estado dos dedos registrados, isso permite que o Touch ID seja usado como um segundo fator em aplicativos sensíveis à segurança.


Segurança do Touch IDO sensor de impressão digital é ativado apenas quando o anel capacitivo de aço que envolve o botão Início detecta o toque de um dedo, o que aciona o seu escaneamento pela matriz de imagens avançada e envia o escaneamento para o Enclave Seguro.

O escaneamento da varredura é armazenado temporariamente em uma memória crip-tografada dentro do Enclave Seguro enquanto é vetorizado para análise e depois des-cartado. A análise utiliza mapeamento de ângulo de fluxo dos fluxos subdérmicos, um processo com perda que descarta os dados de minúcias que seriam necessários para reconstruir a impressão digital real do usuário. O mapa de nós resultante é armazena-do em formato criptografado e sem nenhuma informação de identificação, podendo ser lido apenas pelo Enclave Seguro. Ele nunca é enviado à Apple nem ao iCloud ou iTunes para backup.

Como o Touch ID desbloqueia um dispositivo iOSSe o Touch ID estiver desativado, quando um dispositivo for bloqueado, as chaves Completas da classe Proteção de Dados, armazenadas no Enclave Seguro, são descarta-das. Os arquivos e os itens das chaves dessa classe ficam inacessíveis até que o usuário desbloqueie o dispositivo digitando o código.

Com o Touch ID ativado, as chaves não são descartadas quando o dispositivo é blo-queado. Ao invés disso, elas são embaladas com uma chave fornecida ao subsistema do Touch ID dentro do Enclave Seguro. Se o Touch ID reconhecer a impressão digi-tal quando um usuário tentar desbloquear o dispositivo, ele fornecerá a chave para desembalar as chaves de Proteção de Dados, desbloqueando o dispositivo. Esse pro-cesso fornece proteção adicional ao exigir que a Proteção de Dados e os subsistemas do Touch ID cooperem para desbloquear o dispositivo.

As chaves necessárias para que o Touch ID desbloqueie o dispositivo são perdidas se o dispositivo for reiniciado e são descartadas pelo Enclave Seguro após 48 horas ou cinco tentativas malsucedidas de reconhecimento do Touch ID.


A cadeia de inicialização de segurança, a assinatura de código e a segurança do pro-cesso de execução ajudam a garantir que apenas códigos e aplicativos confiáveis possam ser executados em um dispositivo. O iOS possui recursos de criptografia e de proteção de dados adicionais para resguardar os dados do usuário, mesmo em casos onde outras partes da infraestrutura de segurança tenha sido comprometidas (em um dispositivo com modificações não autorizadas, por exemplo). Isso oferece benefícios importantes, tanto para os usuários como para os administradores de TI, protegendo sempre as informações pessoais e corporativas e fornecendo métodos para apagamen-to remoto completo e imediato no caso de roubo ou perda do dispositivo.

Recursos de Segurança do HardwareEm dispositivos móveis, velocidade e eficiência energética são fatores críticos. As ope-rações criptográficas são complexas e podem causar problemas de desempenho ou para a vida útil da bateria se não forem criadas e implementadas tendo essas priorida-des em mente.

Todos os dispositivos iOS possuem um mecanismo de criptografia dedicado AES 256 integrado ao caminho DMA, entre o armazenamento flash e a memória principal do sistema, tornando a criptografia de arquivos um processo altamente eficiente.

O ID exclusivo do dispositivo (UID) e um ID de grupo do dispositivo (GID) são cha-ves de 256 bits fundidas (UID) ou compiladas (GID) no processador do aplicativo e no Enclave Seguro durante a fabricação. Nenhum software ou firmware pode lê-los diretamente, somente visualizar os resultados das operações de criptografia ou decrip-tografia realizadas por mecanismos AES dedicados implementados em silício usando o UID ou GID como chave. Além disso, o UID e GID do Enclave Seguro podem ser usa-dos apenas pelo mecanismo AES dedicado ao Enclave Seguro. Todos os dispositivos possuem um UID exclusivo, que não é gravado pela Apple ou qualquer um de seus fornecedores. Os GIDs são comuns a todos os processadores de uma classe de disposi-tivos (todos os dispositivos que usam o processador A8 da Apple, por exemplo) e são usados para tarefas de segurança não críticas, como a entrega do software do sistema durante a instalação e a restauração. A integração dessas chaves no silício ajuda a impedir que elas sejam adulteradas, sobrepostas ou acessadas de fora do mecanismo AES. Os UIDs e GIDs também não são disponibilizados através do JTAG ou de outras interfaces de depuração.

O UID permite que os dados sejam criptograficamente atrelado a um dispositivo espe-cífico. Por exemplo, a hierarquia de chaves que protege o sistema de arquivos inclui o UID, então, se os chips de memória forem movidos fisicamente de um dispositivo para outro, os arquivos ficam inacessíveis. O UID não está relacionado a nenhum outro iden-tificador do dispositivo.

Com exceção do UID e do GID, todas as outras chaves criptográficas são criadas pelo gerador de números aleatórios do sistema (RNG) usando um algoritmo baseado em CTR_DRBG. A entropia do sistema é gerada a partir de variações do temporizador durante a inicialização e, adicionalmente, ao interromper o temporizador quando a ini-cialização do dispositivo é concluída. As chaves geradas no Enclave Seguro usam seus próprios geradores de números aleatórios de hardware com base em vários osciladores ring pós-processados com CTR_DRBG.

Criptografia e Proteção de Dados

Apagar Conteúdo e Ajustes A opção “Apagar Conteúdo e Ajustes” nos Ajustes destrói todas as chaves do Armazenamento Apagável, deixando todos os dados do usuário no dispositivo inaces-síveis criptograficamente. Portanto, esta é a maneira ideal de certificar-se de que todas as informações pessoais sejam removidas de um dispositivo antes de passá-lo para outra pessoa ou levá-lo para a assistên-cia. Importante: não use a opção “Apagar Conteúdo e Ajustes” antes de ter um backup do dispositivo, pois não há forma de recuperar os dados apagados.


O apagamento seguro das chaves salvas é tão importante quanto sua geração. É espe-cialmente desafiador fazer isso em armazenamento flash, no qual o nivelamento por uso pode significar que cópias múltiplas de dados precisem ser apagadas. Para abordar esse problema, os dispositivos iOS possuem um recurso dedicado a garantir o apaga-mento seguro de dados, chamado de “Armazenamento Apagável”. Esse recurso acessa a tecnologia de armazenamento base (NAND, por exemplo) para endereçar e apagar diretamente um número pequeno de blocos em um nível muito baixo.

Proteção de Dados de ArquivosAlém dos recursos de criptografia de hardware integrados a dispositivos iOS, a Apple usa uma tecnologia chamada de “Proteção de Dados” para fornecer uma proteção ainda maior aos dados armazenados na memória flash do dispositivo. A Proteção de Dados permite que o dispositivo responda a eventos comuns, como ligações telefô-nicas, mas também possibilita um alto nível de criptografia nos dados de usuário. Os aplicativos principais do sistema, como o Mensagens, Mail, Calendário, Contatos, Fotos e os valores de dados do Saúde, usam a Proteção de Dados por padrão, e os aplicativos de terceiros instalados no iOS 7 ou posterior recebem essa proteção automaticamente.

A Proteção de Dados é implementada pela construção e gerenciamento de uma hie-rarquia de chaves, acrescentando às tecnologias de criptografia de hardware integra-das a dispositivos iOS. A Proteção de Dados é controlada por arquivo, atribuindo uma classe a cada um deles; a acessibilidade é determinada pela constatação do desblo-queio das chaves de classe.

Visão geral da arquiteturaSempre que um arquivo é criado na partição de dados, a Proteção de Dados cria uma nova chave de 256 bits (a chave única “por arquivo”) e a fornece ao mecanismo AES de hardware, que usa a chave para criptografar o arquivo conforme ele é gravado na memória flash usando o modo CBC do AES (em dispositivos com um processador A8, o AES-XTS é usado). O vetor de inicialização (IV) é calculado com o offset do bloco den-tro do arquivo, criptografado com o hash SHA-1 da chave única por arquivo.

A chave única por arquivo é embalada por uma das várias chaves de classe, depen-dendo das circunstâncias em que se poderá acessar o arquivo. Como todos os outros embalamentos, este é executado usando o embalamento de chaves AES NIST, de acor-do com o RFC 3394. A chave única por arquivo embalada é armazenada nos metada-dos do arquivo.

Quando um arquivo é aberto, seus metadados são decriptografados com a chave do sistema de arquivos, revelando a chave única por arquivo embalada e uma anotação sobre qual classe a protege. A chave única por arquivo é desembalada pela chave de classe e fornecida ao mecanismo AES de hardware, que decriptografa o arquivo con-forme ele é lido da memória flash. Todo o tratamento da chave do arquivo embalada ocorre no Enclave Seguro; a chave do arquivo nunca é exposta diretamente ao proces-sador do aplicativo. Na inicialização, o Enclave Seguro negocia uma chave transitória com o mecanismo AES. Quando o Enclave Seguro desembala as chaves de um arquivo, elas são reembaladas pela chave transitória e enviadas de volta para o processador do aplicativo.

Os metadados de todos os arquivos no sistema de arquivos são criptografados com uma chave aleatória, criada ao instalar o iOS pela primeira vez ou quando o dispo-sitivo é apagado pelo usuário. A chave do sistema de arquivos é armazenada no Armazenamento Apagável. Como a chave é armazenada no dispositivo, ela não é usada para manter a confidencialidade dos dados. Ao invés disso, ela é projetada para ser apagada rapidamente sob demanda (por um usuário, através da opção “Apagar Conteúdo e Ajustes” ou por um usuário ou administrador ao emitir um comando de


apagamento remoto a partir de um servidor de gerenciamento de dispositivos móvel (MDM), Exchange ActiveSync ou iCloud). O apagamento de uma chave dessa maneira deixa todos os arquivos criptograficamente inacessíveis.

Conteúdo do Arquivo

Metadados do Arquivo

Chave do Arquivo

Chave do Sistemade Arquivos

Chave deClasse

Chave do Código

Chave doHardware

O conteúdo de um arquivo é criptografado com uma chave única por arquivo, emba-lada por uma chave de classe e armazenada nos metadados de um arquivo que, por sua vez, é criptografado com a chave do sistema de arquivos. A chave de classe é protegida pelo UID do hardware e, em algumas classes, pelo código do usuário. Essa hierarquia fornece flexibilidade e bom desempenho. Por exemplo, a alteração da classe de um arquivo requer apenas que a chave única por arquivo seja reembalada e a alte-ração do código reembala somente a chave de classe.

CódigosAo configurar um código para o dispositivo, o usuário ativa a Proteção de Dados auto-maticamente. O iOS oferece suporte a códigos de seis ou quatro dígitos e códigos alfanuméricos de tamanho arbitrário. Além de desbloquear o dispositivo, um código fornece entropia para certas chaves de criptografia. Isso significa que se um invasor se apossar de um dispositivo, ele não conseguirá acessar os dados em classes de proteção específicas sem o código.

O código é trançado ao UID do dispositivo, portanto, ataques de força bruta precisam ser realizados no dispositivo sendo atacado. Um grande número de iterações é usado para fazer com que as tentativas sejam cada vez mais lentas. O número de iterações é calibrado de forma que uma tentativa dure aproximadamente 80 milissegundos. Isso significa que levaria mais de 5 anos e meio para tentar todas as combinações de letras minúsculas e números de um código alfanumérico de seis caracteres.

Quanto mais forte for o código do usuário, mais forte se torna a chave de criptografia. O Touch ID pode ser usado para melhorar essa equação, permitindo que o usuário defina um código muito mais forte do que seria, de outra maneira, prático. Isso aumen-ta a quantidade efetiva de entropia que protege as chaves de criptografia usadas pela Proteção de Dados, sem prejudicar a experiência do usuário ao desbloquear um dispo-sitivo iOS várias vezes ao dia.

Para desencorajar ainda mais os ataques de força bruta ao código, há um incremento no tempo de atraso entre as tentativas depois que um código inválido é digitado na tela Bloqueada. Se Ajustes > Touch ID e Código > Apagar Dados estiver ativado, o dis-positivo apagará os dados automaticamente após 10 tentativas incorretas consecutivas de digitação do código. Esse ajuste também está disponível como política administrati-va através do gerenciamento de dispositivos móveis (MDM) e do Exchange ActiveSync, podendo ser definido em um valor mais baixo.

Em dispositivos com um processador A7 ou um processador posterior da série A, os atrasos são exigidos pelo Enclave Seguro. Se o dispositivo for reiniciado durante um atraso programado, o atraso ainda é imposto e o timer é reiniciado para o período atual.

Considerações sobre códigoSe uma senha longa contendo ape-nas números for digitada, um teclado numérico é exibido na tela Bloqueada ao invés do teclado completo. Pode ser mais fácil digitar um código numérico longo do que um código alfanumérico curto (a segurança fornecida por ambos é similar).

Atrasos entre as tentativas de digitação do códigoTentativas Atraso Exigido1-4 nenhum5 1 minuto6 5 minutos7-8 15 minutos9 1 hora


Classes de Proteção de DadosQuando um novo arquivo é criado em um dispositivo iOS, o aplicativo que o criou lhe atribui uma classe. Cada classe usa políticas diferentes para determinar quando os dados podem ser acessados. As classes e políticas básicas são descritas nas seções a seguir.

Proteção Completa(NSFileProtectionComplete): a chave de classe é protegida por uma chave derivada do código do usuário e do UID do dispositivo. Pouco tempo depois do usu-ário bloquear um dispositivo (10 segundos, se o ajuste Exigir Senha estiver definido em Imediatamente), a chave de classe decriptografada é descartada, fazendo com que todos os dados desta classe fiquem inacessíveis até que o usuário digite o código novamente ou desbloqueie o dispositivo usando o Touch ID.

Protegido Exceto se Aberto(NSFileProtectionCompleteUnlessOpen): alguns arquivos podem precisar ser gravados enquanto o dispositivo estiver bloqueado. Um bom exemplo disso é a transferência em segundo plano de um anexo de e-mail. Esse comportamento é rea-lizado pelo uso de criptografia de curva elíptica assimétrica (ECDH sobre Curve25519). A chave única por arquivo habitual é protegida por uma chave derivada usando o Acordo de Chave Diffie-Hellman de Troca Única, como descrito em NIST SP 800-56A.

A chave pública transitória do acordo é armazenada em conjunto com a chave única por arquivo embalada. A KDF é a Função de Derivação da Chave de Concatenação (Alternativa Aprovada 1), como descrita em 5.8.1 do NIST SP 800-56A. O AlgorithmID é omitido. PartyUInfo é uma chave pública transitória e PartyVInfo é uma chave pública estática. SHA-256 é usado como a função hash. Assim que o arquivo é fechado, a chave única por arquivo é apagada da memória. Para abri-lo novamente, o segredo compar-tilhado é recriado usando a chave privada da classe Protegido Exceto se Aberto e a chave pública transitória do arquivo, que são utilizadas para desembalar a chave única por arquivo, que é então utilizada para decriptografar o arquivo.

Protegido Até a Primeira Autenticação do Usuário(NSFileProtectionCompleteUntilFirstUserAuthentication): essa classe se comporta da mesma maneira que a Proteção Completa, exceto pelo fato de que a chave de classe decriptografada não é removida da memória quando o disposi-tivo é bloqueado. A proteção desta classe possui propriedades semelhantes à cripto-grafia de volume completo em computadores de mesa e protege os dados de ataques que envolvem reinicialização. Essa é a classe padrão de todos os dados de aplicativos de terceiros que não tiverem sido atribuídos a uma classe de Proteção de Dados.

Sem Proteção(NSFileProtectionNone): essa chave de classe é protegida apenas pelo UID e é mantida no Armazenamento Apagável. Como todas as chaves necessárias para decrip-tografar os arquivos desta classe são armazenadas no dispositivo, a criptografia oferece apenas o benefício do apagamento remoto rápido. Se um arquivo não for atribuído a uma classe de Proteção de Dados, ele ainda é armazenado criptografado (como todos os dados em um dispositivo iOS).


Proteção de Dados das ChavesMuitos aplicativos precisam gerenciar senhas e outros dados simples, mas sensíveis, como chaves e tokens de acesso. As chaves do iOS oferecem uma maneira segura de armazenar esses itens.

As chaves são implementadas na forma de um banco de dados SQLite armazenado no sistema de arquivos. Existe apenas um banco de dados; o daemon securityd determina quais itens das chaves cada processo ou aplicativo pode acessar. As APIs de acesso às chaves resultam em chamadas ao daemon, que consulta os direitos do aplicativo “grupos-acesso-chaves”, “identificador-aplicativo” e “grupo-aplicativo”. Ao invés de limitar o acesso a um único processo, os grupos de acesso permitem que os itens das chaves sejam compartilhados entre aplicativos.

Os itens das chaves podem ser compartilhados apenas entre aplicativos do mesmo desenvolvedor. O gerenciamento disso é feito ao solicitar que aplicativos de tercei-ros usem grupos de acesso com um prefixo a eles alocado através do Programa de Desenvolvedor da Apple, via grupos de aplicativos. A exigência do prefixo e a exclusi-vidade do grupo de aplicativo são impostas através da assinatura de código, Perfis de Provisão e Programa de Desenvolvedor da Apple.

Os dados das chaves são protegidos usando uma estrutura de classe semelhante à usada na Proteção de Dados de arquivos. Essas classes apresentam comportamentos equivalentes às classes de Proteção de Dados de arquivos, mas usam chaves distintas e são parte das APIs que são denominadas de forma diferente.

Disponibilidade ProteçãodeDadosdeArquivos ProteçãodeDadosdasChaves

Quando desbloqueado

NSFileProtectionComplete kSecAttrAccessibleWhenUnlocked

Enquanto bloqueado

NSFileProtectionCompleteUnlessOpen NA

Depois do primeiro desbloqueio

NSFileProtectionCompleteUntilFirstUserAuthentication kSecAttrAccessibleAfterFirstUnlock

Sempre NSFileProtectionNone kSecAttrAccessibleAlways

Código ativado NA kSecAttrAccessible- WhenPasscodeSetThisDeviceOnly

Os aplicativos que utilizam serviços de atualização em segundo plano podem usar kSecAttrAccessibleAfterFirstUnlock para itens das chaves que precisam ser acessados durante atualizações em segundo plano.

A classe kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly se com-porta da mesma maneira que kSecAttrAccessibleWhenUnlocked, mas fica disponível apenas quando o dispositivo está configurado com um código. Essa classe existe ape-nas na bolsa de chaves do sistema. Ela não é sincronizada com as Chaves do iCloud, não possui backup e não é incluída nas bolsas de chaves de guarda. Se o código for removi-do ou redefinido, os itens são inutilizados através do descarte das chaves de classe.

Outras classes de chaves possuem um equivalente “Apenas este dispositivo”, sempre protegido com o UID ao ser copiado do dispositivo durante um backup, tornando-se inutilizáveis se restauradas em um dispositivo diferente.

Componentes de um item das chaves

Juntamente ao grupo de acesso, cada item das chaves contém metadados administrati-vos (como marcas temporais de criação e de última atualização).

Cada item também contém hashes SHA-1 dos atributos usados para consultá-lo (como os nomes da conta e do servidor) para permitir buscas sem que ele seja decriptografado. E, finalmente, cada item contém os dados de criptografia, que incluem o seguinte:• Número da versão;• Dados da lista de controle de acesso (ACL);• Valor que indica a classe de proteção ocu-

pada pelo item;• Chave única por item embalada pela chave

de classe de proteção;• Dicionário de atributos que descrevem o

item (conforme passado ao SecItemAdd), codificado como um arquivo plist binário com a chave única por item.

A criptografia usada é AES 128 em GCM (Modo Galois/Counter); o grupo de acesso é incluído nos atributos e protegido pela eti-queta GMAC, calculada durante a criptografia.


A Apple equilibrou segurança e usabilidade cuidadosamente, escolhendo classes de cha-ves que dependem do tipo de informação sendo protegida e de quando o iOS precisa dela. Por exemplo, um certificado VPN deve estar sempre disponível para que o dispositi-vo mantenha uma conexão contínua, mas é classificado como “não migratório” para que não possa ser movido para outro dispositivo.

Para os itens de chaves criados pelo iOS, as seguintes proteções de classe são exigidas:

Item Acessível

Senhas de rede Wi-Fi Depois do primeiro desbloqueio

Contas do Mail Depois do primeiro desbloqueio

Contas do Exchange Depois do primeiro desbloqueio

Senhas de VPN Depois do primeiro desbloqueio

LDAP, CalDAV, CardDAV Depois do primeiro desbloqueio

Tokens de contas de redes sociais Depois do primeiro desbloqueio

Chaves de criptografia de anúncio de Handoff Depois do primeiro desbloqueio

Token do iCloud Depois do primeiro desbloqueio

Senha do compartilhamento pessoal Quando desbloqueado

Token do Buscar iPhone Sempre

Voicemail Sempre

Backup do iTunes Quando desbloqueado, não migratório

Senhas do Safari Quando desbloqueado

Favoritos do Safari Quando desbloqueado

Certificados de VPN Sempre, não migratório

Chaves do Bluetooth® Sempre, não migratório

Token do serviço de Notificações Push da Apple Sempre, não migratório

Certificados e chaves privadas do iCloud Sempre, não migratório

Chaves do iMessage Sempre, não migratório

Certificados e chaves privadas instalados pelo Perfil de Configuração Sempre, não migratório

PIN do SIM Sempre, não migratório

Controle de acesso às chaves As chaves podem usar listas de controle de acesso (ACLs) para definir políticas de acessibilidade e requisitos de autenticação. Os itens podem estabelecer condições que exijam a presença do usuário, especificando que os mesmos não poderão ser acessados ao menos que o usuário tenha autenticado através do Touch ID ou pela digitação do código do dispositivo. O acesso a itens também pode ser limitado por meio da especifi-cação de que o registro do Touch ID não mudou desde que o item foi adicionado. Esta limitação ajuda a impedir que um invasor adicione sua própria impressão digital a fim de acessar um item das chaves. As ACLs são avaliadas no Enclave Seguro e liberadas ao núcleo somente se as restrições especificadas forem atendidas.

Acesso às senhas salvas do SafariOs aplicativos do iOS podem interagir com itens de chaves salvos pelo Safari para preen-chimento automático de senha usando as duas APIs a seguir:

• SecRequestSharedWebCredential

• SecAddSharedWebCredential


O acesso será fornecido apenas se o desenvolvedor do aplicativo e o administrador outorgarem e o usuário conceder. Os desenvolvedores de aplicativos expressam a intenção de acessar as senhas salvas do Safari incluindo um direito no aplicativo. Esse direito lista os nomes de domínio totalmente qualificados de sites associados. Os sites devem colocar um arquivo em seus servidores com uma lista dos identificadores exclu-sivos dos aplicativos aprovados. Quando um aplicativo que possui o direito com.apple.developer.associated-domains entitlement estiver instalado, o iOS faz uma solicitação TLS para cada site listado, pedindo o arquivo /apple-app-site-association. Caso o arqui-vo liste o identificador do aplicativo sendo instalado, o iOS assinala que o site e o apli-cativo têm uma relação confiável. Somente com uma relação confiável, as chamadas a estas duas APIs resultarão em uma solicitação ao usuário, que deverá concordar antes que qualquer senha seja liberada ao aplicativo, atualizada ou apagada.

Bolsas de chavesAs chaves das classes de Proteção de Dados de arquivos e de chaves são coletadas e gerenciadas em bolsas de chaves. O iOS usa as cinco bolsas de chaves seguintes: usuá-rio, dispositivo, backup, guarda e Backup do iCloud.

Abolsadechavesdousuário é onde as chaves de classe embaladas, usadas em ope-rações normais, são armazenadas. Por exemplo, quando um código é digitado, a chave NSFileProtectionComplete é carregada a partir da bolsa de chaves do sistema e desembalada. Ela é um plist binário armazenado na classe Sem Proteção, mas com conteúdo criptografado com uma chave mantida no Armazenamento Apagável. Para oferecer mais segurança às bolsas de chaves, essa chave é apagada e gerada novamen-te sempre que um usuário altera seu código. A extensão de núcleo AppleKeyStore gerencia a bolsa de chaves do usuário e pode ser consultada sobre o estado de blo-queio do dispositivo. Ela informa que o dispositivo está bloqueado somente se todas as chaves de classe da bolsa de chaves do usuário estiverem acessíveis e desembrulha-das corretamente.

Abolsadechavesdodispositivo é utilizada para armazenar as chaves de classe embaladas para operações que envolvem dados específicos de dispositivo. Os disposi-tivos iOS configurados para uso compartilhado às vezes requerem acesso a credenciais antes que algum usuário tenha iniciado a sessão. Portanto, é necessária uma bolsa de chaves não protegida pela senha do usuário. O iOS não aceita a separação criptográfica de conteúdo de sistema de arquivos por usuário, o que significa que o sistema utilizará chaves de classe da bolsa de chaves do dispositivo para embalar chaves por arquivo. As chaves, porém, utilizam as chaves de classe da bolsa de chaves do usuário para proteger itens nas chaves do usuário. Em dispositivos iOS configurados para uso por um usuário único (configuração padrão), a bolsa de chaves do dispositivo e a bolsa de chaves do usuário são uma mesma, protegida pelo código do usuário.

Abolsadechavesdobackup é criada quando o iTunes faz um backup criptografado e o armazena no computador onde o backup do dispositivo foi feito. Uma nova bolsa de chaves é criada com um novo conjunto de chaves e os dados do backup são crip-tografados novamente conforme essas novas chaves. Como explicado anteriormente, os itens de chaves não migratórios permanecem embalados com a chave derivada do UID, permitindo que eles sejam restaurados no dispositivo de onde foram originalmen-te copiados, mas tornando-os inacessíveis em um dispositivo diferente.

A bolsa de chaves é protegida pela a senha definida no iTunes, passada por 10.000 iterações de PBKDF2. Apesar dessa contagem de iteração extensa, não há vínculos com um dispositivo específico e, portanto, teoricamente, seria possível tentar um ataque de força bruta à bolsa de chaves do backup usando-se vários computadores em paralelo. Essa ameaça pode ser atenuada através de uma senha suficientemente forte.


Se um usuário decidir não criptografar um backup do iTunes, os arquivos de backup não são criptografados, independentemente de suas classes de Proteção de Dados, mas as chaves permanecem protegidas por uma chave derivada do UID. É por isso que os itens das chaves são migrados para um novo dispositivo apenas se uma senha de backup for definida.

Abolsadechavesdeguardaé usada para a sincronização com o iTunes e o MDM. Essa bolsa de chaves permite o backup e a sincronização do iTunes sem exigir que o usuário digite uma senha e permite também que um servidor MDM limpe o código de um usuário remotamente. Ela é armazenada no computador usado para fazer a sincro-nização com o iTunes ou no servidor MDM que gerencia o dispositivo.

A bolsa de chaves de guarda melhora a experiência do usuário durante a sincroniza-ção do dispositivo, o que potencialmente requer acesso a todas as classes de dados. Quando um dispositivo bloqueado por código é conectado pela primeira vez ao iTu-nes, o usuário é solicitado a digitar um código. Então, o dispositivo cria uma bolsa de chaves de guarda que contém as mesmas chaves de classe usadas no dispositivo, pro-tegida por uma nova chave recém-gerada. A bolsa de chaves de guarda e a chave que a protege são divididas entre o dispositivo e o host ou servidor, com os dados armaze-nados no dispositivo na classe Protegido Até a Primeira Autenticação do Usuário. É por isso que o código do dispositivo deve ser digitado antes que o usuário faça um backup no iTunes da primeira vez após uma reinicialização.

No caso de uma atualização de software OTA, o usuário é solicitado a digitar o código ao iniciar a atualização. Isso é feito para criar um Token de Desbloqueio Único com segurança, o qual desbloqueia a bolsa de chaves do usuário depois da atualização. Esse token não pode ser gerado sem que o código do usuário seja digitado e todos os toke-ns gerados anteriormente são invalidados se o código do usuário for alterado.

Os Tokens de Desbloqueio Único servem para atualizações de software feitas com ou sem supervisão. Eles são criptografados com uma chave derivada do valor atual de um contador monotônico no Enclave Seguro, o UUID da bolsa de chaves e o UID do Enclave Seguro.

O aumento do contador do Token de Desbloqueio Único no Enclave Seguro invalida todos os tokens existentes. O contador aumenta quando um token é usado, depois do primeiro desbloqueio de um dispositivo reiniciado, quando uma atualização de sof-tware é cancelada (pelo usuário ou pelo sistema) ou quando o timer da política de um token tiver expirado.

O Token de Desbloqueio Único de atualizações de software supervisionadas expi-ra depois de 20 minutos. Esse token é exportado do Enclave Seguro e gravado no Armazenamento Apagável. Um timer da política aumenta o contador se o dispositivo não tiver reinicializado em 20 minutos.

Em atualizações de software não supervisionadas, que acontecem quando o usuário seleciona “Instalar Mais Tarde” ao ser notificado sobre a atualização, o processador do aplicativo pode manter o Token de Desbloqueio Único ativo no Enclave Seguro por até 8 horas. Depois desse período, um time de política aumenta o contador.

AbolsadechavesdoBackupdoiCloud assemelha-se à bolsa de chaves do backup. Todas as chaves de classe nessa bolsa de chaves são assimétricas (usando Curve25519, como a classe de Proteção de Dados “Protegido Exceto se Aberto”) para que os backups do iCloud possam ser realizados em segundo plano. Em todas as classes de Proteção de Dados, exceto a classe Sem Proteção, os dados criptografados são lidos do dispositivo e enviados ao iCloud. As chaves de classe correspondentes são protegidas pelas chaves do iCloud. As chaves de classe das chaves são embaladas por uma chave derivada do UID, da mesma maneira que um backup não criptografado do iTunes. Uma bolsa de chaves assimétrica também é usada para o backup no aspecto de recupera-ção das Chaves do iCloud.


Certificações e programas de segurançaNota: Para obter mais informações sobre as mais recentes validações, orientações e certificações de segurança do iOS, consulte support.apple.com/pt-br/HT202739.

Validação Criptográfica (FIPS 140-2)Os módulos criptográficos do iOS foram validados em conformidade com os Padrões de Processamento de Informações Federais dos EUA (FIPS) 140-2 Nível 1 para todas as versões desde o iOS 6. Os módulos criptográficos do iOS 9 são idênticos aos do iOS 8, mas, como em cada lançamento, a Apple envia os módulos para revalidação. Esse pro-grama valida a integridade das operações criptográficas dos aplicativos da Apple e de terceiros que utilizam adequadamente os serviços de criptografia do iOS.

Certificação Common Criteria (ISO 15408)A Apple já começou a busca pela certificação do iOS sob o programa de Certificação Common Criteria (CCC). As duas primeiras certificações concluídas são VID10695 para iOS contrária ao Perfil de Proteção Fundamental de Dispositivos Móveis v2.0 (MDFPP2) e VID10714 contrária ao Perfil de Proteção do Cliente VPN IPSecPP1.4 (VPNIPSecPP1.4). Uma certificação ativa será concluída em breve para o protocolo integrado MDM con-trária ao Perfil de Proteção do Agente MDM EP 2.0 (MDMAgentEP2). A Apple assumiu um papel ativo na Comunidade Técnica Internacional (ITC) para o desenvolvimento de Perfis de Proteção (PPs) não disponíveis atualmente, com foco na avaliação de tecnolo-gias importantes de segurança móvel. A Apple continua avaliando e buscando certifi-cações que sejam contrárias às versões novas e atualizadas dos PPs disponíveis hoje.

Commercial Solutions for Classified (CSfC)Quando aplicável, a Apple também pediu a inclusão da plataforma iOS e de vários serviços na lista de componentes do programa Commercial Solutions for Classified (CSfC). Especificamente, iOS para Plataforma Móveis e cliente IKEv2 para o Cliente VPN IPSec (somente VPN Sempre Ativa IKEv2). Conforme as plataformas e serviços da Apple obtenham Certificações Common Criteria, elas serão enviadas para inclusão na lista de componentes do programa CSfC.

Manuais de Configuração de SegurançaA Apple tem colaborado com governos em todo o mundo para desenvolver manuais com instruções e recomendações para a manutenção de um ambiente mais seguro, também conhecido como “endurecimento de dispositivo”. Esses manuais fornecem informações definidas e verificadas sobre como configurar e utilizar recursos do iOS para melhor proteção.


19Segurança do iOS — White Paper | Maio de 2016

Segurança de Aplicativos

Os aplicativos estão entre os elementos mais críticos de uma arquitetura de segurança móvel moderna. Eles oferecem aos usuários benefícios incríveis na produtividade, mas também possuem o potencial de impactar negativamente a segurança e estabilidade do sistema, assim como os dados do usuário, se não forem gerenciados corretamente.

Por isso, o iOS fornece camadas de proteção, garantindo que os aplicativos sejam assi-nados e verificados, além de serem isolados para proteger os dados do usuário. Esses elementos proporcionam uma plataforma segura e estável para os aplicativos, permi-tindo que milhares de desenvolvedores ofereçam milhares de aplicativos no iOS sem impactar a integridade do sistema. Os usuários podem acessar esses aplicativos em seus dispositivos iOS sem terem medo de vírus, malware ou ataques não autorizados.

Assinatura de código de aplicativosDepois de ser iniciado, o núcleo do iOS controla quais processadores e aplicativos podem ser executados. Para garantir que todos os aplicativos provenham de uma fonte conhecida e aprovada e que não tenham sido adulterados, o iOS exige que todos os códigos executáveis sejam assinados por um certificado emitido pela Apple. Os apli-cativos fornecidos com o dispositivo, como o Mail e o Safari, são assinados pela Apple. Os aplicativos de terceiros também precisam ser validados e assinados por um certi-ficado emitido pela Apple. A assinatura de código obrigatória amplia o conceito de cadeia de confiança do sistema operacional até os aplicativos e impede que aplicativos de terceiros possam carregar recursos de código não assinado ou usem código que se modifique sozinho.

Para desenvolver e instalar aplicativos em dispositivos iOS, os desenvolvedores devem se registrar na Apple e se associar ao Programa de Desenvolvedor da Apple. A identi-dade real de cada desenvolvedor, seja ele um indivíduo ou uma empresa, é verificada pela Apple antes da emissão de seu certificado. Esse certificado permite que os desen-volvedores assinem e enviem aplicativos à App Store para distribuição. Como resultado, todos os aplicativos que estão na App Store foram enviados por uma pessoa ou orga-nização identificável, o que mitiga a criação de aplicativos maliciosos. Os aplicativos também foram revisados pela Apple para garantir que funcionem como descrito e não contenham erros óbvios ou outros problemas. Além da tecnologia já discutida, esse processo de curadoria permite que os clientes possam confiar na qualidade dos aplica-tivos que adquirem.

O iOS permite que os desenvolvedores integrem estruturas aos seus aplicativos, que podem ser usadas pelo próprio aplicativo ou por extensões integradas a ele. Para proteger o sistema e outros aplicativos do carregamento de códigos de terceiros em seu espaço de endereço, o sistema executará uma validação da assinatura de código de todas as bibliotecas dinâmicas das quais um processo depende ao ser aberto. Essa verificação é realizada através do identificador da equipe (ID da Equipe), extraído do certificado emitido pela Apple. O identificador da equipe é uma string alfanumérica de 10 caracteres; 1A2B3C4D5F, por exemplo. Um programa pode depender de qual-quer biblioteca de plataforma fornecida com o sistema ou qualquer biblioteca com o mesmo identificador da equipe na assinatura de código do executável principal. Como os executáveis fornecidos como parte do sistema não possuem um identificador de equipe, eles só podem depender de bibliotecas fornecidas com o próprio sistema.


As empresas também podem desenvolver aplicativos próprios para uso interno e dis-tribuí-los aos seus funcionários. As empresas e organizações podem se candidatar ao Programa Empresarial de Desenvolvedor da Apple (ADEP) com um número D-U-N-S. A Apple aprova os candidatos depois de verificar suas identidades e elegibilidades. Quando uma empresa se torna membro do ADEP, ela pode se registrar para obter um Perfil de Provisão, que permite que os aplicativos próprios sejam executados em dis-positivos autorizados. Os usuários precisam ter o Perfil de Provisão instalado para exe-cutar esses aplicativos. Isso garante que apenas usuários autorizados possam carregar os aplicativos em seus dispositivos iOS. Os aplicativos instalados através do MDM são implicitamente confiáveis porque o relacionamento entre a empresa e o dispositivo já está estabelecido. Caso contrário, os usuários precisam aprovar o Perfil de Provisão do aplicativo nos Ajustes. As empresas podem restringir a aprovação de aplicativos de desenvolvedores desconhecidos por seus funcionários. Ao abrir um aplicativo empresa-rial pela primeira vez, o dispositivo precisa receber uma confirmação positiva da Apple, permitindo sua execução.

Ao contrário de outras plataformas móveis, o iOS não permite que os usuários instalem aplicativos não assinados e potencialmente maliciosos de sites ou executem código não confiável. Durante a execução, a assinatura de código verifica se todas as páginas de memória executáveis são criadas conforme elas são carregadas para garantir que o apli-cativo não tenha sido modificado desde que foi instalado ou atualizado pela última vez.

Segurança do processo de execuçãoApós a confirmação de que o aplicativo provém de uma fonte confiável, o iOS aplica medidas de segurança criadas para impedir que ele comprometa outros aplicativos ou o restante do sistema.

Todos os aplicativos de terceiros são “isolados” e, portanto, não podem acessar os arquivos armazenados por outros aplicativos ou fazer alterações no dispositivo. Isso impede que um aplicativo colete ou modifique informações armazenadas por outros aplicativos. Cada aplicativo possui um diretório inicial exclusivo para seus arquivos, atribuído aleatoriamente quando o aplicativo é instalado. Se um aplicativo de terceiros precisar acessar informações que não as suas próprias, ele usará os serviços fornecidos explicitamente pelo iOS.

Os arquivos e recursos do sistema também são protegidos dos aplicativos do usuário. A maior parte do iOS é executado como o usuário não privilegiado “mobile” , assim como todos os aplicativos de terceiros. Toda a partição do sistema operacional é monta-da como somente leitura. Ferramentas desnecessárias, como serviços de início de sessão remoto, não estão incluídas no software do sistema e as APIs não permitem que aplica-tivos ampliem os seus próprios privilégios para modificar outros aplicativos ou o iOS.

O acesso de aplicativos de terceiros a informações do usuário e recursos, como o iCloud e a extensibilidade, é controlado através de direitos declarados. Os direitos são pares de valores básicos assinados para um aplicativo e permitem a autenticação além de fatores de execução, como o ID Unix do usuário. Os direitos não podem ser altera-dos, já que são assinados digitalmente. Os direitos são usados extensivamente pelos daemons e aplicativos do sistema para realizar operações privilegiadas específicas que, de outra forma, necessitariam que o processo fosse executado como root. Isso reduz de maneira significativa a possibilidade de aumento de privilégio de um daemon ou aplicativo do sistema comprometido.

Além disso, os aplicativos só podem executar processamento em segundo plano através das APIs fornecidas pelo sistema. Isso permite que os aplicativos continuem a funcionar sem prejudicar o desempenho ou impactar dramaticamente a vida útil da bateria.


A aleatorização do espaço de endereço (ASLR) protege contra a exploração de erros de corrupção da memória. Os aplicativos integrados usam a ASLR para garantir que todas as regiões da memória sejam aleatorizadas na inicialização. A organização aleatória dos endereços de memória do código executável, das bibliotecas do sistema e das constru-ções de programação relacionadas reduz a possibilidade de diversos aproveitamentos sofisticados. Por exemplo, um ataque return-to-libc tenta enganar um dispositivo para que ele execute um código malicioso através da manipulação dos endereços das bibliotecas de contêineres e do sistema. A aleatorização do posicionamento desses itens dificulta o ataque, especialmente em larga escala. O Xcode, o ambiente de desen-volvimento do iOS, compila automaticamente os programas de terceiros com o supor-te à ASLR ativo.

O iOS fornece uma proteção ainda maior através do recurso Nunca Executar (XN) do ARM, que marca as páginas de memória como não executáveis. As páginas de memó-ria marcadas como graváveis e executáveis podem ser usadas por aplicativos apenas sob condições rigorosamente controladas: o núcleo verifica a presença de direitos dinâmicos de assinatura de código somente da Apple. Mesmo assim, apenas uma única chamada mmap pode ser feita para solicitar uma página executável e gravável, que recebe um endereço aleatorizado. O Safari usa essa funcionalidade em seu compi-lador JavaScript JIT.

ExtensõesO iOS permite que os aplicativos forneçam funcionalidade a outros aplicativos através de extensões. As extensões são binários executáveis assinados de finalidade específica, empacotados em um aplicativo. O sistema detecta automaticamente as extensões durante a instalação e as disponibiliza para outros aplicativos usando um sistema de correspondência.

Uma área de sistema que oferece suporte a extensões é chamada de “ponto de exten-são”. Cada ponto de extensão fornece APIs e aplica regras para tal área. O sistema determina quais extensões estão disponíveis com base em regras de correspondência de ponto de extensão específicas. O sistema abre os processos de extensão automati-camente conforme a necessidade e gerencia a sua vida útil. Direitos podem ser usados para restringir a disponibilidade das extensões a certos aplicativos do sistema. Por exemplo, um widget da visualização “Hoje” é exibido apenas na Central de Notificações e uma extensão de compartilhamento só está disponível no painel Compartilhamento. Os pontos de extensão são: widgets “Hoje”, Compartilhar, Ações personalizadas, Edição de fotos, Provedor de Documentos e Teclado Personalizado.

As extensões são executadas em seus próprios espaços de endereço. A comunicação entre a extensão e o aplicativo a partir do qual ela foi ativada usa comunicações inter-processuais mediadas pela estrutura do sistema. Elas não têm acesso aos arquivos ou espaços de memória umas das outras. As extensões são criadas para serem isoladas umas das outras, dos aplicativos que as contêm e dos aplicativos que as usam. Elas são isoladas como qualquer outro aplicativo de terceiro e possuem um contêiner separado do contêiner do aplicativo que as contém. Entretanto, elas compartilham o mesmo acesso aos controles de privacidade do aplicativo em que estão contidas. Portanto, se um usuário conceder acesso aos Contatos para um aplicativo, este acesso também será concedido às extensões integradas ao aplicativo, mas não às extensões ativadas por ele.

Os teclados personalizados são um tipo especial de extensão, já que são ativadas pelo usuário para todo o sistema. Quando ativada, a extensão será usada por qualquer campo de texto, exceto para a digitação do código e para a visualização de textos seguros. Por motivos de privacidade, os teclados personalizados são executados por padrão em um isolamento bastante restritivo que bloqueia o acesso à rede, a serviços que executam operações de rede em nome de um processo e a APIs que poderiam


permitir que a extensão extraísse dados digitados. Os desenvolvedores de teclados personalizados podem solicitar Acesso Aberto às suas extensões, o que permitirá que o sistema execute a extensão no isolamento padrão após obter o consentimento do usuário.

No caso de dispositivos registrados no gerenciamento de dispositivos móveis, as exten-sões de documento e de teclado seguem as regras “Abrir Com Gerenciado”. Por exemplo, o servidor MDM pode impedir que um usuário exporte um documento de um aplicativo gerenciado para um Provedor de Documentos não gerenciado ou use um teclado não gerenciado com um aplicativo gerenciado. Além disso, os desenvolvedores de aplicativos podem impedir o uso de extensões de teclado de terceiros em seus aplicativos.

Grupos de AplicativosOs aplicativos e extensões de propriedade de uma dada conta de desenvolvedor podem compartilhar conteúdo quando configurados para ser parte de um Grupo de Aplicativos. Cabe ao desenvolvedor criar os grupos apropriados no Portal Apple Developer e incluir o conjunto desejado de aplicativos e extensões. Quando configura-dos para ser parte de um Grupo de Aplicativos, os aplicativos têm acesso ao seguinte:

• Um contêiner compartilhado em disco para armazenamento, que permanecerá no dispositivo enquanto houver ao menos um aplicativo do grupo instalado;

• Preferências compartilhadas;

• Itens compartilhados das chaves.

O Portal Apple Developer assegura a exclusividade dos IDs de Grupo de Aplicativos por todo o ecossistema de aplicativos.

Proteção de Dados em aplicativosO Kit de Desenvolvimento de Software (SDK) do iOS oferece um conjunto completo de APIs que facilitam a adoção da Proteção de Dados por terceiros e desenvolvedores empresariais e ajudam a garantir o nível mais alto de proteção para seus aplicativos. A Proteção de Dados está disponível para APIs de banco de dados e de arquivos, incluindo NSFileManager, CoreData, NSData e SQLite.

O aplicativo Mail (incluindo anexos), livros gerenciados, favoritos do Safari, imagens de abertura do aplicativo e dados de localização também são armazenados criptografados com chaves protegidas pelo código do usuário no dispositivo. O Calendário (excluindo anexos), Contatos, Lembretes, Notas, Mensagens e Fotos implementam “Protegido Até a Primeira Autenticação do Usuário”.

Os aplicativos instalados pelo usuário que não optam por uma classe específica de Proteção de Dados recebem “Protegido Até a Primeira Autenticação do Usuário” por padrão.

AcessóriosO programa de licenciamento Made for iPhone, iPod touch e iPad (MFi) fornece a fabri-cantes de acessórios verificados o acesso ao Protocolo de Acessórios para iPod (iAP) e aos componentes de hardware de suporte necessários.

Quando um acessório MFi se comunica com um dispositivo iOS usando um conector Lightning ou Bluetooth, o dispositivo solicita que o acessório prove ter sido autorizado pela Apple, respondendo com um certificado fornecido pela Apple, verificado pelo dispositivo. Então, o dispositivo envia um desafio e o acessório precisa respondê-lo com


uma resposta assinada. Esse processo é gerenciado completamente por um circuito integrado personalizado que a Apple fornece a fabricantes de acessórios aprovados, sendo transparente ao acessório em si.

Os acessórios podem solicitar acesso a diferentes funcionalidades e métodos de trans-porte — como por exemplo, o acesso a transmissões de áudio digital através do cabo Lightning ou às informações de localização fornecidas por Bluetooth. Um CI de auten-ticação garante que apenas os dispositivos aprovados possuam acesso total ao disposi-tivo. Se um acessório não fornece autenticação, seu acesso é limitado ao áudio analógi-co e a um pequeno subconjunto de controles de reprodução de áudio serial (UART).

O AirPlay também utiliza o CI de autenticação para verificar se os receptores foram aprovados pela Apple. As transmissões de áudio AirPlay e de vídeo CarPlay utilizam o MFi-SAP (Protocolo de Associação Segura), que criptografa a comunicação entre o acessório e o dispositivo usando AES-128 no modo CTR. As chaves transitórias são tro-cadas usando a troca de chaves ECDH (Curve25519) e autorizadas usando a chave RSA de 1024 bits do CI de autenticação como parte do protocolo Station-to-Station (STS).

HomeKitO HomeKit oferece uma infraestrutura de automação doméstica que utiliza a segurança do iCloud e do iOS para proteger e sincronizar dados privados sem expô-los à Apple.

Identidade HomeKitA segurança e identidade do HomeKit são baseadas em pares de chaves públicas-pri-vadas Ed25519. Para cada usuário do HomeKit, é gerado um par de chaves Ed25519 em seu respectivo dispositivo iOS, definindo a sua identidade HomeKit. O par de chaves também é usado para autenticar a comunicação entre dispositivos iOS e entre disposi-tivos iOS e acessórios.

As chaves são armazenadas nas Chaves (Keychain) e incluídas apenas em backups crip-tografados das Chaves. Elas são sincronizadas entre os dispositivos usando as Chaves do iCloud.

Comunicação entre acessórios HomeKitOs acessórios HomeKit geram o seus próprios pares de chaves Ed25519 para uso nas comunicações com dispositivos iOS. Se o acessório for restaurado aos ajustes de fábri-ca, um novo par de chaves é gerado.

Para estabelecer um relacionamento entre um dispositivo iOS e um acessório HomeKit, as chaves são trocadas usando o protocolo Secure Remote Password (3072 bits), utili-zando um código de 8 dígitos fornecido pelo fabricante do acessório e digitado no dis-positivo iOS pelo usuário. A seguir, elas são criptografadas usando ChaCha20-Poly1305 AEAD com chaves derivadas HKDF-SHA-512. A certificação MFi do acessório também é verificada durante a configuração.

Quando o dispositivo iOS e um acessório HomeKit se comunicam durante o uso, um autentica o outro utilizando as chaves trocadas no processo acima. Cada sessão é esta-belecida usando o protocolo Station-to-Station e criptografada com chaves derivadas HKDF-SHA-512, baseadas em chaves Curve25519 únicas por sessão. Isso se aplica tanto a acessórios com base em IP como a acessórios Bluetooth Low Energy.

Armazenamento de dados locaisO HomeKit armazena os dados de casas, acessórios, cenas e usuários em um dispositi-vo iOS do usuário. Os dados armazenados são criptografados usando chaves derivadas das chaves de identidade HomeKit do usuário em conjunto com um nonce aleatório. Além disso, os dados do HomeKit são armazenados usando a classe de Proteção de


Dados “Protegido Até a Primeira Autenticação do Usuário”. O backup dos dados do HomeKit é sempre criptografado, portanto, backups não criptografados do iTunes, por exemplo, não contêm dados do HomeKit.

Sincronização de dados entre dispositivos e usuáriosOs dados do HomeKit podem ser sincronizados entre os dispositivos iOS de um usu-ário através do iCloud e das Chaves do iCloud. Eles são criptografados durante a sin-cronização usando as chaves derivadas da identidade HomeKit do usuário e um nonce aleatório. Durante a sincronização, esses dados são tratados como uma bolha opaca. A bolha mais recente é armazenada no iCloud para ativar a sincronização, mas não é usada para nenhum outro propósito. Como os dados são criptografados usando chaves disponíveis apenas nos dispositivos iOS do usuário, seu conteúdo se torna inacessível durante a transmissão e o armazenamento no iCloud.

Os dados do HomeKit também são sincronizados entre os vários usuários da mesma casa. Esse processo usa a mesma autenticação e a mesma criptografia usadas entre um dispositivo iOS e um acessório HomeKit. A autenticação é baseada em chaves públicas Ed25519, que são trocadas entre os dispositivos quando um usuário é adicionado a uma casa. Depois que um novo usuário é adicionado a uma casa, todas as comuni-cações posteriores são autenticadas e criptografadas usando o protocolo Station-to-Station e chaves únicas por sessão.

Apenas o usuário que inicialmente criou a casa no HomeKit pode adicionar novos usuários. Seu dispositivo configura os acessórios com a chave pública do novo usuário para que os acessórios possam autenticar e aceitar comandos do novo usuário. O pro-cesso de configuração do Apple TV para uso com o HomeKit usa a mesma autentica-ção e criptografia da inclusão de usuários adicionais, mas é realizado automaticamente se o usuário que criou a casa tiver uma sessão iniciada no iCloud no Apple TV e o Apple TV estiver na casa.

Se um usuário não tiver vários dispositivos e não conceder acesso a usuários adicionais em sua casa, nenhum dado do HomeKit é sincronizado com o iCloud.

Aplicativo e dados da casaO acesso aos dados da casa por aplicativos é controlado pelos ajustes de Privacidade do usuário. Os usuários são solicitados a conceder acesso quando os aplicativos soli-citam dados da casa, de maneira semelhante ao Contatos, Fotos e outras fontes de dados do iOS. Se o usuário aprovar, os aplicativos terão acesso aos nomes dos quartos, acessórios, qual quarto cada acessório se encontra e outras informações, conforme detalhado na documentação do desenvolvedor do HomeKit.

SiriA Siri pode ser usada para consultar e controlar acessórios e para ativar cenas. Uma quantidade mínima de informações sobre a configuração da casa é fornecida anoni-mamente à Siri, como descrito na seção Siri deste documento, para fornecer nomes de salas, acessórios e cenas necessários para o reconhecimento de comandos.

Acesso remoto do iCloud para acessórios HomeKitOs acessórios HomeKit podem ser conectados diretamente ao iCloud para permitir que dispositivos iOS os controlem quando a comunicação Bluetooth ou Wi-Fi não estiver disponível.

O acesso Remoto do iCloud foi projetado cuidadosamente para que os acessórios sejam controlados e enviem notificações sem revelar suas identidades à Apple ou quais comandos e notificações estão sendo enviados. O HomeKit não envia informa-ções sobre a casa através do acesso Remoto do iCloud.


Quando um usuário envia um comando usando o acesso remoto do iCloud, o acessó-rio e o dispositivo iOS são autenticados mutuamente e os dados são criptografados usando o mesmo procedimento descrito para conexões locais. O conteúdo das comu-nicações é criptografado e não pode ser visualizado pela Apple. O endereçamento através do iCloud é baseado nos identificadores do iCloud registrados durante o pro-cesso de configuração.

Os acessórios que oferecem suporte ao acesso remoto do iCloud são fornecidos duran-te o processo de configuração do acessório. O processo de provisão começa com o início de sessão do usuário no iCloud. A seguir, o dispositivo iOS solicita que o acessó-rio assine um desafio usando o Coprocessador de Autenticação da Apple, integrado a todos os acessórios Built for HomeKit. O acessório também gera chaves de curva elíptica prime256v1, e a chave pública é enviada ao dispositivo iOS junto com o desa-fio assinado e o certificado X.509 do coprocessador de autenticação. Esses dados são usados para solicitar um certificado do servidor de provisão do iCloud para o acessório. O certificado é armazenado pelo acessório, mas não contém nenhuma identificação sobre ele além da informação de que o acesso remoto ao iCloud do HomeKit foi-lhe concedido. O dispositivo iOS que está conduzindo a provisão também envia um pacote ao acessório, o qual contém as URLs e outras informações necessárias para conexão ao servidor de acesso remoto do iCloud. Essas informações não são específicas a nenhum usuário ou acessório.

Cada acessório registra uma lista de usuários permitidos no servidor de acesso remoto do iCloud. A capacidade de controlar o acessório foi concedida a esses usuários pela pessoa que os adicionou à casa. Os usuários recebem um identificador pelo servidor do iCloud e podem ser mapeados a uma conta do iCloud com o intuito de receberem mensagens de notificações e respostas dos acessórios. De maneira semelhante, os acessórios possuem identificadores emitidos pelo iCloud, mas eles são opacos e não revelam nenhuma informação sobre o acessório em si.

Quando um acessório se conecta ao servidor de acesso remoto do iCloud do HomeKit, ele apresenta seu certificado e um tíquete. O tíquete é obtido de um servidor do iCloud diferente e não é exclusivo por acessório. Quando um acessório solicita um tíquete, ele inclui o fabricante, modelo e versão do firmware na solicitação. Nenhuma informação que identifique o usuário ou a casa é enviada nessa solicitação. A conexão ao servidor de tíquetes não é autenticada para ajudar a proteger a privacidade.

Os acessórios se conectam ao servidor de acesso remoto do iCloud através de HTTP/2 e são protegidos por TLS 1.2 com AES-128-GCM e SHA-256. O acessório mantém a conexão ao servidor de acesso remoto do iCloud aberta para receber mensagens e enviar respostas e notificações para dispositivos iOS.

HealthKitO HealthKit armazena e agrega dados dos aplicativos de saúde e preparo físico com a permissão do usuário. O HealthKit também funciona diretamente com dispositivos de saúde e preparo físico, tais como monitores cardíacos Bluetooth LE compatíveis e o coprocessador de movimento integrado a vários dispositivos iOS.

Dados de saúdeO HealthKit armazena e agrega os dados de saúde do usuário, como altura, peso, distância caminhada, pressão sanguínea, etc. Esses dados são armazenados na classe de Proteção de Dados “Proteção Completa”, o que significa que ele pode ser acessado somente depois que um usuário digita a sua senha ou usa o Touch ID para desbloque-ar o dispositivo.


Outro banco de dados armazena dados operacionais, como tabelas de acesso de apli-cativos, nomes de dispositivos conectados ao HealthKit e informações de programação usadas para abrir aplicativos quando novos dados estiverem disponíveis. Esse banco de dados é armazenado na classe de Proteção de Dados “Protegido Até a Primeira Autenticação do Usuário”.

Arquivos temporários de registro armazenam registros de saúde gerados quando o dispositivo está bloqueado, como quando o usuário está se exercitando. Esses dados são armazenados na classe de Proteção de Dados “Protegido Exceto se Aberto”. Quando o dispositivo é desbloqueado, eles são importados para os bancos de dados de saúde primários e depois apagados quando a combinação é concluída.

Os dados de saúde não são sincronizados entre dispositivos. Os dados de saúde são incluídos em backups do dispositivo para o iCloud e em backups criptografados do iTunes. Os dados de saúde não são incluídos em backups não criptografados do iTunes.

Integridade de DadosOs dados armazenados no banco de dados incluem metadados para rastrear a prove-niência de cada registro. Esses metadados incluem um identificador de aplicativo que indica qual aplicativo armazenou o registro. Além disso, um item de metadados opcio-nal pode conter uma cópia do registro assinada digitalmente. O objetivo é fornecer integridade de dados para registros gerados por um dispositivo confiável. O formato usado para a assinatura digital é a Sintaxe de Mensagem Criptográfica (CMS), especifi-cado no IETF RFC 5652.

Acesso por aplicativos de terceirosO acesso à API do HealthKit é controlado por direitos e os aplicativos devem atender às restrições sobre como os dados são usados. Por exemplo, os aplicativos não têm permissão para utilizar dados de saúde para publicidade. Os aplicativos também preci-sam fornecer aos usuários uma política de privacidade que detalhe o uso de dados de saúde.

O acesso aos dados de saúde por aplicativos é controlado pelos ajustes de Privacidade do usuário. Os usuários são solicitados a conceder acesso aos dados de saúde a pedi-dos dos aplicativos, de maneira semelhante ao Contatos, Fotos e outras fontes de dados do iOS. Entretanto, no caso de dados de saúde, o acesso para ler e gravar é con-cedido aos aplicativos separadamente, assim como para cada tipo de dado de saúde. Os usuários podem visualizar e revogar as permissões de acesso concedidas aos dados de saúde na aba Fontes do aplicativo Saúde.

Se a permissão para gravar dados for concedida, os aplicativos também podem ler os dados que gravam. Se a permissão para ler dados for concedida, eles podem ler dados gravados por todas as fontes. Entretanto, os aplicativos não podem determinar o acesso concedido a outros aplicativos. Além disso, os aplicativos não podem afirmar categoricamente se receberam acesso de leitura aos dados de saúde. Quando um aplicativo não possui acesso de leitura, nenhuma consulta retorna dados — a resposta gerada é a mesma que um banco de dados vazio retornaria. Isso impede que aplicati-vos infiram o estado de saúde do usuário ao aprender quais tipos de dados o usuário está rastreando.

Ficha MédicaO aplicativo Saúde oferece aos usuários a opção de preencher uma ficha médica com informações que podem ser importantes durante uma emergência médica. As informa-ções são digitadas ou atualizadas manualmente e não são sincronizadas com as infor-mações dos bancos de dados de saúde.


As informações da ficha médica podem ser visualizadas tocando no botão Emergência, na tela de Bloqueio. As informações são armazenadas no dispositivo usando a classe de Proteção de Dados “Sem Proteção”, para que sejam acessadas sem que seja necessá-rio digitar o código do dispositivo. A ficha médica é um recurso opcional que permite que os usuários decidam como equilibrar segurança e privacidade.

Notas SegurasO aplicativo Notas inclui um recurso de Notas Seguras, que permite aos usuários pro-tegerem os conteúdos de notas específicas. As notas seguras são criptografadas por meio de uma senha fornecida pelo usuário que é exigida para a visualização das notas no iOS, OS X e no site do iCloud.

Quando um usuário utiliza uma nota segura, uma chave de 16 bytes é derivada da senha do usuário por meio de PBKDF2 e SHA256. Os conteúdos da nota são criptogra-fados por meio de AES-GCM. Novos registros são criados no Core Data e no CloudKit para armazenar a nota criptografada, a etiqueta e o vetor de inicialização, e os registros originais da nota são apagados. Os dados criptografados não são sobrescritos. Anexos também são criptografados da mesma maneira. São anexos compatíveis: imagens, desenhos, mapas e sites. Notas que contém outros tipos de anexos não podem ser criptografadas e anexos incompatíveis não podem ser adicionados a notas seguras.

Quando um usuário digita corretamente a senha, tanto para visualizar ou criar uma nota segura, o aplicativo Notas abre uma sessão segura. Enquanto o aplicativo estiver aberto, o usuário não precisará digitar a senha ou usar o Touch ID para visualizar ou assegurar outras notas. Contudo, se algumas notas tiverem uma senha diferente, a ses-são segura aplica-se somente às notas protegidas com a senha atual. A sessão segura será encerrada quando o usuário tocar no botão Bloquear Agora no Notas, quando o Notas ficar em segundo plano por mais de três minutos ou quando o dispositivo for bloqueado.

Usuários que esquecerem a senha ainda poderão visualizar as notas seguras ou asse-gurar notas adicionais se tiverem ativado o Touch ID nos dispositivos. Além disso, o Notas mostrará uma dica fornecida pelo usuário após três tentativas incorretas de digi-tar a senha. O usuário terá que saber a senha atual para alterá-la.

Usuários podem redefinir a senha caso esqueçam a atual. Esse recurso permite que usuários criem novas notas seguras com uma nova senha, mas não permitirá que eles vejam notas asseguradas anteriormente. As notas asseguradas anteriormente ainda poderão ser visualizadas se a senha antiga for lembrada. A redefinição da senha requer a senha da conta do iCloud do usuário.

Apple WatchO Apple Watch usa os recursos e a tecnologia de segurança feitos para o iOS para ajudar a proteger os dados do dispositivo, assim como as comunicações com o iPhone com o qual está emparelhado e com a Internet. Isso inclui tecnologias como a Proteção de Dados e o controle de acesso às chaves. O código do usuário também é trançado ao UID do dispositivo para criar chaves de criptografia.

A segurança do emparelhamento do Apple Watch com o iPhone é feita usando-se um processo fora de banda (OOB) para trocar chaves públicas, seguido pelo segredo compartilhado do link BTLE. O Apple Watch exibe um padrão animado, capturado pela câmera do iPhone. Este padrão contém um segredo codificado usado pelo empare-lhamento fora de banda BTLE 4.1. O padrão de emparelhamento BTLE Passkey Entry é usado como método alternativo, se necessário.


Com a sessão BTLE estabelecida, o Apple Watch e o iPhone trocam chaves usando um processo adaptado do IDS, como descrito na seção iMessage deste documento. Quando as chaves forem trocadas, a chave da sessão Bluetooth é descartada e todas as comunicações entre o Apple Watch e o iPhone são criptografadas usando DS, com os links BTLE e Wi-Fi fornecendo uma camada de criptografia secundária. A rotatividade de chaves é utilizada com intervalos de 15 minutos para limitar a janela de exposição, caso o tráfego seja comprometido.

Para oferecer suporte aos aplicativos que necessitam de dados de transmissão, a crip-tografia é fornecida usando os métodos descritos na seção FaceTime deste documento, usando o serviço IDS oferecido pelo iPhone emparelhado.

O Apple Watch implementa o armazenamento criptografado por hardware e a pro-teção de arquivos e itens de chaves com base em classes, como descrito na seção “Proteção de Dados” deste documento. Para o acesso de itens das chaves, bolsas de chaves controladas também são usadas. As chaves usadas para a comunicação entre o relógio e o iPhone também são mantidas em segurança através do uso de proteção com base em classes.

Quando o Apple Watch não estiver dentro do alcance do Bluetooth, o Wi-Fi pode ser usado. O Apple Watch não se conectará a redes de Wi-Fi, a menos que existam creden-ciais para isso no iPhone emparelhado, fornecendo automaticamente a lista de redes conhecidas ao relógio.

O Apple Watch pode ser bloqueado manualmente pressionando o botão lateral. Além disso, a heurística do movimento é usada para tentar bloquear o dispositivo automa-ticamente assim que ele for removido do braço. Quando bloqueado, o Apple Pay não pode ser usado. Se o bloqueio automático fornecido pela detecção de braço estiver desativado nos ajustes, o Apple Pay será desativado. A detecção de braço pode ser desativada através do aplicativo Apple Watch do iPhone. Esse ajuste também pode ser aplicado através do gerenciamento de dispositivos móveis.

O iPhone emparelhado também pode desbloquear o relógio, desde que o relógio este-ja sendo usado. Isso é realizado ao estabelecer uma conexão autenticada pelas chaves reconhecidas durante o emparelhamento. O iPhone envia a chave, a qual é usada pelo relógio para desbloquear as suas chaves de Proteção de Dados. O código do relógio não é de conhecimento do iPhone e não é transmitido. Esse recurso pode ser desativa-do através do aplicativo Apple Watch do iPhone.

O Apple Watch pode ser emparelhado apenas com um iPhone por vez. O emparelha-mento do Apple Watch com um novo iPhone apaga todos os dados e conteúdo do Apple Watch automaticamente

A ativação do Buscar iPhone no iPhone emparelhado também ativa o Bloqueio de Ativação do Apple Watch. O Bloqueio de Ativação dificulta o uso ou venda de um Apple Watch perdido ou roubado. O Bloqueio de Ativação requer o ID Apple e a senha do usuário para desemparelhar, apagar ou reativar o Apple Watch.


Além da segurança integrada que a Apple usa para proteger os dados armazenados em dispositivos iOS, há várias medidas de segurança de rede que podem ser tomadas por empresas para manter a segurança durante a transferência de dados a partir de um dispositivo iOS.

Usuários de dispositivos celulares precisam acessar redes corporativas de qualquer lugar do mundo. A garantia da autorização e da proteção de seus dados durante a transmissão é muito importante. O iOS usa protocolos de rede padrão (e os fornece a desenvolvedores) para comunicações autenticadas, autorizadas e criptografadas. Para que esses objetivos de segurança sejam alcançados, o iOS integra tecnologias compro-vadas e os padrões mais recentes de conexões de rede Wi-Fi e de dados celulares.

Em outras plataformas, um software de firewall se faz necessário para proteger as por-tas de comunicação abertas contra invasões. Por limitar as portas de escuta e remover utilitários de rede desnecessários (como telnet, shells ou servidor web), reduzindo assim a área de ataque, dispositivos iOS não precisam de nenhum firewall adicional.

TLSO iOS oferece suporte ao Transport Layer Security (TLS v1.0, TLS v1.1, TLS v1.2) e DTLS. O Safari, Calendário, Mail e outros aplicativos de Internet usam esses mecanismos automaticamente para ativar um canal de comunicação criptografado entre o disposi-tivo e os serviços de rede. As APIs de alto nível (como CFNetwork) facilitam a adoção do TLS por desenvolvedores em seus aplicativos, enquanto as APIs de baixo nível (SecureTransport) fornecem um controle mais detalhados. Por padrão, o CFNetwork não permite SSLv3 e os aplicativos que usam WebKit (como o Safari) são proibidos de fazer uma conexão SSLv3.

Segurança de Transporte em AplicativosA Segurança de Transporte em Aplicativos fornece requisitos de conexão padrão para que os aplicativos possam seguir as melhores práticas de conexão segura ao usar as APIs NSURLConnection, CFURL ou NSURLSession.

Servidores precisam oferecer suporte a, no mínimo, TLS 1.2 forward secrecy e os certi-ficados precisam ser válidos e assinados com SHA-256 ou posterior com, no mínimo, uma chave RSA de 2048 bits ou chave de curva elíptica de 256 bits.

As conexões de rede que não atendam a esses requisitos falharão, a não ser que o apli-cativo substitua a Segurança de Transporte em Aplicativos. Certificados inválidos sem-pre resultarão em falha e falta de conexão. A Segurança de Transporte em Aplicativos é aplicada automaticamente a aplicativos compilados para iOS 9.

Segurança de Rede


VPNOs serviços de rede segura, como redes privadas virtuais, normalmente requerem configurações e ajustes mínimos para funcionar com dispositivos iOS. Os dispositivos iOS funcionam com servidores VPN que oferecem suporte aos seguintes protocolos e métodos de autenticação:

• IKEv2/IPSec com autenticação por segredo compartilhado, Certificados RSA, Certificados ECDSA, EAP-MSCHAPv2 ou EAP-TLS;

• Pulse Secure, Cisco, Aruba Networks, SonicWALL, Check Point, Palo Alto Networks, Open VPN, AirWatch, MobileIron, NetMotion Wireless e F5 Networks SSL-VPN usando o aplicativo cliente apropriado App Store;

• Cisco IPSec com autenticação do usuário por Senha, RSA SecurID ou CRYPTOCard e autenticação por máquina por segredo compartilhado e certificados;

• L2TP/IPSec com autenticação do usuário por Senha MS-CHAPV2, RSA SecurID ou CRYPTOCard e autenticação por máquina por segredo compartilhado;

• Há suporte, embora não seja recomendado, a PPTP com autenticação do usuário por Senha MS-CHAPV2 e RSA SecurID ou CRYPTOCard.

O iOS oferece suporte a VPN por Demanda em redes que usam autenticação baseada em certificado. As políticas de TI especificam, através de um perfil de configuração, quais domínios requerem conexão VPN.

O iOS também oferece suporte a VPN por Aplicativo, facilitando conexões VPN de forma muito mais granular. O gerenciamento de dispositivos móveis (MDM) pode especificar uma conexão para cada aplicativo gerenciado e/ou domínios específicos do Safari. Isso ajuda a garantir que os dados seguros sempre transitem pela rede corpora-tiva, mas não os dados pessoais de usuários.

O iOS oferece suporte a VPN Sempre Ativa, o que pode ser configurado em dispositi-vos gerenciados através de MDM e supervisionado usando o Apple Configurator ou o Programa de Registro de Dispositivos. Isso elimina a necessidade de ativação da VPN pelos usuários para ativar a proteção ao se conectarem a redes Wi-Fi ou celulares. A VPN Sempre Ativa proporciona a empresas o controle total do tráfego do dispositivo, encapsulando todo o tráfego IP através das mesmas. O protocolo de encapsulamento padrão, IKEv2, protege o tráfego através da criptografia dos dados. As empresas podem monitorar e filtrar o tráfego de seus dispositivos, proteger os dados de suas redes e restringir o acesso de dispositivos à Internet.

Wi-Fi O iOS oferece suporte aos protocolos de Wi-Fi padrões do setor, incluindo WPA2 Empresarial, para fornecer acesso autenticado a redes corporativas sem fio. O WPA2 Empresarial usa criptografia AES de 128 bits, proporcionando aos usuários o maior nível de segurança de dados, que permanecem protegidos durante o envio e recebimento de comunicações em conexões de rede Wi-Fi. Com suporte a 802.1X, os dispositivos iOS podem ser integrados a uma grande variedade de ambientes de autenticação RADIUS. Os métodos de autenticação sem fio 802.1X compatíveis com o iPhone e o iPad incluem EAP-TLS, EAP-TTLS, EAP-FAST, EAP-SIM, PEAPv0, PEAPv1 e LEAP.

O iOS usa um endereço de Media Access Control (MAC) aleatório ao realizar um esca-neamento do tipo Preferred Network Offload (PNO) quando um dispositivo não está associado a uma rede Wi-Fi e o seu processador está em repouso. O processador de um dispositivo entra em repouso pouco depois que a tela é desligada. Os escanea-mentos PNO são executados para determinar se um usuário pode se conectar a uma rede Wi-Fi preferida para realizar atividades como a sincronização via conexão sem fio com o iTunes.


O iOS também usa um endereço MAC aleatório ao realizar escaneamentos PNO apri-morados (ePNO) quando um dispositivo não está associado a uma rede Wi-Fi ou o seu processador está em repouso. Os escaneamentos ePNO são executados quando um dispositivo usa Serviços de Localização para aplicativos que usam cercas virtuais, como lembretes baseados em localização, que determinam se o dispositivo está próximo a uma localização específica.

Como o endereço MAC de um dispositivo é alterado quando ele não está conectado a uma rede Wi-Fi, os observadores passivos de tráfego Wi-Fi não podem usá-lo para rastrear o dispositivo continuamente, mesmo quando ele está conectado a uma rede de dados celulares.

Avisamos aos fabricantes de Wi-Fi que os escaneamentos em segundo plano usam endereços MAC aleatórios e que nem eles e nem a Apple podem prevê-los.

Não há suporte para a aleatorização de endereços MAC via Wi-Fi no iPhone 4s.

BluetoothO suporte a Bluetooth do iOS foi projetado para fornecer funcionalidades que sejam úteis, mas sem aumentar desnecessariamente o acesso a dados privados. Dispositivos iOS oferecem suporte a conexões com Modo de Criptografia 3, Modo de Segurança 4 e Nível de Serviço 1. O iOS oferece suporte aos seguintes perfis de Bluetooth:

• Perfil de Handsfree (HFP 1.5);

• Perfil de Acesso à Agenda (PBAP);

• Perfil de Distribuição de Áudio Avançada (A2DP);

• Perfil de Controle Remoto de Áudio/Vídeo (AVRCP);

• Perfil de Rede de Área Pessoal (PAN);

• Perfil de Dispositivo de Interface Humana (HID).

O suporte a estes perfis varia de acordo com o dispositivo. Para obter mais informa-ções, consulte https://support.apple.com/pt-br/HT3647.

Início de Sessão ÚnicoO iOS oferece suporte à autenticação em redes empresariais através do Início de Sessão Único (SSO). O SSO trabalha com redes baseadas em Kerberos para autenticar usuários nos serviços em que são autorizados a acessar. O SSO pode ser usado em uma série de atividades de rede, de sessões seguras do Safari até aplicativos de terceiros.

O SSO do iOS utiliza tokens SPNEGO e protocolo HTTP Negotiate para funcionar com gateways de autenticação baseados em Kerberos e sistemas de Autenticação Integrada do Windows que oferecem suporte a tíquetes do Kerberos. Também há suporte para à autenticação baseada em certificados. O suporte ao SSO é baseado no projeto Heimdal de código aberto.

Há suporte para os seguintes tipos de criptografia:

• AES128-CTS-HMAC-SHA1-96;

• AES256-CTS-HMAC-SHA1-96;

• DES3-CBC-SHA1;

• ARCFOUR-HMAC-MD5.

O Safari oferece suporte ao SSO e os aplicativos de terceiros que usam APIs de rede padrão do iOS também podem ser configurados para usá-lo. Para configurar o SSO, o iOS oferece suporte ao payload de um perfil de configuração que permite que servi-



dores MDM acionem os ajustes necessários. Isso inclui a definição do nome principal do usuário (ou seja, a conta do usuário no Active Directory) e os ajustes do domínio Kerberos, assim como a definição de quais aplicativos e/ou URLs do Safari devem ter permissão para usar o SSO.

Segurança AirDropOs dispositivos que oferecem suporte ao AirDrop usam tecnologia Bluetooth Low Energy (BLE) e tecnologia Wi-Fi peer-to-peer criada pela Apple para enviar arquivos e informações para dispositivos próximos, incluindo computadores Mac compatíveis com AirDrop com OS X Yosemite ou posterior. O sinal de rádio Wi-Fi é usado para comunicação direta entre os dispositivos, sem necessidade de conexão à Internet ou ponto de acesso Wi-Fi.

Quando um usuário ativa o AirDrop, uma identidade RSA de 2048 bits é armazenada no dispositivo. Além disso, é criado um hash de identificação com base nos endereços de e-mail e números de telefone associados ao ID Apple do usuário.

Quando um usuário escolhe o AirDrop como método de compartilhamento de um item, o dispositivo emite um sinal AirDrop através de Bluetooth Low Energy. Outros dispositivos próximos que não estejam em repouso e tenham o AirDrop ativado detectam o sinal e respondem com uma versão reduzida do hash de identificação do proprietário.

O AirDrop é configurado com a opção de compartilhamento Apenas Contatos por padrão. Os usuários também podem escolher se desejam usar o AirDrop para compar-tilhar com Todos ou desativar o recurso completamente. No modo Apenas Contatos, os hashes de identificação recebidos são comparados aos hashes das pessoas incluídas no aplicativo Contatos do iniciador. Se uma correspondência for encontrada, o disposi-tivo remetente cria uma rede Wi-Fi peer-to-peer e anuncia uma conexão AirDrop usan-do o Bonjour. Através dessa conexão, os dispositivos receptores enviam seus hashes de identificação completos para o iniciador. Se o hash completo ainda corresponder no aplicativo Contatos, o nome e a foto do receptor (se existente nos Contatos) são exibi-dos na folha de compartilhamento do AirDrop.

Ao usar o AirDrop, o usuário remetente seleciona com quem o compartilhamento será feito. O dispositivo remetente inicia uma conexão criptografada (TLS) com o disposi-tivo receptor, que troca seus certificados de identidade do iCloud. A identidade nos certificados é comparada com o aplicativo Contatos de cada usuário para verificá-la. Depois, o usuário receptor é solicitado a aceitar a transferência da pessoa ou disposi-tivo identificado. Se vários destinatários forem selecionados, este processo é repetido para cada um deles.

O mesmo processo é usado no modo Todos, mas se uma correspondência não for encontrada nos Contatos, os dispositivos receptores são exibidos na folha de envio do AirDrop com uma silhueta e o nome do dispositivo, como definido em Ajustes > Geral > Sobre > Nome.

Empresas podem restringir o uso do AirDrop para dispositivos e aplicativos controla-dos por uma solução de gerenciamento de dispositivos móveis.


Apple Pay

Com o Apple Pay, os usuários podem usar dispositivos iOS compatíveis e o Apple Watch para fazer pagamentos de maneira fácil, segura e privada. É uma solução simples para os usuários e construída com segurança integrada, tanto no hardware como no software.

O Apple Pay também foi projetado para proteger as informações pessoais do usuário. O Apple Pay não coleta nenhuma informação de transação que possa ser atrelada ao usuário. As transações de pagamentos ocorrem entre o usuário, o comerciante e a administradora do cartão.

Componentes do Apple PayElemento Seguro: o Elemento Seguro é um chip certificado, padrão do setor, execu-tado em Java Card, uma plataforma que cumpre os requisitos do setor financeiro para pagamentos eletrônicos.

Controlador NFC: o controlador NFC gerencia os protocolos do tipo “Near Field Communication” e encaminha a comunicação entre o processador do aplicativo e o Elemento Seguro e entre o Elemento Seguro e o terminal de vendas.

Wallet: a Wallet é usada para adicionar e gerenciar cartões de crédito, débito, fidelidade e cartões de lojas, além de fazer pagamentos com o Apple Pay. Na Wallet, os usuários podem visualizar seus cartões, informações adicionais sobre a operadora do cartão, política de privacidade da administradora, etc. Os usuários também podem adicionar cartões ao Apple Pay no Assistente de Configuração e nos Ajustes.

Enclave Seguro: o Enclave Seguro gerencia o processo de autenticação e permite o prosseguimento de transações de pagamento. Ele armazena os dados de impressão digital para o Touch ID.

No Apple Watch, o dispositivo deve estar desbloqueado e o usuário precisa clicar duas vezes no botão lateral. O clique duplo é detectado e encaminhado diretamente ao Enclave Seguro, sem passar pelo processador do aplicativo.

Servidores do Apple Pay: os servidores do Apple Pay gerenciam o estado de cartões de crédito e débito na Wallet e os Números de Conta do Dispositivo armazenados no Elemento Seguro. Eles se comunicam com o dispositivo e com os servidores da rede de pagamento. Os Servidores do Apple Pay também são responsáveis por criptografar novamente as credenciais de pagamento para pagamentos dentro de aplicativos.

Como o Apple Pay usa o Elemento SeguroO Elemento Seguro hospeda um applet feito especificamente para gerenciar o Apple Pay. Isso também inclui applets de pagamento certificados pelas redes de paga-mento. Os dados de cartões de crédito ou débito são criptografados e enviados pela rede de pagamento ou administradora do cartão aos applets de pagamento usando chaves que são de conhecimento apenas da rede de pagamento e do domínio de segurança dos applets. Esses dados são armazenados nos applets de pagamento e pro-tegidos com os recursos de segurança do Elemento Seguro. Durante uma transação, o terminal se comunica diretamente com o Elemento Seguro através do controlador Near Field Communication (NFC) em um barramento dedicado.


Como o Apple Pay usa o controlador NFC Como gateway do Elemento Seguro, o controlador NFC garante que todos os paga-mentos por proximidade sejam conduzidos através de um terminal de vendas próximo ao dispositivo. Apenas solicitações de pagamento provenientes de um terminal dentro do alcance são marcadas pelo controlador NFC como transações por proximidade.

Quando o pagamento é autorizado pelo titular do cartão com o Touch ID, código ou através de dois cliques no botão lateral de um Apple Watch desbloqueado, as res-postas de proximidade preparadas pelos applets de pagamento dentro do Elemento Seguro são encaminhadas exclusivamente pelo controlador para o campo NFC. Consequentemente, os detalhes de autorizações de pagamento de transações por pro-ximidade ficam contidos no campo NFC local e nunca são expostos ao processador do aplicativo. Por outro lado, os detalhes de autorizações de pagamento dentro de aplicati-vos são encaminhados ao processador do aplicativo, mas apenas depois de criptografa-dos pelo Elemento Seguro no Servidor do Apple Pay.

Provisão de cartões de crédito e débito Quando um usuário adiciona um cartão de crédito ou débito (incluindo cartões de lojas) ao Apple Pay, a Apple envia as informações do cartão com segurança, juntamente a outras informações sobre a conta e o dispositivo do usuário, à administradora do car-tão. Usando essas informações, a operadora determinará se o cartão será adicionado ao Apple Pay.

O Apple Pay usa três ligações do lado do servidor para enviar e receber comunicações com a administradora do cartão ou a rede, como parte do processo de provisão do car-tão: Campos Obrigatórios, Verificação do Cartão e Vínculo e Provisão. A operadora do car-tão ou a rede usa essas ligações para verificar, aprovar e adicionar cartões ao Apple Pay. Essas sessões cliente-servidor são criptografadas usando SSL.

Os números completos do cartão não são armazenados no dispositivo ou nos servi-dores da Apple. Ao invés disso, um Número de Conta do Dispositivo é criado, cripto-grafado e armazenado no Elemento Seguro. Esse Número de Conta do Dispositivo é criptografado de tal maneira que a Apple não consegue acessá-lo. O Número de Conta do Dispositivo é exclusivo e diferente dos números usuais de cartões de crédito e débito. A administradora do cartão pode impedir o seu uso em um cartão de tarja magnética, através do telefone ou em sites. O Número de Conta do Dispositivo no Elemento Seguro é isolado do iOS e do WatchOS, nunca é armazenado nos Servidores do Apple Pay e um backup nunca é feito no iCloud.

Os cartões para uso com o Apple Watch são fornecidos ao Apple Pay através do uso do aplicativo Apple Watch no iPhone. A provisão de um cartão para o Apple Watch exige que o relógio esteja dentro da área de comunicação do Bluetooth. Os cartões são regis-trados especificamente para uso com o Apple Watch e possuem um Número de Conta do Dispositivo próprio, armazenado no Elemento Seguro do Apple Watch.

Há três maneiras inserir um cartão de crédito ou débito no Apple Pay:

• Adicionando um cartão de crédito ou débito ao Apple Pay manualmente;

• Adicionando cartões de crédito ou débito já registrados em uma conta da iTunes Store ao Apple Pay;

• Adicionando cartões de crédito ou débito em um aplicativo de administradora de cartões.


Adição manual de um cartão de crédito ou débito ao Apple PayPara adicionar um cartão manualmente (incluindo cartões de lojas), o nome, número, data de validade e CVC do cartão de crédito são usados para facilitar o processo de provisão. Essas informações podem ser digitadas pelos usuários ou capturadas pela câmera iSight nos aplicativos Ajustes, Wallet ou Apple Watch. Quando a câmera captu-ra as informações do cartão, a Apple tenta preencher o nome, número e data de vali-dade do cartão. A foto nunca é salva no dispositivo ou armazenada na fototeca. Uma vez que todos os campos estejam preenchidos, o processo de Verificação do Cartão confirma todos os campos, exceto o CVC. As informações são criptografadas e enviadas ao Servidor do Apple Pay.

Se um ID de termos e condições for retornado junto ao processo de Verificação do Cartão, a Apple transfere e exibe os termos e condições da administradora do cartão para o usuário. Caso o usuário aceite os termos e condições, a Apple envia o ID dos termos aceitos, assim como o CVC, para o processo de Vínculo e Provisão. Além disso, como parte do processo de Vínculo e Provisão, a Apple compartilha informações do dispositivo com a administradora ou rede do cartão, como informações sobre a ativi-dade da sua conta da iTunes Store e da App Store (se você tem um histórico longo de transações no iTunes, por exemplo), informações sobre o seu dispositivo (número de telefone, nome e modelo do dispositivo), além de qualquer dispositivo iOS comple-mentar necessário para usar o Apple Pay) e sua localização aproximada no momento em que o cartão é adicionado (se os Serviços de Localização estiverem ativados). Através do uso dessas informações, a administradora do cartão determinará se o cartão será aprovado para uso no Apple Pay.

Dois fatores decorrem do processo de Vínculo e Provisão:

• O dispositivo inicia a transferência do tíquete da Wallet que representa o cartão de crédito ou débito;

• O dispositivo inicia o vínculo do cartão com o Elemento Seguro.

O tíquete contém URLs para transferir a imagem ilustrativa do cartão e metadados sobre o cartão (como informações de contato, aplicativo relacionado da administradora e recursos compatíveis). Ele também contém o estado do tíquete, que inclui informa-ções sobre a conclusão da personalização do Elemento Seguro, a suspensão vigente do cartão pela administradora ou exigências de verificações adicionais para que o cartão possa fazer pagamentos com o Apple Pay.

Adição de cartões de crédito ou débito de uma conta da iTunes Store ao Apple PayNo caso de cartões de crédito ou débito já registrado no iTunes, o usuário pode ser solicitado a digitar seu ID Apple novamente. O número do cartão é obtido do iTunes e o processo de Verificação do Cartão é iniciado. Se o cartão for elegível para o Apple Pay, o dispositivo irá transferir e exibir os termos e condições para depois enviar o ID dos ter-mos e o código de segurança do cartão para o processo de Vínculo e Provisão. Cartões já registrados em contas do iTunes poderão estar sujeitos a verificações adicionais.

Adição de cartões de crédito ou débito em um aplicativo de administra-dora de cartõesQuando o aplicativo está registrado para uso com o Apple Pay, chaves são estabeleci-das para o aplicativo e o servidor do comerciante. Essas chaves são usadas para cripto-grafar as informações do cartão enviadas ao comerciante, impedindo sua leitura pelo dispositivo iOS. O fluxo de provisão assemelha-se ao usado para cartões adicionados manualmente (descrito acima), exceto pelo fato de que senhas de uso único são usa-das ao invés do CVC.


Verificação adicional A administradora do cartão pode decidir se um cartão de crédito ou débito requer verificação adicional. Dependendo do que for oferecido pela administradora, talvez o usuário possa escolher entre diversas opções de verificação adicional, como mensagem de texto, e-mail, ligação do serviço ao cliente ou um método em um aplicativo de terceiros aprovado para completar a verificação. No caso de mensagens de texto ou e-mail, o usuário seleciona dentre as informações de contato registradas na administra-dora. Um código será enviado para que o usuário o digite no aplicativo Wallet, Ajustes ou Apple Watch. No caso de serviço ao cliente ou verificação através de um aplicativo, a administradora realiza um processo de comunicação próprio.

Autorização de pagamento O Elemento Seguro permitirá que um pagamento seja feito somente após receber autorização do Enclave Seguro, confirmando a autenticação do usuário com o Touch ID ou o código do dispositivo. Caso disponível, o Touch ID é o método padrão, mas o código pode ser usado no lugar do Touch ID a qualquer momento. Um código é ofe-recido automaticamente após três tentativas malsucedidas de identificação de uma impressão digital e exigido após cinco tentativas malsucedidas. Um código também é exigido quando o Touch ID não está configurado ou ativado para o Apple Pay.

A comunicação entre o Enclave Seguro e o Elemento Seguro ocorre através de uma interface serial, com o Elemento Seguro conectado ao controlador NFC, que por sua vez encontra-se conectado ao processador do aplicativo. Embora não estejam conec-tados diretamente, o Enclave Seguro e o Elemento Seguro podem comunicar-se em segurança usando uma chave de emparelhamento compartilhada, fornecida durante o processo de fabricação. A criptografia e a autenticação da comunicação são baseadas em AES, com nonces criptográficos usados em ambos os lados para proteção contra ataques de reprodução. A chave de emparelhamento é gerada dentro do Enclave Seguro a partir de sua chave UID e do identificador exclusivo do Elemento Seguro. A chave de emparelhamento é então transferida seguramente do Enclave Seguro para um módulo de segurança de hardware (HSM) na fábrica, que possui o material da chave necessário para injetar a chave de emparelhamento no Elemento Seguro.

Quando o usuário autoriza a transação, o Enclave seguro envia os dados sobre o tipo de autenticação e os detalhes sobre o tipo de transação (proximidade ou dentro de aplicativos) para o Elemento Seguro, atrelado a um valor de Autorização Randômica (AR). O AR é gerado no Enclave Seguro na primeira vez que o usuário fornece um car-tão de crédito e persevera enquanto o Apple Pay estiver ativado, protegido pela crip-tografia do Enclave Seguro e pelo mecanismo de antidesmantelamento. Ele é entregue com segurança ao Elemento Seguro através da chave de emparelhamento. Ao receber um novo valor AR, o Elemento Seguro marca qualquer cartão adicionado anteriormen-te como apagado.

Cartões de crédito e débito adicionados ao Elemento Seguro podem ser usados somente se uma autorização que use a mesma chave de emparelhamento e valor AR de quando o cartão foi adicionado for apresentada ao Elemento Seguro. Isso permite que o iOS instrua o Enclave Seguro a inutilizar os cartões, marcando suas cópias do AR como inválidas nos seguintes casos:

Quando o código é desativado.

• O usuário finaliza a sessão no iCloud;

• O usuário seleciona “Apagar Conteúdo e Ajustes”;

• O dispositivo é restaurado a partir do modo de recuperação.

No Apple Watch, cartões são marcados como inválidos quando:

• O código do relógio é desativado;


• O relógio é desemparelhado do iPhone;

• A detecção de braço é desativada.

Usando a chave de emparelhamento e sua cópia do valor AR atual, o Elemento Seguro verifica a autorização recebida do Enclave Seguro antes de ativar o applet de pagamen-to por proximidade. Esse processo também é aplicado ao receber dados de pagamento criptografados de um applet de pagamento em transações dentro de aplicativos.

Código de segurança dinâmico específico à transação Todas as transações de pagamento originadas de applets de pagamento incluem um código de segurança dinâmico específico à transação juntamente a um Número de Conta do Dispositivo. Esse código de uso único é calculado através do uso de um contador que aumenta a cada nova transação e de uma chave fornecida no applet de pagamento durante a personalização, sendo reconhecido pela rede de pagamentos e/ou administradora do cartão. Dependendo do esquema de pagamento, outros dados também podem ser usados no cálculo desses códigos, incluindo o seguinte:

• Um número aleatório gerado pelo applet de pagamento;

• Outro número aleatório gerado pelo terminal — no caso de transações NFC;

ou

• Outro número aleatório gerado pelo servidor — no caso de transações dentro de aplicativos.

Esses códigos de segurança são fornecidos à rede de pagamentos e à administradora do cartão, o que lhes permite verificar cada transação. O tamanho desses códigos de segurança pode variar conforme o tipo de transação sendo feita.

Pagamentos por proximidade com o Apple PaySe o iPhone estiver ligado e detectar um campo NFC, ele apresentará o cartão de crédito ou débito relevante ou o cartão padrão (gerenciado em Ajustes) ao usuário. O usuário também pode acessar o aplicativo Wallet e escolher um cartão de crédito ou débito ou clicar duas vezes no botão Início quando o dispositivo estiver bloqueado.

A seguir, o usuário precisa autenticar com o Touch ID ou o código antes que as infor-mações de pagamento sejam transmitidas. Quando o Apple Watch está desbloque-ado, o cartão de pagamento padrão é ativado ao clicar duas vezes no botão lateral. Nenhuma informação de pagamento é enviada sem a autenticação do usuário.

Depois que o usuário autentica, o Número de Conta do Dispositivo e um código de segurança dinâmico específico à transação são usados ao processar o pagamento. A Apple e o dispositivo do usuário não enviam os números completos do cartão de cré-dito ou débito para os comerciantes. A Apple pode receber informações anônimas da transação, como a hora e o local aproximado da transação, o que ajuda a melhorar o Apple Pay e outros produtos e serviços da Apple.

Pagamento dentro de aplicativos com o Apple PayO Apple Pay também pode ser usado para fazer pagamentos dentro de aplicativos iOS. Quando usuários pagam com o Apple Pay em aplicativos, a Apple recebe as informa-ções da transação criptografadas e as criptografa novamente com uma chave específi-ca do comerciante antes de enviá-las ao comerciante. O Apple Pay retém informações anônimas da transação, como a quantidade aproximada da compra. Essas informações não podem ser atreladas ao usuário e nunca incluem o que o usuário compra.


Quando um aplicativo inicia uma transação de pagamento do Apple Pay, os Servidores do Apple Pay recebem a transação criptografada do dispositivo antes que o comer-ciante a receba. Os Servidores do Apple Pay criptografam novamente a transação com uma chave específica do comerciante antes de repassá-la ao comerciante.

Quando um aplicativo solicita um pagamento, ele invoca uma API para determinar se o serviço é compatível com o Apple Pay e se o usuário tem cartões de crédito ou débito que possam fazer pagamentos em uma rede de pagamentos aceita pelo comerciante. O Aplicativo solicita qualquer informação necessária para processar e executar a transa-ção, como o endereço de cobrança e entrega e informações de contato. Depois, o apli-cativo pede para que o iOS apresente a folha do Apple Pay, que solicita informações para o aplicativo, assim como outras informações necessárias, como qual cartão usar.

Nesse momento, informações sobre a cidade, estado e CEP são apresentadas ao apli-cativo para o cálculo do custo de entrega final. O conjunto completo de informações solicitadas não é fornecido ao aplicativo até que o usuário autorize o pagamento com o Touch ID ou o código do dispositivo. Depois que o pagamento for autorizado, as informações apresentadas na folha do Apple Pay serão transferidas ao comerciante.

Quando o usuário autoriza o pagamento, uma ligação é feita para os Servidores do Apple Pay, para que um nonce criptográfico (que se assemelha ao valor retornado por terminais NFC usados em transações em lojas) seja obtido. O nonce, juntamente a outros dados da transação, é passado ao Elemento Seguro para gerar uma credencial de pagamento que será criptografada com uma chave da Apple. Quando a credencial de pagamento criptografada sai do Elemento Seguro, ela é passada para os Servidores do Apple Pay, que decriptografam a credencial, comparam o nonce da credencial como aquele enviado pelo Elemento Seguro e criptografam a credencial de pagamen-to novamente com a chave do comerciante associada ao ID do Comerciante. Depois, ela é reenviada ao dispositivo, que a redireciona ao aplicativo através da API. O apli-cativo então a envia ao sistema do comerciante para processamento. O comerciante pode então decriptografar a credencial de pagamento usando sua chave privada para processamento. Isso, juntamente à assinatura dos servidores da Apple, permite que o comerciante verifique que a transação se destina especificamente a esse comerciante.

As APIs requerem um direito que especifique os IDs de comerciante compatíveis. Um aplicativo também pode incluir dados adicionais para enviar ao Elemento Seguro para assinatura, como o número do pedido ou identidade do cliente, garantindo que a transação não possa ser desviada para outro cliente. Isso é realizado pelo desenvolve-dor do aplicativo. O desenvolvedor do aplicativo pode especificar applicationData no PKPaymentRequest. Um hash desses dados é incluído nos dados de pagamento cripto-grafados. O comerciante é então responsável por verificar se o hash de seu application-Data corresponde àquele incluído nos dados de pagamento.


Cartões de fidelidadeDesde o iOS 9, o Apple Pay oferece suporte ao protocolo VAS (Value Added Service) para a transmissão de cartões de fidelidade de comerciantes para terminais NFC com-patíveis. O protocolo VAS pode ser implementado em terminais de comerciantes e usa NFC para se comunicar com dispositivos Apple compatíveis. O protocolo VAS funciona sobre distâncias curtas e é usado para fornecer serviços complementares, como a transmissão de informações de cartões de fidelidade, como parte de uma transação do Apple Pay.

O terminal NFC inicia o recebimento das informações do cartão através do envio de uma solicitação de um cartão. Se o usuário tiver um cartão com a identidade da loja, ele é solicitado a autorizar seu uso. Se o comerciante oferecer criptografia, as infor-mações do cartão, uma marca temporal e uma chave ECDH P-256 de uso único são usadas com a chave pública do comerciante para derivar uma chave de criptografia para os dados do cartão, que são enviados ao terminal. Se o comerciante não oferecer criptografia, o usuário é solicitado a reapresentar o dispositivo ao terminal antes que as informações do cartão de fidelidade sejam enviadas.

Suspensão, remoção e apagamento de cartõesOs usuários podem usar o Buscar iPhone para colocar seus dispositivos no Modo Perdido e suspender o Apple Pay no iPhone e iPad. Os usuários também podem usar o Buscar iPhone, Ajustes do iCloud ou o aplicativo Wallet (diretamente no dispositivo), para remover e apagar seus cartões do Apple Pay. No Apple Watch, os cartões podem ser removidos por meio dos ajustes do iCloud, do aplicativo Apple Watch no iPhone ou diretamente no relógio. A capacidade de fazer pagamentos usando cartões no dispositivo será suspensa ou removida do Apple Pay pela administradora do cartão ou rede de pagamentos correspondente mesmo que o dispositivo esteja off-line e desconectado de uma rede celular ou Wi-Fi. Os usuários também podem ligar para a administradora do cartão para suspender ou remover cartões do Apple Pay.

Além disso, quando um usuário usa a opção “Apagar Conteúdo e Ajustes”, o aplicativo Buscar iPhone ou a restauração do dispositivo usando o modo de recuperação para apagar todo o dispositivo, o iOS instruirá o Elemento Seguro a marcar todos os cartões como apagados. Isso faz com que os cartões sejam alterados imediatamente para um estado não utilizável até que os Servidores do Apple Pay possam ser contatados para apagar os cartões do Elemento Seguro completamente. Independentemente, o Enclave Seguro marca o AR como inválido, para que autorizações de pagamento posteriores com cartões já inscritos não sejam possíveis. Quando o dispositivo estiver on-line, ele tentará contatar os Servidores do Apple Pay para garantir que todos os car-tões no Elemento Seguro sejam apagados.


Criação de senhas fortes para o ID AppleIDs Apple são usados para a conexão a diver-sos serviços, incluindo o iCloud, FaceTime e iMessage. Para ajudar os usuários a criarem senhas fortes, todas as contas novas devem conter os seguintes atributos de senha:

• Ao menos oito caracteres;

• Ao menos uma letra;

• Ao menos uma letra maiúscula;

• Ao menos um número;

• Não mais do que três caracteres idênticos consecutivos;

• Não ser igual ao nome da conta.

Serviços de Internet

A Apple construiu um conjunto de serviços robustos para ajudar os usuários a obte-rem ainda mais utilidade e produtividade em seus dispositivos, incluindo iMessage, FaceTime, Siri, Spotlight, Sugestões do Safari, iCloud, Backup do iCloud e Chaves do iCloud.

Esses serviços de Internet foram construídos com os mesmos objetivos de segurança que o iOS oferece em toda a plataforma. Esses objetivos incluem o manuseio seguro de dados (seja no dispositivo em si ou ao trafegar por redes sem fio), a proteção de informações pessoais dos usuários e a proteção contra ameaças de acesso malicioso ou não autorizado a informações e serviços. Cada serviço usa a sua própria arquitetura sólida sem comprometer a facilidade de uso geral do iOS.

ID AppleUm ID Apple é o nome de usuário e senha usados para iniciar a sessão em serviços da Apple como o iCloud, iMessage, FaceTime, iTunes Store, iBooks Store e App Store, dentre outros. É importante que os usuários mantenham seus IDs Apple em segurança para impedir o acesso não autorizado às suas contas. Para ajudar nisso, a Apple exige senhas fortes que devem ter ao menos oito caracteres, conter letras e números e não conter mais do que três caracteres idênticos consecutivos nem ser uma senha usada frequentemente. Os usuários são encorajados a excederem essas diretrizes através da adição de caracteres extras e sinais de pontuação para tornar suas senhas ainda mais fortes. A Apple também requer que os usuários definam três perguntas de segurança que podem ser utilizadas para comprovar a identidade do proprietário ao realizar alte-rações em suas informações de conta ou ao redefinir uma senha esquecida.

A Apple também envia e-mails e notificações push aos usuários quando alterações importantes são feitas às suas contas; por exemplo, se uma senha ou informação de cobrança for alterada ou se o ID Apple for usado para iniciar a sessão em um novo dispositivo. Se algo estiver fora do esperado, os usuários são instruídos a modificar a senha de seus IDs Apple imediatamente.

Além disso, a Apple emprega diversas políticas e procedimentos feitos para proteger as contas dos usuários. Isso inclui limitar o número de tentativas de início de sessão e redefinição de senha, o monitoramento ativo contra fraude para ajudar na identifica-ção de ataques à medida que ocorrem e revisões regulares das políticas, o que permite à Apple adaptar-se a quaisquer informações novas que possam afetar a segurança do cliente.

Autenticação de dois fatoresPara ajudar os usuários a assegurar ainda mais suas contas, a Apple oferece a autenti-cação de dois fatores. A autenticação de dois fatores é uma camada de segurança extra aos IDs Apple. Foi desenvolvida para garantir que somente o proprietário da conta possa acessar a conta, mesmo se mais alguém souber a senha.

Com a autenticação de dois fatores, a conta de um usuário pode ser acessada somente em dispositivos de confiança, como o iPhone, iPad ou Mac do usuário. Para iniciar a sessão pela primeira vez em qualquer dispositivo novo, são necessárias duas infor-mações: a senha do ID Apple e o código de verificação de seis dígitos que é exibido automaticamente nos dispositivos autorizados do usuário ou enviado a um número de telefone autorizado. Ao digitar o código, o usuário comprova que autoriza o dispo-sitivo novo e que é seguro iniciar a sessão. Devido a apenas uma senha não ser mais


suficiente para acessar a conta de um usuário, a autenticação de dois fatores melhora a segurança do ID Apple do usuário e de todas as informações pessoais que ele armaze-na junto à Apple.

A autenticação de dois fatores melhora a segurança dos IDs Apple dos usuários e das informações pessoais que eles armazenam junto à Apple. É integrada diretamente no iOS, OS X, tvOS, watchOS e nos sistemas de autenticação utilizados pelos sites da Apple.

Para obter mais informações sobre a autenticação de dois fatores, consulte support.apple.com/pt-br/HT204915.

Confirmação em dois passosDesde 2013, a Apple também oferece um método de segurança semelhante, chamado confirmação em dois passos. Com a confirmação em dois passos ativada, a identidade do usuário deve ser verificada através de um código temporário enviado a um dos dis-positivos confiáveis do usuário antes que seja permitido alterar suas informações da conta do ID Apple, antes de iniciar a sessão no iCloud, iMessage, FaceTime ou Game Center; e antes de fazer compras na iTunes Store, iBooks Store ou App Store em um novo dispositivo. Uma Chave Reserva de 14 caracteres também é fornecida aos usuários para que ela seja armazenada em um local seguro, caso esqueçam suas senhas ou percam o acesso aos seus dispositivos confiáveis. Para obter mais informa-ções sobre a confirmação em dois passos do ID Apple, consulte https://support.apple.com/pt-br/HT5570.

IDs Apple GerenciadosCom o iOS 9.3 ou mais recente, os IDs Apple Gerenciados funcionam de maneira seme-lhante a um ID Apple, mas são de propriedade e controle de uma instituição de ensino. A instituição pode redefinir senhas, limitar compras e comunicações como FaceTime e Mensagens, além de configurar permissões por cargo para funcionários, professores e alunos.

Alguns serviços da Apple são desativados para IDs Apple Gerenciados, tais como Touch ID, Apple Pay, Chaves do iCloud, HomeKit e Buscar iPhone.

Para obter mais informações sobre os IDs Apple Gerenciados, consulte Ajuda Apple School Manager.

Auditoria de IDs Apple GerenciadosIDs Apple Gerenciados também são compatíveis com auditorias, o que permite que as instituições de ensino cumpram as regulamentações legais e de privacidade. Contas de administrador, professor ou gerente podem receber privilégios de auditoria para IDs Apple Gerenciados específicos. Os auditores podem monitorar apenas contas que estão abaixo deles na hierarquia da escola. Isso significa que professores podem moni-torar alunos; gerentes podem auditar professores e alunos; a administradores podem auditar gerentes, professores e alunos.

Quando credenciais de auditoria são solicitadas por meio do Apple School Manager, é emitida uma conta especial que dá acesso somente ao ID Apple Gerenciado para o qual a auditoria foi solicitada. As permissões de auditoria expiram após sete dias. Durante esse período, o auditor pode ler e modificar o conteúdo do usuário armazena-do no iCloud ou em aplicativos onde o iCloudKit esteja ativado. Todas as solicitações de acesso de auditoria são registradas no Apple School Manager. Os registros mostram quem foi o auditor, o ID Apple Gerenciado para o qual o auditor solicitou acesso, a hora da solicitação e se a auditoria foi realizada.

http://support.apple.com/pt-br/HT204915


https://help.apple.com/schoolmanager/



IDs Apple Gerenciados e dispositivos pessoaisIDs Apple Gerenciados também podem ser utilizados em dispositivos iOS particulares. Os estudantes iniciam a sessão no iCloud utilizando o ID Apple Gerenciado emitido pela instituição e uma senha adicional para uso doméstico, que serve como segundo fator do processo de autenticação de dois fatores do ID Apple. Durante a utilização de um ID Apple Gerenciado em um dispositivo pessoal, as Chaves do iCloud não ficam dis-poníveis e a instituição pode restringir outros recursos, como FaceTime ou Mensagens. Quaisquer documentos do iCloud criados por alunos enquanto eles estiverem com a sessão iniciada estarão sujeitos a auditoria, conforme descrito anteriormente.

iMessageO iMessage da Apple é um serviço de mensagens para dispositivos iOS e compu-tadores Mac. O iMessage oferece suporte a texto e anexos, como fotos, contatos e localizações. As mensagens aparecem em todos os dispositivos registrados de um usuário para que a conversa possa ser continuada de qualquer um deles. O iMessage faz amplo uso do serviço de Notificações Push da Apple (APNs). A Apple não registra as mensagens ou anexos e seus conteúdos são protegidos por criptografia de ponta a ponta, para que ninguém, exceto o remetente e o destinatário, possa acessá-los. A Apple não pode decriptografar os dados.

Quando um usuário ativa o iMessage em um dispositivo, o dispositivo gera dois pares de chaves para uso no serviço: uma chave RSA de 1280 bits para criptografia e uma chave ECDSA de 256 bits na curva NIST P-256 para assinatura. As chaves privadas de ambos os pares de chaves são salvas nas chaves do dispositivo e as chaves públicas são enviadas para o serviço de diretório da Apple (IDS), onde são associadas ao núme-ro de telefone ou endereço de e-mail do usuário, juntamente ao endereço APNs do dispositivo.

Conforme os usuários adicionam dispositivos para uso no iMessage, suas chaves de criptografia e assinatura pública, endereços APNs e números de telefone associados são adicionados ao serviço de diretório. Os usuários também podem adicionar outros endereços de e-mail, que serão verificados através do envio de um link de confirma-ção. Os números de telefone são verificados pela rede e SIM da operadora. Além disso, todos os dispositivos registrados do usuário exibem uma mensagem de alerta quando um novo dispositivo, número de telefone ou endereço de e-mail é adicionado.

Como o iMessage envia e recebe mensagensPara iniciar uma nova conversa do iMessage, os usuários digitam um endereço ou nome. Se um número de telefone ou um endereço de e-mail for digitado, o dispositivo contata o IDS para obter as chaves públicas e endereços APNs de todos os dispositi-vos associados ao destinatário. Se um nome for digitado, primeiro o dispositivo usa o aplicativo Contatos do usuário para coletar números de telefone e endereços de e-mail associados ao nome para depois obter as chaves públicas e endereços APNs do IDS.

A mensagem sendo enviada é criptografada individualmente para cada um dos dispo-sitivos recipientes. As chaves públicas de criptografia RSA dos dispositivos recipientes são obtidas do IDS. Para cada dispositivo recipiente, o dispositivo de envio gera uma chave de 128 bits aleatória para criptografar a mensagem usando AES no modo CTR. Essa chave AES única por mensagem é criptografada à chave pública do dispositivo recipiente usando RSA-OAEP. Depois, o hash SHA-1 é aplicado à combinação do texto e da chave da mensagem criptografada, e o hash é assinado com ECDSA usando a chave de assinatura privada do dispositivo de envio. As mensagens resultantes, uma para cada dispositivo recipiente, consistem do texto da mensagem criptografada, chave da mensagem criptografada e assinatura digital do remetente. Elas então são


despachadas para o APNs para entrega. Metadados, como a marca temporal e informa-ções de roteamento do APNs, não são criptografados. A comunicação com o APNs é criptografada usando um canal TLS de encaminhamento secreto.

O APNs só pode transmitir mensagens de até 4 KB ou 16 KB, dependendo da versão do iOS. Se a mensagem de texto for muito longa ou se um anexo (como uma foto) estiver incluído, o anexo é criptografado usando AES no modo CTR com uma chave de 256 bits gerada aleatoriamente e enviado para o iCloud. A chave AES do anexo, seu URI (Identificador Uniforme de Recursos) e um hash SHA-1 de sua forma criptografada são então enviados para o destinatário na forma de conteúdo de uma iMessage, com suas confidencialidade e integridade protegidas através da criptografia normal do iMessage, como mostrado abaixo.

Usuário 2

Anexocriptografado com

chave aleatória

Chave pública e token APNs para usuário 2

iCloud

IDS

Usuário 1

Chave pública e token APNs para usuário 1

Mensagem assinada e criptografada para usuário 2 com URI e

chave para anexo

APNs

Nas conversas em grupo, este processo é repetido para cada destinatário e seus dispositivos.

No lado recipiente, cada dispositivo recebe sua cópia da mensagem do APNs e, se necessário, obtém o anexo do iCloud. O número de telefone ou endereço de e-mail vindo do remetente é correspondido ao contato do recipiente para que um nome seja exibido, se possível.

Assim como em todas as notificações push, a mensagem é apagada do APNs quan-do entregue. No entanto, ao contrário de outras notificações push, as mensagem do iMessage são colocadas em fila para entrega a dispositivos off-line. Atualmente, as mensagens são armazenadas por 30 dias.

FaceTimeO FaceTime é o serviço de ligações de vídeo e áudio da Apple. Semelhante ao iMessage, o FaceTime também usa o serviço de Notificações Push da Apple para esta-belecer uma conexão inicial aos dispositivos registrados do usuário. O conteúdo de áudio/vídeo de ligações FaceTime é protegido por criptografia de ponta a ponta, para que ninguém, exceto o remetente e o destinatário, possa acessá-lo. A Apple não pode decriptografar os dados.


O FaceTime usa o Estabelecimento de Conectividade via Internet (ICE) para estabe-lecer uma conexão peer-to-peer entre dispositivos. Através do uso de mensagens de Protocolo de Iniciação de Sessão (SIP), os dispositivos verificam seus certificados de identidade e estabelecem um segredo compartilhado para cada sessão. Os nonces criptográficos fornecidos por cada dispositivo são combinados a chaves de sal em cada um dos canais de mídia, que são transmitidos via Protocolo Seguro de Transporte em Tempo Real (SRTP) usando criptografia AES-256.

iCloudO iCloud armazena contatos, calendários, fotos, documentos e outros itens de um usuário, mantendo as informações atualizadas em todos os dispositivos do usuário automaticamente. O iCloud também pode ser usado por aplicativos de terceiros para armazenar e sincronizar documentos, assim como valores de chaves para dados de aplicativos, conforme definido pelo desenvolvedor. Para configurar o iCloud, os usu-ários iniciam a sessão com um ID Apple e escolhem quais serviços desejam usar. Os recursos do iCloud (incluindo Meu Compartilhamento de Fotos, iCloud Drive e Backup), podem ser desativados por administradores de TI através de um perfil de configuração. O serviço não leva em consideração aquilo que é armazenado e lida com o conteúdo de arquivos da mesma maneira, como uma coleção de bytes.

Cada arquivo é dividido em blocos e criptografado pelo iCloud usando AES-128 e uma chave derivada de cada conteúdo de bloco que use SHA-256. As chaves e os metadados do arquivo são armazenados pela Apple na conta do iCloud do usuário. Os blocos criptografados do arquivo são armazenados (sem nenhuma informação que identifique o usuário) em serviços de armazenamento de terceiros, como Amazon S3 e Windows Azure.

iCloud DriveO iCloud Drive adiciona chaves baseadas em conta para proteger documentos arma-zenados no iCloud. Assim como em serviços existentes do iCloud, ele divide e cripto-grafa o conteúdo de arquivos em blocos, armazenando-os em serviços de terceiros. No entanto, as chaves de conteúdo do arquivo são embaladas por chaves de registro armazenadas com os metadados do iCloud Drive. Por sua vez, essas chaves de registro são protegidas pela chave de serviço do iCloud Drive do usuário, que é então armaze-nada na conta do iCloud do usuário. Os usuários obtêm acesso aos metadados de seus documentos do iCloud através da autenticação no iCloud, mas também é preciso que tenham a chave de serviço do iCloud Drive para expor partes protegidas do armazena-mento do iCloud Drive.

CloudKitO CloudKit permite que desenvolvedores de aplicativos armazenem dados de valores de chaves, dados estruturados e recursos no iCloud. O acesso ao CloudKit é controla-do pelo uso de direitos do aplicativo. O CloudKit oferece suporte a bancos de dados públicos e privados. Bancos de dados públicos são usados por todas as cópias do apli-cativo (normalmente para recursos típicos) e não são criptografados. Bancos de dados privados armazenam os dados do usuário.

Assim como o iCloud Drive, o CloudKit usa chaves baseadas em conta para proteger as informações armazenadas no banco de dados privado do usuário e, de forma seme-lhante a outros serviços do iCloud, os arquivos são divididos em blocos, criptografados e armazenados em serviços de terceiros. O CloudKit usa uma hierarquia de chaves, semelhante à Proteção de Dados. As chaves únicas por arquivo são embaladas por chaves de Registro do CloudKit. As chaves de Registro, por sua vez, são protegidas por


uma chave de zona, que é protegida pela chave de Serviço do CloudKit do usuário. A chave de Serviço do CloudKit é armazenada na conta do iCloud do usuário e disponi-bilizada somente depois de sua autenticação no iCloud.

Chave de Zonado CloudKit

Chave deRegistro

do CloudKitMetadadosdo Arquivo

Lista de Blocosdo Arquivo

Chave deServiço

do CloudKit

CriptografiaConvergente

Blocodo Arquivo

Backup do iCloudO iCloud também faz o backup de informações — incluindo os ajustes do dispositi-vo, dados de aplicativos, fotos e vídeos do Rolo da Câmera e conversas do aplicativo Mensagens — diariamente via Wi-Fi. O iCloud criptografa o conteúdo para dar segu-rança ao transmiti-lo pela Internet, armazenando-o em formato criptografado e usando tokens de segurança para a autenticação. O Backup do iCloud ocorre somente quando o dispositivo está bloqueado, conectado a uma fonte de alimentação e possui acesso Wi-Fi à Internet. Por conta da criptografia usada no iOS, o sistema é feito para manter os dados seguros e, ao mesmo tempo, permitir que backups incrementais não supervi-sionados e restaurações ocorram.

O iCloud faz o backup de:

• Informações sobre músicas, filmes, programas de TV, aplicativos e livros comprados (mas não o conteúdo comprado em si);

• Fotos e vídeos no Rolo da Câmera;

• Contatos, eventos do calendário, lembretes e notas;

• Ajustes do dispositivo;

• Dados de aplicativos;

• PDFs e livros adicionados ao iBooks (mas não comprados);

• Histórico de ligações;

• Tela de Início e organização dos aplicativos;

• Mensagens do iMessage, de texto (SMS) e MMS;

• Toques;

• Dados do HomeKit;

• Dados do HealthKit;

• Visual Voicemail.

Quando arquivos são criados em classes de Proteção de Dados que não estão aces-síveis quando o dispositivo está bloqueado, suas chaves únicas por arquivo são crip-tografadas pelas chaves de classe da bolsa de chaves do Backup do iCloud. O backup dos arquivos é feito no iCloud, em seus estados originais, criptografados. Os arquivos da classe Sem Proteção da Proteção de Dados são criptografados durante o transporte.

A bolsa de chaves do Backup do iCloud contém chaves assimétricas (Curve25519) para cada classe de Proteção de Dados, que são usadas para criptografar as chaves únicas por arquivo. Para obter mais informações sobre o conteúdo da bolsa de chaves do backup e sobre a bolsa de chaves do Backup do iCloud, consulte “Proteção de Dados das Chaves” na seção Criptografia e Proteção de Dados.


O conjunto do backup é armazenado na conta do iCloud do usuário e consiste em uma cópia dos arquivos do usuário e a bolsa de chaves do Backup do iCloud. A bolsa de chaves do Backup do iCloud é protegida por uma chave aleatória, também armaze-nada no conjunto do backup (a senha do iCloud do usuário não é usada para a cripto-grafia, logo, a alteração da senha do iCloud não invalida os backups existentes).

Enquanto o banco de dados das chaves do usuário tiver um backup no iCloud, ele continuará protegido por uma chave UID trançada. Isso permite que as chaves sejam restauradas apenas no mesmo dispositivo onde foram originadas e significa que nin-guém, nem mesmo a Apple, pode ler os itens das chaves do usuário.

Ao restaurar, os arquivos que tenham backup, a bolsa de chaves do Backup do iCloud e a chave da bolsa de chaves são obtidas da conta do iCloud do usuário. A bolsa de chaves do Backup do iCloud é decriptografada usando sua própria chave; em segui-da, as chaves únicas por arquivo na bolsa de chaves são usadas para decriptografar os arquivos no conjunto do backup, que são gravados no sistema de arquivos como novos arquivos, sendo criptografados novamente conforme suas classes de Proteção de Dados.

Chaves do iCloudAs Chaves do iCloud permitem que os usuário sincronizem suas senhas seguramente entre dispositivos iOS e computadores Mac sem expor essas informações à Apple. Os objetivos que influenciaram fortemente o design e a arquitetura das Chaves do iCloud (além do enfoque forte em privacidade e segurança) foram a facilidade de uso e a possibilidade de recuperação das chaves. As Chaves do iCloud são compostas de dois serviços: sincronização das chaves e recuperação das chaves.

A Apple projetou as Chaves do iCloud e recuperação das chaves para que as senhas de um usuário estejam protegidas mesmo nas seguintes circunstâncias:

• A conta do iCloud de um usuário seja comprometida;

• O iCloud seja comprometido por um ataque externo ou de um funcionário;

• Acesso de terceiros a contas de usuários.

Sincronização das chavesQuando um usuário ativa as Chaves do iCloud pela primeira vez, o dispositivo estabe-lece um círculo de confiança e cria uma identidade de sincronização para si. Uma iden-tidade de sincronização consiste em uma chave privada e uma chave pública. A chave pública da identidade de sincronização é colocada no círculo e o círculo é assinado duas vezes: primeiro pela chave privada da identidade de sincronização e depois por uma chave elíptica assimétrica (usando P256) derivada da senha da conta do iCloud do usuário. Também armazenados no círculo estão os parâmetros (sal e iterações alea-tórios) usados para criar a chave baseada na senha do iCloud do usuário.

O círculo de sincronização assinado é colocado na área de armazenamento de valores de chaves do iCloud do usuário. Ele não pode ser lido sem o conhecimento da senha do iCloud do usuário e não pode ser modificado legalmente sem a chave privada da identidade de sincronização do seu integrante.

Quando o usuário ativa as Chaves do iCloud em outro dispositivo, o novo dispositivo percebe que o usuário possui um círculo de sincronização estabelecido anteriormente no iCloud do qual não é integrante. O dispositivo cria o seu par de chaves de identida-de de sincronização e um tíquete de candidatura para solicitar o ingresso no círculo. O tíquete consiste na chave pública da identidade de sincronização do dispositivo e o usu-ário é solicitado a autenticar usando a sua senha do iCloud. Os parâmetros de geração da chave elíptica são obtidos do iCloud e geram uma chave que é usada para assinar o tíquete de candidatura. Finalmente, o tíquete de candidatura é colocado no iCloud.

Integração do Safari com as Chaves do iCloudO Safari pode gerar strings aleatórias crip-tograficamente fortes de forma automática para criar senhas de sites, que são arma-zenadas nas Chaves e sincronizadas com os seus outros dispositivos. Os itens das Chaves são transferidos de dispositivo para dispositivo através de servidores da Apple, mas são criptografadas de tal maneira que nem a Apple e nem outros dispositivos possam ler seu conteúdo.


Quando o primeiro dispositivo percebe o recebimento de um tíquete de candidatura, ele exibe um aviso ao usuário, reconhecendo a solicitação do novo dispositivo para entrar no círculo de sincronização. O usuário digita a sua senha do iCloud e o tíquete de candidatura é verificado como assinado através da correspondência de uma chave privada. Isso demonstra que a pessoa que gerou a solicitação para entrar no círculo digitou a senha do iCloud do usuário na hora em que a solicitação foi feita.

Depois que o usuário aprova a adição do novo dispositivo ao círculo, o primeiro dis-positivo adiciona a chave pública do novo integrante ao círculo de sincronização e a assina novamente com a identidade de sincronização e a chave derivada da senha do iCloud do usuário. O novo círculo de sincronização é colocado no iCloud, onde é assi-nado pelo novo integrante do círculo de maneira semelhante.

Agora há dois integrantes no círculo de sincronização e cada integrante possui a chave pública do outro dispositivo. Eles começam a trocar itens individuais das chaves através do armazenamento de valores de chaves do iCloud. Se os dois integrantes do círculo tiverem o mesmo item, aquele com a data de modificação mais recente será sincroni-zado. Se o outro integrante possuir o item e as datas de modificação forem idênticas, o item é ignorado. Cada item sincronizado é criptografado especificamente para o dispositivo ao qual está sendo enviado. Ele não pode ser decriptografado por outros dispositivos ou pela Apple. Além disso, o item criptografado é transitório no iCloud; ele é substituído por cada novo item sincronizado.

Esse processo repete-se conforme novos dispositivos entram no círculo de sincroniza-ção. Por exemplo, quando da entrada de um terceiro dispositivo, a confirmação é exibi-da nos outros dois dispositivos do usuário. O usuário pode aprovar o novo integrante de qualquer um desses dispositivos. Conforme novos dispositivos são adicionados, cada um é sincronizado ao novo para garantir que todos os integrantes tenham os mesmos itens das chaves.

No entanto, as chaves completas não são sincronizadas. Alguns itens são específicos a cada dispositivo (como identidades VPN) e não devem sair do dispositivo. Somente os itens com o atributo kSecAttrSynchronizable são sincronizados. A Apple definiu esse atributo para os dados do Safari do usuário (incluindo nomes de usuários, senhas e números de cartão de crédito), além de senhas do Wi-Fi e chaves de cripto-grafia do HomeKit.

Além disso, os itens das chaves adicionados por aplicativos de terceiros não são sincronizados por padrão. Desenvolvedores devem definir o atributo kSecAttrSynchronizable ao adicionar itens às chaves.


Recuperação das chavesA recuperação das chaves fornece aos usuários uma maneira de guardar suas chaves com a Apple, sem permitir que a Apple leia suas senhas ou outros dados contidos. Mesmo que o usuário tenha um único dispositivo, a recuperação das chaves fornece uma camada de segurança contra a perda de dados. Isso é particularmente importante quando o Safari é usado para gerar senhas fortes e aleatórias para contas da web, pois o único registro dessas senhas encontra-se nas chaves.

Um dos pilares da recuperação das chaves é a autenticação secundária e um serviço de guarda seguro, criado pela Apple para oferecer suporte a este recurso especifica-mente. As chaves do usuário são criptografadas usando um código forte e o serviço de guarda fornecerá uma cópia das chaves somente se um conjunto de condições especí-ficas for atendido.

Quando as Chaves do iCloud estão ativadas, o usuário é solicitado a criar um Código de Segurança do iCloud. Esse código é exigido para recuperar as chaves guardadas. Por padrão, o usuário é solicitado a fornecer um valor simples de quatro dígitos como código de segurança. No entanto, os usuários também pode especificar seus próprios (e maiores) códigos ou permitir que seus dispositivos criem um código criptografica-mente aleatório que possa ser registrado e mantido em separado.

A seguir, o dispositivo iOS exporta uma cópia das chaves do usuário, criptografa-o embalado em chaves dentro de uma bolsa de chaves assimétrica e o coloca na área de armazenamento de valores de chaves do iCloud do usuário. A bolsa de chaves é emba-lada pelo Código de Segurança do iCloud do usuário e a chave pública do cluster HSM (módulo de segurança de hardware) que armazenará o registro de guarda. Isso se torna o Registro de Guarda do iCloud do usuário.

Se o usuário decidiu aceitar um código de segurança criptograficamente aleatório ao invés de especificar o seu próprio código ou usar um valor de quatro dígitos, o registro de guarda não é necessário. No lugar disso, a chave aleatória é embalada diretamente pelo Código de Segurança do iCloud.

Além de estabelecer um código de segurança, os usuários devem registrar um número de telefone. Isso é usado para fornecer um nível secundário de autenticação durante a recuperação das chaves. O usuário receberá um SMS que deve ser respondido para que a recuperação continue.

Segurança de guardaO iCloud fornece uma infraestrutura segura para a guarda de chaves, garantindo que apenas os usuários e dispositivos autorizados realizem uma recuperação. Posicionados topograficamente atrás do iCloud estão os clusters de módulos de segurança de har-dware (HSM). Esses clusters protegem os registros de guarda. Cada um possui uma chave que é usada para criptografar os registros de guarda pelos quais são responsá-veis, conforme descrito anteriormente.


Para recuperar suas chaves, o usuário deve usar sua conta e senha do iCloud para autenticar e responder a um SMS enviado para o número de telefone registrado. Uma vez feito isso, o usuário deve digitar o seu Código de Segurança do iCloud. O cluster HSM usa o protocolo de Senha Remota Segura (SRP) para verificar se o usuário sabe o seu Código de Segurança do iCloud; o código em si não é enviado à Apple. Cada integrante do cluster verifica independentemente se o usuário não excedeu o número máximo de tentativas permitidas para recuperar seu registro, conforme descrito abaixo. Havendo consenso da maioria, o cluster abre o registro de guarda e o envia para o dispositivo do usuário.

A seguir, o dispositivo usa o Código de Segurança do iCloud para abrir a chave alea-tória usada para criptografar as chaves do usuário. Com essa chave, as chaves (obtidas do armazenamento de valores de chaves do iCloud) são decriptografadas e restaura-das no dispositivo. São permitidas apenas 10 tentativas de autenticação para obter o registro de guarda. Depois de várias tentativas malsucedidas, o registro é bloqueado e o usuário precisará ligar para o Suporte da Apple para obter mais tentativas. Depois da 10ª tentativa malsucedida, o cluster HSM destrói o registro de guarda e as chaves se perdem para sempre. Isso fornece proteção contra tentativas de aquisição do registro com força bruta, à custa do sacrifício dos dados das chaves em retorno.

Essas políticas estão codificadas no firmware HSM. Os cartões de acesso administrativo que permitem a alteração do firmware foram destruídos. Qualquer tentativa de alterar o firmware ou acessar a chave privada fará com que o cluster HSM destrua a chave privada. Caso isso ocorra, os proprietários de todas as chaves protegidas pelo cluster receberão uma mensagem informando-lhes sobre a perda de seus registros de guarda. Eles poderão optar por inscrever-se novamente.

SiriAtravés da simples fala natural, os usuários podem pedir à Siri para enviar mensagens, programar reuniões, fazer ligações telefônicas e muito mais. A Siri usa reconhecimento de fala, vocalização de texto e um modelo cliente-servidor para responder a uma gran-de variedade de pedidos. As tarefas às quais a Siri oferece suporte foram projetadas para garantir que apenas o mínimo absoluto de informações pessoais sejam usadas e que elas estejam totalmente protegidas.

Quando a Siri está ativada, o dispositivo cria identificadores aleatórios para uso nos servidores de reconhecimento de voz e da Siri. Esses identificadores são utilizados somente para a Siri e são usados para melhorar o serviço. Se, posteriormente, a Siri for desativada, o dispositivo gerará um novo identificador aleatório para uso caso a Siri seja reativada.

Para auxiliar os recursos da Siri, algumas informações do usuário presentes no dispo-sitivo são enviadas ao servidor. Isso inclui informações sobre a biblioteca de música (nome das músicas, artistas e playlists), nomes das listas do Lembretes e nomes de relacionamentos definidos no Contatos. Todas as comunicações com o servidor ocor-rem via HTTPS.

Quando uma sessão da Siri é iniciada, o nome e sobrenome do usuário (do Contatos) e uma localização geográfica aproximada são enviadas ao servidor. Isso permite que a Siri responda com o nome ou replique a perguntas que precisam apenas de uma loca-lização aproximada, como perguntas sobre o tempo.

Se uma localização mais precisa for necessária (para determinar a localização de cine-mas próximos, por exemplo), o servidor solicita que o dispositivo forneça uma localiza-ção mais exata. Isso é um exemplo de como, por padrão, as informações são enviadas ao servidor somente quando absolutamente necessárias para processar o pedido do usuário. De qualquer forma, as informações da sessão são descartadas depois de 10 minutos de inatividade.


Quando a Siri é usada a partir do Apple Watch, o relógio cria o seu próprio identifi-cador exclusivo aleatório, conforme descrito acima. No entanto, ao invés de enviar as informações do usuário novamente, o pedido também envia o identificador da Siri do iPhone emparelhado para fornecer uma referência a essas informações.

A gravação das palavras ditas pelo usuário é enviada ao servidor de reconhecimento de voz da Apple. Se a tarefa envolver apenas ditado, o texto reconhecido é enviado de volta para o dispositivo. Caso contrário, a Siri analisa o texto e, se necessário, o combi-na com informações do perfil associado ao dispositivo. Por exemplo, se o pedido for “envie uma mensagem para a minha mãe”, os relacionamentos e nomes enviados ante-riormente do Contatos são usados. O comando da ação identificada é então enviado de volta ao dispositivo para ser cumprido.

Várias funções da Siri são realizadas pelo dispositivo sob orientação do servidor. Por exemplo, se o usuário pedir à Siri para ler uma mensagem que acabou de chegar, o servidor simplesmente diz ao dispositivo para falar o conteúdo das mensagens não lidas. O conteúdo e o remetente da mensagem não são enviados ao servidor.

As gravações da voz do usuário são salvas por seis meses para que o sistema de reconhecimento possa usá-las para entender melhor a voz do usuário. Depois de seis meses, outra cópia é salva (sem o identificador) para uso da Apple por até dois anos, visando a melhoria e o desenvolvimento da Siri. Além disso, algumas gravações que refiram-se a músicas, times esportivos e jogadores, empresas ou pontos de interesse também são salvas com o propósito de melhorar a Siri.

A Siri também pode ser chamada sem o uso das mãos através da ativação por voz. A detecção do acionamento por voz é feita localmente no dispositivo. Nesse modo, a Siri é ativada somente quando o padrão de áudio recebido corresponde suficientemente à acústica da frase de acionamento especificada. Quando o acionamento é detectado, o áudio correspondente (incluindo o comando subsequente) é enviado ao servidor de reconhecimento de voz da Apple para processamento adicional, o qual segue as mes-mas regras de outras gravações de voz feitas através da Siri.

ContinuidadeA Continuidade aproveita-se das tecnologias iCloud, Bluetooth e Wi-Fi para permitir que usuários continuem a atividade de um dispositivo em outro, façam e recebam ligações telefônicas, enviem e recebam mensagens de texto e compartilhem uma conexão celular de Internet.

HandoffCom o Handoff, quando o Mac e dispositivo iOS de um usuário estão próximos, o usuário pode passar aquilo em que estiver trabalhando de um dispositivo para outro. O Handoff permite que o usuário alterne entre dispositivos e continue trabalhando imediatamente.

Quando um usuário inicia a sessão no iCloud em um segundo dispositivo compatível com o Handoff, os dois dispositivos estabelecem um emparelhamento Bluetooth Low Energy 4.0 fora de banda usando o serviço de Notificações Push da Apple (APNs). As mensagens individuais são criptografadas de forma similar ao iMessage. Uma vez emparelhados, cada dispositivo gera uma chave AES de 265 bits que é armazenada nas chaves do dispositivo. A chave é usada para criptografar e autenticar os anúncios de Bluetooth Low Energy que comunicam a atividade atual do dispositivo para outros dispositivos emparelhados que usam o iCloud – usando AES-256 no modo GCM, com medidas de proteção contra replay. Da primeira vez que um dispositivo recebe um anúncio de uma nova chave, ele estabelece uma conexão Bluetooth Low Energy ao dispositivo originário e anuncia uma troca de chaves de criptografia. O uso de cripto-grafia padrão Bluetooth Low Energy 4.0 mantém essa conexão em segurança, assim como a criptografia de mensagens individuais, que assemelha-se à criptografia do


iMessage. Em algumas situações, essas mensagens serão enviadas através do serviço de Notificações Push da Apple, ao invés de Bluetooth Low Energy. O payload da ativi-dade é protegido e transferido da mesma maneira que uma iMessage.

HandoffentreaplicativosnativosesitesO Handoff permite que um aplicativo nativo do iOS retome páginas web em domínios controlados legitimamente pelo desenvolvedor do aplicativo. Ele também permite que a atividade do usuário do aplicativo nativo seja retomada em um navegador.

Para impedir que aplicativos nativos reivindiquem a retomada de sites que não sejam controlados pelo desenvolvedor, o aplicativo precisa demonstrar controle legítimo sobre os domínios web que deseja retomar. O controle sobre um domínio de site é estabelecido através do mecanismo usado por credenciais web compartilhadas. Para obter detalhes, consulte “Acesso a senhas salvas do Safari” na seção Criptografia e Proteção de Dados. O sistema deve validar o controle do nome de domínio de um aplicativo antes que o aplicativo tenha permissão para aceitar o Handoff da atividade do usuário.

A fonte do Handoff de uma página web pode ser qualquer navegador que tenha adotado as APIs do Handoff. Quando o usuário visualiza uma página web, o sistema anuncia o nome do domínio da página web em bytes de anúncio de Handoff cripto-grafados. Somente os outros dispositivos do usuário podem decriptografar os bytes de anúncio (conforme descrito na seção acima).

No dispositivo recipiente, o sistema detecta que um aplicativo nativo instalado aceita o Handoff do nome de domínio anunciado e exibe o ícone do aplicativo nativo como opção de Handoff. Quando aberto, o aplicativo nativo recebe o URL completo e o título da página web. Nenhuma outra informação é passada do navegador para o apli-cativo nativo.

Em contrapartida, um aplicativo nativo poderá especificar uma URL alternativa quan-do o dispositivo receptor do Handoff não tiver o mesmo aplicativo nativo instalado. Nesse caso, o sistema exibe o navegador padrão do usuário como opção de aplicativo Handoff (caso o navegador tenha adotado as APIs do Handoff). Quando o Handoff for solicitado, o navegador será aberto e a URL alternativa será fornecida pelo aplicativo fonte. Não há requisitos para que a URL alternativa seja limitada a nomes de domínios controlados pelo desenvolvedor do aplicativo nativo.

HandoffdedadosmaioresAlém dos recursos básicos do Handoff, alguns aplicativos podem optar se por usar APIs que oferecem suporte ao envio de uma quantidade maior de dados através da tecno-logia Wi-Fi peer-to-peer criada pela Apple (de forma similar ao AirDrop). O aplicativo Mail, por exemplo, usa essas APIs para que o rascunho de um e-mail (que talvez tenha anexos grandes) possa usar o Handoff.

Quando um aplicativo usa essa capacidade, a troca entre dois dispositivos é iniciada da mesma forma que no Handoff (consulte as seções anteriores). No entanto, depois de receber o payload inicial usando Bluetooth Low Energy, o dispositivo receptor inicia uma nova conexão via Wi-Fi. Nessa conexão criptografada (TLS), os dispositivos trocam seus certificados de identidade do iCloud. A identidade nos certificados é comparada com a identidade do usuário para verificá-la. Dados adicionais de payload são enviados por essa conexão criptografada até que a transferência seja concluída.

RetransmissãodeLigaçõesCelularesdoiPhoneQuando seu Mac, iPad ou iPod estão na mesma rede Wi-Fi do seu iPhone, eles podem fazer e receber ligações telefônicas usando a conexão celular do iPhone. A configura-ção requer que os dispositivos tenham uma sessão iniciada no iCloud e no FaceTime usando o mesmo ID Apple.


Quando uma ligação é recebida, todos os dispositivos configurados são notificados através do serviço de Notificações Push da Apple (APNs), e cada notificação usa a mesma criptografia ponta a ponta usada pelo iMessage. Os dispositivos que estiverem na mesma rede mostrarão a notificação da ligação. Depois de atender à ligação, o áudio será transmitido continuamente do iPhone usando uma conexão peer-to-peer segura entre os dois dispositivos.

Quando uma ligação é atendida em um dispositivo, o toque dos dispositivos próximos emparelhados com o iCloud é interrompido com um breve anúncio do Bluetooth Low Energy 4.0. Os bytes do anúncio são criptografados pelo mesmo método dos anúncios do Handoff.

As ligações feitas também serão retransmitidas pelo iPhone através do serviço de Notificações Push da Apple e o áudio transmitido pela conexão peer-to-peer segura entre os dispositivos, citada anteriormente.

Os usuários podem desativar a retransmissão de ligações telefônicas em um dispositi-vo, bastando desativar “Ligações via iPhone” nos ajustes do FaceTime.

Encaminhamento de Mensagens do iPhoneO Encaminhamento de Mensagens envia automaticamente as mensagens de texto SMS recebidas em um iPhone para um iPad, iPod touch ou Mac registrado do usuário. Cada dispositivo deve ter uma sessão iniciada no iMessage usando o mesmo ID Apple. Quando o Encaminhamento de Mensagens SMS está ativado, o registro de cada dispo-sitivo é verificado através da digitação de um código numérico aleatório de seis dígitos gerado pelo iPhone.

Uma vez que os dispositivos estejam conectados, o iPhone criptografa e encaminha as mensagens de texto SMS recebidas para cada dispositivo, usando os métodos des-critos na seção iMessage deste documento. As respostas são enviadas de volta para o iPhone usando o mesmo método, para que o iPhone as envie como mensagens de texto usando o mecanismo de transmissão SMS da operadora. O Encaminhamento de Mensagens pode ser ativado ou desativado nos ajustes do Mensagens.

Instant HotspotOs dispositivos iOS que oferecem suporte ao Instant Hotspot usam Bluetooth Low Energy para descoberta e comunicação com dispositivos que tenham uma sessão ini-ciada na mesma conta do iCloud. Computadores Mac compatíveis (com OS X Yosemite e posterior) usam a mesma tecnologia para descoberta e comunicação com dispositi-vos iOS que usam Instant Hotspot.

Quando um usuário entra nos Ajustes de Wi-Fi no dispositivo iOS, o dispositivo emite um sinal Bluetooth Low Energy contendo um identificador com o qual todos os dis-positivos que tenham uma sessão iniciada na mesma conta do iCloud concordam. O identificador é gerado de um DSID (Identificador de Sinalização de Destino) atrelado à conta do iCloud e alternado periodicamente. Quando outros dispositivos que tenham uma sessão iniciada na mesma conta do iCloud estão próximos e oferecem suporte ao acesso pessoal, eles detectam o sinal e respondem, comunicando disponibilidade.

Quando um dispositivo disponível é escolhido como acesso pessoal, uma solicitação para ativar o Acesso Pessoal é enviada para o mesmo. A solicitação é enviada através de um link usando criptografia Bluetooth Low Energy, criptografado de forma similar ao iMessage. O dispositivo então responde através do mesmo link Bluetooth Low Energy usando a mesma criptografia por mensagem com informações de conexão para o acesso pessoal.


Sugestões do SpotlightA busca do Safari e a busca do Spotlight incluem sugestões de busca da Internet, apli-cativos, iTunes, App Store, horários de filmes, localizações próximas e outras.

Para tornar as sugestões mais relevantes aos usuários, o contexto usado, os comentá-rios da busca e as solicitações de busca são enviados à Apple. O contexto enviado com as solicitações de busca fornecem à Apple: i) a localização aproximada do dispositivo; ii) o tipo do dispositivo (por ex.: Mac, iPhone, iPad, ou iPod); iii) o aplicativo cliente, que é o Spotlight ou o Safari; iv) o idioma padrão e os ajustes de região do dispositivo; v) os três aplicativos usados por último no dispositivo; e vi) um ID de sessão anônimo. Todas as comunicações com o servidor são criptografadas via HTTPS.

Para ajudar a proteger a privacidade do usuário, as Sugestões do Spotlight nunca enviam a localização exata, acobertando-a no cliente antes de enviá-la. O nível de acobertamento é baseado na densidade populacional estimada da localização do dispositivo; por exemplo, em localizações rurais, mais acobertamento é usado, enquan-to em centros metropolitanos (onde usuários encontram-se mais próximos), menos acobertamento é usado. Além disso, os usuários podem desativar o envio de todas as informações de localização à Apple no aplicativo Ajustes, bastando desativar os Serviços de Localização para as Sugestões do Spotlight. Se os Serviços de Localização estiverem desativados, a Apple poderá usar o endereço IP do cliente para deduzir uma localização aproximada.

O ID de sessão anônimo permite que a Apple analise padrões entre consultas con-duzidas em um período de 15 minutos. Por exemplo, se usuários buscam “Telefone do bar” com frequência logo depois de buscarem por “Bar”, a Apple poderá aprender a disponibilizar o número de telefone nos resultados mais rapidamente. No entanto, e ao contrário da maioria dos buscadores, o serviço de busca da Apple não usa um identificador pessoal persistente sobre o histórico de busca de um usuário para atrelar as consultas ao usuário ou ao dispositivo; ao invés disso, os dispositivos da Apple usam um ID de sessão anônimo temporário por um período máximo de 15 minutos antes de descartá-lo.

As informações sobre os três aplicativos usados por último no dispositivo são incluídas como contexto adicional de busca. Para proteger a privacidade dos usuários, apenas os aplicativos que estiverem na lista de aplicativos populares permitidos mantida pela Apple e que tenham sido acessados nas últimas três horas são incluídos.

Os comentários da busca enviados à Apple fornecem: i) o tempo entre as ações do usuário, como o pressionamento de teclas e a seleção de resultados; ii) o resultado das Sugestões do Spotlight, se houver; e iii) o tipo de resultado local selecionado (por ex.: “Favorito” ou “Contato”). Assim como o contexto da busca, os comentários da busca não estão atrelados a nenhuma pessoa ou dispositivo específico.

A Apple retém os registros das Sugestões do Spotlight com consultas, contexto e comentários por até 18 meses. Registros reduzidos, que incluem apenas a consul-ta, país, idioma, data (com hora) e tipo do dispositivo são retidos por até dois anos. Endereços IP não são retidos com os registros das consultas.

Em alguns casos, as Sugestões do Spotlight podem encaminhar consultas de palavras e frases comuns a um associado qualificado para que seja possível receber e exibir os resultados da busca provenientes do associado. Essas consultas não são armazena-das pelo associado qualificado e associados não recebem comentários de buscas. Os associados também não recebem o endereço IP do usuário. As comunicações com o associado são criptografadas via HTTPS. A Apple fornecerá a localização da cidade, tipo do dispositivo e idioma do cliente como contexto de busca ao associado com base nas localizações, tipos de dispositivo e idiomas dos quais consultas repetidas sejam identi-ficadas pela Apple.


As Sugestões do Spotlight podem ser desativadas para o Spotlight, para o Safari ou para ambos em Ajustes. Se desativado para o Spotlight, o Spotlight voltará a ser um cliente de busca local, somente no dispositivo, que não transmite informações à Apple. Se desativado para o Safari, as buscas, o contexto da busca e os comentários da busca não serão transmitidos à Apple.

O Spotlight também inclui mecanismos para que o conteúdo armazenado localmente no dispositivo seja pesquisável:

• A API CoreSpotlight, que permite que a Apple e aplicativos de terceiros passem con-teúdo indexável ao Spotlight.

• A API The NSUserActivity, que permite que a Apple e aplicativos de terceiros passem informações ao Spotlight sobre as páginas de aplicativos visitadas pelo usuário.

O Spotlight mantém um índice (armazenado no dispositivo) das informações recebidas através desses dois métodos para que os resultados desses dados possam ser mostra-dos quando o usuário fizer uma busca ou, automaticamente, quando o Spotlight for aberto. Há também uma API local de busca combinada, disponível apenas para aplica-tivos fornecidos pela Apple, que permite que o Spotlight passe as buscas do usuário para o processamento e recebimento dos resultados por aplicativos.


Controles do Dispositivo

O iOS oferece suporte a políticas e configurações de segurança flexíveis de fácil apli-cação e gerenciamento. Isso permite que empresas protejam informações corporativas e garante que o cumprimento dos requisitos empresariais pelos funcionários, mesmo que eles usem dispositivos próprios (como parte do programa “traga o seu próprio dispositivo”, por exemplo).

As empresas podem usar recursos como proteção por código, perfis de configuração, apagamento remoto e soluções MDM de terceiros para gerenciar uma gama de dispo-sitivos, ajudando a manter os dados corporativos em segurança, mesmo quando esses dados são acessados pelos funcionários em seus dispositivos iOS pessoais.

Proteção por códigoPor padrão, o código do usuário pode ser definido por um PIN numérico. Em disposi-tivos com Touch ID, o tamanho mínimo do código é de seis dígitos. Em outros dispo-sitivos, o tamanho mínimo é de quatro dígitos. Os usuários podem selecionar “Código Alfanumérico Personalizado” nas “Opções de Código” em Ajustes > Código pra especi-ficar um código alfanumérico maior. Códigos maiores e mais complexos são recomen-dados para uso empresarial por serem mais difíceis de adivinhar ou atacar.

Os administradores podem exigir códigos complexos e outras políticas usando MDM, Exchange ActiveSync ou requisitando que os usuários instalem perfis de configuração manualmente. As seguintes políticas de código estão disponíveis:

• Permitir valor simples;

• Exigir valor alfanumérico;

• Tamanho mínimo do código;

• Número mínimo de caracteres complexos;

• Duração mínima do código;

• Histórico de código;

• Tempo limite de bloqueio automático;

• Período de tolerância para bloqueio do dispositivo;

• Número máximo de tentativas erradas;

• Permitir Touch ID.

Para obter detalhes sobre cada política, consulte a documentação Configuration Profile Key Reference em https://developer.apple.com/library/ios/featuredarticles/ iPhoneConfigurationProfileRef/.

https://developer.apple.com/library/ios/featuredarticles/iPhoneConfigurationProfileRef/



Modelo de emparelhamento do iOSO iOS usa um modelo de emparelhamento para controlar o acesso a um dispositivo a partir de um computador host. O emparelhamento estabelece um relacionamento de confiança entre o dispositivo e o host conectado, simbolizado pela troca de chaves públicas. Usuários de iOS usam essa demonstração de confiança para ativar funciona-lidades adicionais com o host conectado, como a sincronização de dados. No iOS 9, os serviços que exigem emparelhamento não podem ser iniciados até que o dispositivo seja desbloqueado pelo usuário.

O processo de emparelhamento requer que o usuário desbloqueie o dispositivo e acei-te o pedido de emparelhamento do host. Depois disso, o host e o dispositivo trocam e salvam chaves públicas RSA de 2048 bits. O host então recebe uma chave de 256 bits que pode desbloquear uma bolsa de chaves de guarda armazenada no dispositivo (consulte “Bolsa de chaves de guarda” na seção “Bolsa de chaves”). As chaves trocadas são usadas para iniciar uma sessão SSL criptografada, a qual é exigida pelo dispositivo antes que ele envie dados protegidos ao host ou inicie um serviço (sincronização do iTunes, transferência de arquivo, desenvolvimento Xcode, etc). O dispositivo exige que as conexões de um host via Wi-Fi usem essa sessão criptografada para todas as comu-nicações, portanto ele deve ser emparelhado via USB previamente. O emparelhamento também ativa diversos recursos de diagnóstico. No iOS 9, os registros de emparelha-mentos expiram se não forem usados por mais de seis meses. Para obter mais informa-ções, consulte https://support.apple.com/pt-br/HT6331.

Alguns serviços, incluindo com.apple.pcapd, são restritos ao uso somente via USB. Além disso, o serviço com.apple.file_relay requer que um perfil de configuração assinado pela Apple esteja instalado.

O usuário pode usar as opções “Redefinir Ajustes de Rede” ou “Redefinir Localização/Privacidade” para limpar a lista de hosts confiáveis. Para obter mais informações, consulte https://support.apple.com/pt-br/HT5868.

Exigência de configuraçõesUm perfil de configuração é um arquivo XML que permite que administradores distri-buam informações de configuração para dispositivos iOS. Os ajustes definidos por um perfil de configuração instalado não podem ser alterados pelo usuário. Se o usuário apagar um perfil de configuração, todos os ajustes definidos pelo perfil também serão removidos. Dessa forma, os administradores podem exigir ajustes atrelando politicas ao acesso. Por exemplo, um perfil de configuração que fornece configurações de e-mail também pode especificar uma política de código do dispositivo. Os usuários não poderão acessar e-mails caso seus códigos não cumpram os requisitos definidos pelo administrador.

Um perfil de configuração do iOS contém diversos ajustes que podem ser especificados, incluindo:

• Políticas de código;

• Restrições aos recursos do dispositivo (desativação da câmera, por exemplo);

• Ajustes de Wi-Fi;

• Ajustes de VPN;

• Ajustes de servidor do Mail;

• Ajustes do Exchange;

• Ajustes do serviço de diretório LDAP;

• Ajustes do serviço de calendário CalDAV;

• Web clips;




• Credenciais e chaves;

• Ajustes avançados de rede celular.

Um perfil de configuração pode ser assinado e criptografado para validar sua origem, garantir sua integridade e proteger seu conteúdo. Os perfis de configuração são cripto-grafados usando CMS (RFC 3852), com suporte a 3DES e AES-128.

Um perfil de configuração também pode ser bloqueado em um dispositivo para impe-dir completamente sua remoção ou para permitir sua remoção somente com um códi-go. Já que vários usuários empresariais usam seus próprios dispositivos iOS, os perfis de configuração que vinculam um dispositivo a um servidor MDM podem ser removidos, embora tal ação também remova todas as informações de configuração gerenciada, dados e aplicativos.

Os usuários podem instalar perfis de configuração diretamente em seus dispositivos usando o Apple Configurator ou perfis transferidos através do Safari, enviados por e-mail ou por meio de uma conexão sem fio usando um servidor MDM.

Gerenciamento de dispositivos móveis (MDM)O suporte do iOS ao MDM permite que empresas configurem e gerenciem com segu-rança a implementação em larga escala de dispositivos iOS em suas organizações. Os recursos MDM são construídos sobre tecnologias iOS existentes, como perfis de confi-guração, inscrição via conexão sem fio e serviço de Notificações Push da Apple (APNs). Por exemplo, o APNs é usado para despertar o dispositivo para que ele se comunique diretamente com seu servidor MDM através de uma conexão segura. Nenhuma infor-mação confidencial ou proprietária é transmitida via APNs.

Através do uso do MDM, os departamentos podem registrar dispositivos iOS em ambientes empresariais, configurar e atualizar ajustes via conexão sem fio, monitorar a conformidade com as políticas corporativas e até mesmo apagar ou bloquear disposi-tivos gerenciados. Para obter mais informações sobre o gerenciamento de dispositivos móveis, consulte www.apple.com/iphone/business/it/management.html.

iPad CompartilhadoiPad Compartilhado é um modo multiusuário para utilização em implantações de iPads educacionais. Permite que estudantes compartilhem um iPad sem compartilhar docu-mentos e dados. iPad Compartilhado requer o uso de um ID Apple Gerenciado emitido e pertencente à escola. iPad Compartilhado permite a um aluno iniciar a sessão em qualquer dispositivo de propriedade organizacional que esteja configurado para uso por vários alunos.

Os dados do aluno são particionados em diretórios iniciais separados, todo protegi-dos por permissões UNIX e isolamento. Quando um aluno inicia a sessão, o ID Apple Gerenciado é autenticado com servidores de identidade Apple por meio de protocolo SRP. Se bem-sucedido, um token de acesso de curta duração específico é concedido ao dispositivo. Se o aluno já tiver utilizado o dispositivo, ele já terá uma conta de usu-ário local desbloqueada. Se o aluno ainda não tiver utilizado o dispositivo, um novo ID de usuário UNIX, diretório inicial e chaves são fornecidos (se o dispositivo não estiver conectado à Internet, somente usuários com contas locais pré-existentes poderão ini-ciar a sessão).

Após a conta local do aluno ter sido desbloqueada ou criada, autenticando-se remo-tamente, o token de curta duração emitido pelos servidores Apple será convertido em um token do iCloud que permite iniciar a sessão no iCloud. Em seguida, os ajustes do aluno são restaurados e seus documentos e dados são sincronizados do iCloud.

http://www.apple.com/iphone/business/it/management.html


Enquanto a sessão do aluno estiver ativa e o dispositivo permanecer on-line, documen-tos e dados serão armazenados no iCloud à medida que forem criados ou modificados. Além disso, um mecanismo de sincronização em segundo plano garante que as altera-ções sejam enviadas ao iCloud após o aluno encerrar a sessão.

Apple School Manager

O Apple School Manager é um serviço para instituições educacionais, que permite que elas comprem conteúdo, configurem o registro automático de dispositivos em soluções de gerenciamento de dispositivo (MDM), criem contas para alunos e funcionários, além de configurar cursos do iTunes U. O Apple School Manager pode ser acessado na web e foi projetado para gerentes de tecnologia, administradores de TI, funcionários e instrutores.

Registro de Dispositivos

O Programa de Registro de Dispositivos (DEP) fornece uma maneira rápida e eficiente de implementar dispositivos iOS comprados por empresas diretamente da Apple ou através de Revendedores Autorizados Apple e operadoras. O registro de dispositivos também é um recurso integrado do Apple School Manager para instituições de ensino.

Organizações podem registrar os dispositivos automaticamente no MDM sem que seja preciso tocá-los fisicamente ou prepará-los antes que os usuários os obtenham. Depois de registrar-se no programa, os administradores iniciam a sessão no site do programa e vinculam o programa ao seu servidor MDM. Os dispositivos que eles compraram poderão então ser atribuídos a usuários via MDM. Uma vez que o usuário seja atribuído, quaisquer configurações, restrições ou controles MDM específicos são instalados auto-maticamente. Toda a comunicação entre dispositivos e servidores Apple é criptografada em trânsito via HTTPS (SSL).

O processo de configuração para os usuários pode ser simplificado ainda mais remo-vendo passos específicos do Assistente de Configuração, para que eles comecem a usar os dispositivos rapidamente. Os administradores também podem controlar se o usuário pode remover o perfil MDM do dispositivo e assegurar a implementação de restrições do dispositivo desde o início. Uma vez que o dispositivo seja retirado da caixa e ativado, ele é registrado no MDM da empresa — e todos os ajustes de gerenciamento, aplicati-vos e livros são instalados.

Para obter mais informações, consulte Ajuda Programa de Registro de Dispositivos ou, para instituições de ensino, consulte Ajuda Apple School Manager.

Nota: o registro de dispositivos não está disponível em todos os países ou regiões.

Apple Configurator 2Além do MDM, o Apple Configurator para OS X facilita a configuração e pré-configura os dispositivos antes que sejam distribuídos aos usuários. O Apple Configurator pode ser utilizado para pré-configurar rapidamente dispositivos com aplicativos, dados, restrições e ajustes. O Apple Configurator 2 permite que você utilize o Apple School Manager (para ensino) ou o Programa de Registro de Dispositivos (para empresas) para registrar dispositivos em uma solução de gerenciamento de dispositivos móveis (MDM) sem que os usuários precisem utilizar o Assistente de Configuração.

https://help.apple.com/deployment/business/e3



SupervisãoDurante a configuração de um dispositivo, uma empresa pode configurá-lo para que ele seja supervisionado. A supervisão denota que um dispositivo é de propriedade institu-cional, o que fornece controle adicional sobre sua configuração e definição de restrições. Os dispositivos podem ser supervisionados durante a configuração por meio do Apple School Manager, do Programa de Registro de Dispositivos ou do Apple Configurator.

Para obter mais informações sobre como configurar e gerenciar dispositivos usando MDM ou o Apple Configurator, consulte iOS Deployment Reference (em inglês).

RestriçõesOs administradores podem restringir recursos do dispositivo através da instalação de perfis de configuração. Algumas das restrições disponíveis incluem:• Permitir a instalação de aplicativos;• Permitir confiar em aplicativos empresariais;• Permitir o uso da câmera;• Permitir FaceTime;• Permitir capturas de tela;• Permitir discagem por voz enquanto bloqueado;• Permitir sincronização automática enquanto em roaming;• Permitir compras dentro do app;• Permitir a sincronização de e-mails recentes;• Forçar o usuário a digitar a senha da loja para todas as compras;• Permitir Siri enquanto o dispositivo estiver bloqueado;• Permitir o uso da iTunes Store;• Permitir documentos de fontes gerenciadas em destinos não gerenciados;• Permitir documentos de fontes não gerenciadas em destinos gerenciados;• Permitir a sincronização das Chaves do iCloud;• Permitir a atualização do banco de dados de confiança de certificados via conexão

sem fio;• Permitir a exibição de notificações na tela Bloqueada;• Forçar o uso de senhas de emparelhamento para conexões AirPlay;• Permitir que o Spotlight mostre conteúdo da Internet gerado pelo usuário;• Ativar as Sugestões do Spotlight no Spotlight;• Permitir Handoff;• Tratar AirDrop como destino não gerenciado;• Permitir o backup de livros empresariais;• Permitir anotações e marcadores em livros empresariais para sincronização entre os

dispositivos do usuário;• Permitir o uso do Safari;• Ativar o preenchimento automático do Safari;• Forçar o Aviso de Site Fraudulento;• Ativar o JavaScript;• Limitar a publicidade rastreada no Safari;• Bloquear pop-ups;• Aceitar cookies;• Permitir o backup do iCloud;• Permitir a sincronização de documentos e valores de chaves do iCloud;• Permitir Álbuns Compartilhados;• Permitir que diagnósticos sejam enviados à Apple;• Permitir que o usuário aceite certificados TLS não confiáveis;

https://help.apple.com/deployment/ios


• Forçar backups criptografados;• Permitir Touch ID;• Permitir acesso à Central de Controle a partir da tela Bloqueada;• Permitir a visualização de Hoje a partir da tela Bloqueada;• Exigir a detecção de braço no Apple Watch. • Permitir a observação de tela na Sala de Aula• Usar AirDrop a partir de um aplicativo gerenciado• Autorizar um novo desenvolvedor de aplicativo empresarial• Usar a Fototeca do iCloud

Restrições somente de supervisionamento• Permitir iMessage;• Permitir a remoção de aplicativos; • Permitir a instalação manual de perfis de configuração;• Proxy de rede global para HTTP;• Permitir o emparelhamento com computadores para sincronização de conteúdo;• Restringir conexões AirPlay com uma lista de permissão e códigos de conexões

opcionais;• Permitir AirDrop;• Permitir modificações no Buscar Amigos;• Permitir Modo de Aplicativo Único para certos aplicativos gerenciados;• Permitir modificações na conta;• Permitir modificações nos dados celulares;• Permitir emparelhamento com host (iTunes);• Permitir o Bloqueio de Ativação;• Impedir Apagar Conteúdo e Ajustes;• Impedir a ativação de restrições;• Filtro de conteúdo de terceiros;• Modo de Aplicativo Único;• VPN Sempre Ativa; • Permitir modificação no código;• Permitir o emparelhamento com Apple Watch;• Permitir a transferência automática de aplicativos;• Permitir predições, correção automática, verificação ortográfica e atalhos no teclado. • Permitir o Apple Music• Permitir Rádio• Observação de tela na Sala de Aula• Alterações nos ajustes de Notificações• Mostrar ou ocultar aplicativos específicos na tela de Início• Instalar aplicativos por meio da App Store• Transferência automática de aplicativos• Atalhos de teclado• Permitir Definição• Modificar o nome do dispositivo• Alterar o papel de parede• Ocultar o aplicativo News• Emparelhar com o Apple Watch

Para obter mais informações sobre os controles adicionais para dispositivos supervisio-nados, consulte: Configuration Profile Reference.


https://developer.apple.com/library/ios/featuredarticles/iPhoneConfigurationProfileRef/iPhoneConfigu


Apagamento RemotoDispositivos iOS podem ser apagados remotamente por um administrador ou usuário. O apagamento remoto imediato é executado através do descarte seguro da chave de criptografia do armazenamento de bloco do Armazenamento Apagável, o que torna todos os dados ilegíveis. O comando de apagamento remoto pode ser iniciado via MDM, Exchange ou iCloud.

Quando um comando de apagamento remoto é acionado via MDM ou iCloud, o dispositivo atesta seu recebimento e realiza o apagamento. No caso de apagamento remoto via Exchange, o dispositivo verifica com o Servidor Exchange antes de realizar o apagamento.

Os usuários também podem usar o aplicativo Ajustes para apagar dispositivos que estiverem em sua posse. E, conforme já mencionado, os dispositivos podem ser confi-gurados para serem apagados após uma série de tentativas malsucedidas de digitação do código.

Modo PerdidoSe um dispositivo for perdido ou furtado, um administrador de MDM pode ativar remotamente o Modo Perdido em um dispositivo supervisionado com iOS 9.3 ou pos-terior. Quando o Modo Perdido está ativado, o usuário atual tem a sessão encerrada e o dispositivo não pode ser desbloqueado. A tela mostra uma mensagem que pode ser personalizada pelo administrador, como por exemplo o número de telefone para o qual ligar caso o dispositivo seja encontrado. Quando o dispositivo é colocado em Modo Perdido, o administrador pode solicitar que o dispositivo envie sua localização atual. Quando o administrador desativa o Modo Perdido, que é a única maneira de sair do modo, o usuário é informado dessa ação por meio de uma mensagem na tela de bloqueio e um alerta na Tela de Início.

Bloqueio de Ativação Quando o Buscar iPhone está ativado, o dispositivo não pode ser reativado sem que as credenciais do ID Apple do usuário sejam digitadas.

Com dispositivos pertencentes a uma organização, é recomendável supervisionar dis-positivos de modo que o Bloqueio de Ativação possa ser gerenciado pela organização em vez de encarregar o usuário de digitar suas credenciais de ID Apple a fim de reati-var os dispositivos.

Em dispositivos supervisionados, uma solução MDM compatível pode armazenar um código de sobreposição quando o Bloqueio de Ativação está ativado e usá-lo mais tarde para eliminar o Bloqueio de Ativação automaticamente, quando o dispositivo precisar ser apagado e atribuído a um novo usuário. Consulte a documentação da sua solução MDM para obter detalhes.

Por padrão, os dispositivos supervisionados nunca estão com o Bloqueio de Ativação ativado, mesmo que o usuário ative o Buscar iPhone. No entanto, um servidor MDM pode obter um código de sobreposição e permitir que o Bloqueio de Ativação seja ativado no dispositivo. Se o Buscar iPhone estiver ativo quando o servidor MDM ativar o Bloqueio de Ativação, ele será ativado nesse momento. Se o Buscar iPhone estiver inativo quando o servidor MDM ativar o Bloqueio de Ativação, ele será ativado da pró-xima vez que o usuário ativar o Buscar iPhone.

Para dispositivos utilizados em contexto educacional com um ID Apple Gerenciado criado por meio do Apple School Manager, o Bloqueio de Ativação pode ser vinculado a um ID Apple de administrador em vez do ID Apple do usuário, ou desativado por meio do código do dispositivo.


Controles de Privacidade

A Apple leva a privacidade de seus clientes a sério e oferece muitas opções e controles integrados que permitem que os usuários de iOS decidam como e quando os aplicati-vos usam suas informações, assim como quais informações são utilizadas.

Serviços de LocalizaçãoOs Serviços de Localização usam GPS, Bluetooth, hotspots Wi-Fi obtidos pela contribui-ção de um grande número de pessoas e localizações de torres de redes celulares para determinar a localização aproximada do usuário. Os Serviços de Localização podem ser desativados, bastando desligar um seletor em Ajustes, ou os usuários podem aprovar o acesso para cada aplicativo que use o serviço. Os aplicativos podem solicitar o rece-bimento de dados de localização quando estiverem em uso ou sempre. Os usuários podem optar por não permitir o acesso e alterar essa escolha a qualquer momento nos Ajustes. Nos Ajustes, o acesso pode ser definido para nunca permitir, permitir durante o uso ou sempre, dependendo da necessidade de uso de localização do aplicativo. E mais, se um aplicativo com acesso para sempre usar a localização utilizar essa per-missão quando estiver em segundo plano, os usuários serão lembrados da aprovação, podendo alterar o acesso do aplicativo.

Além disso, os usuários possuem controles detalhados sobre serviços do sistema que usam informações de localização. Isso inclui a possibilidade de desativar a inclusão de informações de localização nas informações coletadas pelos serviços de uso e diagnósti-co usados pela Apple para melhorar o iOS, informações baseadas em localização da Siri, contexto baseado em localização de buscas das Sugestões do Spotlight, condições de trânsito locais e locais visitados frequentemente para estimativa do tempo de viagem.

Acesso a dados pessoais O iOS ajuda a impedir que aplicativos acessem as informações pessoais de um usuário sem a sua permissão. Além disso, nos Ajustes, os usuários podem ver quais aplicativos foram permitidos a acessar certas informações, assim como conceder ou revogar qual-quer acesso futuro. Isso inclui o acesso a:

• Contatos; • Microfone;• Calendários; • Câmera;• Lembretes; • HomeKit;• Fotos; • HealthKit;• Atividade de movimento no iPhone 5s • Compartilhamento Bluetooth;

ou posterior;• Biblioteca de Mídia• Contas sociais, como Twitter

e Facebook.

Se o usuário iniciar a sessão no iCloud, os aplicativos recebem acesso ao iCloud Drive por padrão. Os usuário podem controlar o acesso de cada aplicativo na seção iCloud dos Ajustes. Além disso, o iOS fornece restrições que impedem o movimento de dados entre aplicativos e contas instaladas via MDM e aqueles instalados pelo usuário.


Política de privacidadeA política de privacidade da Apple está disponível on-line em https://www.apple.com/br/legal/privacy.

https://www.apple.com/br/legal/privacy

64Segurança do iOS — White Paper | Maio de 2016

Conclusão

64

Um compromisso com a segurançaA Apple está comprometida a ajudar na proteção de clientes usando tecnologias de privacidade e segurança de ponta, criadas para o resguardo de informações pessoais, assim como métodos abrangentes para ajudar a proteger dados corporativos em ambientes empresariais.

A segurança é parte integral do iOS. Desde a plataforma, passando pela rede, até os aplicativos, tudo aquilo que uma empresa precisa está disponível na plataforma iOS. Juntos, esses componentes dão ao iOS a liderança em segurança, sem comprometer a experiência do usuário.

A Apple usa uma infraestrutura de segurança consistente e integrada por todo o iOS e ecossistema de aplicativos iOS. A criptografia de armazenamento baseada em hardwa-re fornece a possibilidade de apagamento remoto quando um dispositivo é perdido e permite que usuários removam todas as informações corporativas e pessoais com-pletamente ao vender ou transferir um dispositivo para outra pessoa. Além disso, as informações de diagnóstico são coletadas anonimamente.

Os aplicativos iOS feitos pela Apple são construídos tendo em mente a segurança aprimorada. O Safari oferece navegação segura com suporte a Online Certificate Status Protocol (OCSP), certificados EV e alertas de verificação de certificados. O Mail compara certificados de e-mails autenticados e criptografados através do suporte a S/MIME (o qual permite S/MIME por mensagem) para que os usuários de S/MIME possam optar por sempre assinar e criptografar mensagens por padrão ou controlar seletivamente como cada mensagem é protegida. O iMessage e o FaceTime também fornecem crip-tografia de cliente a cliente.

No caso de aplicativos de terceiros, a combinação da assinatura de código exigida, isolamento e direitos fornece uma proteção sólida aos usuários contra vírus, malware e outros aproveitamentos mal intencionados que comprometem a segurança de outras plataformas. O processo de envio à App Store visa proteger ainda mais os usuários desses riscos através da revisão de cada aplicativo do iOS antes que ele seja disponibi-lizado para venda.

Para tirar o máximo de proveito dos apurados recursos de segurança integrados ao iOS, empresas são encorajadas a analisar suas políticas de TI e segurança para garantir que o melhor uso possível das camadas de tecnologia de segurança oferecidas por esta plataforma sejam aplicados.

A Apple mantém uma equipe de segurança exclusiva para oferecer suporte a todos os produtos da Apple. A equipe fornece auditoria e teste de segurança de produtos em desenvolvimento, assim como para produtos já lançados. A equipe da Apple também fornece ferramentas e treinamento de segurança e monitora ativamente os relató-rios de novos problemas e ameaças de segurança. A Apple é membro do Forum of Incident Response and Security Teams (FIRST). Para saber mais sobre como comunicar problemas à Apple e assinar notificações de segurança, visite apple.com/br/support/security.

https://www.apple.com/br/support/security/


Aleatorização do espaçode endereço (ASLR)

Técnica empregada pelo iOS para dificultar o êxito do aproveitamento mal-intencionado em erros de software. A garantia de imprevisibilidade de endereços e offsets da memória, impossi-bilita o hardcode desses valores pelo código de aproveitamento. No iOS 5 e posterior, a posição de todos os aplicativos e bibliotecas do sistema são aleatorizados, juntamente aos aplicativos de terceiros compilados como executáveis de posição independente.

Armazenamento Apagável Área dedicada do armazenamento NAND, usada para armazenar chaves criptográficas, que pode ser endereçada diretamente e apagada com segurança. Mesmo não fornecendo proteção caso ocorra um ataque físico ao dispositivo, as chaves armazenadas no Armazenamento Apa-gável podem ser usadas como parte de uma hierarquia de chaves para facilitar o apagamento rápido e invocar segurança.

Atualização do Firmware do Dispositivo (DFU)

Modo no qual o código ROM de Inicialização aguarda por recuperação via USB. A tela fica preta quando no modo DFU, mas ao conectar-se a um computador com o iTunes aberto, o seguinte diálogo é apresentado: “O iTunes detectou um iPad em modo de recuperação. Você precisa restaurar esse iPad para poder utilizá-lo com o iTunes.”

Bolsa de chaves Estrutura de dados usada para armazenar uma coleção de chaves de classe. Cada tipo (usuário, dispositivo, sistema, backup, guarda ou Backup do iCloud) possui o mesmo formato:• Um cabeçalho contendo:– Versão (definida em 3 no iOS 5);– Tipo (sistema, backup, guarda ou Backup do iCloud);– UUID da bolsa de chaves;– Um HMAC se a bolsa de chaves for assinada;– O método usado para embalar as chaves de classe: trançado com o UID ou PBKDF2, junta-

mente com o sal e contagem de iteração.• Uma lista de chaves de classe:– UUID principal;– Classe (de qual classe de Proteção de Dados de arquivo ou chaves);– Tipo usado para embalar (chave derivada somente de UID; chave derivada de UID e chave

derivada de código);– Chave de classe embalada;– Chave pública para classes assimétricas.

Cartão inteligente Circuito integrado e incorporado que fornece identificação, autenticação e armazenamento de dados com segurança.

Chave do sistema de arquivos Chave que criptografa os metadados de cada arquivo, incluindo sua chave de classe. Mantida no Armazenamento Apagável, priorizando facilitar o apagamento rápido em detrimento da confidencialidade.

Chave única por arquivo Chave AES de 256 bits usada para criptografar um arquivo no sistema de arquivos. A chave úni-ca por arquivo é embalada por uma chave de classe e armazenada nos metadados do arquivo.

Chaves Infraestrutura e conjunto de APIs usadas pelo iOS e aplicativos de terceiros para armazenar e obter senhas, chaves e outras credenciais sensíveis.

Circuito integrado (CI) Também chamado de “microchip”.

ECID Um identificador de 64 bits exclusivo ao processador de cada dispositivo iOS. Usado como parte do processo de personalização, ele não é considerado um segredo.

Embalamento de chaves Criptografia de uma chave com outra. O iOS usa o embalamento de chaves NIST AES, conforme o RFC 3394.

Gerenciador de Inicialização de Baixo Nível (LLB)

Código invocado pela ROM de Inicialização, que por sua vez, carrega o iBoot, como parte da cadeia de inicialização segura.

Glossário


iBoot Código carregado pelo LLB, que por sua vez, carrega o XNU, como parte da cadeia de inicializa-ção segura.

ID de Grupo (GID) Semelhante ao UID, mas comum a cada processador de uma classe.

ID Exclusivo (UID) Chave AES de 256 bits gravada em cada processador durante o processo de manufatura. Não pode ser lido por firmware ou software e é usado apenas pelo mecanismo AES de hardware do processador. Para obter a chave em si, seria preciso montar um ataque físico altamente sofisticado e caro contra o silício do processador. O UID não está relacionado a nenhum outro identificador do dispositivo, incluindo, entre outros, o UDID.

Identificador Uniforme de Recursos (URI) String de caracteres que identifica um recurso baseado na web.

Joint Test Action Group (JTAG) Ferramenta padrão de depuração de hardware usada por programadores e desenvolvedores de circuitos.

Mapeamento do ângulo de fluxo dos sulcos Representação matemática da direção e largura dos sulcos extraídos de parte de uma impres-são digital.

Módulo de Segurança de Hardware (HSM) Computador especializado inviolável que resguarda e gerencia chaves digitais.

Perfil de Provisão Arquivo plist assinado pela Apple que contém um conjunto de entidades e direitos permitindo a instalação e o teste de aplicativos em um dispositivo iOS. Um Perfil de Provisão de desenvolvi-mento lista os dispositivos escolhidos por um desenvolvedor para distribuição ad hoc. Um Perfil de Provisão de distribuição contém o ID do aplicativo de aplicativos empresariais.

Proteção de Dados Mecanismo de proteção de arquivos e chaves para iOS. Também pode referir-se às APIs que os aplicativos usam para proteger arquivos e itens das chaves.

ROM de Inicialização Primeiro código executado pelo processador de um dispositivo ao ser inicializado. Por ser parte integral do processador, não pode ser alterado pela Apple ou através de ataque.

Serviço de Identidade (IDS) Diretório da Apple de chaves públicas do iMessage, endereços APNs, números de telefone e endereços de e-mail usados para buscar chaves e endereços de dispositivos.

Serviço de Notificações Push da Apple (APNs) Serviço mundial fornecido pela Apple que entrega notificações push para dispositivos iOS.

System on a chip (SoC) Circuito integrado (CI) que incorpora vários componentes em um único chip. O Enclave Seguro é um SoC dentro do processador central A7 ou posterior da Apple.

Trançamento Processo pelo qual o código de um usuário é transformado em uma chave criptográfica e fortificado com o UID do dispositivo. Isso assegura que ataques de força bruta tenham que ser realizados em um dispositivo específico, diminuindo assim a probabilidade da ocorrência (que não pode ser feita em paralelo). O algoritmo do trançamento (PBKDF2) usa AES chaveado com o UID do dispositivo como função pseudorrandômica (PRF) em cada iteração.

XNU Núcleo dos sistemas operacionais iOS e OS X. Presume-se ser confiável e exige medidas de segurança como assinatura de código, isolamento, verificação de direitos e ASLR.


Histórico de Revisão do Documento

Data Resumo

Maio de 2016 Atualizado para o iOS 9.3

• iPad Compartilhado

• ID Apple Gerenciados

• Autenticação de dois fatores para ID Apple

• Bolsas de chaves

• Certificações de Segurança

• Bloqueio de Ativação

• Notas Seguras

• Apple School Manager

• Modo Perdido

• Para obter mais informações sobre o conteúdo de segurança do iOS 9.3, consulte: support.apple.com/pt-br/HT206166

Setembro de 2015 Atualizado para o iOS 9

• Bloqueio de ativação do Apple Watch;

• Políticas de código;

• Suporte à API do Touch ID;

• A Proteção de dados no A8 usa AES-XTS;

• Bolsas de chaves para atualização de software não supervisionada;

• Atualizações de certificação;

• Modelo de confiança de aplicativo empresarial;

• Proteção de dados para favoritos do Safari;

• Segurança de Transporte em Aplicativos;

• Especificações VPN;

• Acesso Remoto ao iCloud para o HomeKit;

• Cartões de Fidelidade do Apple Pay;

• Aplicativo da administradora de cartões do Apple Pay;

• Indexação local do Spotlight;

• Modelo de Emparelhamento do iOS;

• Apple Configurator;

• Restrições;

• Para obter mais informações sobre o conteúdo de segurança do iOS 9, consulte: support.apple.com/pt-br/HT205212

© 2016 Apple Inc. Todos os direitos reservados. Apple, o logotipo da Apple, AirDrop, AirPlay, Apple TV, Apple Watch, Bonjour, FaceTime, iBooks, iMessage, iPad, iPhone, iPod, iPod touch, iTunes, Chaves, Mac, OS X, Safari, Siri, Spotlight e Xcode são marcas comerciais da Apple Inc., registradas nos EUA e em outros países. Apple Pay, CarPlay, Lightning e Touch ID são marcas comerciais da Apple Inc. iCloud e iTunes Store são marcas de serviço da Apple Inc., registradas nos EUA e em outros países. App Store e iBooks Store são marcas de serviço da Apple Inc. iOS é uma marca comercial ou registrada da Cisco nos EUA e em outros países, sendo utilizada sob licença. A logomarca e os logotipos Bluetooth® são marcas registradas de propriedade da Bluetooth SIG, Inc. e qualquer uso dessas marcas pela Apple é feito sob licença. Java é uma marca registrada da Oracle e/ou de seus afiliados. Outras nomes de produtos e empresas mencionados aqui podem ser marcas comerciais de suas respectivas empresas. As especificações do produto estão sujeitas a alteração sem aviso prévio.



Documents

Segurança do iOS