Segurança de
transações via celular
documento de discussão
SEGURANÇA DE TRANSAÇÕES VIA CELULAR DOCUMENTO DE DISCUSSÃO
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 10.000
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.
Índice
SUMÁRIO EXECUTIVO 1. INTRODUÇÃO
4
5
2.INTRODUÇÃO À SEGURANÇA 6
2.1 Diferentes tipos de segurança 2.2 Objetivos da segurança 2.3 Tipos de medidas de segurança 6
7
7
3.
SEGURANÇA EM TRANSAÇÕES VIA CELULAR 3.1 Proteção do armazenamento de dados 3.2 Vulnerabilidades do ecossistema 8
8
11
Para obter mais informações, visite www.UL.com
4. SOLUÇÕES DE SEGURANÇA PARA HARDWARE E SOFTWARE
EM TRANSAÇÕES VIA CELULAR 14
SOBRE A GSMA
4.1 Elemento seguro e HCE 4.2 Framework/Estrutura de avaliação da segurança 4.3 Avaliação da segurança 14
16
16
5. 18
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.
RESUMO
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 www.gsma.com
3
SEGURANÇA DE TRANSAÇÕES VIA CELULAR DOCUMENTO DE DISCUSSÃO
Sumário executivo
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.
SEGURANÇA DE TRANSAÇÕES VIA CELULAR DOCUMENTO DE DISCUSSÃO
1. Introdução
À 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.
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.
•
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
SEGURANÇA DE TRANSAÇÕES VIA CELULAR DOCUMENTO DE DISCUSSÃO
SEGURANÇA DE TRANSAÇÕES VIA CELULAR DOCUMENTO DE DISCUSSÃO
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.
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
Lógica
Figura 1
6
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).
3.1 apresenta uma discussão detalhada do
assunto.
2.3 Tipos de medidas de segurança
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.
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:
TRIÂNGULO DA SEGURANÇA
Física
2.2 Objetivos da segurança
0011101110000
110SECURITY1
11011100010111
0000111011010
1101010100001
De
procedimentos
000110111111101
0001000111100
1111111010101101
•
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.
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.
7
SEGURANÇA DE TRANSAÇÕES VIA CELULAR DOCUMENTO DE DISCUSSÃO
SEGURANÇA DE TRANSAÇÕES VIA CELULAR DOCUMENTO DE DISCUSSÃO
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
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.
3.1 Armazenamento seguro de dados
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 é
8
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.
MEDIDAS DE SEGURANÇA LÓGICA PARA SOLUÇÕES
DE PAGAMENTO DA TELEFONIA MÓVEL
Há muitas medidas de segurança lógica ligadas aos
aplicativos de pagamento da telefonia móvel. Elas
incluem:
• instalar aplicativos mal-intencionados, que
podem efetuar atos fraudulentos, como ataques
de intermediário
A. Verificação de usuários e hardware
D. Criptografia de caixa branca
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.
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.
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.
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
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
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
SEGURANÇA DE TRANSAÇÕES VIA CELULAR DOCUMENTO DE DISCUSSÃO
SEGURANÇA DE TRANSAÇÕES VIA CELULAR DOCUMENTO DE DISCUSSÃO
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.
10
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
SEGURANÇA DE TRANSAÇÕES VIA CELULAR DOCUMENTO DE DISCUSSÃO
SEGURANÇA DE TRANSAÇÕES VIA CELULAR DOCUMENTO DE DISCUSSÃO
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)
AMEAÇAS
• I nterceptação por aplicativos mal-intencionados instalados
•F
alsificaçã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
• 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)
Verificação de usuários e hardware (A)
Verificações do sistema operacional (C)
TEE (seção 3.1)
Ofuscação (E)
!
Sistema na nuvem
Gestão de credenciais
Gestão de transações
Plataforma do aplicativo
Gestão na nuvem
Com base em software
FIGURA 3.1 AMBIENTE COM BASE
EM HARDWARE E SOFTWARE, COM
AMEAÇAS E POSSÍVEIS MEDIDAS
AMEAÇAS
AMEAÇAS
Elemento seguro inviolável
(seção 3.1) (discute sobre a
maioria das ameaças)
Verificação de usuários (A)
12
Com base em hardware
POSSÍVEIS MEDIDAS
!
Aplicativo de pagamento
Cartão SIM (UICC)
Emissor
(sistema do processador)
Rede de
pagamentos
Internet
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
!
!
Aparelho
telefônico
Adquirente
Aplicativo de
pagamento da
telefonia móvel
APIs da HCE
Controlador de
NFC
!
PDV do comerciante
• 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
Operadora da rede
de telefonia móvel
TSM do operador
TSM do provedor de serviços
Verificação de usuários e
hardware (A)
Restrições às transações (B)
Tokenização (F)
13
SEGURANÇA DE TRANSAÇÕES VIA CELULAR DOCUMENTO DE DISCUSSÃO
SEGURANÇA DE TRANSAÇÕES VIA CELULAR DOCUMENTO DE DISCUSSÃO
4.Soluções de segurança
com base em hardware e
software nos pagamentos
da telefonia móvel
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.
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
FIGURA 4.1 SOLUÇÃO DE SEGURANÇA COM BASE EM HARDWARE ENVOLVENDO
ELEMENTO SEGURO
ASPECTO DA SEGURANÇA
EXEMPLO COM BASE NO SE
Medida de segurança
1. Uso de PCIU/SEe
2. Os pagamentos envolvendo valores
altos necessitam de um PIN
Tipo de segurança
Física
Lógica
Mitigação de riscos
Menor probabilidade de um ataque
bem-sucedido
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
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
FIGURA 4.2 SOLUÇÃO DE SEGURANÇA COM BASE EM SOFTWARE E NA HCE
ASPECTO DA SEGURANÇA
EXEMPLO COM BASE NA HCE
Medida de segurança
1. Criptografia de caixa
branca
2. Tokenização
3. Autenticação do
usuário
Tipo de segurança
Lógica
Lógica
Lógica
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.
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, http://www.globalplatform.org/specifications.asp
14
15
SEGURANÇA DE TRANSAÇÕES VIA CELULAR DOCUMENTO DE DISCUSSÃO
SEGURANÇA DE TRANSAÇÕES VIA CELULAR DOCUMENTO DE DISCUSSÃO
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.
ESTRUTURA
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).
SOLUÇÃO COM BASE EM HARDWARE
SOLUÇÃO COM BASE EM SOFTWARE
• 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 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.
• 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.
• É 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.
• 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.
• 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.
• 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 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 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 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.
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.
16
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.
17
SEGURANÇA DE TRANSAÇÕES VIA CELULAR DOCUMENTO DE DISCUSSÃO
SEGURANÇA DE TRANSAÇÕES VIA CELULAR DOCUMENTO DE DISCUSSÃO
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
18
IMPACTO
Solução com base em hardware
Solução com base em software
Segurança
Nível de segurança comprovado e bem
compreendido.
É 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.
Usabilidade
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.
É 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.
Custos
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.
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.
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.
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.
19
Sede da GSMA
Level 2, 25 Walbrook
London, EC4N 8AF,
Reino Unido
Telefone: +44 (0)207 356 0600
www.gsma.com
©GSMA 2014