Segurança do iOS

Transcrição

Segurança do iOS

Segurança do iOS
iOS 9.3 ou posterior
Maio de 2016
Conteúdo
Página 4
Introdução
Página 5
Segurança do Sistema
Cadeia de inicialização segura
Autorização do Software do Sistema
Enclave Seguro
Touch ID
Página 10 Criptografia e Proteção de Dados
Recursos de Segurança do Hardware
Proteção de Dados de Arquivos
Códigos
Classes de Proteção de Dados
Proteção de Dados das Chaves
Acesso às senhas salvas do Safari
Bolsas de chaves
Certificações e programas de segurança
Página 19 Segurança de Aplicativos
Assinatura 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
HomeKit
HealthKit
Notas Seguras
Apple 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 Pay
Componentes do Apple Pay
Como o Apple Pay usa o Elemento Seguro
Como o Apple Pay usa o controlador NFC
Provisão de cartões de crédito e débito
Autorização de pagamentos
Código de segurança dinâmico específico por transação
Pagamentos por proximidade com o Apple Pay
Pagamentos com o Apple Pay dentro de aplicativos
Cartões de fidelidade
Suspensão, remoção e apagamento de cartões
Segurança do iOS – White Paper | Maio de 2016
2
Página 40 Serviços de Internet
ID Apple
iMessage
FaceTime
iCloud
Chaves do iCloud
Siri
Continuidade
Sugestões do Spotlight
Página 55 Controles do Dispositivo
Proteção por código
Modelo de emparelhamento do iOS
Exigência de configurações
Gerenciamento de Dispositivo Celular (MDM)
iPad Compartilhado
Apple School Manager
Registro de Dispositivos
Apple Configurator 2
Supervisão
Restrições
Apagamento Remoto
Modo Perdido
Bloqueio de Ativação
Página 62 Controles de Privacidade
Serviços de Localização
Acesso a dados pessoais
Política de privacidade
Página 64 Conclusão
Um compromisso com a segurança
Página 65 Glossário
Página 67 Histórico de Revisão do Documento
3
Introdução
Classe
Proteção de Dados
Isolamento do Aplicativo
Software
Partição do Usuário
(criptografada)
Partição do SO
Sistema de Arquivos
Núcleo
Enclave
Seguro
Elemento
Seguro
Hardware e
Firmware
Mecanismo de Criptografia
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 trabalhar 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 departamentos de TI não precisem realizar configurações extensas. E os recursos básicos de seguranç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:
Chave do Dispositivo
Chave do Grupo
Certificado de Raiz da Apple
Diagrama da arquitetura de segurança do iOS
com uma visão geral das várias tecnologias
discutidas neste documento.
•Segurança do sistema: o software e o hardware de segurança integrados que servem
de plataforma para o iPhone, iPad e iPod touch.
• Criptografia e proteção de dados: 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 autorizada tentar usá-lo ou modificá-lo.
•Segurança de aplicativos: os sistemas que permitem que os aplicativos sejam executados 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 dispositivo 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.
4
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 pressionado. 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.
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 processo 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 confiabilidade de cada componente do sistema e valida o sistema como um todo. Desde a inicializaçã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 segura
Cada etapa do processo de inicialização contém componentes assinados criptograficamente 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 imediatamente 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 verifica 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 verificadas 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.
5
Autorização do Software do Sistema
A Apple lança atualizações de software regularmente para abordar questões de seguranç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 assinado pela Apple possa ser instalado em um dispositivo. Para impedir que os dispositivos 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 vulnerabilidade 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 atualizaçõ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 completo 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.
6
Enclave Seguro
O Enclave Seguro é um coprocessador fabricado nos processadores A7 ou processadores 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 criptográficas para o gerenciamento principal da Proteção de Dados e mantém a integridade 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 criptografados 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 interface 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 ID
O 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 qualquer â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ódigos
Para 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 impressã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 circunstâncias:
• O dispositivo acabou de ser ligado ou reiniciado;
• O dispositivo não foi desbloqueado por mais de 48 horas;
7
• 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 ID
O 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 autenticaçã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 recebe 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 desbloquear 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.
8
Segurança do Touch ID
O 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 criptografada dentro do Enclave Seguro enquanto é vetorizado para análise e depois descartado. 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 é armazenado 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 iOS
Se 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 descartadas. 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 é bloqueado. 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 digital 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 processo 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.
9
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 inacessí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ência. 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.
A cadeia de inicialização de segurança, a assinatura de código e a segurança do processo 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 apagamento remoto completo e imediato no caso de roubo ou perda do dispositivo.
Recursos de Segurança do Hardware
Em dispositivos móveis, velocidade e eficiência energética são fatores críticos. As operaçõ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 prioridades 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 chaves 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 decriptografia 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 usados 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 dispositivos (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 especí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 identificador 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 inicializaçã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.
10
O apagamento seguro das chaves salvas é tão importante quanto sua geração. É especialmente 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 apagamento 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.
Alé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 hierarquia de chaves, acrescentando às tecnologias de criptografia de hardware integradas 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 desbloqueio das chaves de classe.
Visão geral da arquitetura
Sempre 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 dentro 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, dependendo 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 acordo com o RFC 3394. A chave única por arquivo embalada é armazenada nos metadados 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 conforme 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 processador 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 dispositivo é 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
11
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.
Chave do Sistema
de Arquivos
Chave do
Hardware
Chave de
Classe
Chave do Código
Metadados
do Arquivo
Chave do Arquivo
Conteúdo
do Arquivo
O conteúdo de um arquivo é criptografado com uma chave única por arquivo, embalada 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 alteração do código reembala somente a chave de classe.
Códigos
Considerações sobre código
Se uma senha longa contendo apenas 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).
Ao configurar um código para o dispositivo, o usuário ativa a Proteção de Dados automaticamente. 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 aumenta 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 dispositivo iOS várias vezes ao dia.
Atrasos entre as tentativas
de digitação do código
Tentativas
Atraso Exigido
1-4
nenhum
5
1 minuto
6
5 minutos
7-8
15 minutos
9
1 hora
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 dispositivo 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 administrativa 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.
12
Classes de Proteção de Dados
Quando 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 é realizado 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 compartilhado é 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 dispositivo é bloqueado. A proteção desta classe possui propriedades semelhantes à criptografia 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 decriptografar 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).
13
Componentes de um item das chaves
Juntamente ao grupo de acesso, cada item
das chaves contém metadados administrativos (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 ocupada 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 etiqueta GMAC, calculada durante a criptografia.
Muitos 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 terceiros 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 exclusividade 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
Quando
desbloqueado
NSFileProtectionComplete
kSecAttrAccessibleWhenUnlocked
Enquanto
bloqueado
NSFileProtectionCompleteUnlessOpen
NA
Depois
do primeiro
desbloqueio
NSFileProtectionCompleteUntilFirstUserAuthentication
kSecAttrAccessibleAfterFirstUnlock
Sempre
NSFileProtectionNone
kSecAttrAccessibleAlways
Código ativado
NA
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly
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 comporta da mesma maneira que kSecAttrAccessibleWhenUnlocked, mas fica disponível
apenas quando o dispositivo está configurado com um código. Essa classe existe apenas 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 removido 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.
14
A Apple equilibrou segurança e usabilidade cuidadosamente, escolhendo classes de chaves 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 dispositivo 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
Contas do Exchange
Senhas de VPN
LDAP, CalDAV, CardDAV
Tokens de contas de redes sociais
Chaves de criptografia de anúncio de Handoff
Token do iCloud
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®
Token do serviço de Notificações Push da Apple
Certificados e chaves privadas do iCloud
Chaves do iMessage
Certificados e chaves privadas instalados pelo Perfil de Configuração Sempre, não migratório
PIN do SIM
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 especificaçã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 Safari
Os aplicativos do iOS podem interagir com itens de chaves salvos pelo Safari para preenchimento automático de senha usando as duas APIs a seguir:
• SecRequestSharedWebCredential
• SecAddSharedWebCredential
15
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 exclusivos 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 arquivo liste o identificador do aplicativo sendo instalado, o iOS assinala que o site e o aplicativo 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 chaves
As 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.
A bolsa de chaves do usuário é onde as chaves de classe embaladas, usadas em operaçõ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 novamente 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 bloqueio 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 desembrulhadas corretamente.
A bolsa de chaves do dispositivo é utilizada para armazenar as chaves de classe
embaladas para operações que envolvem dados específicos de dispositivo. Os dispositivos 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.
A bolsa de chaves do backup é 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 criptografados 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 originalmente 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.
16
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.
A bolsa de chaves de guarda é 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 sincronizaçã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 iTunes, 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, protegida 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 armazenados 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 tokens 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 software é 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 expira 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.
A bolsa de chaves do Backup do iCloud 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.
17
Certificações e programas de segurança
Nota: 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 programa 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 contrá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 tecnologias importantes de segurança móvel. A Apple continua avaliando e buscando certificaçõ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ça
A 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.
18
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 assinados 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, permitindo 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 aplicativos
Depois 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 aplicativos 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 certificado 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 identidade 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 desenvolvedores 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 organizaçã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 aplicativos 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 qualquer 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.
Segurança do iOS — White Paper | Maio de 2016
19
As empresas também podem desenvolver aplicativos próprios para uso interno e distribuí-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 dispositivos autorizados. Os usuários precisam ter o Perfil de Provisão instalado para executar 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 empresarial 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 aplicativo não tenha sido modificado desde que foi instalado ou atualizado pela última vez.
Segurança do processo de execução
Apó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 é montada 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 aplicativos 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 alterados, 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.
20
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 desenvolvimento do iOS, compila automaticamente os programas de terceiros com o suporte à 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 compilador JavaScript JIT.
Extensões
O 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 extensã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 automaticamente 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 interprocessuais 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
21
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 extensõ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 Aplicativos
Os 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 configurados 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 aplicativos
O 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órios
O programa de licenciamento Made for iPhone, iPod touch e iPad (MFi) fornece a fabricantes 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
22
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 transporte — 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 autenticação garante que apenas os dispositivos aprovados possuam acesso total ao dispositivo. Se um acessório não fornece autenticação, seu acesso é limitado ao áudio analógico 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 trocadas 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).
HomeKit
O 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 HomeKit
A segurança e identidade do HomeKit são baseadas em pares de chaves públicas-privadas 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 dispositivos iOS e acessórios.
As chaves são armazenadas nas Chaves (Keychain) e incluídas apenas em backups criptografados das Chaves. Elas são sincronizadas entre os dispositivos usando as Chaves
do iCloud.
Comunicação entre acessórios HomeKit
Os 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ábrica, 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), utilizando um código de 8 dígitos fornecido pelo fabricante do acessório e digitado no dispositivo 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 é estabelecida 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 locais
O HomeKit armazena os dados de casas, acessórios, cenas e usuários em um dispositivo 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
23
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ários
Os 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 sincronizaçã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 comunicações posteriores são autenticadas e criptografadas usando o protocolo Station-toStation 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 processo 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 casa
O 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 solicitam 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.
Siri
A 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 anonimamente à 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 HomeKit
Os 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.
24
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 comunicaçõ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 processo de configuração.
Os acessórios que oferecem suporte ao acesso remoto do iCloud são fornecidos durante 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 desafio 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.
HealthKit
O 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úde
O 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 desbloquear o dispositivo.
25
Outro banco de dados armazena dados operacionais, como tabelas de acesso de aplicativos, 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 Dados
Os dados armazenados no banco de dados incluem metadados para rastrear a proveniê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 opcional 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), especificado no IETF RFC 5652. Acesso por aplicativos de terceiros
O 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 precisam 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 pedidos 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 é concedido 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 aplicativos infiram o estado de saúde do usuário ao aprender quais tipos de dados o usuário
está rastreando.
Ficha Médica
O 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 informações dos bancos de dados de saúde.
26
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 Seguras
O aplicativo Notas inclui um recurso de Notas Seguras, que permite aos usuários protegerem 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 criptografados 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 sessã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 assegurar 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 digitar 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 Watch
O 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 emparelhamento fora de banda BTLE 4.1. O padrão de emparelhamento BTLE Passkey Entry é
usado como método alternativo, se necessário.
27
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 criptografia é 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 proteçã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 credenciais 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 automaticamente 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 esteja 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 desativado através do aplicativo Apple Watch do iPhone.
O Apple Watch pode ser emparelhado apenas com um iPhone por vez. O emparelhamento 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.
28
Segurança de Rede
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 comprovadas 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 portas 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.
TLS
O 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 dispositivo 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 Aplicativos
A 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 certificados 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 aplicativo substitua a Segurança de Transporte em Aplicativos. Certificados inválidos sempre resultarão em falha e falta de conexão. A Segurança de Transporte em Aplicativos é
aplicada automaticamente a aplicativos compilados para iOS 9.
29
VPN
Os 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 corporativa, mas não os dados pessoais de usuários.
O iOS oferece suporte a VPN Sempre Ativa, o que pode ser configurado em dispositivos 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 escaneamento 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 escaneamentos 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.
30
O iOS também usa um endereço MAC aleatório ao realizar escaneamentos PNO aprimorados (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.
Bluetooth
O 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 Único
O 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-
31
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 AirDrop
Os 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 compartilhar 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 dispositivo remetente cria uma rede Wi-Fi peer-to-peer e anuncia uma conexão AirDrop usando 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 exibidos 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 dispositivo 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 dispositivo 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 controlados por uma solução de gerenciamento de dispositivos móveis.
32
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 Pay
Elemento Seguro: o Elemento Seguro é um chip certificado, padrão do setor, executado 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 Seguro
O Elemento Seguro hospeda um applet feito especificamente para gerenciar o
Apple Pay. Isso também inclui applets de pagamento certificados pelas redes de pagamento. 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 protegidos 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.
33
Como o Apple Pay usa o controlador NFC
Como gateway do Elemento Seguro, o controlador NFC garante que todos os pagamentos 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 respostas 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 proximidade 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 aplicativos são encaminhados ao processador do aplicativo, mas apenas depois de criptografados 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 cartã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 cartão: Campos Obrigatórios, Verificação do Cartão e Vínculo e Provisão. A operadora do cartã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 servidores da Apple. Ao invés disso, um Número de Conta do Dispositivo é criado, criptografado 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 registrados 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.
34
Adição manual de um cartão de crédito ou débito ao Apple Pay
Para 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 captura as informações do cartão, a Apple tenta preencher o nome, número e data de validade 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 atividade 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 complementar 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 Pay
No 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 termos 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 administradora de cartões
Quando o aplicativo está registrado para uso com o Apple Pay, chaves são estabelecidas para o aplicativo e o servidor do comerciante. Essas chaves são usadas para criptografar 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 usadas ao invés do CVC.
35
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 administradora. 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 é oferecido 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 conectados 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 cartão de crédito e persevera enquanto o Apple Pay estiver ativado, protegido pela criptografia 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 anteriormente 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;
36
• 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 pagamento 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 Pay
Se 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 informações de pagamento sejam transmitidas. Quando o Apple Watch está desbloqueado, 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 Pay
O 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ífica 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.
37
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 comerciante 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 aplicativo 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 aplicativo 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 pagamento 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 aplicativo 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 desenvolvedor do aplicativo. O desenvolvedor do aplicativo pode especificar applicationData no
PKPaymentRequest. Um hash desses dados é incluído nos dados de pagamento criptografados. O comerciante é então responsável por verificar se o hash de seu applicationData corresponde àquele incluído nos dados de pagamento.
38
Cartões de fidelidade
Desde 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 compatí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 informaçõ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ões
Os 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 cartões no Elemento Seguro sejam apagados.
39
Serviços de Internet
Criação de senhas fortes para o ID Apple
IDs Apple são usados para a conexão a diversos 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.
A Apple construiu um conjunto de serviços robustos para ajudar os usuários a obterem 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 Apple
Um 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 alteraçõ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 fatores
Para ajudar os usuários a assegurar ainda mais suas contas, a Apple oferece a autenticaçã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 informaçõ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 dispositivo novo e que é seguro iniciar a sessão. Devido a apenas uma senha não ser mais
40
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 armazena 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 passos
Desde 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 dispositivos 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 Gerenciados
Com o iOS 9.3 ou mais recente, os IDs Apple Gerenciados funcionam de maneira semelhante 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 Gerenciados
IDs 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 monitorar 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 armazenado 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.
41
IDs Apple Gerenciados e dispositivos pessoais
IDs 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 disponí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.
iMessage
O iMessage da Apple é um serviço de mensagens para dispositivos iOS e computadores 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úmero 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 mensagens
Para 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 dispositivos 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 dispositivos 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
42
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.
Anexo
criptografado com
chave aleatória
iCloud
APNs
Mensagem assinada e criptografada
para usuário 2 com URI e
chave para anexo
Usuário 1
Usuário 2
Chave pública
e token APNs
para usuário 2
Chave pública
e token APNs
para usuário 1
IDS
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 quando 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.
FaceTime
O 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 estabelecer 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.
43
O FaceTime usa o Estabelecimento de Conectividade via Internet (ICE) para estabelecer 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.
iCloud
O 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 Drive
O iCloud Drive adiciona chaves baseadas em conta para proteger documentos armazenados no iCloud. Assim como em serviços existentes do iCloud, ele divide e criptografa 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 armazenada 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 armazenamento do iCloud Drive.
CloudKit
O CloudKit permite que desenvolvedores de aplicativos armazenem dados de valores
de chaves, dados estruturados e recursos no iCloud. O acesso ao CloudKit é controlado 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 aplicativo (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 semelhante 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
44
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 disponibilizada somente depois de sua autenticação no iCloud.
Chave de
Serviço
do CloudKit
Chave de Zona
do CloudKit
Chave de
Registro
do CloudKit
Metadados
do Arquivo
Lista de Blocos
do Arquivo
Bloco
do Arquivo
Criptografia
Convergente
Backup do iCloud
O iCloud também faz o backup de informações — incluindo os ajustes do dispositivo, 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 seguranç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 supervisionados 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 acessíveis quando o dispositivo está bloqueado, suas chaves únicas por arquivo são criptografadas 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.
45
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 armazenada no conjunto do backup (a senha do iCloud do usuário não é usada para a criptografia, 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 ningué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 seguida, 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.
Integração do Safari com as Chaves do
iCloud
O Safari pode gerar strings aleatórias criptograficamente fortes de forma automática
para criar senhas de sites, que são armazenadas 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.
Chaves do iCloud
As 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 chaves
Quando um usuário ativa as Chaves do iCloud pela primeira vez, o dispositivo estabelece um círculo de confiança e cria uma identidade de sincronização para si. Uma identidade 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 aleató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 identidade 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.
46
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 dispositivo 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 é assinado 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á sincronizado. 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 é exibida 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 criptografia 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.
47
Recuperação das chaves
A 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 especificamente. 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 criptograficamente 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 é embalada 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 guarda
O 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 hardware (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.
48
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 aleató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 restauradas 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.
Siri
Atravé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 grande 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 dispositivo 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 ocorrem 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 localização aproximada, como perguntas sobre o tempo.
Se uma localização mais precisa for necessária (para determinar a localização de cinemas 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.
49
Quando a Siri é usada a partir do Apple Watch, o relógio cria o seu próprio identificador 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 combina 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 anteriormente 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 mesmas regras de outras gravações de voz feitas através da Siri.
Continuidade
A 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.
Handoff
Com 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 criptografia 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
50
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 atividade é protegido e transferido da mesma maneira que uma iMessage.
Handoff entre aplicativos nativos e sites
O 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 criptografados. 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 aplicativo nativo.
Em contrapartida, um aplicativo nativo poderá especificar uma URL alternativa quando 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.
Handoff de dados maiores
Alé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 tecnologia 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ão de Ligações Celulares do iPhone
Quando 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.
51
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 dispositivo, bastando desativar “Ligações via iPhone” nos ajustes do FaceTime.
Encaminhamento de Mensagens do iPhone
O 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 dispositivo é 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 descritos 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 Hotspot
Os dispositivos iOS que oferecem suporte ao Instant Hotspot usam Bluetooth Low
Energy para descoberta e comunicação com dispositivos que tenham uma sessão iniciada 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 dispositivos 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 dispositivos 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.
52
Sugestões do Spotlight
A busca do Safari e a busca do Spotlight incluem sugestões de busca da Internet, aplicativos, 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, enquanto 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 conduzidas 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 consulta, 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 armazenadas 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 identificadas pela Apple.
53
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 conteú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 mostrados 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 aplicativos fornecidos pela Apple, que permite que o Spotlight passe as buscas do usuário
para o processamento e recebimento dos resultados por aplicativos.
54
Controles do Dispositivo
O iOS oferece suporte a políticas e configurações de segurança flexíveis de fácil aplicaçã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 dispositivos, 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ódigo
Por padrão, o código do usuário pode ser definido por um PIN numérico. Em dispositivos com Touch ID, o tamanho mínimo do código é de seis dígitos. Em outros dispositivos, 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 especificar um código alfanumérico maior. Códigos maiores e mais complexos são recomendados 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/.
55
Modelo de emparelhamento do iOS
O 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 funcionalidades 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 aceite 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 comunicaçõ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 emparelhamentos 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ções
Um perfil de configuração é um arquivo XML que permite que administradores distribuam 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;
56
• 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 criptografados 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 impedir completamente sua remoção ou para permitir sua remoção somente com um código. 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 seguranç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 configuraçã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 informaçã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 dispositivos gerenciados. Para obter mais informações sobre o gerenciamento de dispositivos
móveis, consulte www.apple.com/iphone/business/it/management.html.
iPad Compartilhado
iPad Compartilhado é um modo multiusuário para utilização em implantações de iPads
educacionais. Permite que estudantes compartilhem um iPad sem compartilhar documentos 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 protegidos 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 iniciar a sessão).
Após a conta local do aluno ter sido desbloqueada ou criada, autenticando-se remotamente, 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.
57
Enquanto a sessão do aluno estiver ativa e o dispositivo permanecer on-line, documentos 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 automaticamente. 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 removendo 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, aplicativos 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 2
Alé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.
58
Supervisão
Durante 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 institucional, 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ções
Os 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;
59
• 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 supervisionados, consulte: Configuration Profile Reference.
60
Apagamento Remoto
Dispositivos 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 configurados para serem apagados após uma série de tentativas malsucedidas de digitação
do código.
Modo Perdido
Se 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 posterior. 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 dispositivos 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 reativar 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.
61
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 aplicativos usam suas informações, assim como quais informações são utilizadas.
Serviços de Localização
Os 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 recebimento 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 permissã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óstico 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 qualquer acesso futuro. Isso inclui o acesso a:
• Contatos;
• Microfone;
• Calendários;
• Câmera;
• Lembretes;
• HomeKit;
• Fotos;
• HealthKit;
• Atividade de movimento no iPhone 5s ou posterior;
• Compartilhamento Bluetooth;
• 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.
62
Política de privacidade
A política de privacidade da Apple está disponível on-line em
https://www.apple.com/br/legal/privacy.
63
Conclusão
Um compromisso com a segurança
A 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 hardware fornece a possibilidade de apagamento remoto quando um dispositivo é perdido
e permite que usuários removam todas as informações corporativas e pessoais completamente 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 criptografia 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 disponibilizado 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.
Segurança do iOS — White Paper | Maio de 2016
64
Glossário
Aleatorização do espaço
de 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, impossibilita 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 Apagá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, juntamente 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 única 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.
65
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 impressã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 desenvolvimento 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.
66
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.
67

Segurança do iOS

Transcrição

Documentos relacionados

Prova - IDHTec

Linx desenvolve aplicativos para redes de food service

CONCURSO CULTURAL CARTOON NETWORK 20 ANOS e GTV

Caso de Sucesso

Entrada de Horário de Verão

Entrada de Horário de Verão

Chaves Seccionadoras Compactas

Bíblia Plus - Sociedade Bíblica do Brasil

A cabeça de Steve Jobs

Capítulo 8 Conquistando Excelência - SIT2011-1

Transfira a brochura