Segurança de transações via celular documento de discussão - PDF
Download "Segurança de transações via celular documento de discussão"
1 Segurança de transações via celular documento de discussão
2 SOBRE A UL A UL é uma empresa independente e global de destaque no setor de ciências da segurança, defendendo o progresso há 120 anos. Os seus mais de profissionais se pautam pela filosofia da UL, que é promover ambientes seguros para todos trabalharem e viverem. A UL utiliza pesquisas e padrões para se antecipar continuamente e atender às exigências de segurança em constante evolução. A UL firmou parcerias com empresas, fabricantes, associações comerciais e autoridades internacionais de regulamentação, levando soluções a uma cadeia de fornecimento global mais complexa. A divisão Segurança das transações da UL orienta as empresas nos domínios da telefonia celular, de pagamentos e transportes públicos pelo complexo mundo das transações eletrônicas. A UL é líder global na garantia de segurança, cumprimento de normas e interoperabilidade global. Ela oferece recomendações, presta serviços de testes e certificação, avaliações de segurança e ferramentas de testes, durante todo o ciclo do processo de desenvolvimento do seu produto ou da implementação de novas tecnologias. Os funcionários da UL colaboram proativamente com os participantes do setor, definindo padrões e normas robustos. Servindo você localmente, agindo globalmente. A UL é credenciada por organismos do setor, que incluem a Visa, MasterCard, Discover, JCB, American Express, EMVCo, PCI, GCF, ETSI, GSMA, GlobalPlatform, NFC Forum, entre outros. Para obter mais informações, visite SOBRE A GSMA A GSMA representa os interesses das operadoras de telefonia celular do mundo inteiro. A GSMA atua em mais de 220 países e reúne quase 800 operadoras internacionais de telefonia celular, assim como mais de 250 empresas no ambiente mais amplo de telefonia celular, que incluem os fabricantes de aparelhos telefônicos e dispositivos, empresas de software, fornecedores de equipamentos, empresas provedoras de serviços de Internet e organizações nos setores de serviços financeiros, saúde, mídia transporte e serviços públicos. A GSMA também produz eventos de destaque no setor, como o Congresso Mundial de Telefonia Móvel e a Exposição Asiática de Telefonia Móvel. Índice SUMÁRIO EXECUTIVO 4 1. INTRODUÇÃO 5 2. INTRODUÇÃO À SEGURANÇA Diferentes tipos de segurança Objetivos da segurança Tipos de medidas de segurança 7 3. SEGURANÇA EM TRANSAÇÕES VIA CELULAR Proteção do armazenamento de dados Vulnerabilidades do ecossistema SOLUÇÕES DE SEGURANÇA PARA HARDWARE E SOFTWARE EM TRANSAÇÕES VIA CELULAR Elemento seguro e HCE Framework/Estrutura de avaliação da segurança Avaliação da segurança RESUMO 18 O programa de Comércio Digital da GSMA envolve as operadoras de telefonia celular, os comerciantes, bancos, redes de pagamento, operadoras de transporte e provedores de serviços, apoiando a implantação de serviços de comércio móvel. Ao estimular o ambiente a encorajar e facilitar a colaboração, o programa contribui para que o ambiente de telefonia móvel desenvolva especificações e diretrizes para a implementação técnica e faça propostas enriquecedoras para os setores adjacentes. Para obter mais informações, visite 3
3 Sumário executivo 1. Introdução Transações via celular são avaliadas para entender o risco que elas oferecem. Esta avaliação é feita para proporcionar um nível transparente dos riscos, que podem ser avaliados, aceitos e geridos pelos bancos emissores. Com a Tecnologia Host-based Card Emulation (HCE) oferecendo novas maneiras de implementação, bancos emissores estão interessados em lançar serviços com maior flexibilidade em um ecossistema mais acessível. Há, contudo, um ajuste de segurança na mudança de soluções baseadas em hardware para as baseadas em software. Enquanto as transações via celular que usam medidas de segurança baseadas em hardware, como o inviolável elemento seguro (SE), tenham sido testadas contra os mais recentes ataques, novas soluções baseadas em software, como HCE, ainda têm um nível de segurança desconhecido. É possível implementar medidas para reduzir a probabilidade e o impacto de um ataque bem-sucedido com base em atuais suposições e no uso de medidas de segurança que envolvem lógica e procedimentos. Contudo, deve-se verificar e avaliar a eficiência de determinada implementação dessas medidas ao longo do tempo. Tradicionalmente, os pagamentos contactless via celular usam um elemento seguro (SE) de hardware inviolável, inspirados em cartões com Chip e PIN, que controla o nível de segurança das transações por meio de um processo já conhecido. Isso exige o envolvimento de diversos participantes, especialmente operadoras de celular, quando o elemento seguro é o SIM card. A HCE oferece aos aplicativos de pagamento baseados em software, acesso à interface contacless dos aparelhos sem a necessidade do uso de um elemento seguro de hardware. Isso interessa aos bancos, que têm grandes expectativas de implementar seus aplicativos com mais flexibilidade. Contudo, sem um elemento seguro, a HCE não oferece ferramentas para proteger os aplicativos de pagamento, fazendo com que outras medidas de segurança sejam necessárias para reduzir a probabilidade e o impacto de um ataque. Este documento explora as vulnerabilidades típicas de um sistema de pagamentos via celular e as medidas de segurança aplicadas à soluções de pagamentos com e sem um elemento seguro de hardware, avaliando-as em relação a: Restrições de segurança para atingir níveis de risco comparáveis Complexidade e custos para implementar as medidas de segurança consideradas Usabilidade o impacto sobre a experiência do usuário Auditabilidade a capacidade de avaliar o nível de riscos com bom nível de confiança. Chegou-se a quatro importantes conclusões: A complexidade do ecossistema pode ser reduzida nas soluções de segurança com base em software, na ausência de um elemento seguro de hardware SE. Ao mesmo tempo a complexidade é repassada ao emissor, que será sobrecarregado com as medidas de segurança em seu back-end, no aplicativo e nos processos. À medida em que celulares se tornarem comuns ferramentas para pagamentos e operações bancárias, a segurança dos dados confidenciais se torna cada vez mais importante. Há preocupações sobre pagamentos via celular, como o modo que os aplicativos e as transações são protegidos e viabilizados, e com a segurança de autenticação do usuário. A gestão de riscos em soluções de pagamentos está sendo avaliada pelos bancos, que estudam a implementação de serviços de transações via celular. Destinado à bancos emissores e escrito em colaboração com a empresa UL, este documento fornece um resumo básico sobre a tecnologia de segurança envolvida na implementação de soluções de pagamentos via celular. Mais especificamente, o documento considera implicações de segurança das soluções de pagamentos da telefonia móvel com base em hardware (elemento seguro, por exemplo) e em software (emulação de cartões no sistema, por exemplo). O documento estabelece objetivos gerais, tipos e necessidades de segurança, ressaltando pagamentos via telefonia móvel. Armazenamento de dados confidenciais, medidas de segurança e vulnerabilidades dos dispositivos móveis no ambiente, são parte desta pesquisa e apresenta uma avaliação que compara as soluções com base em hardware e software atualmente disponíveis no mercado. Há impacto de custos em ambas as soluções: a complexidade com a qual o emissor enfrentará para implementar e gerenciar novas medidas de segurança com base em software acarretará custos desconhecidos, enquanto elemento seguro (SE) baseados em hardware exigirá um investimento significativo em infraestrutura compartilhada por múltiplos participantes. A usabilidade em uma solução baseada em software exige o fornecimento de tokens de autenticação nos aparelhos telefônicos, para autorizar as transações e efetuar atualizações frequentes de segurança que obriguem o usuário a autenticar novamente. A auditabilidade através de processos formais estará em vigor para os testes, a certificação e a avaliação de segurança das soluções envolvendo SE com base em hardware. É difícil implementar semelhantes processos em uma grande variedade de soluções com base em software não padronizadas. Por enquanto, a avaliação deve ser feita caso a caso, e o nível efetivo de riscos apenas será avaliado com maior confiabilidade quando tiverem sido coletadas suficientes experiências no mercado. 4 5
4 2. Introdução à segurança Costuma-se medir a segurança comparando riscos e com o risco total associado aos pagamentos. Este capítulo proporciona uma visão ampla dos diferentes tipos e objetivos de segurança, e explica as medidas para a mitigação de riscos. 2.1 Diferentes tipos de segurança A segurança pode ser representada por um triângulo, com três bases vinculadas entre si, a segurança: física, lógica e de procedimentos. O nível total de segurança é determinado pelo elo mais fraco. 2.2 Objetivos da segurança O objetivo geral da segurança é proteger itens relevantes do patrimônio contra ameaças, em termos de confidencialidade, integridade e disponibilidade, por meio de medidas de segurança. Patrimônio O patrimônio contém os dados confidenciais do usuário, como o número primário da conta (PAN), chaves de uso e tokens. É possível que esse patrimônio seja capturado por hackers, como usuários e comerciantes fraudulentos, e hackers. Ameaças Um sistema está aberto a ataques em diferentes maneiras, que são definidos como pontos de vulnerabilidade. As vulnerabilidades são alvo de ataques quando o patrimônio é considerado valioso para o hacker. Medidas de segurança As medidas de segurança podem ser aplicadas para mitigar o risco de uma ameaça a um patrimônio valioso. É possível não utilizar (ou reduzir) as medidas de segurança para acelerar as implementações ou reduzir os custos (como durante as fases piloto ou de testes). Segurança física A segurança física se baseia em elementos físicos ou de hardware. O objetivo da segurança física é resguardar dados por meio de elementos invioláveis de hardware, nos quais esses dados confidenciais são armazenados e operações cruciais são executadas. A seção 3.1 apresenta uma discussão mais detalhada do assunto. Segurança lógica A segurança lógica se baseia em safeguards de software disponibilizadas no sistema. Embora o software precise de elementos de hardware para funcionar, a segurança lógica não utiliza estes elementos para proporcionar a segurança. A seção TRIÂNGULO DA SEGURANÇA 3.1 apresenta uma discussão detalhada do assunto. Segurança de procedimentos A segurança de procedimentos se baseia em safeguards de informações confidenciais por meio de procedimentos organizacionais. A segurança de procedimentos protege a confidencialidade, integridade e/ou disponibilidade das informações por meio de procedimentos e suas correspondentes medidas de segurança organizacionais, que podem ser implementadas antes ou de forma reativa. A segurança de procedimentos é específica e determinada pelo modo em que implementação é feita e precisa ser avaliada individualmente. 2.3 Tipos de medidas de segurança A segurança de uma implementação é sempre avaliada para proporcionar uma estimativa dos possíveis riscos. Isso fornecerá ao banco emissor um nívelde riscos, que seja aceitável, transparente e gerenciável. As medidas de segurança tem o objetivo de tornar complexo e custoso para se hacker o sistema, reduzindo o valor e a visibilidade de um patrimônio. Há dois tipos de medidas de segurança para mitigar os riscos: Redução da probabilidade de ataques bemsucedidos A probabilidade de um ataque bem-sucedido diminui com a implementação de medidas de segurança robustas e adequadas. Isso pode ser feito, por exemplo, ao se armazenar os dados confidenciais em elementos invioláveis. Além disso, o ocultamento das informações por meio de criptografia pode tornar significativos os esforços ou as despesas com a pirataria. Redução do impacto de ataques bem-sucedidos A possibilidadede um ataque bem-sucedido diminui com a redução do valor do patrimônio que hackers possam obter, diminuindo a sua atratividade. Por exemplo: a tokenização diminui o impacto, já que o patrimônio (os tokens) possuem valor limitado para um hacker. Essa estratégia permite aos emissores aceitar um nível menor de segurança, mantendo um nível aceitável de riscos. Lógica Figura 1 Física SECURITY De procedimentos Implementação no mercado: Apple Pay O Apple Pay permite aos usuários fazer pagamentos por NFC. Utiliza-se a tokenização para armazenar dados de cartões de pagamento. Além disso, um código dinâmico de segurança validará cada transação. O usuário confirma a transação com o TouchID. Principais mecanismos de segurança: SE: Armazena o número exclusivo da conta do dispositivo e números de transação exclusivos de uso único Verificação de usuários e hardware: usuário verificado com o TouchID Tokenização: PAN autenticado armazenado no dispositivo, números exclusivos de uso único usados por transação. Criptografia: número exclusivo da conta do dispositivo armazenado criptograficamente, números exclusivos de uso único gerados criptograficamente. 6 7
5 MEDIDAS DE SEGURANÇA LÓGICA PARA SOLUÇÕES DE PAGAMENTO DA TELEFONIA MÓVEL 8 3. Segurança nos pagamentos via celular Os bancos emissores trabalham com dados de pagamento confidenciais, e os pagamentos da telefonia móvel criam outras barreiras de segurança para os emissores. Os emissores se deparam com o desafio de autenticar o usuário e o seu dispositivo, assim como armazenar localmente e com segurança o número primário da conta (PAN), chaves de uso e criptogramas no aparelho de telefonia móvel. O nível geral de riscos para os emissores deve permanecer razoável quando estes implementarem soluções de segurança nos pagamentos da telefonia móvel com base 3.1 Armazenamento seguro de dados em hardware ou em software. Essas medidas afetam não apenas o ecossistema do sistema como também a funcionalidade da solução. É necessário considerar o impacto, juntamente com aspectos críticos, como a usabilidade, os custos, a auditabilidade e a complexidade. Para administrar o patrimônio, os emissores podem implementar soluções de segurança com base em hardware ou software. Um fator importante para determinar o nível de segurança é o local de geração e de armazenamento dos dados confidenciais ou das credenciais. A segurança do armazenamento deve depender da confidencialidade dos dados, já que cada solução provoca um impacto sobre os riscos. Os emissores dispõem de algumas opções para gerar, processar e armazenar os dados confidenciais. Unidade central de processamento (CPU) do sistema As informações confidenciais são protegidas no aplicativo que estiver sendo executado no sistema operacional (SO) do aparelho telefônico móvel. A proteção contra possíveis ataques é baixa, já que o único mecanismo padrão de segurança é o isolamento de processos. O isolamento de processos é um mecanismo de segurança que separa programas em execução não verificados. Nessa instância, o SO Android isola o patrimônio em um nível do SO. Armazenamento seguro na nuvem Os dados confidenciais são gerenciados em um servidor de rede na nuvem. É necessário que o aparelho telefônico móvel estabeleça uma conexão segura para obter esses dados. Potencialmente, o usuário deve confirmar sua identidade por meio de autenticação no aparelho telefônico e no aplicativo. Nas soluções com base em software, a autenticação do aparelho telefônico é encaminhada ao se ocultar chaves de uso no software, utilizando ofuscação de código ou criptografia de caixa branca. Ambiente de execução segura O ambiente de execução segura (TEE) é uma área segura da CPU de aparelhos telefônicos móveis. O TEE proporciona a execução segura de aplicativos confiáveis e impõe direitos de acesso, além de armazenar os dados confidenciais. O TEE executa o seu próprio SO, que isola seus recursos de segurança de hardware e software do SO principal. O TEE proporciona a execução segura de aplicativos e impõe direitos de acesso, além de armazenar os dados confidenciais. O aprovisionamento dos dados confidenciais para o TEE impõe desafios semelhantes aos do aprovisionamento por meio de um gerenciador confiável de serviços (TSM) ou de um servidor de aplicativos. Geralmente, o TEE não conta com a inviolabilidade de um SE com base em hardware. Cada fabricante de equipamento utiliza a sua própria versão dessa tecnologia, como o Knox da Samsung (que utiliza o Trustzone da ARM) e o Secure Enclave da Apple. Há muitas medidas de segurança lógica ligadas aos aplicativos de pagamento da telefonia móvel. Elas incluem: A. Verificação de usuários e hardware A autenticação de usuários pode ser efetuada: pelo que o usuário sabe, como o seu nome de usuário e a sua senha, PIN ou padrão pelos itens em propriedade do usuário, como um identificador exclusivo de dispositivo ou token pelo comportamento do usuário, como a localização da transação ou o histórico das transações pelo que o usuário é (identificação biométrica), como as impressões digitais, voz ou o reconhecimento facial É possível combinar diversos métodos em identificadores bifatoriais, sob a forma do número exclusivo do dispositivo (IMEI ou ICCID). Por exemplo: além da autenticação de usuário, é possível utilizar a autenticação por hardware, para autenticar duplamente o usuário. B. Restrições às transações A limitação das transações pode diminuir o impacto de uma violação da segurança. São exemplos de restrições: pagamentos envolvendo valores reduzidos e número limitado de transações em determinado período permissão apenas de transações on-line, nos pagamentos por proximidade restrições a localidades/países Essas restrições às transações são assinadas pelo emissor e armazenadas no SE ou terminal do ponto de venda (PDV), dificultando muito a sua adaptação por um usuário malicioso. C. Verificações do sistema operacional Os aplicativos são capazes de recuperar as definições do SO, para verificar se um dispositivo foi infectado. O risco de dispositivos infectados é que o usuário ou hacker é capaz de controlar os processos e as operações controladas pelo SO. O usuário ou hacker pode burlar as safeguards de segurança e ganhar acesso ao local de armazenamento seguro. O usuário é capaz de: alterar identificadores do dispositivo ou aplicativo utilizado na verificação de usuários e hardware obter acesso ao código dos aplicativos onde estão armazenados os dados confidenciais instalar aplicativos mal-intencionados, que podem efetuar atos fraudulentos, como ataques de intermediário D. Criptografia de caixa branca O principal propósito da criptografia de caixa branca é implementar um grande conjunto de tabelas de pesquisa e introduzir código inalterável na chave nelas contida. Todas as operações criptográficas são tratadas como uma sucessão de tabelas de pesquisa durante uma operação, o que interfere na oportunidade de deduzir a chave correta utilizada durante uma operação. O patrimônio permanecerá protegido, já que está oculto do hacker, mesmo quando este tiver acesso a todos os recursos. Ao se ocultar a chave no aplicativo, torna-se complexa a distribuição, já que cada aplicativo precisará ser definido com exclusividade pelo usuário. E. Ofuscação A ofuscação de código é um método de gravar deliberadamente código ou partes deste de maneira difícil de se compreender. Isso dificulta para os hackers quebrarem a engenharia reversa do código e oculta partes críticas ou secretas do código. Há várias modalidades de ofuscação de código: transformações envolvendo abstração: destroem a estrutura, as classes e as funções dos módulos transformações dos dados: substituem estruturas de dados por novas representações transformações dos controles: destroem declarações condicionais, como if-, while-, do- transformações dinâmicas: modificam o programa no momento da execução F. Tokenização Na tokenização, os dados confidenciais são substituídos por um equivalente menos confidencial, o token. O valor do patrimônio diminui drasticamente e se torna menos interessante para o hacker. Os tokens podem ser prontamente gerados e substituídos sem comprometer o PAN. Duas formas de tokenização são: a tokenização da EMVCo: Uma versão autenticada do PAN é vinculada ao usuário e armazenada em um dispositivo exclusivo. tokenização por chave de uso: Gera-se um token para uso único ou limitado, que o usuário autentica antes de configurar a conexão segura. 9
6 10 MEDIDAS FÍSICAS DE SEGURANÇA PARA AS SOLUÇÕES DE PAGAMENTOS DA TELEFONIA MÓVEL Elemento seguro O SE com base em hardware é um elemento inviolável nos aparelhos telefônicos móveis, assumindo a forma de um cartão de circuito impresso universal (UICC), também denominada comumente cartão SIM, ou de um SE embutido (SEe). Esses elementos seguros foram testados usando métodos recentes de ataque e aos requisitos de segurança estabelecidos por autoridades confiáveis. Os principais recursos do SE são: as chaves e os dados confidenciais são armazenados no SE. é necessário que haja um aplicativo seguro em execução no SE para processar os dados confidenciais. Os aplicativos seguros armazenam os dados confidenciais e, geralmente, a combinação do UICC e dos aplicativos de pagamento é certificada. quando o aplicativo estiver sendo executado fora do ambiente do SO do aparelho telefônico, será difícil para malware atingir aplicativos e chaves. Implementação no mercado: Softcard Anteriormente conhecido como Isis, o sistema de pagamento on-line Softcard é uma associação entre três operadoras de telefonia celular, que fornecem um aplicativo de pagamento móvel com base em SE. O sistema de pagamentos online oferece pagamentos por NFC, assim como cartões de fidelização. Uma versão virtualizada do cartão de pagamento é armazenada no cartão SIM do aparelho telefônico móvel. Principais mecanismos de segurança: SE: armazenamento de informações de pagamento confidenciais em um UICC (SIM) inviolável restrições às transações: pagamentos envolvendo valores reduzidos (sem PIN móvel), pagamentos envolvendo valores elevados (com PIN móvel) Verificação de usuários e hardware: PIN móvel para desbloquear o aplicativo + verificação de identificador de dispositivo 3.2 Vulnerabilidades do ambiente A Figura 2 apresenta uma análise abstrata que mostra as ameaças potenciais e vulnerabilidades do ambiente. Proveremos possíveis medidas para mitigar o risco de cada ameaça. Cada tipo de implementação exigirá uma análise de riscos individual para identificar vulnerabilidades específicas. EXEMPLOS DE VULNERABILIDADES DO ECOSSISTEMA: Sistema na nuvem Um ataque bem-sucedido ao sistema na nuvem acarretaria uma invasão, violando os dados ou revelando informações confidenciais. As possíveis ameaças ao sistema de pagamentos na nuvem incluem a interceptação dos dados confidenciais através de ataques utilizando mascaramento de identidade (spoofing), a interceptação dos dados por aplicativos mal-intencionados e o redirecionamento dos dados do aplicativo para outro aparelho telefônico móvel. Graças à esses métodos, um hacker pode obter acesso a patrimônio, como os detalhes de usuários e de cartões, valores dos métodos de verificação de cartões, chaves de uso e até mesmo aplicativos inteiros de pagamentos da telefonia móvel. Os maiores desafios são o acesso seguro e a autenticação do usuário na nuvem. Para que um sistema na nuvem possa lidar com pagamentos tokenizados, é necessário que ele consiga gerenciar esses tokens, tokenizar e reconverter os dados confidenciais. Aplicativo de pagamento da telefonia móvel Um ataque bem-sucedido ao aplicativo de pagamento da telefonia móvel com base em software poderia consistir na descompilação do código fonte, no qual o hacker obtém acesso a todo o patrimônio oculto no aplicativo (como os tokens e as chaves criptográficas). A integridade de um aplicativo também pode ser comprometida pela violação de dados e por aplicativos clonados que interceptem os dados confidenciais. Outro ponto de vulnerabilidade é o PDV móvel do comerciante, já que um comerciante fraudulento poderia violar o aplicativo móvel que controla o PDV móvel. Graças a esses métodos, um hacker pode obter itens de patrimônio como os detalhes de usuários e de cartões, valores dos métodos de verificação de cartões e chaves de uso. Os mecanismos de segurança, como a criptografia de caixa branca, reduzem a probabilidade de clonagem e descompilação de aplicativos de pagamento. O aprovisionamento de dados seguros para o SE ou o envio de um token de pagamento é um aspecto de vulnerabilidade dos aplicativos de pagamento da telefonia móvel. Aparelho telefônico móvel Os ataques ao aparelho telefônico móvel podem almejar os seguintes itens do patrimônio do dispositivo: SE, processador da comunicação por aproximação de campo (NFC) e SO do dispositivo móvel. O SO do dispositivo móvel tem pontos fracos, através da porta de depuração ou por meio de infecção com falhas de programação, que podem ganhar acesso ao aplicativo de pagamento da telefonia móvel. Além disso, mecanismos como a gravação de telas podem obter importantes informações de entrada do usuário. Medidas potenciais de segurança incluem PINs off-line, verificações do SO, criptografia de caixa branca e TEE, para proteger o teclado e a tela. Elemento seguro O impacto de um ataque no SE é alto. Contudo, a probabilidade de que um ataque seja bemsucedido é baixa devido ao alto nível de segurança do SE inviolável. O aspecto crítico da segurança é o controle do acesso ao SE, que define o acesso aos aplicativos móveis. O acesso ao SE se baseia em certificados implementados pelo provedor de serviços, que são utilizados para autenticar ou registrar o aplicativo do provedor de serviços no SE. Ponto de venda interface da NFC Nos pagamentos envolvendo valores reduzidos, a interface entre a NFC e o PDV pode sofrer ataques por retransmissão. A interface da NFC pode ser inadequadamente usada por um comerciante fraudulento, simulando pagamentos sem PIN. Um hacker que esteja coletando chaves de uso também pode violar os dados. Uma possibilidade de entrada para redirecionar os dados confidenciais são os aplicativos malintencionados no processador da NFC. O impacto desse tipo de ataque pode ser reduzido ao se implementar mecanismos de segurança, como a tokenização, por exemplo. 11
7 AMEAÇAS AMEAÇAS FIGURA 3.1 AMBIENTE COM BASE EM HARDWARE E SOFTWARE, COM AMEAÇAS E POSSÍVEIS MEDIDAS AMEAÇAS Violação do controle do acesso entre o SO e o SE, obtendo acesso a dados confidenciais Phishing, que captura dados confidenciais (chaves de uso, PIN móvel) Interceptação do aplicativo POSSÍVEIS MEDIDAS Elemento seguro inviolável (seção 3.1) (discute sobre a maioria das ameaças) Verificação de usuários (A) AMEAÇAS Violação pela descompilação do aplicativo. O hacker obtém os detalhes de usuários e cartões, valores de CVM e chaves de uso Mascaramento de identidade/phishing aplicativos falsos / clonados e captura dados confidenciais (chaves de uso, PIN móvel) Violaçãog pela injeção de código malicioso no aplicativo. O hacker obtém dados confidenciais. POSSÍVEIS MEDIDAS TEE (seção 3.1) Criptografia de caixa branca (D) Verificações do sistema operacional (C) Ofuscação (E) Verificação de usuários e hardware (A) Com base em hardware Com base em software Aplicativo de pagamento Cartão SIM (UICC) Operadora da rede de telefonia móvel Interceptação por aplicativos mal-intencionados instalados Falsificação de identidade pela interceptação da credencial de autenticação dos dados do aplicativo Redirecionamento de dados do aplicativo para outro aparelho telefônico Captura de detalhes de usuários e cartões, valores de CVM e chaves de uso POSSÍVEIS MEDIDAS Verificação de usuários e hardware (A) Verificações do sistema operacional (C) TEE (seção 3.1) Ofuscação (E)! Gestão de credenciais Plataforma do aplicativo! Sistema na nuvem! Internet Aparelho telefônico Aplicativo de pagamento da telefonia móvel APIs da HCE Controlador de NFC Gestão de transações Gestão na nuvem! TSM do operador Violação pelo acesso a dados confidenciais por meio da porta de depuração do dispositivo ou da infecção com falhas de programação Violação pela execução em um ambiente simulado, para localizar vulnerabilidades Hacker localiza as vulnerabilidades e captura detalhes de usuários e cartões, valores de CVM e chaves de uso POSSÍVEIS MEDIDAS Verificações do sistema operacional (C) Criptografia de caixa branca (D) Ofuscação (E) TEE (seção 3.1) Verificação de usuários e hardware (A) Rede de pagamentos Adquirente! PDV do comerciante Emissor (sistema do processador) TSM do provedor de serviços AMEAÇAS Aplicativos mal-intencionados instalados no controlador de NFC, juntamente com um ataque por retransmissão, vulnerabilizam o aparelho telefônico móvel Um comerciante fraudulento pode simular um pagamento envolvendo valores reduzidos, em que nenhuma verificação adicional é ativada Violação pela captura de criptogramas e chaves de uso, para descobrir pontos fracos no algoritmo de criptografia POSSÍVEIS MEDIDAS Verificação de usuários e hardware (A) Restrições às transações (B) Tokenização (F) 12 13
8 4. Soluções de segurança com base em hardware e software nos pagamentos da telefonia móvel A Figura 4.2 examina solução na nuvem com base em software envolvendo a HCE. Nesse exemplo, os dados de cartões de pagamento são armazenados na CPU do sistema. O aplicativo móvel sendo executado na CPU do sistema gerencia os dados de cartões de pagamento e se conecta a um sistema de pagamentos na nuvem para autenticar o usuário e aprovar as transações. De acordo com o exemplo assumimos que: a tokenização é utilizada pelo aplicativo para gerar chaves de uso. Estas chaves contêm qualquer dado confidencial usado sob a forma autenticada e proporcionam a autenticação do usuário a criptografia de caixa branca é utilizada para proteger os dados confidenciais o PIN off-line ou on-line é ativado, dependendo da transação Este capítulo apresenta uma estrutura de avaliação da segurança, contribuindo para a comparação entre as soluções de segurança com base em hardware e software nos pagamentos da telefonia móvel. A Figura 4.3 avalia as soluções típicas com base em hardware e software. FIGURA 4.2 SOLUÇÃO DE SEGURANÇA COM BASE EM SOFTWARE E NA HCE ASPECTO DA SEGURANÇA Medida de segurança EXEMPLO COM BASE NA HCE 1. Criptografia de caixa branca 2. Tokenização 3. Autenticação do usuário Tipo de segurança Lógica Lógica Lógica 4.1 Soluções envolvendo o elemento seguro e a HCE Esta seção discute soluções de nível de segurança similar: uma com base em hardware e a outra com base em software, incluindo medidas de segurança relevantes para a mitigação de riscos. A Figura 4.1 examina uma solução com base em hardware envolvendo o SE. Nesse exemplo, o cartão de pagamento é armazenado como um cartão virtual no SE. De acordo com o exemplo assumimos que: todos os dados de cartões de pagamento estão localizados no SE, de onde são recuperados é possível permitir pagamentos envolvendo valores reduzidos sob medidas de segurança reduzida, como na ausência de PIN móvel Mitigação de riscos Menor probabilidade de um ataque bem-sucedido Menor probabilidade de um ataque bem-sucedido Menor probabilidade de um ataque bem-sucedido Numa solução de segurança com base em software, efetua-se uma conexão com a rede diretamente do aplicativo, por meio da NFC. Para ativar pagamentos, o usuário precisará autenticar-se na nuvem, para obter os tokens do pagamento, que deverão ser aprovisionados com segurança, envolvendo um emissor de tokens. Utiliza-se a tokenização para diminuir o impacto de ataques bem-sucedidos e esses tokens terão de ser armazenados no aparelho telefônico móvel. A solução com base em software poderá envolver menos participantes, mas também exige medidas de segurança com base em software, para compensar a ausência de um SE, como os três pressupostos apresentados na Tabela 2. FIGURA 4.1 SOLUÇÃO DE SEGURANÇA COM BASE EM HARDWARE ENVOLVENDO ELEMENTO SEGURO ASPECTO DA SEGURANÇA Medida de segurança EXEMPLO COM BASE NO SE 1. Uso de PCIU/SEe Tipo de segurança Física Lógica Mitigação de riscos Menor probabilidade de um ataque bem-sucedido 2. Os pagamentos envolvendo valores altos necessitam de um PIN Menor impacto de um ataque bemsucedido Numa solução com base em hardware, o SE (como o cartão SIM ou UICC) é o principal responsável pela segurança. Para aprovisionar os aplicativos seguros e personalizar o aplicativo de pagamento, estabelece-se a conexão segura com o SE. Os bancos emissores são capazes de controlar plenamente o seu patrimônio no SE, por meio de padrões da GlobalPlatform. 1 Implementação no mercado: BankInter Este é um aplicativo de pagamento via telefonia móvel com base em software que oferece transações do comércio eletrônico (pagamentos remotos), assim como pagamentos com base na HCE no PDV. Os cartões de pagamentos são armazenados e vinculados a um aparelho telefônico móvel como cartões virtuais móveis. Não há necessidade de conectividade de telefonia móvel para as transações por NFC, mas apenas para repor as credenciais parcialmente calculadas ao aparelho telefônico móvel. Principais mecanismos de segurança: Tokenização: Sob a forma da criação do cartão virtual móvel no aparelho telefônico e cartões de uso único Criptografia: Criptograma da EMV Restrições às transações: Restrição de 60 segundos para o cartão de uso único Validade Verificação de usuários e hardware: PIN do cartão virtual móvel + verificação do identificador do dispositivo 1. GlobalPlatform Specifications,
9 FIGURA 4.3 COMPARAÇÃO ENTRE AS ESTRUTURAS 4.2 Estrutura de avaliação da segurança Para comparar as soluções, utiliza-se a estrutura de avaliação da segurança baseada em cinco aspectos: segurança, usabilidade, custos, auditabilidade e complexidade. Não se consideram outros fatores nessa estrutura, como os meios específicos de configuração, a implementação e a viabilidade das medidas de mitigação de riscos, já que eles são específicos a determinadas implementações. 4.3 Avaliação da segurança A estrutura de avaliação da segurança apresenta uma comparação abstrata com base nesses cinco aspectos: segurança, usabilidade, custos, auditabilidade e complexidade. Uma comparação completa exigiria análise exaustiva dos riscos de duas implementações específicas. Observe que, na prática, a avaliação do nível de riscos de uma implementação com base em software deverá ser concluída ao longo de um período de monitoramento operacional antes que se possa estabelecer por completo as regras comerciais (certificação, status do risco das transações, aprovisionamento para riscos financeiros). Em vez disso, apresenta-se uma comparação abstrata que leva em conta os recursos gerais das soluções com base em hardware e software. ESTRUTURA SOLUÇÃO COM BASE EM HARDWARE SOLUÇÃO COM BASE EM SOFTWARE SEGURANÇA Medidas de segurança reduzem o índice de riscos e a segurança concreta precisa ser avaliada em uma determinada implementação. Nessa estrutura, a estimativa de riscos é efetuada de acordo com o ambiente apresentado, com os pontos de vulnerabilidade e as possíveis mitigações de riscos ponderados pelo impacto da possível fraude. O local de armazenamento dos dados confidenciais é um fator importante para determinar o nível geral de segurança. A segurança concreta é avaliada nesta seção, já que a segurança percebida pelo usuário varia de acordo com o mercado e se altera ao longo do tempo. USABILIDADE Geralmente, a usabilidade compromete ou é comprometida com o requisito de segurança, o banco emissor deve buscar equilíbrio entre os dois. Por exemplo: senhas adicionais aumentariam a segurança, mas diminuiriam a usabilidade (as pessoas precisam memorizar outra senha). CUSTOS Os custos são afetados principalmente pela extensão do ambiente, o nível implementado de segurança e o tipo de medidas de segurança. AUDITABILIDADE Outro importante aspecto para os bancos emissores é a auditabilidade, que requer transparência na solução, nas transações e na abrangência dos registros armazenados. As implementações complexas são difíceis de avaliar. COMPLEXIDADE A complexidade pode ser determinada pelo número de participantes, pela extensão do ambiente e pelo nível de segurança desejada. Reduz a probabilidade de um ataque bem-sucedido, proporcionando uma robusta mitigação de riscos física, já que o patrimônio do banco emissor e do usuário está armazenado seguramente no SE. O SE inviolável proporciona a segurança, tendo sido produzido e testado no campo há mais de dez anos. O aprovisionamento de dados é gerenciado em segurança e enviado diretamente ao SE, e não encaminhado através do SO do telefone celular. A segurança foi certificada por esquemas de cartões quanto aos ataques conhecidos mais recentes. A usabilidade de uma solução com base em hardware é boa, já que oferece a possibilidade de efetuar pagamentos envolvendo valores reduzidos sem PIN e pagamentos quando o aparelho telefônico móvel estiver desligado, o que é comparável a um cartão físico de pagamento. Quando o SE for um UICC (cartão SIM), os usuários têm a possibilidade de transferi-lo para outros aparelhos telefônicos. Para aprovisionar com segurança e personalizar os cartões de pagamento virtual em aparelhos telefônicos móveis, é necessária a participação de revendedores de TSM. {MQ}As operadoras de telefonia celular poderão cobrar uma taxa para utilizar o UICC (cartão SIM) como um SE. É necessário um investimento significativo na infraestrutura: configuração e administração dos TSMs, enquanto a conexão com o TSM é coberta pelo usuário. Há um processo estabelecido em vigor para os testes, a certificação e a avaliação da segurança formal a muitos anos, o que o torna robusto. A complexidade de uma solução de pagamentos da telefonia móvel com base em SE advém do extenso ambiente e do número de participantes externos envolvidos. Esses participantes precisam se integrar e trabalhar em conjunto para que possam lançar uma solução bem-sucedida. As questões de integração e interoperabilidade surgem devido ao número de interfaces e à complexidade de se integrar outros bancos emissores e operadoras de telefonia celular. A solução com base em software não coincide com a segurança de uma solução com base em hardware. Para melhorar a segurança da solução com base em software, são necessários métodos de criptografia de caixa branca e de verificação de usuário que afetem os outros aspectos da estrutura. A estratégia de mitigação de riscos se concentra principalmente na redução do impacto de um ataque bemsucedido por meio de tokenização e das respectivas restrições às transações (como permitir apenas pagamentos envolvendo valores reduzidos sem um PIN), para alcançar um nível geral de riscos comparável ao das soluções com base em hardware. Como mencionado anteriormente, essas soluções são um avanço recente. Não há experiências de campo suficientes para avaliar o nível efetivo de riscos a longo prazo. É necessário que o dispositivo seja ligado para poder efetuar as transações. Com frequência, a conectividade de telefonia móvel é necessária para se conectar ao servidor de tokens na nuvem, para repor os tokens dos pagamentos. O aplicativo necessitará de atualizações frequentes de software, para manter atualizadas as medidas de segurança do software. O acesso seguro à nuvem exige que o usuário efetue novamente e com alguma regularidade a autenticação com mecanismos de autenticação robustos. É provável que transações rápidas, como pagamentos de circuito aberto para o transporte público, estejam fora desse âmbito. O emissor não precisa contratar participantes externos, como TSMs, operadoras de telefonia celular nem gerenciamento de elementos seguros (Ses) Contudo, pode haver necessidade de lidar com outros participantes, como o provedor de tokens e os responsáveis por proporcionar e atualizar as medidas de segurança de software. Custos adicionais para lidar com novas complexidades (consulte Complexidade) provocarão novos custos, cuja extensão ainda não é conhecida. Mesmo assim, o aplicativo deve ser aprovisionado com segurança e personalizado com chaves ou tokens, o que pode ser feito interna ou externamente. A auditabilidade não está tão amadurecida quanto as soluções com base em hardware, já que{mq}os processos formais estão sendo desenvolvidos (inclusive pela Visa e pela MasterCard). Os processos são propositalmente escondidos ou protegidos por criptografia, o que os torna menos transparentes e, consequentemente, menos auditáveis. A totalidade do ambiente pode ter menos participantes, já que o papel das operadoras de telefonia celular e dos GCSs é substituído por provedores de serviços de autenticação e gerentes das medidas de segurança do software. Pode haver uma maior complexidade na implementação no banco emissor. Será necessário adaptar os sistemas na camada de acesso aos dados dos bancos emissores, incorporando-se uma plataforma de pagamentos na nuvem que gerencie o aplicativo de pagamento da telefonia móvel e seja capaz de autenticar os usuários e lidar com esse tipo de transação. Assim, mudanças significativas terão de ser feitas nos sistemas da camada de acesso aos dados de um banco emissor. Quando o aplicativo incorporar algoritmos de criptografia, será necessário outro participante para disponibilizar chaves ou atualizações de segurança. Outro exemplo é a tokenização, na qual poderá ser necessário um gerente de tokens
10 5. Resumo Semelhantes níveis de riscos podem ser observados nas diversas soluções. Porém, o impacto sobre a usabilidade, os custos, a auditabilidade e a complexidade varia, conforme mostra a Figura 5.1. FIGURA 5.1 RESUMO COMPARATIVO DAS ESTRUTURAS DE AVALIAÇÃO DA SEGURANÇA ASPECTO DA ESTRUTURA Segurança Usabilidade Custos IMPACTO Solução com base em hardware Nível de segurança comprovado e bem compreendido. A usabilidade é boa. Assim que o produto de pagamentos for aprovisionado para o usuário, a usabilidade estará no mesmo nível que a de um cartão físico de pagamento. O envolvimento de muitos participantes, como GCSs e as operadoras de telefonia celular, para aprovisionar com segurança o produto de pagamentos para o usuário, aumenta os custos nesse ambiente pluralista. Solução com base em software É possível obter níveis similares de segurança, mas é necessário tempo de de uma implementação para que se possa avaliar e verificar o nível de riscos. É possível que a usabilidade seja tão boa quanto outras soluções, mas ela dependerá das medidas específicas de segurança com base em software que serão adotadas pelo banco emissor. Essas medidas podem interferir na usabilidade e introduzir novos fatores de custos e complexidade para os bancos emissores. Em um nível de segurança similar, exigemse medidas de tokenização e criptografia, o que aumenta os fatores de custos, como provedores de serviços de autenticação e uma taxa de licença para atualizar o software segurança. É necessário adaptar o sistema da camada de acesso aos dados de um banco emissor, o que também representa um fator de custos. Auditabilidade Processos formais em vigor. Processos formais em desenvolvimento. Complexidade A complexidade decorre do ecosistema com múltiplos players. A implementação nos banco emissor é complexa. Em geral, os riscos podem, em princípio, ser mantidos em um nível comparável quando se implementa uma solução de segurança com base em software, ao se adotar medidas lógicas de segurança, tais como tokenização, restrições às transações e criptografia de caixa branca. Deve-se implementar um grande espectro de medidas lógicas de segurança para compensar a falta de um SE com base em hardware. Para apoiar o aprovisionamento dos tokens e atualizações de segurança do software, poderá se fazer necessária uma autenticação robusta de usuários, para garantir o acesso seguro do aparelho telefônico para o armazenamento seguro na nuvem, o que afetará a usabilidade da solução com base em software. Apesar disso, a experiência do usuário poderia ser mantida num nível comparável à do aplicativo com base em hardware, dependendo da implementação específica das medidas de segurança. Os custos de lançamento e operação de uma solução com base em software podem ser reduzidos pela ausência de dependência de parceiros externos. Contudo, é provável que o banco emissor tenha outros custos, já que este deverá absorver as complexidades técnicas. A solução pode ser desenvolvida no banco ou por outros participantes, como o gerente de serviços da tokenização, por exemplo. A auditabilidade por meio de processos formais estará em vigor para os testes, a certificação e a avaliação da segurança de aplicativos de pagamento com base no SE. Contudo, no caso de uma solução com base em software, os processos estarão em desenvolvimento e serão determinados com o tempo. Na solução com base em software, a complexidade passa ao emissor e está vinculada ao prazo para comercialização de produtos. Ao escolher a solução com base em software, não há necessidade da integração de grande escala de muitos participantes do ambiente. Contudo, aumenta a complexidade no lado do emissor em termos de integração das camadas de acesso aos dados, que aumenta o prazo para comercialização de produtos, além da implementação das medidas de segurança com base em software. O lançamento de aplicativos de pagamento com base na HCE só se tornou possível recentemente. Nos pagamentos efetuados na nuvem, a Visa e a MasterCard lançaram exigências para os licenciados. Um processo de avaliação de testes e segurança está sendo desenvolvido para certificar esse novo tipo de solução de pagamentos da telefonia móvel. Porém, as respostas definitivas relativas ao nível de riscos resultará do trabalho operacional destes pioneiros e, até então, será necessário avaliar os riscos individualmente
11 Sede da GSMA Level 2, 25 Walbrook London, EC4N 8AF, Reino Unido Telefone: +44 (0) GSMA 2014
A HCE e o uso de tokens em serviços de pagamento Documento de Discussão SOBRE A CONSULT HYPERION Líderes e referência em dinheiro e identidade digitais A Consult Hyperion é uma empresa de consultoria estratégica