Seguridad por CHIP y PIN - Parte 2

Parte 2

La segunda vulnerabilidad implica la comprensión de la arquitectura chip y PIN. Además de la verificación del titular de la tarjeta donde el chip verifica el PIN del cliente, la información de la cuenta ( de igual manera que puede estar en una tarjeta magnética ) se encuentra protegida por una firma digital, la cual puede ser verificada por el terminal. Recordemos que verificar una firma digital solo requiere una llave pública auténtica. La segunda característica de seguridad es una firma digital que proteja los datos de la transacción para comprobar que provienen desde una tarjeta genuina.

Según la especificación para chip y PIN (EMV) tenemos dos opciones para hacer esto:

• Autenticación por datos estáticos (SDA)
• Autenticación por datos dinámicos (DDA)

En el caso del esquema SDA tenemos un valor de verificación criptográfico (CCV el cual no es en realidad una firma digital pero provee los elementos necesarios de autenticación e integridad necesarios) creado utilizando una llave secreta guardada en la tarjeta. El algoritmo criptográfico es simétrico lo que significa que la misma llave secreta se utiliza para verificar este CCV.

Es muy difícil administrar llaves secretas en terminales de gran población entonces el CCV puede ser verificado solamente por el emisor de la tarjeta quien conoce la llave secreta para cada tarjeta en su población. Si se permite que la transacción se realice off-line, entonces el terminal no puede asegurar que la tarjeta es genuina. Por supuesto que en el modo on-line el emisor verifica el CCV.

Para el esquema DDA la tarjeta con chip y PIN tiene la capacidad de crear una firma digital para la transacción como para que la información de la cuenta pueda ser verificada en el terminal por la llave pública apropiada. En este caso no es necesario para el terminal estar en modo on-line para verificar la autenticidad de la tarjeta.

Entonces, Qué puede hacer realmente el Hacker? ( vamos a ignorar en esta conversación al especialista de laboratorio en ingeniería inversa ). Bueno la especificación EMV se encuentra libremente disponible en Internet. Cualquier programador puede construir una tarjeta EMV o comprar una en el mercado abierto. Si capturamos la información de la cuenta de una tarjeta genuina, recordemos que necesitamos acceso a la tarjeta para realizar esto, entonces podemos producir una tarjeta SDA que para un terminal off-line sería correcta porque no puede verificar previamente el CCV al que se refiere.

El PIN es irrelevante, debido a que Ud. puede haber elegido uno y configurarlo en la tarjeta falsificada. El ancla de seguridad es la clave secreta la cual creo el CCV y que no esta disponible para el Hacker. Si la tarjeta falsificada es utilizada en un terminal on-line, será detectada inmediatamente debido al falso CCV generado con una clave aleatoria elegida por el Hacker. Con esto esta claro que el Hacker tendrá el mismo problema para generar una tarjeta DDA, él no puede saber cual es la clave secreta utilizada para generar la firma digital, entonces en este caso sería descubierto inmediatamente en un terminal off-line.

Así que ahora todo el problema se reduce a la gestión de riesgos. En el caso de la tarjeta de banda magnética falsificada existe un problema real, ya que el banco emisor, no tiene medios para determinar si la tarjeta utilizada es genuina. En este caso la cuenta del cliente se encuentra realmente en riesgo. Es por esto que tenemos el esquema chip y PIN. Para DDA y SDA en modo on-line la transacción puede ser rechazada por el terminal. El riesgo para el banco emisor se encuentra sujeto a las condiciones en las cuales permiten una transacción off-line de una tarjeta SDA. Pero esto solamente es una pequeña porción de la historia. El costo de las tarjetas DDA se esta acercando rapidamente al costo original de las tarjetas SDA, las comunicaciones on-line se encuentran cada vez más fácilmente disponibles, y en el modelo general de riesgo, el emisor necesita saber si existen los fondos disponibles o que el cliente si paga en un escenario vencido, que en realidad va a cumplir sus compromisos y, además, se tiene todos los otros controles en una tarjeta EMV que le ayudarán a minimizar el riesgo. Más importante es que cuando se implementan y operan de forma correcta, el riesgo real para el consumidor se encuentra en el uso de tarjetas magnéticas y terminales, no en el uso de chip y PIN.

{FIN}

Esta obra está bajo una licencia de Creative Common

Seguridad por CHIP y PIN - Parte 1

Parte 1

       Diferentes comentadores de los medios han atacado la seguridad por medio del esquema "CHIP y PIN" tergiversando los hechos de manera importante. Por supuesto siempre es más sencillo atacar un sistema que defenderlo y los puristas pueden fácilmente perder de vista una solución óptima, la seguridad perfecta no es económicamente viable, aunque prácticamente sea realizable. El objetivo del esquema para los operadores debe ser lograr una solución que sea "apropiada para los fines".

En mayo del 2006 la prensa estaba llena de Fraudes efectuados por skimming de la tarjeta en las estaciones de servicio Shell del Reino Unido, al parecer sólo en tres sitios, pero resultando en una pérdida en las cuentas de los usuarios en más de £1 millón de libras. En consecuencia Shell ha dejado de utilizar el PIN en sus propias gasolineras.

En junio ha habido más noticias, sobre todo en el Daily Mail (lunes 5 de junio); que el chip y PIN del Sistema de tarjetas bancarias posee graves deficiencias, consecuentemente millones de clientes están peligrosamente expuestos a los delincuentes.

Las críticas están fundamentadas sobre dos vulnerabilidades:

1) Que puede construirse una falsificación de tarjetas de banda magnética utilizando información obtenida de una tarjeta chip auténtica en una terminal peligrosa y que el hacker obtenga de ese mismo terminal el PIN.

2) Que puede construirse una falsificación de tarjetas con chip y PIN, utilizando información obtenida de una tarjeta verdadera en una terminal en peligro.

El valor de la falsificación de tarjetas de banda magnética, se debe a que todavía hay un número de terminales de banda magnética en Asia y América. El problema aquí no tiene nada que ver con el sistema de chip y PIN, es puramente una cuestión de aplicación y funcionamiento. Suponiendo que se siguen las especificaciones, no hay suficiente información en el chip para la construcción de los datos de la banda magnética, en particular, usted necesita el CVV, que no deben ser almacenados en el chip. Esto significa que el hacker ha de leer también la banda magnética de la tarjeta. Se trata de una vulnerabilidad en la seguridad ya que algunos terminales se han implementado tanto para leer el chip y la banda magnética (de la misma tarjeta). Evidentemente es una violación de seguridad, si el mecanismo de resistencia contra alteraciones del terminal es fácilmente roto. Es evidente que este ataque no tiene ningún valor en un mundo donde el esquema total sea chip y PIN.

.....continuará


Esta obra está bajo una licencia de Creative Commons

Introducción a la programación de tarjetas Java (JavaCard)

    La posibilidad de programación en Java de las tarjetas  trajo una nueva era en el desarrollo de aplicaciones para tarjetas inteligentes. La tarjeta soporta correr una JVM (Maquina virtual Java). Los Programas escritos en Java pueden ser almacenados y ejecutados directamente en la tarjeta. La programación en Java para Tarjetas se basa en la especificación Java Card 2.0 (http://java.sun.com/products/javacard) la cual es mantenida por Sun. A continuación presentamos las características principales de la JVM en Java card:

•  Es una versión restringida de la Java Virtual Machine que soporta un sub-juego del lenguaje Java que puede aplicarse en applets para Java Card.

•  Para el soporte de aplicaciones antiguas se provee una API dedicada al desarrollo de applets para smart card basados en los estándares de bajo nivel ISO 7816.

•  Un entorno de ejecución abstracto que soporta funciones de administración de applets como el mecanismo de selección del applet a ejecutar. Este entorno se denomina JCRE (Java card Runtime Environment ó Entorno de Ejecución para Tarjetas Java).

Debido a limitaciones técnicas del procesador contenido en la tarjeta y algunas características como multiprocesamiento que son claramente no necesarias para las Tarjetas Java, solo se soporta un sub-juego del lenguaje Java. También existen nuevas clases en la especificación Java Card 2.0 (como javacard.framework.APDU) las cuales están relacionadas con el estándar ISO 7816 o a la criptografía. La implementación de la JVM esta constituida por un verificador de bytecode, un cargador de clase y un interprete de bytecodes. El verificador se utiliza para verificar que el archivo de clase sea un archivo clase de Java válido. El cargador de clase se utiliza para cargar las clases en el sistema. El interprete de bytecode se utiliza para ejecutar la aplicación. (recuerde que bytecode es el código independiente del hardware que generá Java a partir de su lenguaje y será interpretado por la JVM para el hardware en el que se encuentre corriendo).

Un verificador de bytecodes es una pieza larga de software que no cabe dentro de una tarjeta inteligente. Debido a ello, la implementación de la JVM para tarjetas inteligentes se divide en dos partes, como muestra la figura 1:

Figura 1. Arquitectura del Verficador de ByteCodes en la Java Card.

• La parte implementada fuera de la tarjeta se encarga de manejar la verificación de las clases y asegura que todas las clases necesarias se encuentren disponibles.

• La parte residente en la tarjeta tiene como responsabilidad primaria la ejecución del código (bytecodes).

La máquina JVM es persistente, de tal forma que el estado de los programas y objetos son preservados aunque la tarjeta sea desconectada. Todos los datos relacionados se guardarán en la memoria interna EEPROM. Otra consecuencia de la JVM, es que las clases son cargadas e inicializadas solo una vez, permaneciendo activas hasta que se las elimine.

Además de la metodología del estandar APDU comando/respuesta, la otra forma de interactuar con el programa en la tarjeta Java es utilizando el Método de Invocación Remota (RMI).  RMI, tecnología de objetos distribuidos, es una arquitectura que manifiesta el principio de que un servicio provisto por un servidor (tarjeta Java) debe ser descriptos mediante una interfase.  La interfase provee una lista de métodos disponibles públicamente para un determinado objeto.  Una interfase de este tipo es una especie de contrato que obliga al servidor con sus clientes (terminales).  El servidor garantiza que va a responder por los métodos definidos en su interfase.  Por otro lado, el protocolo enlaza al servidor con sus clientes.  El protocolo define la manera en que el servidor y los clientes se comunicaran.  Debido a que la implementación de protocolos es un tanto complicada, frecuentemente es generada automáticamente por un determinado objeto en la JCRE.  Este programa generado automáticamente, el cual implementa el lado-cliente del protocolo, se denomina proxy como se muestra en la figura 5-2.  Además de contener el código para las funciones, también contiene el código requerido para acceder a las funciones desde un servidor remoto.  Una tarjeta Java puede ser considerada como un Servidor que provee servicios a sus clientes (terminales) para acceder o administrar la información almacenada en la tarjeta inteligente.  Además, varios de los protocolos definidos por los estándares ISO 7816-3 y 4 definen la tarjeta inteligente como un esclavo en una configuración maestro/esclavo:

• La funcionalidad provista por un programa Java (applet) en la tarjeta Java se provee mediante la interfase Java, la cual define la lista de métodos disponibles.
  

• Entre el applet y sus clientes (terminales) se define claramente un protocolo de alto-nivel.
  
  

• Para dar soporte al diseño y desarrollo del software cliente esta disponible un generador proxy.
  

Figura 5-2.  El Proxy entre la aplicación y el Applet

Existen tres reglas para controlar la seguridad y visibilidad de los applets (programas) en una tarjeta Java:

La visibilidad de un paquete es dependiente de la plataforma. Para un paquete visible, solamente las clases públicas son visibles desde el exterior. Si un applet es capaz de obtener una referencia hacia un objeto, entonces el applet esta autorizado a utilizar el objeto.

En realidad , estas tres reglas son las mismas que en las reglas del Java estándar. Además, la mayoría de los fabricantes de tarjetas Java incluyen una característica adicional de seguridad – firewall – entre applets.  Esta característica es global para la tarjeta, y el propósito es aislar cada objeto en su propio casillero para reducir el riesgo de acceso ilegal.  
Luego de que el applet de una tarjeta Java ha sido creado y cargado en el terminal, el primer paso será instalarlo y registrarlo en la tarjeta Java.  Debido a que este método es estático, es el encargado de alojar una nueva instancia del applet y de registrarlo con la JCRE mediante el método de registro como es mostrado en la figura 5-3 (paso 1).  Una vez que el applet ha sido registrado satisfactoriamente, estará listo para ser seleccionado y activado como muestra la figura 5-3 (paso 2).  Solamente un applet puede ser seleccionado y activado por vez.  Si la selección del applet es satisfactoria, estará listo para procesar comandos, como muestra la figura 5-3 (paso 3).  Cualquier comando enviado a la tarjeta se incrustara en un objeto APDU y será enviado al método procesar (process) del applet, mientras este se encuentre seleccionado.  Esto continuará hasta que el applet se deseleccione como muestra la figura 5-3 (paso 4).  El método de deseleccionar del applet actual deberá ser llamado antes que uno nuevo sea seleccionado.

Figura 5-3.  El ciclo de vida de un Applet en una tarjeta Java.

[FIN]

	Esta obra está bajo una licencia de Creative Common