Tradicionalmente, en transacciones presenciales en las que se requiere la tarjeta física (denominadas “card present” o “brick-and-mortar”), la autorización de la misma se realiza empleando cualquiera de los siguientes métodos de verificación del titular de tarjeta (“cardholder verification methods” – CVM):

Esta validación se realiza posterior a la captura de los datos de la tarjeta en un punto de interacción (“point of interaction” – POI) mediante lectura de banda magnética, chip EMV o contactless

En el caso del PIN, la captura de este dato se requiere efectuar en un dispositivo de hardware exclusivo para esta tarea, que recibe diferentes nombres dependiendo si la captura se realiza en una terminal POI desatendida o atendida:

  • Encrypting PIN pad (EPP): Dispositivo de seguridad con controles físicos y lógicos para el ingreso seguro del dato del PIN y la encriptación del mismo, típicamente instalado como parte de una solución desatendida (“Unnatended Payment Terminal” – UPT) como un cajero automático, un quiosco desatendido o un dispensador automático de combustible, que puede incluir una pantalla y/o un lector de tarjetas o usarlos como componentes externos.

Figura 1. Encrypting PIN Pad (EPP)

  • Point-of-sale PIN entry device (POS PED): Un PED es un dispositivo para la entrada y procesamiento seguro de PIN en terminales atendidas de punto de venta (TPV). El POS PED normalmente consta de un teclado para la entrada del PIN, una pantalla para la interacción del usuario, un procesador y almacenamiento para el procesamiento de PIN lo suficientemente seguro para el esquema de gestión de claves y el firmware utilizado. En algunas ocasiones, el PIN puede ser capturado a través de una pantalla táctil (“PIN on Glass”).  Un PED tiene unos límites físicos y lógicos claramente definidos y una estructura física resistente a manipulaciones y por lo general suele venir integrado en una estructura que incluye los mecanismos de lectura de la tarjeta.

Figura 2. PIN Entry Devices: (1) PED externo, (2) PED conectado a un lector de tarjetas, y (3) PED integrado con el lector de tarjetas (datáfono)

Para validar la seguridad de estos dispositivos, el PCI SSC ha establecido una serie de controles en el estándar Payment Card Industry (PCI) PIN Transaction Security (PTS) Point of Interaction (POI). Aquellos dispositivos de hardware certificados en este estándar por laboratorios independientes se enumeran en la lista de dispositivos aprobados PTS para poder ser usados en entornos PCI DSS y obligatoriamente en entornos P2PE.

Como se puede concluir, la introducción del PIN actualmente se debe realizar en dispositivos de hardware certificados, que permitan garantizar su seguridad tanto física como lógicamente.

¿Se puede capturar el PIN por software?

Las terminales de pago siempre van a requerir de hardware y software (aparte del hardware de captura de PIN y lectura de tarjeta) que les permita desarrollar las tareas vinculadas a la venta, la impresión de recibos y la conectividad a la red de datos, entre otras.  Hoy en día, esas funcionalidades ya pueden ser provistas por un teléfono móvil inteligente (“smartphone”) o por una tableta, por lo cual diversos fabricantes han desarrollado dispositivos de hardware para la captura de los datos de la tarjeta de pago (denominados “Non-PIN acceptance POI devices”, que también tienen que cumplir con PCI PTS) que pueden ser integrados a través de los puertos de audio o USB con los teléfonos móviles. Este es el caso de Square, Intuit, iZettle y PayPal Here, por solo nombrar algunos.

Figura 3. Lectores de tarjetas con conexión a teléfonos móviles a través del puerto de audio: (1) Intuit, (2) Square, (3) iZettle (adquirida por Paypal) y (4) PayPal Here

El gran problema de estas soluciones es que las transacciones requieren ser autenticadas con la firma manuscrita (mecanismo de seguridad ya declarado obsoleto) o con un PED externo adicional que se puede conectar vía wireless.

Figura 4. PED externos con conexión a teléfono móvil: (1) iZettle, (2) PayPal Here

Figura 5. Dispositivo de lectura de tarjetas de Square conectado a una tableta con autenticación de transacción a través de firma manuscrita.

Debido a estas restricciones operativas, el PCI SSC ha optado por permitir la captura del PIN a través de software, facilitando el proceso de integración y despliegue de soluciones como las anteriormente nombradas y alineándose con los desarrollos tecnológicos actuales.

Por ello, el 24 de enero del 2018 se publicó el estándar “PCI Software-based PIN Entry on COTS (SPoC)“. Este nuevo estándar define los controles de seguridad en el desarrollo y la implementación de soluciones de pago que permitirán la captura del PIN en dispositivos comerciales estándares (“Commercial off-the-shelf devices” – COTS), tales como teléfonos móviles y tabletas, en transacciones en línea (“online”) realizadas exclusivamente con EMV y contactless (no se admitirán transacciones con banda magnética). Las transacciones fuera de línea (“offline”) o procesadas en lote (“batch”) no son soportadas por sistemas SPoC.

¿Cuál es la arquitectura de una solución SPoC?

Mientras que en una solución tradicional de captura de PIN por hardware (usando EPP/PED) la protección del PIN radica exclusivamente en el hardware y el firmware, en un modelo SPoc se incluyen varios bloques adicionales:

Figura 6. Arquitectura de una solución SPoC

  1. Un dispositivo “Secure Card Reader – PIN” (SCRP): Se trata de un periférico con soporte para lectura segura e intercambio de datos (“Secure reading and exchange of data” – SRED) conectado al dispositivo COTS que se encarga de la lectura de los datos del plástico y operaciones de desencriptación/re-encriptación del PIN. En el estándar PCI PTS POI v5.1 (de próxima publicación) se incluirán estas categorías de dispositivos.
  2. Una aplicación PIN CMV: Una aplicación de seguridad que se instala en el dispositivo COTS que provee una interfaz segura para el usuario para la captura del PIN, realiza una encriptación inicial del PIN capturado, verifica la seguridad de los demás componentes del sistema garantizando su propia integridad y envía el PIN encriptado al SCRP para ser desencriptado/re-encriptado para ser enviado al backoffice.
  3. Un dispositivo comercial estándar (COTS) en el que se instala la aplicación PIN CVM y se conectará el SCRP. De forma opcional, el COTS puede contener componentes Trusted Execution Environment (TEE).
  4. Un conjunto de sistemas de back-end que ejecutan tres tareas principales:
    • Validación de controles de la aplicación PIN CVM y reforzamiento de políticas de seguridad (“attestation”),
    • Monitorización de controles de seguridad para detectar, alertar y mitigar amenazas sospechadas o reales contra el SCRP, la aplicación PIN CVM y el dispositivo COTS (“monitoring”), y
    • Recepción de los datos de tarjeta encriptados y los datos del PIN desde el SCRP (“processing”).

Bajo este modelo, el flujo operacional es el siguiente:

Figura 7. Flujo operativo de una solución SPoC

  1. La aplicación PIN CVM y el dispositivo SCRP son inicializados con sus claves de encriptación financieras.
  2. Se establece un canal de comunicación seguro entre la aplicación PIN CVM y los sistemas de monitorización de back-end.
  3. El subsistema de monitorización del back-end determina el estatus de seguridad de la plataforma móvil (SCRP, COTS y la aplicación PIN CVM) usando el subsistema de verificación.
  4. La tarjeta EMV con contacto o sin contacto (“contactless”) o un dispositivo móvil de pago EMV NFC es presentado al SCRP.
  5. La aplicación PIN CVM genera y presenta la pantalla de captura de PIN en el dispositivo COTS. El usuario digita su PIN, que es encriptado y enviado al componente SCRP por la aplicación PIN CVM.
  6. El componente SRED del SCRP encripta a su vez los datos de la tarjeta leídos usando un conjunto de claves de encriptación precargadas.
  7. La transacción de pago es procesada.

¿Qué controles de seguridad debe implementar una solución SPoC?

Debido a que el principal riesgo al que se enfrenta este tipo de solución es el de la captura no autorizada de los datos del PIN (ya que se parte de la premisa que el sistema operativo del dispositivo COTS es inseguro), es necesario establecer una serie de controles en cada uno de los bloques operativos para identificar, detectar, alertar, contener y bloquear cualquier posible incidente. Por ello, estos controles de seguridad se han organizados como “módulos” en el estándar, como se describe a continuación:

  1. Requisitos básicos (“Core requirements”): Conjunto de requerimientos generales que definen los controles de seguridad aplicables a toda la solución. El proveedor del servicio es el responsable de que estos controles estén implementados de forma correcta.
  2. Requisitos para la aplicación CVM (“PIN Cardholder Verification Method Application”): Conjunto de controles de seguridad que deben ser implementados en la aplicación que será instalada en el dispositivo COT y que realizará las tareas de presentación del formulario de captura del PIN, enmascaramiento de los dígitos ingresados, encriptación de los datos recibidos y recolección y envío de los datos de verificación de seguridad de los componentes.
  3. Requisitos para los sistemas de back-end de monitorización y verificación (“Back-end Systems – Monitoring/Attestation”): Controles para los sistemas de back-end que interactúan con la aplicación PIN CVM y el dispositivo COTS y que facilitan la detección de actividades anómalas y potencialmente fraudulentas, incluyendo transacciones sospechosas.
  4. Requerimientos de integración de la solución (“Solution Integration Requirements”): Requisitos para la supervisión, el gobierno y la responsabilidad general de la solución, que son necesarios para garantizar que todos los controles de seguridad están en su lugar y funcionan según lo previsto.
    El Proveedor de soluciones es responsable de garantizar que estos requisitos se implementen.
  5. Requisitos para los sistemas de procesamiento de back-end (“Back-end Systems – Processing”): Controles de seguridad para los procesos y entornos vinculados con la gestión del pago.

¿Quién evaluará y certificará una solución SPoC?

La evaluación y certificación de soluciones SPoC las realizarán exclusivamente los laboratorios reconocidos y homologados por el PCI SSC. De igual forma, las soluciones ya certificadas aparecerán listadas en la página del PCI SSC dentro de la categoría “Software-based PIN Entry on COTS (SPoC) Solutions“.

¿Una solución SPoC puede ser incluida dentro de un entorno P2PE (Point-to-Point Encryption)?

En principio, no. Tal y como se indica en la FAQ #1457 “Is a Software-based PIN Entry on COTS Solution eligible for a P2PE Solution approval?“, son estándares diferentes y aplican a casos de uso únicos.

¿Qué viene a continuación?

Debido a que el estándar ha sido publicado recientemente, se espera que en los próximos meses se empiecen a certificar e implementar las primeras soluciones SPoC. Estas soluciones podrán convivir de forma paralela con las soluciones tradicionales basadas en hardware sin que exista problema.

Por otro lado, en el corto plazo el PCI SSC empezará a definir los controles de seguridad necesarios para la aceptación de pagos “contactless” a través de las interfaces NFC nativas de los dispositivos COTS. Más información en el artículo “Contactless Payments: PCI SSC on Plans to Develop Security Standard for Payment Acceptance on Merchant COTS Devices” del blog del PCI SSC.

¿Cómo se integra una solución SPoC en el cumplimiento PCI DSS de los comercios?

A diferencia de los entornos que usan datáfonos PCI PTS conectados vía RPTC o IP que requieren la presentación de un SAQ B o un SAQ B-IP respectivamente, o en las soluciones P2PE que cuentan con su propio cuestionario (SAQ P2PE), al día de hoy el PCI SSC no se ha pronunciado respecto a los controles de PCI DSS que estarán vinculados a un entorno que use tecnologías SPoC. Debido a ello, aún no se puede evaluar el beneficio que traerá a un comercio el uso de SPoC en términos de minimización de entorno de cumplimiento.

Para información adicional, se pueden consultar los siguientes artículos del blog del PCI SSC: