Cumplimiento de PCI: requisitos de seguridad de tarjetas de pago PTS POI – noviembre de 2020

By | noviembre 9, 2021

Preguntas frecuentes técnicas sobre PCI SSC para su uso con la versión 6

Pagos desatendidos UCP

UCP Unattended Payments es un experto en cumplimiento de PCI

Se ha publicado una nueva actualización de noviembre de las Preguntas frecuentes técnicas de PCI SSC. Se enumera a continuación. También hemos enumerado algunas otras preguntas interesantes.

Para obtener una copia completa de este documento, es proporcionado por el PCI Security Standards Council

Noviembre de 2020: los dispositivos de PDI deben admitir una o más de las cuatro técnicas especificadas para la carga de claves privadas o secretas. Los métodos ayb son para la carga de claves de texto plano y los métodos cyd son para la carga de claves cifradas. El requisito especifica que los EPP y los PED OEM destinados a su uso en un entorno desatendido solo admitirán los métodos a, c y d. Además, especifica que los SCRP solo admitirán la carga de material de codificación cifrado. ¿Existen otras restricciones?

Sí. Para todas las evaluaciones nuevas (es decir, evaluaciones que resulten en una nueva aprobación) de dispositivos POI v5, los dispositivos POI deben admitir al menos uno de los métodos de carga de claves cifradas para la carga de claves privadas o secretas.

El requisito A9 estipula que el dispositivo debe proporcionar un medio para disuadir la observación visual de los valores del PIN cuando el titular de la tarjeta los ingresa. ¿Qué métodos son aceptables?

R Los requisitos de seguridad de POI proporcionan varias opciones que pueden usarse por separado o en combinación para brindar privacidad durante la entrada del PIN. Estas opciones son: ▪ Una barrera de protección física (privacidad). Tenga en cuenta que en caso de que el escudo de privacidad sea desmontable, una guía del usuario debe acompañar al dispositivo que indique que el escudo de privacidad debe usarse para cumplir con la norma ISO 9564. Opcionalmente, la guía del usuario también puede hacer referencia a los requisitos del dispositivo PCI; ▪ Diseñado para que el titular de la tarjeta pueda protegerlo con su cuerpo para protegerse contra la observación del PIN durante la entrada del PIN, por ejemplo, un dispositivo de mano; ▪ Ángulo de visión limitado (por ejemplo, un filtro polarizador o un teclado PIN empotrado); ▪ Vivienda que forma parte del cajero automático o quiosco, la mano o el cuerpo del titular de la tarjeta (solo se aplica a los dispositivos portátiles); y ▪ el entorno del dispositivo instalado.

Mayo (actualización) 2018: los dispositivos de ingreso de PIN pueden integrar físicamente en el mismo dispositivo otras funciones, como teléfonos móviles, capacidades de PDA o terminales POS. Las configuraciones portátiles de los dispositivos de entrada de PIN pueden acomodar la conexión (por ejemplo, a través de un trineo, funda o conector de audio) de un teléfono móvil, PDA o terminal POS, donde el dispositivo adjunto se comunica con el PED. Esta configuración aparece como un solo dispositivo, con interfaces separadas para que ingresen el empleado y el titular de la tarjeta. ¿Qué consideraciones deben tenerse en cuenta para cualquiera de estas configuraciones?

A Para cualquier dispositivo donde se espera que el titular de la tarjeta use la misma interfaz para ingresar el PIN que el empleado usaría para propósitos de teléfono, PDA, aplicaciones de pago, etc., o donde haya múltiples interfaces en un solo dispositivo integrado, el dispositivo integrado debe estar física y lógicamente reforzado de acuerdo con los requisitos de seguridad de PTS POI. En una configuración de dispositivo portátil con un dispositivo adjunto, existe el riesgo de que el titular de la tarjeta ingrese el PIN en la interfaz incorrecta. Además, la interfaz de comunicación entre el PED y el dispositivo adjunto puede dar a este último acceso a las funciones de MSR sin controles criptográficos, lo que permite la extracción de datos de la cuenta de la tarjeta. En este modelo de integración, entonces: ▪ Ambos dispositivos se evalúan y validan para que cumplan con los requisitos de PTS POI, o Preguntas frecuentes sobre la evaluación de PCI PTS POI – Técnico – Para uso con la versión 6 de noviembre de 2020 Copyright © 2013-2020 PCI Security Standards Council, LLC . Todos los derechos reservados Page 8 ▪ El dispositivo PED, que también debe controlar el (los) lector (es) de tarjetas, debe implementarse y ser validado contra el módulo PTS POI SRED. El PED debe hacer cumplir las funciones SRED para el cifrado de los datos de la tarjeta en todo momento. El PED solo se permite en un estado, y es para cifrar todos los datos de la cuenta. No se puede configurar para ingresar a un estado en el que los datos de la cuenta no estén encriptados.

Mayo (actualización) 2018: Se requieren dispositivos de ingreso de PIN que se conectan a un teléfono móvil, PDA o terminal POS a través de un trineo, funda, conector de audio o conexión inalámbrica para admitir SRED. ¿Esto se aplica a los PED que están integrados con otros dispositivos (como una tableta o un teléfono móvil) que aparecen como un solo dispositivo?

Sí. Un dispositivo integrado es aquel en el que dos dispositivos física y electrónicamente distintos (por ejemplo, un PED y un dispositivo comercial listo para usar (COTS) como un teléfono móvil) aparecen como un solo dispositivo mediante el uso de plásticos para enmascarar la conectividad. En tal configuración, existe el riesgo de que el titular de la tarjeta ingrese el PIN en la interfaz incorrecta. Además, la interfaz de comunicación entre el PED y el dispositivo integrado puede dar a este último acceso a las funciones del lector de tarjetas sin controles criptográficos, lo que permite el desnatado de los datos de la cuenta de la tarjeta. En este modelo de integración, entonces: ▪ Tanto el PED como el no PED se evalúan y validan para que cumplan con los requisitos de PTS POI, o ▪ El PED, que también debe controlar los lectores de tarjetas, debe implementarse y validarse contra el módulo PTS POI SRED y ser física y electrónicamente distinto del sistema no PED (por ejemplo, no es aceptable que el firmware PED se ejecute dentro del mismo procesador que el firmware no PED). El PED debe hacer cumplir las funciones SRED para el cifrado de los datos de la tarjeta en todo momento. El PED solo se permite en un estado, y es para cifrar todos los datos de la cuenta. No se puede configurar para ingresar a un estado en el que los datos de la cuenta no estén encriptados. La Política de seguridad también debe indicar que el no PED no ha sido evaluado bajo el programa PCI PTS y se requiere una guía de seguridad para garantizar el funcionamiento seguro de la solución. Se agregará una nota adicional al portal señalando que el no PED no ha sido evaluado bajo el programa PTS.

Octubre de 2018: ¿Existen requisitos mínimos para que la versión de Android se utilice en un dispositivo PTS?

R Sí, se espera que la versión de Android sea oficialmente compatible con parches de seguridad, como mínimo. Se rechazarán todos los informes, incluidos los deltas, en los que la versión de Android no sea compatible con los parches de seguridad habituales. Cuando Google no proporcione estos parches, la evidencia de los parches de seguridad (implementados al menos una vez al mes) proporcionada por el proveedor debe documentarse en el informe proporcionado por PCI; Se espera que la evidencia de esto sea la validación del código de actualización por parte del laboratorio para al menos dos parches anteriores, así como la validación por parte del laboratorio de que estos parches han solucionado las vulnerabilidades conocidas existentes en la versión de Android utilizada. Los proveedores deben tener en cuenta que esto significa que se debe tener en cuenta el estado del parche futuro de cualquier versión de Android utilizada durante las etapas iniciales de diseño del dispositivo, para evitar el rechazo inesperado de dispositivos después de que una versión de Android deja de ser compatible durante el desarrollo de una solución.

 

¿Qué vulnerabilidades se deben tener en cuenta para una pantalla táctil?

R Si los lados son accesibles, un ataque de superposición utilizando una segunda pantalla táctil clara podría ser un problema. La conexión / ruta desde la pantalla táctil al procesador (y cualquier dispositivo utilizado para decodificar las señales intermedias) debe verificarse para que sea segura. Los biseles alrededor de la pantalla táctil son especialmente peligrosos porque pueden ocultar el acceso a las áreas de interés descritas anteriormente. La API para firmware y aplicaciones (si corresponde) debe examinarse detenidamente para determinar las condiciones bajo las cuales se permite la entrada de datos de texto sin formato. Ejemplo: No debería ser posible, a menos que el adquirente muestre dispositivos controlados por indicaciones, que un tercero muestre una imagen (JPEG) que diga “presione enter cuando esté listo para ingresar el PIN” y luego haga que aparezca un teclado de texto sin formato en el siguiente pantalla. La precaución adicional está garantizada para los dispositivos con pantalla táctil debido al deseo de hacer que los dispositivos con pantalla táctil sean fáciles de usar y de ejecutar muchas aplicaciones diferentes, no autenticadas y no controladas. Esto es especialmente cierto para los dispositivos que están destinados a ser retenidos debido a la tendencia a considerarlos como una PDA que puede realizar transacciones de débito.

Febrero (actualización) de 2014: ¿El uso de superposiciones de teclado de protección afecta el estado de aprobación de un dispositivo?

Sí. En general, las superposiciones no son compatibles con el programa de aprobación del dispositivo debido a la posibilidad de que se toque el teclado o se oculte la evidencia de manipulación. Se pueden usar superposiciones cuando no cubran ninguna parte del área de entrada del PIN. Por ejemplo, en un dispositivo de pantalla táctil donde la pantalla táctil se usa tanto para la captura de firmas como para la entrada de PIN, se puede usar una superposición para proteger el área de la firma del desgaste excesivo. En este ejemplo, solo se puede proteger el área utilizada para la captura de firmas. El material utilizado debe ser transparente, y no meramente translúcido, para no obstruir el área de entrada de la llave cuando se ve desde cualquier ángulo.

Algunos dispositivos se envían con firmware que puede convertirse en una versión compatible, pero no cumple con el envío. ¿Cuándo es esto aceptable?

R Esto solo es aceptable cuando la conversión es unidireccional y no se puede revertir. Un dispositivo solo se puede convertir a una versión compatible. No podrá convertir una versión conforme en una versión no conforme. La conversión debe realizarse en la carga inicial de claves de las claves secretas de la entidad adquirente. La transformación debe resultar en la puesta a cero de cualquier clave secreta de entidad adquirente existente previamente. La versión compatible del firmware debe distinguirse claramente de la versión no compatible. No es aceptable simplemente agregar un sufijo (uno o más caracteres) a una versión de firmware existente. Más bien, la conversión debe dar como resultado un número de versión de alto orden que sea claramente distinguible para los compradores de dichos dispositivos. Solo se aprobará y enumerará la versión compatible.

Enero de 2015: hay una serie de preguntas frecuentes sobre el uso de tecnologías inalámbricas, como Bluetooth y Wi-Fi. ¿Cuál es la intención de estas preguntas frecuentes? ¿Tiene PCI algún requisito específico para otros tipos de tecnologías de comunicaciones?

R La intención de las preguntas frecuentes sobre todas las comunicaciones inalámbricas para dispositivos POI es garantizar que las interfaces del POI estén protegidas de manera que: ▪ Los datos de la tarjeta no se puedan interceptar fácilmente. ▪ Las interfaces de comando al terminal no se pueden acceder fácilmente, no se pueden interceptar para ataques (como MITM) ni se pueden usar como un vector de ataque en el dispositivo. ▪ El compromiso de la interfaz no conduce, respalda ni facilita un mayor compromiso de los activos de seguridad del PDI. PCI no exige ni requiere el uso de ninguna tecnología de comunicación específica, pero cualquier implementación debe cumplir con los requisitos anteriores a través de algún aspecto de las capas físicas o lógicas de comunicación. La comunicación por cable física o directa a menudo logra esto a través de la naturaleza de su interfaz física. Las comunicaciones inalámbricas no pueden depender de esto y, por lo tanto, deben depender de la seguridad en el enlace o las capas de aplicación mediante el uso de un protocolo de seguridad para establecer una ruta confiable para todas las comunicaciones a través del enlace inalámbrico. Este protocolo de seguridad debe haber sido probado y aprobado bajo el módulo de protocolos abiertos de la evaluación PCI PTS de ese dispositivo, y los ejemplos de implementaciones aceptables del protocolo de seguridad incluyen WPA2 (implementado en la capa de enlace) o túneles encriptados VPN (implementados en la aplicación). capa)

Diciembre (actualización) 2016: ¿Se puede utilizar un dispositivo PTS como transmisor de baliza (iBeacon o baliza BLE)?

Se permiten balizas para cualquier versión de BLE (por ejemplo, 4.0, 4.1) siempre que existan las siguientes condiciones y estén validadas por un laboratorio aprobado por PTS: ▪ La baliza se incluye como una interfaz de dispositivo en el informe de puntos de interés de PTS. ▪ El aprovisionamiento por aire (OTA) no está permitido en ningún momento. El aprovisionamiento y la actualización de balizas deben ser coherentes con los estándares PTS existentes. (es decir, Sección J, B4 o B4.1) ▪ Debe estar referenciado en la política de seguridad. ▪ Las balizas son solo de transmisión. El laboratorio debe validar que la comunicación BLE no se puede utilizar para responder a solicitudes externas, conectarse, emparejarse o proporcionar comunicación bidireccional a cualquier otro dispositivo. ▪ El proveedor proporciona documentación sobre el uso seguro y el aprovisionamiento de la baliza y que la documentación establece claramente que la baliza se usa solo para transmisión y que el aprovisionamiento de OTA no está permitido. ▪ El proveedor documentará el propósito de uso de la funcionalidad de la baliza, es decir, su uso previsto. La documentación debe incluir qué datos se transmiten y garantizar que no se puedan transmitir datos sensibles. ▪ El dispositivo PTS nunca puede recibir transmisiones de balizas.

Enlaces adicionales

Vínculos relevantes para miembros de cumplimiento de PCI