A HCE e o uso de tokens em serviços de pagamento Documento ... · de software, fornecedores de equipamentos, empresas provedoras de serviços de Internet e organizações nos setores

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 e técnica independente, baseada no Reino Unido e nos EUA, especializada em transações eletrônicas seguras. Contribuímos para que organizações do mundo inteiro façam uso de novas tecnologias para pagamentos eletrônicos seguros e serviços de transações envolvendo identidade, desde pagamentos móveis, com “chip e PIN” até a emissão de bilhetes contactless e cartões de identidade inteligente. Nosso objetivo é auxiliar os clientes a alcançar suas metas de maneira oportuna e econômica.

Apoiamos a implementação de soluções práticas usando as tecnologias mais adequadas, e dispomos de uma expertise reconhecida globalmente em todos os aspectos das transações eletrônicas, desde a autenticação, o acesso e as redes, até os sistemas e aplicativos responsáveis pelas transações.

Para obter mais informações, visite www.chyp.com

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 Mobile World Congress, Mobile World Congress Shanghai e as conferências Mobile 360 Series.

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 implementaçã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

A HCE E O USO DE TOKENS EM SERVIÇOS DE PAGAMENTO DOCUMENTO DE DISCUSSÃO

SUMÁRIO EXECUTIVO 4

1. INTRODUÇÃO 5

1.1 Histórico e objetivos 51.2 O que é a emulação de cartões? 61.3 O que é a emulação de cartões no sistema? 61.4 O papel dos tokens 71.5 A discussão do elemento seguro versus HCE 9

2. AMBIENTES DE PAGAMENTO POR NFC 10

2.1 O ecossistema do HCE 102.2 Ecossistemas de elemento seguro (SE) 12 2.2.1 SE de cartão SIM 12 2.2.2 SE embutido – Apple Pay 13 2.2.3 Apple Pay versus elemento seguro de cartão SIM: Outras considerações 14

3. CONSIDERAÇÕES 15

3.1 Aprovisionamento 15 3.1.1 Aprovisionamento de dados dinâmicos 16 3.1.2 O uso de tokens 183.2 Experiência do usuário 19 3.2.1 Download de dados 21 3.2.2 Considerações sobre experiência do usuário 233.3 Segurança 24 3.3.1 Controle e gestão de riscos 253.4 Modelo comercial 26 3.4.1 HCE no software 26 3.4.2 Com hardware seguro 263.5 Maturidade 28

4. CONCLUSÃO 30

Índice

4


ResumoEm julho de 2014, com o objetivo de compreender as oportunidades e desafios relativos entre o uso do elemento seguro (SE) dos cartões SIM e serviços de emulação de cartões no sistema (HCE), a GSMA solicitou que a Consult Hyperion produzisse o guia “HCE e o Elemento Seguro do SIM: Nada é Preto e Branco” (disponível em inglês: HCE and SIM Secure Element: It’s not Black and White). Após a publicação, leitores solicitaram mais informações a respeito do uso da HCE. Este estudo visa a apresentar uma análise detalhada para bancos e operadoras da rede de telefonia móvel que estiverem interessadas no uso de HCE e tokens para serem usados nos serviços de transação via celular.

Além da penetração cada vez maior da infraestrutura de aceitação cartões contactless, há uma tendência dessa tecnologia ser utilizada em pagamentos via celular. Com a entrada da Apple, a migração cobre diversas opções de implementação, tais como HCE, baseada em cartão SIM e incorporada.

A HCE oferece a promessa de um mecanismo adicional para que bancos dêem suporte aos seus clientes. Ela:• Simplifica o ambiente de aprovisionamento de aplicativos, aumentando, em contrapartida, a gestão de

riscos de transações de pagamentos,• Elimina os custos e a complexidade da gestão de aplicativos usando um elemento seguro apoiado por

terceiros, mas• Aumenta a complexidade dos sistemas emissores, já que estes devem fornecer dados dinâmicos para cada

transação.

Dados dinâmicos (chaves criptográficas específicas para cada transação, por exemplo) são necessários para lidar com as vulnerabilidades causadas pela ausência de uma plataforma segura de hardware no aparelho telefônico do cliente. A utilização de um PAN estático dedicado para HCE, ou de PANs dinâmicos para cada transação darão assistência para limitar a contaminação cruzada em e-commerces. Emissores podem optar por gerir o PAN ou por utilizar um dos serviços comerciais de tokenização que estão sendo lançados no mercado.

Como o usuário deve efetuar o download (por opção ou imposição) dos dados dinâmicos antes de a transação ocorrer, a segurança da HCE depende desta autenticação feita pelo cliente. É importante que se enfatize a necessidade de que o cliente mantenha a autenticação ativa por toda a vida útil dos produtos. Para lidar com isso, os emissores devem considerar adotar medidas adicionais de segurança de hardware nas credenciais de autenticação.

Os custos adicionais exigidos pelos novos processos do emissor demandam consideração cuidadosa. Durante a análise de custos, sugerimos que os emissores definam com os seus parceiros a estratégia de como explorar possíveis vantagens provenientes da integração do elemento seguro em seu back end para a HCE. Como resultado, espera-se compreender como a abordagem híbrida poderia controlar o custo e a complexidade de uma solução implementada em larga escala.

A HCE ainda está no início do seu ciclo de vida, especificações ainda estão sendo publicadas ou em desenvolvimento. Se presumirmos que a HCE seguirá trajetória similar de outras tecnologias de pagamento, aproximadamente em um ano as especificações e o produto estabilizarão.

As descobertas do guia inicial sobre a HCE, preparado pela Consult Hyperion, continuam válidas.

• Comece avaliando as condições do mercado local e o perfil de transações almejado• Mantenha sua estratégia flexível, pois o hardware seguro deve continuar a ser uma parte significativa da

solução mais adequada e• Trabalhe em conjunto com os seus parceiros do setor, para garantir que os clientes e os comerciantes se

engajem na promessa de facilidade de uso proporcionada pela HCE.

5


1. Introdução1.1 Histórico e objetivos

Near Field Communication (NFC) é a tecnologia com suporte mais frequente nas transações de pagamento em pontos de venda (PDV) envolvendo telefones celulares. A NFC permite ao consumidor utilizar os telefones celulares em serviços seguros, inclusive pagamentos, emissão de bilhetes, acesso, cartões de fidelização e cupons de descontos.

Atualmente, há condições favoráveis para os serviços que utilizam a NFC, uma quantidade significativa de Smartphones, lojas de aplicativos para celulares e os mais de 225 modelos de telefones celulares compatíveis com a NFC, assim como a aparição de terminais para pagamentos compatíveis com cartões contactless.

Por aproximadamente cinco anos, a NFC tem lançado pilotos e produtos que possuem o elemento seguro no mundo todo. O uso de um elemento seguro para efetuar esse processo em um telefone compatível com a NFC é denominado “emulação de cartão”. Para o terminal do PDV, o telefone celular se comporta como um cartão do tipo “smart card”. Já existem mais de 50 serviços comerciais em vigor ou na fase piloto, como OrangeCash na França, SmartPass na Alemanha, Tapit na Suíça, SureTap no Canadá, e Softcard nos EUA, além do Mobile Wallet da China Mobile.

Em outubro de 2013, Google anunciou a inclusão do recurso “emulação de cartões no sistema” (HCE) no Android 4.4 KitKat, que permite ao aplicativo de pagamento se comunicar diretamente com controladores de NFC/credenciais de antena e armazenar as credenciais de pagamento no aplicativo de pagamento do sistema operacional do telefone celular (o “host”), e não mais

no elemento seguro. Em 2014, a Visa e a MasterCard lançaram especificações, requisitos e diretrizes para aplicativos de pagamento que utilizam a HCE, inclusive um kit de desenvolvimento de software para permitir aos seus clientes que efetuassem pagamentos via celular utilizando a HCE. Bancos na Espanha e na Austrália lançaram pilotos que utilizam a tecnologia de HCE em aplicativos de pagamento.

Com o objetivo de compreender oportunidades e desafios relativos ao SE dos cartões SIM e os serviços de HCE, a GSMA solicitou que a Consult Hyperion produzisse um guia “HCE e o Elemento Seguro do SIM: Nada é Preto e Branco” (disponível em inglês: HCE and SIM Secure Element: It’s not Black and White), uma comparação entre SE e HCE. O guia foi endossado pela MasterCard, Associação de Cartões do Reino Unido e Fórum Mobey.

Os bancos solicitaram mais informações sobre o uso da HCE. Este documento pretende apresentar uma análise detalhada para bancos e operadoras da rede de telefonia móvel que estiverem considerando o uso da HCE e da tokenização em serviços de pagamentos via telefonia móvel.

6


Figura 1 (Fonte: Google http://developer.android.com/guide/topics/connectivity/nfc/hce.html)

A emulação de cartões foi precursora da emulação de cartões no sistema (HCE), portanto é necessário tecer uma breve descrição do HCE, para fornecer contexto.

Como o nome sugere, a emulação de cartões faz um telefone celular atuar como um cartão inteligente, ou “smart card”. Isso permite, por exemplo, que um telefone celular seja utilizado em uma transação de pagamento local, substituindo o cartão contactless (sem contato).

Antes da HCE, era necessário que um dispositivo de cartões inteligentes (por exemplo, um elemento seguro como um cartão SIM) estivesse acessível ao telefone celular e fosse utilizado para armazenar o aplicativo de pagamento. Esta estrutura é denominada “Emulação de Cartões”. O aplicativo de pagamento do elemento seguro proporciona a lógica para as transações e os riscos, de modo que o aplicativo de pagamento se envolva no processo de

aprovação ou recusa de uma transação, gerenciando dados críticos no ambiente inviolável do elemento seguro.

Quando se efetua a emulação de cartões por NFC com um elemento seguro, a experiência do usuário com a máquina de pagamentos (em uma loja, por exemplo) é idêntica. De modo semelhante, com a HCE, efetua-se uma transação de pagamento padrão da EMV em um aplicativo presente no sistema operacional do telefone celular e o PDV detecta um aplicativo de telefonia móvel, semelhante à um cartão móvel de pagamentos.

O controlador NFC é um elemento de hardware projetado para encapsular a troca de dados entre a leitora de NFC e o aplicativo de destino, da camada de rádio para a do aplicativo. O elemento seguro de cartão SIM conecta-se diretamente ao controlador NFC por meio de um único fio físico e, assim, o sistema operacional (SO) móvel não tem acesso aos dados trocados.

1.2 O que é a emulação de cartões?

1.3 O que é emulação de cartões no sistema?

EMULAÇÃO DE CARTÕES POR ELEMENTO SEGURO DA NFC E EMULAÇÃO DE CARTÕES NO SISTEMA

Com a HCE, não se requer um dispositivo de elemento seguro. O aplicativo de pagamento é armazenado no sistema operacional do telefone celular (o sistema do dispositivo ou, abreviadamente, “sistema”). Como o sistema do dispositivo não é seguro, o aplicativo de pagamento da HCE não pode proteger plenamente os dados confidenciais e deve garantir que a utilidade dos dados nele contidos permaneça restrita, de forma que os riscos associados ao comprometimento desses dados sejam limitados. Isso é feito utilizando-se diferentes dados de pagamento por transação.

CPU do sistema

Controlador de NFC

Leitora de NFC

Elemento seguro

CPU do sistema

Controlador de NFC

Leitora de NFC

DISPOSITIVO ANDROID

DISPOSITIVO ANDROID

7


Na HCE, o controlador de NFC está conectado ao aplicativo através do sistema operacional (SO) do dispositivo móvel que, teoricamente, permite ao SO ler os dados intercambiados. Isso pode ser um problema para alguns aplicativos, mas, nos pagamentos com cartão, não há requisitos específicos quanto à confidencialidade de dados entre um aplicativo e a leitora. No padrão EMV, os dados são intercambiados entre o aplicativo e o terminal livre de riscos. Garante-se a integridade dos

pagamentos utilizando criptogramas de transações que podem ser verificados apenas pelo emissor e utilizando diferentes dados em diversos canais, como a exigência de uso do código seguro nas transações sem cartão (CNP), ou utilizando diferentes números primários da conta (PANs) através de canais diferentes.

Atualmente, a HCE é compatível com o KitKat do Android 4.4 e com o SO 10 da Blackberry.

Vimos que a HCE permite aos aplicativos de pagamento alocados no aparelho telefônico emular cartões na interface da NFC. O que a HCE não proporciona é uma maneira de garantir a segurança desses aplicativos caso um elemento seguro de hardware não seja instalado. Como não é possível confiar na segurança dos dados do pagamento da mesma maneira que os produtos tradicionais envolvendo cartões e a NFC do elemento seguro, são necessárias abordagens alternativas de segurança. Normalmente, elas envolvem o aprovisionamento de credenciais de pagamento de uso limitado (PANs e chaves criptográficas, por exemplo) no aplicativo antes de cada transação. O aprovisionamento de PANs de uso limitado é denominado tokenização.

A tokenização é o processo de substituição do PAN de uma conta por um “Token PAN” de uso único ou limitado, cujo uso pode ser limitado pelo dispositivo do consumidor, canal

ou comerciante. Isso reduz significativamente o impacto de violações de dados já que, por exemplo, a captura dos PANs em sistemas de um comerciante não afetaria os de outros comerciantes. O objetivo é se certificar de que, caso um “Token PAN” for capturado, a sua utilidade será limitada ou nula. A tokenização é uma camada que pode ser sobreposta à HCE.

Para poder empregar esse serviço, o emissor deve entrar em contato com um provedor de serviços de tokens (TSP) para gerar “Token PANs” (e, possivelmente, chaves de pagamento), que serão enviados ao aplicativo de telefonia móvel e utilizados em transações por HCE. Quando essas transações forem processadas pela rede de pagamentos, o TSP será contatado para converter os “Token PANs” em PANs reais, o que permitirá o emissor processar normalmente a transação.

1.4 O papel da tokenização

TOKENIZAÇÃO DOS PANS

Figura 2

EmissorAplicativo de pagamento

TerminalEmissor

Provedor de serviços de

token

“Token PAN” + chaves

“Token PAN” + Criptograma da Transação

“Token PAN”

“Token PAN”

PAN

PAN

AP

RO

VIS

ION

AM

EN

TOA

CE

ITA

ÇÃ

O

8


Embora não seja uma nova técnica de pagamentos feitos no varejo, a tokenização ainda está sendo formalmente definida pela EMVCo1. Criada especialmente com a tentativa de lidar com o número crescente de fraudes sem cartão (CNP) do comércio eletrônico, uma das possíveis situações identificadas pela EMVCo para tokenização é apoiar os pagamentos com a HCE sem contato.

Vale observar que não é obrigatória a tokenização da EMV nos pagamentos contactless HCE com cartões da EMV. Os emissores têm liberdade de usar os seus próprios esquemas de segurança que não se baseiam em provedores externos de tokenização. Normalmente, esses esquemas seriam a adoção de PANs estáticos, utilizados apenas em transações específicas nos aplicativos com HCE e dados dinâmicos, como a utilização de chaves de sessão de uso limitado que são válidas apenas para uma única transação (cada valor do contador de transações de aplicativos [CTA]), conforme o permitido pelas especificações existentes de pagamentos da EMV. Observe também que as chaves de sessão podem ser utilizadas com PANs autenticados. De qualquer forma, será necessário distribuir e administrar os dados específicos a cada transação (token ou chaves de sessão).

CHAVES DE SESSÃO SEM TOKENIZAÇÃO

Figura 3

1. Especificação da tokenização do pagamento da EMV – Estrutura Técnica: http://www.emvco.com/specifications.aspx?id=263

Emissor Aplicativo de Pagamento

TerminalEmissor

PAN + Chaves de Sessão Para Cada Transação

Aplicativo de Pagamento

Valor Individual do CTA Pré-computado

PAN + Criptograma de Transação

AP

RO

VIS

ION

AM

EN

TOA

CE

ITA

ÇÃ

O

9


1.5 A discussão Elemento seguro versus HCE

O guia recente da Consult Hyperion “HCE e o Elemento Seguro do SIM: Nada é Preto e Branco” (disponível em inglês: HCE and SIM Secure Element: It’s not Black and White), apresenta uma discussão detalhada que confronta os elementos seguros com a HCE e compara as duas abordagens.É possível resumir a discussão da seguinte maneira.

Como o hardware seguro não é utilizado, acredita-se que a solução da HCE por NFC para pagamentos contactless via celular elimine um pouco da complexidade associada aos pagamentos de cartões SIM com base no SE por NFC e reduza a necessidade do envolvimento de operadoras de telefonia.

Embora a HCE simplifique de fato alguns aspectos do ambiente de NFC, ela requer uma nova abordagem de segurança que, por enquanto, implica na necessidade dos emissores criarem novos recursos internos ou trabalharem com fornecedores especializados. Os emissores também precisarão colaborar com as redes de pagamentos para obter isenções de certificação, até que as regras da HCE sejam finalizadas.

Por outro lado, os processos envolvendo cartões SIM com base no SE estão estáveis, porém são mais complexos para implementar. Por isso, as operadoras estão trabalhando para simplifica-los. Nos

mercados com ambientes maduros de NFC envolvendo cartões SIM com base no SE, a adoção da abordagem envolvendo cartões SIM baseados em SE deve ser mais rápida e com menores riscos do que a HCE, já que, do ponto de vista do emissor, a gestão de riscos dos aplicativos de pagamento de cartões SIM baseados em SE é muito semelhante à gestão de riscos dos aplicativos de pagamento de cartões.

As abordagens de pagamentos por NFC envolvendo cartões SIM com base no SE e na HCE não devem ser consideradas como mutuamente exclusivas. Há uma sobreposição significativa dos recursos necessários ao suporte de pagamentos contactless em cada abordagem, deve-se explorar os recursos complementares.

Para compreender as opções envolvidas, vale a pena fazer uma análise estruturada dos principais elementos da proposta de pagamentos contactless, que incluem: o ambiente, o aprovisionamento, a experiência do usuário, a segurança, o modelo comercial e a segurança da infraestrutura. Cada uma destas características em relação à HCE será explicada em detalhe neste documento.

10


2. Ambientes de pagamento por NFC

A Figura 4 ilustra o ambiente que está emergindo da HCE nos pagamentos móveis sem contato.

2.1 O ambiente da HCE

O AMBIENTE DE NFC DA HCE

Figura 4

Provedor de Serviços de

Tokens

Cliente

AdquirenteEmissor Esquema de Cartões

Comerciante

Provedor de Terminais

Provedor de SOs de Dispositivos

Repositório de Aplicativos

Provedor de Aplicativos

Provedor de Dispositivos

As relações necessárias para processar transações de pagamento de HCE são as mesmas que as dos pagamentos tradicionais com cartão (o modelo de quatro cantos), com o potencial para a inclusão de um TSP, caso a tokenização seja adotada. Conforme observado, o emissor é responsável por escolher o esquema de segurança a ser utilizado nos seus aplicativos de HCE, e o uso da tokenização da EMV é opcional.

O emissor mantém a sua relação com o esquema de cartões correspondente ao produto de pagamentos sendo emitido. O esquema de cartões opera a rede de pagamentos que proporciona as relações de aceitação de transações com os comerciantes, por intermédio dos adquirentes e processadores.

11


As transações por NFC de HCE aceitas pelos comerciantes são diretamente equivalentes ao cartão contactless ou às transações por NFC com SE – denominadas transações “com cartão presente”. Isso significa que os emissores e os adquirentes têm as mesmas responsabilidades que os cartões (conforme a definição do esquema de cartões) e comerciantes são oferecidos os mesmos termos de acordo. De acordo com as regras do esquema, os emissores deverão garantir que o modelo de responsabilidades envolvendo a presença de cartão coincida com a norma de gestão de riscos das transações de HCE. Por exemplo: os emissores poderão optar por não autorizar determinados tipos de transação a partir de aplicativos de HCE, como os que exigem autenticação off-line de dados. Clientes recebem aparelhos telefônicos de provedores de dispositivos (que, em muitos mercados, são operadoras da rede de telefonia móvel), independente do processo de aplicativos de pagamento. Em uma “loja” de aplicativos, os clientes efetuam o download dos aplicativos de pagamento da HCE para os seus dispositivos, seguindo o processo usado para qualquer outro aplicativo. Normalmente, os repositórios de aplicativos são mantidos pelo provedor do SO correspondente ao dispositivo. O provedor do aplicativo de pagamento poderá publicar o aplicativo em uma “loja de aplicativos” em nome de um emissor, ou o emissor poderá publicá-lo. Como este é o processo padrão para fins genéricos na gestão de aplicativos, o emissor tem menos controle sobre o mecanismo de distribuição do aplicativo e não poderá necessariamente confiar em sua integridade nem na dos dados que são carregados no aplicativo. Isto é completamente diferente de distribuir aplicativos de smart cards ou elementos seguros, onde a integridade do dispositivo pode ser confiada no Centro de Personalização para cartões ou com TSMs para elementos seguros. Isso difere significativamente da distribuição de aplicativos de cartões inteligentes para cartões ou elementos seguros, nos quais é possível confiar na integridade do dispositivo

por meio das relações com o Centro de Personalização, no caso de cartões, ou com gerenciadores confiáveis de serviços (TSMs), no caso de elementos seguros. Desta forma, emissores derem utilizar novas maneiras para garantir a integridade dos aplicativos, através de novas tecnologias. Assim, os emissores devem utilizar novos meios para garantir a integridade dos aplicativos, por meio do uso de técnicas de redução das vulnerabilidades do software, e para proteger os dados de transações, por meio da geração e utilização de dados dinâmicos nas transações, que forem de uso limitado e que possam ou não incluir tokenização dos PANs. Esses aspectos serão avaliados em detalhe nas seções seguintes deste documento.

Não são necessários TSMs na HCE. Esta é uma das principais diferenças entre o ecossistema de elementos seguros e o da HCE. Nos elementos seguros que utilizam TSMs, obtém-se a interoperabilidade graças à utilização de padrões da GlobalPlatfom. Na HCE, não há um padrão único que indique como garantir a integridade do aplicativo de pagamento e dos dados. Isso pode levar a uma fragmentação das soluções e a questões de uso entre os clientes. Esses aspectos serão avaliados em detalhe nas seções seguintes deste documento.

12


2.2 Ecossistema de elementos seguros

2. http://nfctimes.com/news/tsm-hubs-and-aggregators-can-they-help-banks-roll-out-nfc

EXEMPLO DE ECOSSISTEMA DE CARTÕES SIM COM BASE EM SE QUE UTILIZA UM NÚCLEO DE TSM

Figura 5

2.2.1 Cartões SIM com base em SENos pagamentos contactless via celular, o ecossistema de elementos seguros dos cartões SIM se baseia no aprovisionamento dos aplicativos de pagamento de smart cards, incluindo credenciais confidenciais de pagamentos contidas no elemento seguro do cartão SIM. O aplicativo de pagamento efetua a transação de pagamento contactless da EMV ao PDV através da interface NFC, que, ao PDV, se assemelha a um cartão de pagamento contactless. O aplicativo de telefonia móvel também instalado no aparelho telefônico (fora do SE) é parte da interface de usuário com o consumidor – mas a transação é gerenciada pelo aplicativo que estiver ativo no cartão SIM.

O modelo permite aos emissores e esquemas de cartões atuarem em conjunto com as operadoras de telefonia celular, de modo a instalarem o seu aplicativo de pagamento no cartão SIM através do TSM da operadora de telefonia celular. Assim que tiver sido aprovisionado, o emissor utilizará o seu próprio TSM para gerenciar as credenciais de pagamento no seu aplicativo de pagamento. Para simplificar o aprovisionamento de aplicativos de pagamento por NFC, as operadoras da rede de telefonia móvel e terceiros (como os esquemas de cartões ou consórcios de emissores) criaram núcleos de TSM2 e os TSM comuns para que os emissores se conectem a todas as operadoras de um determinado mercado. A Figura 5 ilustra essa abordagem.

Uma outra prática comum é pré-instalar aplicativos de pagamento do esquema de cartões principal no cartão SIM, que, podem ser ativados remotamente por cada emissor. Isso evita a necessidade de efetuar o download de um aplicativo para cada emissor. Uma abordagem semelhante também é utilizada pelo ApplePay (item 2.2.2).

A partir de agora, as operadoras oferecem aos emissores de mercados pertinentes uma abordagem pronta, por meio dos núcleos de TSM, que combina o alcance de múltiplas operadoras, a concordância com a infraestrutura padrão de aceitação e oferece um modelo de segurança fácil de compreender.

OP

ER

AD

OR

3

OP

ER

AD

OR

2

OPERADOR 1

Comerciante

Provedor de terminais

Provedor de dispositivos

Provedor de pagamentos on-line

Provedor de elementos

seguros

Cliente

Esquema de cartõesNúcleo de TSM

Provedor de SOs de dispositivos

Emissor Adquirente

13


2.2.2 SE embutido – Apple PayA abordagem selecionada pela Apple é muito semelhante à abordagem existente de cartões SIM com base em SE. A Apple também criou um ecossistema próprio para pagamentos contactless via celular baseado em aplicativos de pagamento de smart cards, que é executado em um elemento seguro embutido em seus dispositivos. Segundo informações disponibilizadas publicamente3, a Apple tem acordos com os esquemas de cartões que permitem a estes mapear um aplicativo de pagamento instalado no elemento seguro na conta de um cliente emissor, por meio do serviço de TSM do próprio provedor de serviços (SP) do esquema.

Emissores devem se cadastrar no serviço Apple Pay, após isso, suas contas de cartões são mapeadas como aplicativos de pagamento do esquema SE. Os esquemas de cartões viabilizam o contrato entre o emissor e a Apple.

A Figura 6 ilustra o ecossistema correspondente a essa abordagem.

O AMBIENTE APPLE PAY

Figura 6

3. http://www.apple.com/apple-pay/

Esquema de cartões

Provedor de serviços de

token

Comerciante

Provedor de terminais

ESQUEMA DE CARTÕES

Adquirente

Cliente

Provedor de SOs de dispositivos

Serviço Apple Pay

Provedor de elementos

seguros

Provedor de pagamentos

on-line (Carteira)

OPERADOR 1

Emissor

Provedor de dispositivos

TSM do provedor de

serviços

14


A transação de pagamento é a transação padrão na presença de cartão que ocorre no caixa de um comerciante. Os esquemas de cartões personalizam um “Token PAN” estático (assim como as chaves e os dados a ele associados) em um aplicativo de pagamento do elemento seguro embutido, em nome do emissor. A conta do titular do cartão no emissor é mapeada para o PAN do SE no serviço de cartões. A diferença entre essa abordagem e a do cartão SIM descrita no item 2.2.1 é que o PAN é substituído por um nome alternativo, que é tokenizado. Por exemplo: para renovar as informações da conta pessoal, os esquemas de cartões podem emitir novamente um token para um novo cartão, sem reaprovisionar um novo token. Esse modelo de tokenização difere do modelo da HCE porque, como o token é armazenado com segurança em um elemento seguro, ele não precisa ser renovado a cada transação ou credenciamento dinâmico, o que simplifica o gerenciamento do sistema.

O Apple Passbook proporciona a interface de usuário para celulares. No iPhone da Apple, o usuário efetua a autenticação no Passbook, utilizando a leitora de impressões digitais do botão inicial. No Apple Watch, o usuário ativa o aplicativo de pagamento do SE por meio de dois toques em um botão lateral. Isso significa que o emissor não define a forma de autenticação do titular do cartão no aparelho telefônico, apenas adota o processo implementado pela Apple para o Passbook.

Como o serviço está sendo lançado nos EUA, não tendo ainda sido implementado em terminais da EMV, algumas questões estão em aberto quanto à sua compatibilidade com pagamentos existentes, até que seja lançado internacionalmente. Por exemplo: não há evidências confirmando que a autenticação de dados off-line será apoiada e se a verificação do titular do cartão do Passbook poderá substituir plenamente o PIN on-line nos terminais de PDVs em países que utilizam esse método de verificação do titular do cartão em pagamentos sem contato envolvendo valores mais altos.

Em resumo: a Apple está oferecendo aos emissores uma abordagem pronta, por meio dos esquemas de cartões, na qual o ecossistema e a experiência do usuário são gerenciados e definidos pela Apple.

2.2.3 ApplePay versus elemento seguro de cartões SIM: Outras consideraçõesA semelhança entre as abordagens da Apple e das operadoras sugere consistencia, segurança e simplicidade nos serviços de pagamento tanto no sistema operacional da Apple quanto em outros SOs.

Normalmente, o elemento seguro de cartão SIM poderia oferecer flexibilidade na interface do usuário, se comparar às restrições impostas pela Apple. A seleção de um produto de pagamento na lista de aplicativos instalados costuma ser feita numa interface de pagamentos on-line da operadora, mas é possível que seja um aplicativo separado.

A tokenização estática do PAN é uma ideia interessante para a abordagem do cartão SIM.Ele simplificaria a gestão da vida útil de cartões e permitiria aos emissores se conectarem com as operadoras da rede de telefonia móvel por meio das mesmas plataformas de tokenização.

Embora esteja fora do escopo deste documento, também vale observar que tanto a abordagem de SE de cartão SIM da operadora quanto a de SE embutido oferece potencial para que as transações iniciadas no elemento seguro sejam utilizadas em transações remotas de comércio eletrônico. A GSMA publicou o seguinte artigo, Comércio móvel e on-line, oportunidades proporcionadas pelo cartão SIM)4, que investiga detalhadamente esse tópico. O ApplePay também aborda as transações sem contato e remotas, embora de maneira diferente, já que os pagamentos embutidos em aplicativos são parte dos casos de estudo de seus devices.

4. http://www.gsma.com/digitalcommerce/mobile-and-online-commerce-opportunities-provided-by-the-sim

15


3. CONSIDERAÇÕES

Normalmente, a abordagem envolve o aprovisionamento de credenciais de pagamento de uso limitado (ou seja, chaves criptográficas e dados) ao aplicativo no dispositivo de telefonia celular, que se tornarão inválidas após a efetuação da transação que utilizará as credenciais.

As credenciais de pagamento de uso limitado são denominadas dados dinâmicos para o aplicativo da HCE. É necessário que os dados dinâmicos sejam armazenados no aplicativo a cada nova transação (ou número pequeno de transações, dependendo das regras do

esquema e da escolha do emissor para com relação à riscos) a ser efetuada. Na HCE, portanto, o armazenamento de credenciais de pagamento é obrigatório antes de uma transação, ao contrário dos aplicativos envolvendo elementos seguros, nos quais as credenciais de pagamento são aprovisionadas uma vez. Esta é uma diferença importante em termos de gestão de serviços.

A Figura 7 fornece uma visão geral do modelo de aprovisionamento de pagamentos móveis contactless com HCE.

Como um aplicativo de pagamento da HCE sendo executado no software do sistema do dispositivo não proporciona os mesmos níveis de segurança que um elemento seguro de hardware, são necessárias abordagens alternativas de segurança, que resultem em um modelo diferente de aprovisionamento.

3.1 Aprovisionamento

MODELO DE APROVISIONAMENTO DA HCE

Figura 7

Terminal de pagamento do

comerciante

Adquirente

Aplicativo da HCE

EMISSOR

APARELHO TELEFÔNICO

Rede de pagamentos

Gestão de dados dinâmicos

Gestão de aplicativos e dispositivos

Autenticação do cliente

Gestão de contas

Gestão de fraudes Autorização

Repositório de aplicativos, Loja de Aplicativos,

App Store AprovisionamentoTransação

16


Conforme se observou no Capítulo 2, o emissor não controla a distribuição do aplicativo para a sua base de clientes.Para garantir que o aplicativo correto seja utilizado pelos clientes, é necessário que os recursos a seguir sejam disponibilizados pelos emissores:

• Gestão de aplicativos, para proteger a integridade do aplicativo da HCE e garantir que haja apenas instâncias identificáveis do aplicativo instaladas na base de clientes. Embora os emissores já tenham aplicativos adquiridos previamente, é possível que a gestão da HCE precise incluir outros recursos para proteger a integridade.

Do mesmo modo, a integridade dos aplicativos de HCE exigirá recursos que não são necessariamente obrigatórios em aplicativos compatíveis com transações de elementos seguros. Por exemplo: é possível que um aplicativo da HCE queira detectar se o SO do dispositivo móvel foi

infectado, está executando um depurador ou se o aplicativo está sendo executado em um simulador.

• Gestão de dispositivos, para identificar e acompanhar cada dispositivo utilizado em aplicativos da HCE, e para controlar quaisquer alterações. Sem acesso a hardware seguro no dispositivo, os emissores precisam se basear em métodos de autenticação mais fracos para identificar o dispositivo. Esses métodos incluem perfis de software e informações ambientais relatadas por software (a localização, por exemplo).

• Autenticação do cliente, que proporcione funções de vinculação em que será mandatório que o cliente utilize o seu dispositivo e a instância do aplicativo da HCE nele instalada. Quanto mais robusta for a autenticação do cliente, mais confiança os emissores terão de que o aprovisionamento está sendo executado no cliente e no dispositivo corretos.

3.1.1 Providenciando dados dinâmicosOs emissores precisam decidir como gerar e gerenciar os dados dinâmicos a serem utilizados em cada transação durante a concepção do serviço. Por exemplo: o emissor deve decidir entre gerar um PAN dinâmico autenticado em cada transação ou utilizar chaves criptográficas de sessão.

Os PANs dinâmicos são PANs exclusivos pré-computados, que serão utilizados em uma única transação. Um PAN dinâmico pode ser utilizado para gerar uma chave do cartão do aplicativo, esta será utilizada no pagamento por meio de um criptograma de transação.Neste caso, o PAN dinâmico e a chave do cartão constituem credenciais dinâmicas de pagamento a serem baixadas para o aplicativo da HCE antes da transação.

Desde o lançamento da versão 4.0 da EMV (publicada no ano 2000), os emissores têm a opção de utilizar chaves de sessão. Chaves de sessão são chaves criptográficas válidas apenas para uma transação, que é controlada pelo contador de transações mantido pelo emissor. As chaves de sessão são usadas para gerar criptogramas para transações, isso significa que a tokenização do PAN não é necessária, porém é recomendável ter um PAN alternativo para o canal da HCE.

17


GERAÇÃO DE CHAVES DE SESSÃO POR TRANSAÇÃO

Figura 8

Independente do método de dados dinâmicos selecionado, é obrigatória a presença do processo de autorização da transação (verificação da integridade dos dados da transação e dos criptogramas), para implementar um processo que detecte corretamente erros nos dados da transação e criptogramas incompatíveis.

FLUXO DE PROCESSOS DE CRIPTOGRAMAS DAS TRANSAÇÕES COM CHAVES DE SESSÃO

Figura 9

CHAVE-MESTRA

CHAVE DA SESSÃO

Chave de sessão pré-computada para cada valor do contador de transações do aplicativo (CTA)

Utilizada para autorizar uma única transação

Download efetuado para o aplicativo da HCE

PAN + número sequencial

CTA + dados do emissor

EmissorAplicativo de pagamento

TerminalEmissor

Chaves de sessão pré-computadas de acordo com downloads do usuário, válidas para uma única transação

Criptograma verificado pelo

emissor

Criptograma da transação enviado

para o emissor

O terminal fornece dados das transações e o aplicativo usa a chave da sessão para calcular o criptograma da transação

18


Além dos sistemas de autorização de transações, é necessário avaliar o impacto das opções de aprovisionamento associadas a outros sistemas do emissor. Por exemplo: é possível que haja diferentes limites aplicados às transações de HCE; É provável que transações off-line não serão possíveis e não devem ser autorizadas, caso registros de autorização sejam recebidos; é possível que os aplicativos de HCE sejam disponibilizados apenas a um segmento específico dos clientes, etc. É necessário que emissores estejam cientes de que escolhas relativas ao serviço poderão resultar na exigência de alterações em outros sistemas.

3.1.2 TokenizaçãoComo foi assinalado no Capítulo 3, a utilização de PANs autenticados no nível de transação é opcional para os emissores (embora não seja recomendado utilizar o PAN da conta real) e provavelmente dependerá da aprovação das chaves de sessão pelos sistemas emissores em vigor, e se a tokenização será implementada pelo emissor em outros casos, como nos pagamentos do comércio eletrônico, por exemplo.

Caso se opte por utilizar a tokenização e estiver sendo empregado um TSP externo, o modelo providenciado corresponderá àquele ilustrado na Figura 10.

HCE PROVIDENCIANDO A TOKENIZAÇÃO

Figura 10

Nessa configuração, o TSP fornece ao aplicativo da HCE os dados dinâmicos a serem baixados. Isso significa que para obter autorização, o TSP deve verificar o resultado da transação utilizando esses dados, antes de repassar ao emissor os dados equivalentes da transação reconvertidos.

Aplicativo da HCE

EMISSOR


Rede de pagamentos

Provedor de serviços de tokens

Adquirente

Terminal do comerciante


Autenticação de dispositivos e de aplicativos


Gestão de contas


Repositório de aplicativos, loja de aplicativos,

App Store

AprovisionamentoTransação

19


É necessário prover credenciais de pagamento frequentemente, portanto os emissores devem ser cautelosos para não criar problemas de usabilidade. Este tópico será considerado em mais detalhes nesta seção.

Embora a experiência do usuário com um comerciante com um aplicativo da HCE seja idêntica à transação de pagamento iniciada por um elemento seguro, o trajeto para providenciar dados a ser seguido pelo cliente até o aplicativo de telefonia móvel é diferente e mais complicado.

Como não é possível recuperar dinamicamente as credenciais do banco emissor durante uma transação, devido à latência da rede e à falta de conectividade universal entre os comerciantes, é necessário enviar as credenciais de pagamentos (como PANs dinâmicos e chaves de uso único) para o telefone celular antes de cada transação.

A Figura 11 ilustra essa situação.

3.2 Experiência do usuário

Aprovisionamento

20


JORNADA DO CLIENTE

Figura 11

Download do aplicativo

Instalação do aplicativo

Conexão com o emissor

Processo de identificação e

verificação

Personalização dos dados estáti-cos do aplicativo

Download de dados dinâmicos

Efetuação da transação

Geração de dados estáticos (no nível

da transação)

Aprovisionamento dos dados dinâmicos

Recebimento da transação

Reconversão do PAN

Autorização da transação

Processamento da solicitação

de serviço

Verificação de cliente e dispositivo

Geração de dados estáticos (no nível

da conta)

Aprovisionamento dos dados estáticos

do aplicativo

CLIENTEA

PR

OV

ISIO

NA

ME

NTO

ISO

LAD

O D

E S

ER

VIÇ

OS

AP

RO

VIS

ION

AM

EN

TO R

EC

OR

RE

NTE

D

E D

AD

OS

DIN

ÂM

ICO

S E

USO

DE

TR

AN

SAÇ

ÕE

SEMISSOR

Rede de

PDVs

21


De acordo com a Figura 12, as características do pagamento no PDV da NFC por HCE e com base em elementos seguros são semelhantes. Emissores precisam estar cientes das diferenças que aplicativos de HCE possuem pois estas afetam a usabilidade. Por exemplo: atualmente, o Android requer que a tela seja ligada para que o processador do sistema execute aplicativos, o que significa que quando a energia estiver baixa ou ausente, os aplicativos da HCE não funcionarão. Enquanto aplicativos de elemento seguro são capazes de funcionar quando o aparelho telefônico estiver com energia baixa ou ausente, já que o controlador pode ser ativado passivamente pela leitora.

Além disso, é possível que diferentes implementações de esquemas de cartões tenham requisitos diferentes que afetarão a experiência do usuário. Por exemplo: uma opção pode requerir a digitação de um PIN no aplicativo de HCE para verificar o titular do cartão antes da execução de uma transação.

EXPERIÊNCIA DO USUÁRIO NAS TRANSAÇÕES DE PAGAMENTO

Figura 12

3.2.1 Download de dadosComo indica a jornada do cliente ilustrada na Figura 7, o requisito para efetuar o download de dados dinâmicos antes das transações (e como ele é implementado) afetará a experiência do usuário. É necessário que os emissores configurem quantas transações terão apoio em um determinado download de dados dinâmicos e com que frequência os clientes deverão ser autenticados (a cada download ou com menor frequência, por exemplo).

Normalmente, esses aspectos são definidos e controlados pela gestão de riscos do emissor, que é responsável por avaliar riscos, caso haja um comprometimento de um aplicativo de HCE. As principais questões são:

• Quantas “sessões” estarão disponíveis simultaneamente no aparelho telefônico?

• O titular do cartão deve ser autenticado a cada download e atualização?

• É possível utilizar outros fatores, como a localização do dispositivo para aprimorar a experiência? Diminuir a frequência de autenticação em casa/no trabalho, por exemplo.

Nas implementações iniciais, os emissores precisarão acompanhar e aprender comportamentos, para que a experiência do cliente seja otimizada enquanto controla possíveis riscos. Por exemplo, é possível assegurar que o usuário não use o limite “sessões”.

A interação do cliente é exigida apenas no passo de autenticação, conforme ilustra a Figura 13. Se o emissor decidir que nenhuma autenticação é necessária em um determinado download, ela poderá ser executada automaticamente no background. Se a autenticação do cliente for necessária, o usuário receberá uma notificação para completar a autenticação.

Obrigatório Opcional

Transação de HCE

Acionamento da tela

Desbloqueio do aparelho telefônico

Abertura do aplicativo de pagamento

Desbloqueio do aplicativo

de pagamento

Apresentação à leitora

Pagamento enviado

Transação no SE

Acionamento da tela

Desbloqueio do aparelho telefônico

Abertura do aplicativo de pagamento

Desbloqueio do aplicativo

de pagamento

Apresentação à leitora

Pagamento enviado

22


EXPERIÊNCIA DO USUÁRIO NA ATUALIZAÇÃO DOS DADOS DINÂMICOS

Figura 13

Sistemas e processos de gestão de contas dos emissores (como atendimento ao cliente) precisam ser atualizados com desenvolvimentos para aplicativos de HCE. Como a experiência do cliente de aplicativos de HCE é contínua (já que é necessário atualizar os dados dinâmicos), é importante acompanhar a atividade das contas (protegendo a privacidade dos usuários), para que se possa atender clientes com eficiência e lidar com problemas de usabilidade, à medida que surgirem. Isso será parte fundamental da experiência geral do cliente.

Obrigatório Opcional

Atualização dos dados dinâmicos

Aplicativo determina a

atualização de dados necessária

Dispositivo autenticado pelo emissor

Usuário autenticado pelo emissor

Download dos dados dinâmicos

23


3.2.2 Considerações sobre a experiência do usuárioA Tabela 1 apresenta um resumo dos principais recursos da experiência do usuário que precisam ser considerados pelos emissores para apoiar a HCE.

RECURSOS COMENTÁRIOS

Aplicativo padrão de pagamentos

A seleção do aplicativo padrão é definida no Android e é, em princípio, controlada pelo usuário.

Desligamento/baixa energia

Os aplicativos de HCE exigem que o processador funcione normalmente para viabilizar as transações.

Transação on-line A HCE foi desenvolvida para ser autorizada on-line. Na maioria das situações, a HCE proporciona uma experiência semelhante nas transações de cartões sem contato e nas de elemento seguro on-line.

Transação off-line A autenticação de dados off-line padrão em terminais requer uma série adequada de certificados públicos aprovada por uma chave de esquema no ponto inicial da hierarquia. O par de chaves do aplicativo de pagamento e o certificado precisam ser protegidos no software por um período longo o suficiente para impedir que a sua descoberta viabilize outras transações off-line e comprometa a integridade do esquema. As especificações atuais de HCE não permitem transações off-line. O impacto disso dependerá do mercado, já que, embora muitos terminais off-line tenham capacidade de funcionar on-line, alguns pontos de aceitação serão afetados nos mercados que permitem transações off-line.

Trânsito Transações em trânsito são autorizações postergadas – uma combinação de autenticação de dados off-line e uma transação on-line. Como observado anteriormente, seria necessário que a autenticação de dados off-line fosse permitida pelas especificações do esquema de cartões. Há propostas em andamento para uma hierarquia de chaves públicas relativa à trânsito, mas esse projeto ainda não foi padronizado.

Pagamentos envolvendo valores mais altos – mercados de PINs off-line

Em princípio, a HCE proporciona uma experiência do usuário semelhante às transações com PINs on-line envolvendo cartões contactless ou elementos seguros. A transação é aceita pela leitora do PDV e o PIN, digitado em um bloco anexo de PINs.

Pagamentos envolvendo valores mais altos – mercados de PINs off-line

Embora um PIN não possa ser verificado off-line em um aplicativo padrão de telefonia móvel, os PINs podem ser verificados pelos sistemas do emissor por meio do uso de criptogramas de transação que utilizam o PIN como entrada ou, pela utilização de um recurso ou serviço de dispositivos adicionais (como um elemento seguro de hardware ou ambiente de execução segura), ambos dependem das regras e da gestão de riscos do emissor. Os recursos para obter isso não são padronizados, podendo variar de acordo com o emissor.

Pagamentos remotos Em princípio, da mesma maneira que os aplicativos de pagamento da telefonia celular envolvendo elemento seguro podem efetuar transações de comércio eletrônico, os aplicativos de HCE que utilizam credenciais de uso único podem ser utilizados à distância. Será necessário implementar a autenticação do cliente de forma diferente à dos pagamentos no PDV. Atualmente, não há uma operação interoperável definida pelos esquemas de cartões.

TABELA 1: RESUMO DAS EXPERIÊNCIAS DO USUÁRIO

24


Como não há um hardware seguro para a HCE, as soluções propõem o uso de dados dinâmicos (PANs dinâmicos e chaves criptográficas de sessão, por exemplo) a serem repassadas ao aplicativo de telefonia móvel, para permitir que este efetue uma única transação com base nessas credenciais. Como estas credenciais de pagamento se destinam a um único uso, os riscos de segurança das transações seriam menores do que o período esperado de validade das credenciais, por alguns anos (como é o caso das soluções envolvendo elementos seguros).Contudo, é de fundamental importância que as credenciais sejam repassadas ao dispositivo correto, sob o controle do titular do cartão e ao longo da vida útil do dispositivo. A utilização do método de dados dinâmicos geralmente demanda intensa gestão de perfis e monitoramento das transações.

Embora o risco real de serviços de HCE dependa da sua implementação, a Tabela 2 apresenta as principais áreas de riscos dos pagamentos e as medidas contrárias esperadas.

3.3 Segurança

RISCO IMPACTO MEDIDA CONTRÁRIA/CONTROLES

Falsificação Aplicativo clonado e utilização em outro dispositivo, ou reutilização no mesmo dispositivo.

Alteração do código do aplicativo, permitindo que seja utilizado quando a lógica normal recusaria transações

Chaves de pagamento por download com limites de uso em transações on-line.

Limites de uso em transações off-line.

Software que protege o aplicativo de HCE, chaves e outros dados confidenciais.

Não se deve incluir qualquer lógica de gestão de riscos no código do aplicativo.

Monitoramento para detectar fraudes fora dos padrões do uso de dispositivos ou transações.

Incorporação de segurança de hardware, utilizando um elemento seguro ou um ambiente de execução segura.

Perdidos e roubados Dispositivo roubado usado para transações. Autenticação do cliente para a atualização dos dados dinâmicos e, no PDV, para transações envolvendo valores mais altos.

Incorporação da gestão de aplicativos e dispositivos, para garantir que cada aplicativo seja uma instância distinta e identificável.

Contaminação cruzada Captura de dados e reutilização em um outro canal.

Utilização de PANs específicos à HCE, nos aplicativos de HCE, ou de um PAN dinâmico de um serviço de tokenização.

TABELA 2: EXEMPLOS DE RISCOS DA HCE

25


3.3.1 Controles e gestão de riscosPara lidar com as ameaças introduzidas anteriormente será necessário um aplicativo sujeito a riscos e um sistema de gestão de dispositivos que possa gerenciar todo o conjunto de instâncias do aplicativo capazes de tomar decisões que permitam o aprovisionamento ou uso de transações.Os controles requeridos para que os aplicativos de HCE funcionem, exigem os seguintes tipos de funções de segurança incluídos nas implementações do emissor:

• Segurança do aplicativo – para proporcionar proteção para o aplicativo (ou seja, para garantir que ele não tenha sido violado, roubado ou comprometido) as chaves de pagamento e outros dados confidenciais, por meio da proteção por software (por exemplo: utilizando talvez a criptografia de caixa branca, quando possível) no aplicativo do aparelho telefônico e/ou incluindo compatibilidade com o hardware seguro (ou seja, um elemento seguro ou ambiente de execução segura) para armazenar dados confidenciais;

• Segurança do dispositivo – para avaliar se é possível confiar no dispositivo, usando mecanismos de detecção de software vinculados ao SO (detecção de root, e emulador/depuração, por exemplo) e/ou incluindo compatibilidade com o hardware seguro.

• Segurança das comunicações – para garantir que comunicações entre o aplicativo do aparelho telefônico e os servidores do sistema do emissor sejam confidenciais e íntegras.

A aceitação de uma transação de pagamento eletrônico é considerada na gestão de riscos.A gestão de riscos visa a reduzir a probabilidade ou limitar o impacto destes, mantendo a boa usabilidade e aceitando os tipos de transações necessárias. Isso pode ser implementado pelos emissores por meio de uma combinação entre autorização técnica dos dados das transações e sofisticados sistemas e processos de gestão de fraudes (que podem ser terceirizados desde que sigam normas necessárias). Atualizações da gestão de fraudes podem incluir o monitoramento das características das transações de HCE, como a vinculação destas a identidades de dispositivos e aplicativos, além do monitoramento do comportamento do cliente e do histórico de transações.

É importante que a experiência do cliente não seja afetada negativamente pela introdução dos controles necessários à proteção contra os riscos identificados.Esse equilíbrio precisa ser avaliado em conjunto com o ambiente e os aplicativos existentes dos emissores, para garantir uma abordagem coerente em todos os serviços.

Vale observar que o risco à reputação associado a falhas de segurança pode ser mais custoso do que os prejuízos monetários contraídos pelo emissor, especialmente nos mercados off-line nos quais as transações sem contato estão limitadas a valores baixos.

26


3.4.1 HCE no softwareO modelo comercial da HCE parece oferecer um modelo de aprovisionamento “gratuito”.Contudo, é necessário que o emissor invista em suas plataformas, para prover os serviços de HCE, já que os dados dinâmicos transmissíveis de aplicativos sem contato da EMV são um novo recurso.

A vantagem tangível para o emissor seria o modelo de receitas de transações, que se aplica a cartões contactless no mercado, com uma elevação esperada das transações devido à conveniência de se ter um produto para pagamentos no formato de um dispositivo móvel. Graças à autenticação do titular do cartão, o dispositivo móvel permite pagamentos sem contato envolvendo valores mais altos. Dessa maneira, qualquer elevação observada no volume das transações também poderá incluir um aumento do valor das transações sem contato, assim como da sua frequência.

Os principais prováveis componentes de custos para os emissores envolvem o desenvolvimento de sistema que suporte as transações de HCE, sejam:

• Geração de dados dinâmicos (chaves criptográficas de sessão de uso limitado, por exemplo)

• Autenticação de dispositivos e de clientes• Atualizações das autorizações de

transações e da gestão de fraudes (se necessária)

• Atualizações da gestão de contas para atender às solicitações dos clientes e ao ciclo de vida do produto

• Desenvolvimento e suporte aos aplicativos de HCE, possivelmente com a integração com aplicativos existentes de telefonia móvel

• Gestão da vida útil de aplicativos de HCE implementados, para identificar, acompanhar dispositivos e instâncias de aplicativo (inclusive a vinculação a usuários, atualizações e revogação).

Em termos operacionais, esses componentes devem ser gerenciados pelo emissor (ou os terceirizados a ele subordinados). É necessário automatizar as funções de aprovisionamento de e para o dispositivo do cliente. Contudo, como visto anteriormente, a experiência do usuário é significativamente diferente do uso de um cartão padrão sem contato ou de um dispositivo de NFC com elemento seguro, de modo que seja provável a necessidade de assistência adicional ao cliente e de gestão de problemas (como atendimento ao cliente especializado).

Se o emissor optar por utilizar os serviços de tokenização de terceiros, é provável que tenha custos, mas pode reduzir a necessidade de investir antecipadamente em serviços criados pelo sistema bancário.

Este documento não pretende analisar o volume provável do investimento inicial, já que as capacidades e os sistemas atualmente existentes dos emissores terão um impacto significativo (caso os serviços sejam terceirizados, por exemplo).É óbvio que, antes que os emissores se envolvam em um projeto de modificações, será necessário que eles tenham avaliado em detalhe os custos.

3.4.2 Com hardware seguroConforme se observou no Capítulo 3, para reduzir a complexidade do gerenciamento de downloads de dados dinâmicos armazenados nos componentes inseguros de software de um aparelho, pode-se se utilizar, se disponível, o hardware seguro. Em geral, a redução da complexidade leva à diminuição dos custos. Mais importante, se um elemento seguro dos aplicativos de HCE estivesse disponível, ele poderia ser utilizado para melhorar a segurança da autenticação de dispositivos, aplicativos e clientes, reduzindo sua complexidade e potencialmente a necessidade de uma gestão adicional de fraudes de transação. A Figura 14 ilustra essa situação.

3.4 Modelo comercial

27


HCE COMBINADA COM UM ELEMENTO SEGURO

Figura 14

Essa abordagem, ocasionalmente denominada modelo híbrido, não foi completamente definida e, por isso, os emissores precisariam colaborar com os fornecedores e com as organizações parceiras para investigar sua viabilidade e avaliar se ela representaria uma economia efetiva de despesas. A vantagem pode ser uma melhora da experiência do cliente, já que provavelmente seria necessário efetuar o download dos dados dinâmicos com menor frequência. Uma outra vantagem poderia ser a percepção de aumento da segurança pelo usuário.

Terminal do comerciante

Adquirente

Aplicativo da HCE

EMISSOR


Rede de pagamentos


AprovisionamentoTransação

Elemento seguro


Gestão de contas


Proprietário do SE

Gestão de aplicativos e dispositivos

28


O ambiente de pagamentos com cartão é definido pela inter-relação dos esquemas de cartões com a EMVCo, proporcionando interoperabilidade técnica na aceitação de transações dos comerciantes. Essa abordagem teve muito êxito ao criar especificações estáveis e uma interoperabilidade global que cobre muitas centenas de milhões de cartões e dispositivos e terminais pagamento.

A evolução dos pagamentos contactless (assim como os seus parceiros) partiu dos pagamentos sem contato com cartões da EMV, passando pelos pagamentos móveis por NFC que usam elementos seguros e, até recentemente, incluindo pagamentos por NFC de HCE.A Figura 15 ilustra essa evolução temporal.

3.5 Maturidade

LINHAS TEMPORAIS ILUSTRATIVAS DA HCE

Figura 15

2006 2007 2008 2009 2010 2011 2012 2013 2014

2006 2007 2008 2009 2010 2011 2012 2013 2014

2006 2007 2008 2009 2010 2011 2012 2013 2014

2006 2007 2008 2009 2010 2011 2012 2013 2014

SE P

OR

NFC

HCE

PO

R N

FCPA

GA

MEN

TOS

SEM

CO

NTA

TO D

A EM

V

Publicação das especificações da Payez Mobile

Lançamento nos mercados líderes

Quatro milhões de aparelhos telefônicos lançados na França

Anúncio do lançamento nacional na China

Padronização das mensagens com TSM pela Global Platform

A GSMA publica diretrizes técnicas da NFC em comunicações móveis

Experimentos laboratoriais

Especificação do NFC Forum

Especificações iniciais de HCE do esquema de cartões

Disponibilização da bifurcação CyanogenMod

Google disponibiliza APIs

Primeira especificação sem contato da EMVCo

Implementações lançadas nos mercados mais importantes

Especificação estável sem contato versão 2.1 da EMVCo

Trânsito em circuito aberto

Estrutura de tokenização da EMVCo

Pagamentos sem contato de mercados de massa nos mercados líderes

29


Como mostra a Figura 10, para pagamentos feitos no varejo, é considerável a escala da evolução temporal, a partir de uma ideia e uma especificação inicial até a implementação de um produto voltado para o mercado de massas. Isso se deve ao fato de que os ambientes de pagamentos envolvem relações entre muitas partes, cujos interesses devem estar em harmonia. Os produtos tendem a ser implementados em mercados com alternativas já existentes, geralmente funcionando bem, que atuam no sentido de restringir a adesão dos consumidores.

Em comparação a outros produtos contactless, a evolução da HCE junto ao público acabou de começar. É inevitável que os produtos com HCE passarão por uma série de refinamentos com dados fornecidos por testes e pilotos. Por enquanto, é provável que os testes e pilotos se deem numa escala limitada, necessitando de concessões por parte dos esquemas de cartões.

A Figura 11 ilustra os estágios do ciclo típico de desenvolvimento e implementação de um produto.

CICLO TÍPICO DE DESENVOLVIMENTO DE PAGAMENTOS

Figura 16

Historicamente, nos pagamentos feitos no varejo, cada adaptação funcional significativa segue esse tipo de ciclo por um período de pelo menos dois a três anos. Caso sejam necessárias alterações dos terminais, o prazo pode ser maior. Os emissores devem estar cientes disso e, se a disponibilidade do mercado for o fator determinante, considere estabelecer um roteiro adequado com planos para lançar um produto alternativo e mais maduro no mercado.

Testes e pilotos

Produtos aprovados de diversos

revendedores

Implementação limitada com concessões

Segurança definida e modelo de apoio

Especificações estáveis

Especificações iniciais

Implementações conforme as regras

padrão

30


A HCE oferece a promessa de um mecanismo adicional para que os bancos deem apoio aos seus clientes. Ela:

• Simplifica o ecossistema de aprovisionamento de aplicativos, aumentando, em contrapartida, a gestão de riscos de transações de pagamentos,

• Elimina custos e complexidade da gestão de aplicativos usando um elemento seguro apoiado por terceiros, mas

• Aumenta a complexidade dos sistemas emissores, já que estes devem fornecer dados dinâmicos para cada transação.

Os dados dinâmicos (chaves criptográficas específicas a cada transação, por exemplo) são necessários para lidar com as vulnerabilidades expostas pela ausência de uma plataforma segura de hardware no aparelho telefônico do cliente. Nas soluções envolvendo elementos seguros, é gerada uma chave criptográfica por conta, ao longo da vida útil do produto. Este procedimento deverá mudar para que seja possível gerar dezenas de chaves por mês para cada aplicativo de pagamento de HCE. É necessária uma concepção cautelosa dos processos (como a pré-geração em lotes, por exemplo) e a gestão de recursos, para garantir que o bom desempenho do sistema e a experiência do usuário não sejam

afetados adversamente, e que os custos incrementais não sejam proibitivos.

A utilização de um PAN para HCE estático e dedicado ou de PANs dinâmicos para cada transação, contribuirá para limitar a contaminação cruzada de opções no comércio eletrônico. Os emissores podem optar por efetuar a gestão de PAN ou por utilizar um dos serviços comerciais de tokenização que estão sendo lançados no mercado.

Como o usuário deve efetuar o download (por opção ou imposição) dos dados dinâmicos para utilizá-los em transações antes da ocorrência do pagamento, a segurança da HCE depende da autenticação do cliente para este download. Um hacker não teria que romper a segurança do aplicativo caso ele seja capaz de utilizar credenciais legítimas para efetuar o download dos dados do pagamento. É importante que se enfatize bem a garantia da autenticação do cliente ao longo de toda a vida útil dos produtos, inclusive a integração da autenticação dos dispositivos, talvez com vínculos com a gestão de fraudes de transações. Para lidar com isso, os emissores deveriam considerar utilizar outros tipos de segurança em hardware nas credenciais de autenticação de longa durabilidade.

4 CONCLUSÃO

A atratividade dos pagamentos móveis por NFC aumenta de acordo com os níveis crescentes de penetração e estabilidade da infraestrutura de aceitação de contactless. Enquanto há apenas dois anos a aceitação de pagamentos contactless em lojas não tinha sido comprovada, atualmente a penetração e o uso de cartões e terminais contactless estão expandindo em muitos mercados internacionais. Os pagamentos contactless são cada vez mais processados em dispositivos móveis, com o lançamento de aplicativos de pagamento por NFC com elementos seguros (nos mercados nos quais as condições locais forem propícias) e, agora, com a entrada da Apple nos pagamentos móveis por NFC, a tendência é que cresçam ainda mais.

31


Os custos adicionais exigidos pelos novos processos do emissor demandam consideração cuidadosa. Durante uma análise de custos, sugerimos que os emissores colaborem com os seus parceiros no sentido de explorar potenciais vantagens advindas da integração de um elemento seguro com os processos da camada de acesso aos dados da HCE. Isso resultará em como a abordagem híbrida poderia controlar as despesas e a complexidade de uma solução implementada em larga escala. O elemento seguro oferece uma opção para o armazenamento local de dados dinâmicos, melhorando a usabilidade, já que se pode confiar nos dados, dispensando downloads frequentes, e podendo contribuir para garantir a autenticação de dispositivos e clientes quando for necessário efetuar um download do emissor, para lidar com essa vulnerabilidade do processo.

A HCE está no início do seu ciclo de negócio. As especificações iniciais do esquema estão sendo publicadas ou em desenvolvimento. Se presumirmos que a HCE seguirá a trajetória de outras tecnologias de pagamento de cartões, em aproximadamente um ano as especificações e o produto estabilizarão.

As descobertas do guia inicial sobre a HCE, preparado pela Consult Hyperion, continuam válidas:

• Comece avaliando as condições do mercado local e o perfil de transações que se almeja.

• Mantenha a flexibilidade de sua estratégia, já que é provável que o hardware seguro continue a ser uma parte significativa da solução mais adequada e

• Trabalhe em conjunto com os seus parceiros do setor, para garantir que os clientes e os comerciantes se engajem na promessa de facilidade de uso proporcionada pela HCE.

Sede da GSMALevel 2, 25 WalbrookLondon, EC4N 8AF,Reino UnidoTelefone: +44 (0)207 356 0600

www.gsma.com

©GSMA 2014

Documents

A HCE e o uso de tokens em serviços de pagamento Documento ... · de software, fornecedores de equipamentos, empresas provedoras de serviços de Internet e organizações nos setores