Evolución en Control de Acceso

Las tarjetas de control de acceso se han desarrollado a través de varias generaciones, y con cada generación han ido trayendo nuevas funcionalidades y mayor seguridad.

Todo sobre evolución en control de acceso: La primera generación de credenciales de control de accesos nos referimos a menudo como "Prox”. Las tarjetas Prox proporcionan una identificación simple que se puede leer con un lector de proximidad de baja frecuencia (125 kHz). La ID es estática y se lee en abierto. Así, las tarjetas son fáciles de copiar o falsificar. Estas tarjetas no se pueden codificar con varios identificadores u otros atributos de datos. Sin embargo, a pesar de sus limitaciones significativas, las tarjetas de proximidad siguen siendo ampliamente utilizadas debido a la falta de conciencia sobre los riesgos, y la inercia derivada del coste de las mejoras necesarias en las infraestructuras.
Las credenciales de segunda generación, como las iCLASS® o las tarjetas MIFARE® Classic son tarjetas de alta frecuencia (13,56 MHz) que abordan las dos limitaciones principales de tarjetas de proximidad. En primer lugar, el identificador está protegido por un proceso de autenticación mutua que requiere que la tarjeta confíe en el lector y viceversa. Esto evita (en teoría) que la tarjeta sea copiada o regenerada/refabricada por un tercero, siempre que las claves criptográficas en que se basa esta confianza se mantengan seguras, sin ser comprometidas. En segundo lugar estas tarjetas "inteligentes" soportan funcionalidad de lectura / escritura, permitiendo que se escriban datos adicionales en la tarjeta. Las credenciales de segunda generación se fabrican a partir de un circuito integrado para aplicaciones específicas (ASIC - Application Specific Integrated Circuit). El ASIC tiene un identificador único (ID) que se utiliza como la calve de autenticación para este tipo de credenciales.

Las tarjetas de segunda generación proporcionan un aumento sustancial de la seguridad y la funcionalidad. Sin embargo, la implementación de los sistemas de identidad basados en estas credenciales todavía se fundamenta en la identificación del ASIC como sustituto de la identidad del usuario. Esta limitación se aborda con credenciales de tercera generación, como la tarjeta iCLASS® SE®. La identidad del usuario en una tarjeta iCLASS® SE® se encapsula en un paquete de datos conocido como un Objeto de Identidad Segura (SIO™ - Secure Identity Object). En línea con los mejores modelos de seguridad en la práctica, este paquete de datos se encripta y se firma, proporcionando así una capa adicional de protección de la veracidad, e independiente de la tecnología de la tarjeta donde resida. La tecnología SIO™ permite la aplicación de múltiples identidades para codificar la tarjeta, ya sea en la fabricación o en la post-emisión. Los SIOs se pueden cargar en otros tipos de tarjetas, como MIFARE® DESFire® EV1 u otro tipo de credenciales, permitiendo que se desplieguen credenciales tercera generación en tecnologías de tarjetas de HID®, NXP® y otros proveedores.

Mediante la definición de la identidad del usuario a nivel del SIO™, estas credenciales de tercera generación dan el primer paso importante hacia la aplicación de los ecosistemas de identidades seguras, que son independientes del formato de fabricación físico subyacente de la credencial (los que se denomina form factor). Sin embargo, en la práctica, la aplicación sigue estando vinculada a microprocesadores y a los protocolos de comunicación específicos en los que se basa el RFID concreto de cada credencial. Esto se debe a que los mecanismos utilizados para almacenar y leer el SIO™ están vinculados a nivel hardware a los microprocesadores subyacentes. Esta dependencia del hardware representa un factor limitante clave en los ecosistemas de identidad seguros de hoy.

Las organizaciones de hoy están buscando la posibilidad de gestionar las identidades de sus usuarios de forma independiente al formato del hardware (y al microchip) subyacente. Estas organizaciones quieren tener la posibilidad de crear y administrar identidades seguras, no sólo en las tarjetas, sino también en los teléfonos móviles, tablets y otros formatos de credenciales conectados a través de NFC, Bluetooth y otros protocolos de comunicación. Ellas entienden que esto requiere una tecnología de administración de credenciales que sea independiente del formato del hardware subyacente y del protocolo de conexión. Desde el punto de vista de la seguridad, se dan cuenta de que ninguna tecnología es, en última instancia, irrompible, y que la mejor seguridad en la práctica es la adaptabilidad y la posibilidad de evolucionar para hacer frente a las nuevas amenazas. También entienden los beneficios significativos en términos de ahorro de costes, seguridad y facilidad de uso que vienen de una estrategia de gestión convergente de la identidad/credencial.

La tarjeta iCLASS® SEOS® es una credencial de cuarta generación que atiende las necesidades de estas organizaciones con visión de futuro. SEOS® añade una capa de software que se ejecuta en el nivel superior del microchip subyacente, proporcionando un encapsulado de seguridad para el almacenamiento y uso seguros de las identidades múltiples, definido como SIO™. Esta arquitectura proporciona un conjunto único de capacidades y beneficios que hacen de esta tarjeta la credencial más potente en el mercado hoy en día, a un precio comparable a las credenciales de tercera generación.

El presente documento considera esas capacidades y beneficios en más detalle, y posiciona la tarjeta iCLASS® SEOS® con respecto a otras tecnologías de credenciales disponibles en el mercado hoy en día, tales como NXP® MIFARE® DESFire® EV1. También explora cómo las credenciales SEOS® encajan dentro de la estrategia de plataforma SE® y cómo la potencia de la tecnología HID® SEOS® proporciona soluciones globales tales como control de acceso integrado, acceso móvil y el Smart ID para el empleado.

Plataforma iCLASS® SE®

Con el fin de comprender plenamente los beneficios de las credenciales SEOS® de cuarta generación, es útil revisar las capacidades de la plataforma. iCLASS® SE®. SE® son las siglas de SIO™ Enabled, SIO™ Activado. Todos los productos a lo largo de la plataforma iCLASS® SE® permiten la creación, gestión y utilización de Objetos de Identidad Segura (Secure Identity Objects - SIO™). La capa adicional de veracidad que proporcionan estos Objetos de Identidad Segura se sustenta en las cuatro características que definen un SIO™.

  • En primer lugar, el SIO™ contiene un identificador único para el usuario. Este ID es completamente independiente de los medios en los que el SIO™ se almacena.
  • En segundo lugar, el SIO™ contiene un vínculo (binding), es decir, se vincula con el medio de almacenamiento. Esto asegura que el SIO™ no se pueda copiar de una credencial a otra. En otras palabras, se evita que un atacante pueda hacer una copia no autorizada de la credencial del usuario.
  • En tercer lugar, el SIO™ se firma en el momento de la creación, y esta firma se valida cada vez que se utiliza la credencial. Esto permite al sistema implantado (por ejemplo, un lector en una puerta en un CCAA – Control de Acceso) poder validar que es una credencial auténtica y así evitar que un atacante pueda crear una credencial falsificada utilizando un ID de un usuario conocido.
  • Por último, el SIO™ está cifrado, lo que impide que un tercero no autorizado pueda leer la ID, encapsulada en el SIO™, de un usuario.

La plataforma iCLASS® SE® se compone de una amplia cartera de productos que aprovechan el SIO™ para crear, gestionar y utilizar identidades seguras. El Codificador SE® (SE® Encoder) es capaz de crear SIOs para la codificación de tarjetas y formatos de credenciales. Las tarjetas iCLASS® SE® y MIFARE® DESFire® EV1 SE® son capaces de almacenar de forma segura un SIO™. Los lectores iCLASS® SE® son capaces de leer y validar SIOs.

Un Modelo de Seguridad Basado en Capas

La seguridad en capas describe la práctica de combinar múltiples controles de seguridad atenuantes para proteger los recursos y los datos. Mientras que cualquier mecanismo único de defensa tendrá puntos débiles individuales, una serie de capas de defensa diferentes pueden ser utilizadas para cubrir y solapar los vacíos de cualquiera de las capas individuales.
La plataforma iCLASS® SE® aprovecha el Objeto de Identidad Segura (SIO™) como una capa adicional de seguridad.

El SIO™ es un formato de datos protegido criptográficamente para el almacenamiento seguro de los datos de identidad como ID de usuario, plantillas biométricas, datos demográficos o datos personales. Basadas en estándares de la industria, las credenciales SIO™ están diseñadas para aumentar el nivel de seguridad sin importar el nivel de seguridad del dispositivo subyacente. El objeto SIO™ es un ID portable que se puede programar en una gran variedad de credenciales físicas, de forma que puedan ser aprovechadas por las aplicaciones y productos de terceros. Más allá de proporcionar capacidades de confidencialidad y autenticación de datos, el SIO™ también protege contra la clonación de datos mediante la unión/vinculación de todas esas identidades a un soporte físico específico. El algoritmo criptográfico utilizado para proteger un SIO™ se basa en criptografía AES, mientras que la estructura de datos SIO™ cumple con la especificación ASNI para proporcionar una notación modelo de datos flexible.

Cinco especificaciones básicas de un objeto SIO™:

  1. Cada SIO™ puede contener uno o muchos conjuntos de datos (por ejemplo, un formato de tarjeta para control de acceso).
  2. Cada SIO™ tiene un contexto criptográfico que define la criptografía utilizada para autenticar y cifrar o descifrar datos (por ejemplo, AES cifrado y autenticación)
  3. Un SIO™ puede bloquearse mediante claves personalizables o a través del aprovechamiento de los formatos de HID® estándar o ELITE.
  4. Los SIO™ están soportados por el programa "SE® ELITE" que controla una serie de conjuntos de claves específicamente diseñados y asignados a la plataforma iCLASS®.
  5. La criptografía SIO™ es totalmente agnóstica de la criptografía de chip subyacente y del protocolo seguro de canal.

Beneficios para los Clientes

La plataforma SE® y el modelo de seguridad por capas asociado tienen tres cualidades esenciales para la creación, gestión y uso de identidades seguras.

Seguridad. La plataforma iCLASS® SE® incluye una variedad de modelos de credenciales apropiadas para diversos entornos de riesgo. Una de las principales capacidades de iCLASS® SE® es la independencia tecnológica con respecto al soporte; eso se ha logrado a través de un modelo de datos que agrega capas de seguridad más allá de la proporcionada por sí sola por el soporte subyacente (iCLASS®, MIFARE® Classic, etc...). Mientras que las tecnologías de los soportes para credenciales están evolucionando, algunas ya han sido identificados por la comunidad académica por contener vulnerabilidades (incluyendo importantes limitaciones, como el tener una protección insuficiente de la privacidad). El modelo de seguridad en capas iCLASS® SE® protege contra estas vulnerabilidades.
Adicional mente encontramos otros cifrados diferentes que garantizan la seguridad máxima de SIO.

Cifrado:

  • Se encríptan los datos usando técnicas de criptografía probada. Si los datos son extraídos serian una cantidad de caracteres aleatorios:

Firmas digitales:

  • El objeto seguro esta usando técnicas criptográficas comprobadas. La firma digital habilita la auntentificación (prueba de identidad) y la integridad (prueba de que los datos no han sido alterados).

Encapsulado:

  • Una vez confirmada la prueba de identidad, se agrega mas información de Objeto SIO, datos adicionales como huellas y datos y se encapsula en un solo paquete.

Nuevamente firmado:

  • Cuando todo el contenido se confirma, se une, se encapsula, encrípta y se genera al rededor de una nueva firma digital que protege con doble seguridad de cifrado.

Solución de extremo a extremo. La plataforma iCLASS® SE® es compatible con una amplia variedad de tecnologías de credenciales disponibles en el mercado. La plataforma incluye una amplia gama de lectores y programadores, demás de sistemas de impresión segura de credenciales, sistemas de acceso a parkings, terminales de salud, control de ascensores, control de presencia y muchos otros tipos de sistemas que ya han integrado la tecnología SE® en sus soluciones.

Escalabilidad. Los componentes de la plataforma iCLASS® SE® son actualizables para permitir cambios y actualizaciones en los entornos tecnológicos y empresariales. iCLASS® SE® también aprovecha las tecnologías y prácticas basadas en los estándares para, en la medida de lo posible, poder aumentar la interoperabilidad y la evolución de los dispositivos

Empezando con SEOS®

Como se comentó en la sección anterior, la plataforma iCLASS® SE® se apoya en credenciales de tercera generación, como las tarjetas iCLASS® SE® y las tarjetas MIFARE® DESFire® EV1 SE®, proporcionando una cartera de productos para la creación, gestión y uso de los objetos SIO™ de estas tarjetas.
Las credenciales de cuarta generación requieren una independencia del formato físico subyacente (form factor), de forma que los teléfonos, tarjetas, pulseras y otros wearables se puedan utilizar como credenciales acreditadas indistintamente, estando verificadas. Esta independencia se logra a través del encapsulado Seos®.

El Encapsulado/Contenedor SEOS® de la Credencial

A los efectos de control de acceso, una credencial puede ser considerada como un dispositivo físico que se presenta al sistema por un usuario, con el propósito de demostrar una identidad declarada. Como la tecnología de credenciales evoluciona cada vez más, es importante establecer una distinción entre la credencial física, como una tarjeta de plástico con un chip RFID incrustado, y la credencial digital, que son los datos de identificación cargados en ese chip.

Esta credencial digital es la que proporciona la prueba de identificación. El propósito de la credencial física es simplemente el de llevar esa credencial digital y protegerla de ser copiada o manipulada.
Como se explica en la introducción, las credenciales físicas vienen en cada vez más formatos y tamaños diferentes. Es lo que llamamos el form factor. La credencial ya no es sólo una tarjeta de identificación. Puede ser un teléfono, un mando, una pulsera o un reloj. Del mismo modo, la credencial no siempre se comunicará a través de RFID. Se puede comunicar con el lector a través de Bluetooth®, WiFi o algún otro protocolo de comunicación que aún no se haya inventado.

La contenedor SEOS® proporciona un modelo estable para el almacenamiento y el uso de credenciales digitales, independientemente del form factor y del protocolo de comunicación subyacente. SEOS® utiliza las capacidades criptográficas de los microchips subyacentes para asegurar que las credenciales digitales estén protegidas cuando se almacenan dentro del contenedor. Asimismo se establece un canal seguro con el lector, con seguridad multi-capa, en la parte superior del protocolo de transmisión subyacente. Esto significa que las credenciales se pueden leer de forma segura desde el contenedor, usando protocolos ligeros como puede ser Bluetooth® Smart.
Aunque la implementación del contenedor SEOS® pudiera variar, dependiendo del microprocesador subyacente (según el tipo de tarjeta o dispositivo), en todos los casos el encapsulado criptográfico presenta una interfaz consistente. Por lo tanto, el proceso de lectura de una credencial digital es siempre idéntico, independientemente de si la instancia del contenedor se crea en una tarjeta, un teléfono o cualquier otro dispositivo portátil.

La figura a continuación muestra una representación gráfica del contenedor Seos®, instanciado en una credencial física. El contenedor se puede plantear como éste, compartimentado en múltiples recipientes.

Nos referimos a cada contenedor como un ADF (Application Dedicated File). Cada ADF tiene un OID (Object ID) único y se utiliza para almacenar una credencial digital, (tales como un SIO™, aunque no limitado a sólo uno). La generación del contenedor no restringe el formato de esa credencial.
Cada ADF está protegido por una clave de acceso distinta. El lector debe conocer la clave de acceso para un ADF concreto, de forma que pueda leer la credencial digital de ese ADF.
Esta segregación asegura que el lector sólo obtiene visibilidad a los ADFs a los que está autorizado a leer. Es una parte integral del modelo de privacidad del contenedor Seos®, de forma que el lector ni siquiera es consciente de la existencia, y mucho menos el contenido, de otros ADF a los que no está autorizado a acceder.
Esta figura representa el encapsulado SEOS® con tres ADF. En la práctica, el número de ADFs sólo está limitado por el espacio de memoria disponible en el chip subyacente. SEOS® permite que los ADF dentro del contenedor se puedan crear y destruir cuando sea necesario, incluso después de que la credencial se haya desplegado al usuario final.

Esta arquitectura de credencial de cuarta generación, basada en el contenedor Seos®, ofrece un importante conjunto de beneficios.

  • El contenedor SEOS® se puede instanciar en cualquier plataforma informática. Esto permite habilitar a cualquier dispositivo inteligente para operar como una credencial. Por supuesto, la seguridad del contenedor es dependiente del entorno ejecución en tiempo real subyacente. De ahí que un contenedor SEOS® instanciado en un chip de tarjeta Java sea más seguro que uno que se ejecuta de forma nativa en el sistema operativo de un teléfono móvil. No obstante, esta portabilidad ofrece un inmenso potencial para una amplia gama de credenciales de seguridad con diferentes grados de riesgo. Los beneficios de la independencia de cualquier tipo de dispositivo se explora más adelante en este documento.
  • El contenedor SEOS® se implementa como una capa de software independiente de los microchips subyacentes. Esto permite a la aplicación del contenedor evolucionar más rápidamente para hacer frente a las nuevas amenazas a la seguridad. SEOS® soporta cambios en la estructura de los ADF que no son alcanzables con las credenciales de tercera generación. Esta capacidad de actualización es explorada posteriormente en este documento.
  • Las credenciales digitales se pueden leer y escribir en el contenedor Seos® utilizando cualquier canal de comunicación, incluyendo NFC, Bluetooth® y Wi-Fi. Esto amplía considerablemente la gama de casos de uso, así como el aprovisionamiento y uso de una credencial digital. El beneficio más inmediato de esta capacidad es evidente en las soluciones que aprovechan un teléfono móvil como credencial física. Esta característica también se explora en este documento.
  • El contenedor respeta los principios de privacidad. No revela ningún identificador único (UID) que permita al portador de una credencial SEOS® que un tercero no autorizado le realice un seguimiento. Tampoco revela ninguna información sobre los tipos de credenciales digitales almacenados en el contenedor a un lector no autorizado. El soporte de la privacidad se explora con más detalle al final de este documento.

Independencia del Dispositivo

  • El contenedor iCLASS® SEOS® se puede portar a diferentes tipos de microprocesadores. Es esta la portabilidad que permite a la credencial SEOS® ser desplegada en múltiples formatos diferentes, incluyendo Java Card, llaveros, wareables y teléfonos móviles.
  • El interfaz SEOS® (véase la figura de la página anterior) es consistente independientemente del formato físico subyacente (form factor). En otras palabras, los objetos SIO™ o cualquier otro tipo de objeto de datos se puede leer desde el contenedor SEOS® utilizando siempre un mismo conjunto de comandos, independientemente de si el dispositivo es una tarjeta, un teléfono o una pulsera.

La independencia de dispositivo trae una serie de beneficios importantes:

  • Un modelo estable para la gestión del ciclo de vida de las credenciales, independientemente del form factor subyacente.
  • Diferentes form factors de credenciales se pueden utilizar indistintamente con una infraestructura de lectores común, sin necesidad de programar los lectores para comprender los diferentes protocolos de comunicación o los diferentes form factors de los dispositivos.

Capacidad de Estar SIEMPRE Actualizado

La capacidad de actualización de una credencial SEOS® se puede contemplar desde dos niveles.
El primer nivel reside en la capacidad de crear o destruir un ADF dentro del contenedor, después de que la credencial se haya expedido. La estructura de los ADF dentro del contenedor no es fija. Se pueden crear nuevos ADF, y los viejos ADF se pueden destruir dinámicamente, a través de cualquier sistema, si posee los permisos necesarios. Esto es conceptualmente similar a la forma en que las carpetas de archivos pueden ser creadas o destruidas en un sistema operativo de un PC, de forma dinámica. Al igual que con las carpetas de archivos en un PC, el número de carpetas está limitado sólo por el espacio de memoria disponible. Del mismo modo, las propias carpetas son ambivalentes con respecto al formato de los archivos de datos almacenados dentro de ellos.

Beneficios:

  • El contenedor iCLASS® SEOS® se ejecuta como una aplicación software en el microprocesador de la tarjeta. Por lo tanto, es capaz de crear y destruir ADFs con el fin de optimizar el uso de la memoria disponible durante la vida de una tarjeta.
    El segundo nivel reside en la capacidad de actualizar la funcionalidad del contenedor SEOS® después de que el dispositivo haya sido programado y desplegado, sin perder los datos ya existentes mientras se lleva a cabo esta actualización. Esto permite nuevas funciones para el manejo y uso de credenciales digitales, así como la capacidad de aplicar los parches de seguridad que se vayan considerando necesarios en el futuro. Estos requisitos específicos se tratarían de acuerdo con las capacidades y los procesos de gestión habituales de los dispositivos subyacentes (como los TSM para las tarjetas SIM o elementos seguros, las tiendas (AppStores) de aplicaciones para móviles, sistemas de gestión de tarjetas, estaciones de actualización para sistemas OFF-LINE de control de acceso, etc…).

¿SEOS® o DESFire®?

Comparativa de Características Técnicas

Independiente del medio físico

El Objeto de Identidad Segura o SIO® (Secure Identity Objet) representa una estructura de datos segura que se utiliza para almacenar diversos conjuntos de datos (por ejemplo, control de accesos, pagos, etc…) a través de diferentes tecnologías de tarjetas.

SIO® se puede desplegar en toda una serie de formatos de dispositivos (por ejemplo, una tarjeta, llavero, dispositivos NFC como smartphones o tablets).

Beneficios:

  • Portabilidad del SIO® (el mismo objeto de datos seguros puede residir en diferentes tarjetas inteligentes o teléfonos móviles) lo que facilita la gestión y la codificación/personalización de plataformas cruzadas de datos.
  • Admite entornos heterogéneos con una configuración de riesgo adecuada a la seguridad según cada caso concreto, y proporciona una migración sin problemas gracias a las credenciales multi-tecnología aplicando tecnologías de tarjetas existentes y futuras.
  • Mediante la adición de SIO®, la seguridad de cualquier tecnología de tarjetas HF (actualmente MIFARE®, DESFire®) y dispositivos NFC se puede mejorar.
  • Los clientes pueden desplegar SIO® para aprovechar la mayor seguridad de la plataforma abierta iCLASS® SE® independientemente de la tecnología de la tarjeta y el dispositivo.
  • Mayor retorno de inversión: La vida de la infraestructura de credenciales y el lector se prolonga (mejora evolutiva de toda la plataforma iCLASS® SE®)
  • Publicaciones de actualizaciones en la emisión de credenciales HF existentes (datos y aplicaciones adicionales se pueden cargar en cualquier momento durante la vida útil de credenciales mediante el uso del iCLASS® SE® Encoder)

Seos® en comparación con MIFARE® DESFire® EV1:

  • EV1 es propiedad de NXP®, y sólo puede funcionar con los chips NXP®:
    - en últimas plataformas integradas NXP® JCOP / SE (apoyando emulación DESFire®)
    - y en tarjetas SIM con emulación DESFire® (sintaxis propia de comandos, no la compatible ISO / IEC 7816), por lo tanto, DESFire® depende medios físicos propios y definidos.
  • SEOS® es una solución agnóstica del chip / dispositivo: El protocolo SEOS® se puede implementar en diversas tecnologías de tarjetas. Es independiente del protocolo de comunicación, por lo que se puede implementar tanto en la parte superior de la norma ISO / IEC 14443-4 ambos tipos A y B, así como en los protocolos de contacto de tarjeta inteligente (ISO / IEC 7816-3, ISO / IEC 7816-12), siempre y cuando el chip proporciona suficiente de recursos de memoria, así como de criptografía (AES / DES3 criptografía) solicitada por el SEOS®.

Preparado para móviles y NFC

El acceso móvil con NFC y otras nuevas tecnologías están impulsando a los integradores y usuarios finales por igual a buscar mayores niveles de interoperabilidad y seguridad que nunca en sus sistemas de control de acceso. Los sistemas flexibles y abiertos que funcionan a través de múltiples tecnologías que permiten las nuevas tecnologías y las mejoras funcionales se convertirán rápidamente en una necesidad.

Seos® ofrece una migración simplificada a dispositivos habilitados para NFC, como los teléfonos porque el modelo de datos SIO® se puede transferir desde la tarjeta al smartphone (se establece el mismo modelo de datos y paradigma SIO® entre dispositivos). Además la gestión Over-The-Air (OTA) de dispositivos y credenciales proporciona otros beneficios (por ejemplo, carga automática OTA).

Seos® en comparación con MIFARE® DESFire® EV1:

  • La emulación MIFARE® DESFire® EV1 en el teléfono móvil ya existe (en el elemento seguro integrado o tarjeta SIM) pero requiere un chip NXP® con una licencia DESFire® (el coste es excesivo, e implica un modelo de chip específico). Ningún otro proveedor de chips a excepción de NXP® ofrece actualmente una licencia DESFire®.
  • El diseño Seos® permite ser implementado en cualquier tarjeta inteligente programable incluyendo cualquier elemento de seguridad (elemento de seguridad empotrado, microSD o SIM) Por consiguiente aplicación Seos® se puede cargar en una amplia gama de dispositivos móviles.

Actualmente HID® ofrece carga automática para cualquier terminal APPLE® con sistema operativo a partir del iOS 7 con Bluetooth® Smart, o cualquier terminal ANDROID a partir de la versión 4.3 con Bluetooth® Smart.

Soporte de privacidad

La protección de la privacidad asegura que la información de identificación personal o identificadores únicos globales (como el UID o número de serie de la tarjeta) no son accesibles por personas no autorizadas gracias al diseño seguro del chip y, muy importante este punto a continuación, la aplicación.

Ejemplo: Información del portador de la credencial: datos demográficos, biométricos, claves…

Cómo obtener protección de la privacidad efectiva en tarjetas RFID:

  • Comunicaciones seguras: Que no haya información de identificación personal disponible en texto plano o sin cifrar, a través de ningún comando durante cualquier etapa del protocolo.
  • Mensajería segura: Que los datos que van dentro de los mensajes seguros estén cifrados con una clave de sesión, que sea diferente para cada sesión, incluso con la misma tarjeta. De forma que incluso si los datos son siempre los mismos, la comunicación siempre se vea de otra manera.
  • Que no haya datos estáticos que sean exclusivos de la tarjeta, de forma lo que la tarjeta no se pueda utilizar para realizar el rastreo de su titular, como si fuera un proxy ("proxy tracking")
    - Ejemplo: este problema lo tiene cualquier tarjeta usando un UID fijo, PUPI fijo, CSN o cualquier otro identificador estático en cualquier etapa del protocolo; cualquier identificador estático transferido en texto plano después de la autenticación.
  • Con resistencia a los ataques con bombas inteligentes – Esto se basa en que la tarjeta no revele ninguna información, ni si quiera bajo un sondeo activo, acerca del contexto en el que pudiera, o no, trabajar.
    - Ejemplo: los identificadores de aplicación (AIDs) u otra forma de información que se pueda sondear (incluso en el nivel de la recepción de los diferentes códigos de error o la respuesta que vendría en un momento diferente en caso de éxito o fracaso) pueden utilizarse para averiguar si la tarjeta podría estar asociada a un uso determinado (como abrir accesos en una instalación militar). El término "bomba inteligente" se utiliza para ilustrar el posible uso de este tipo de ataques – significa que sólo “mata” a los usuarios que están asociados con un perfil determinado.
  • Un ejemplo de resistencia a este tipo de ataque es la tarjeta PIV. Todos los titulares de una tarjeta PIV trabajan para el gobierno de los Estados Unidos, por lo que todas las personas que tienen acceso a un sitio concreto deberían tener almacenada en su tarjeta una aplicación de control de acceso con un determinado AID....; el objeto SIO® de cualquier tarjeta de dicha instalación contiene esa clave ELITE en texto plano en su interior. Haciendo que dicho objeto SIO® se transfiera cifrado con una clave de sesión única, se consigue que esa parte de los datos no se pueda vincular al titular de la tarjeta con la organización, teniendo así siempre protegida la clave ELITE.
  • Con la incorporación de objetos SIO® para proteger conjunto de datos internos.

Seos® en comparación con MIFARE® DESFire® EV1:

  • Seos® ha sido diseñado desde el principio para ser resistente a todos los ataques anteriores y para cumplir con los más estrictos requisitos de privacidad. Esto no quiere decir que no se pueda diseñar mal una aplicación Seos® que rompiera la privacidad de la tarjeta, pero la aplicación de control de acceso físico de HID® está diseñada de tal manera que cumple con todos los requisitos de privacidad.
  • La tecnología de tarjetas Seos® protege los datos de diversificación devueltos por la tarjeta. Esos datos se cifran de forma dinámica para que diferentes sesiones con la misma tarjeta no contengan datos que permitan distinguir esta tarjeta de otras tarjetas en el sistema.

Aprovechamiento de los estándares de seguridad

La credencial iCLASS® Seos® está basada en estándares tecnológicos abiertos de forma que pueda ser globalmente aceptada por la industria RFID, cubriendo el ámbito de:

      • Las tarjetas inteligentes con y sin contacto,
      • Dispositivos móviles NFC de acceso físico y lógico,
      • Ventas sin efectivo,
      • Operaciones de tránsito y otras aplicaciones utilizando cualquier tecnología disponible en el mercado.

Para conseguir la máxima interoperabilidad, Seos® ha sido desarrollado sobre estándares globales abiertos existentes o especificaciones de referencia, incluyendo:

  • ISO/IEC 9797: Information Technology - Security Techniques - Message Authentication Codes (MACs) -Part 1: Mechanisms using a block cipher, Part 2- Mechanisms using a dedicated hash-function.
  • ISO/IEC 11770: Security Techniques - Key Management Part 2 - Mechanisms using symmetric techniques.
  • FIPS#197: Specification for the Advanced Encryption Standard (AES).
  • FIPS#46-3: Data Encryption Standard.
  • FIPS#180-3: Secure Hash Standard (SHS).
  • FIPS#198: The Keyed-Hash Message Authentication Code (HMAC).
  • European Standard EN 14890-1: Application Interface for Smart Cards used as Secure Signature Creation Devices Part-1: Basic services.
  • [PKCS#5]: Public Key Cryptography Standard #5: Password Based Cryptography Standard, Version 2.0, 1999-03-25. RSA Laboratories, part of RSA Data Security.
  • [SP800-108]: NIST Special Publication 800-108: Recommendation for Key Derivation Using Pseudorandom Functions (Revised); October 2009.
  • [SP800-38A]: NIST Special Publication 800-38A: Recommendation for Block Cipher Modes of Operation; Methods and Techniques; 2001 Edition.
  • [SP800-38B]: NIST Special Publication 800-38B: Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication, ed. M. Dworkin, May 2005.
  • [SP800-56A]: NIST Special Publication 800-56A: Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, Revised; March 2007.[SP800-78-2]: NIST Special Publication 800-78-2: Cryptographic Algorithms and Key Sizes for Personal Identity Verification, February 2010.

 Beneficios:

  • Una seguridad basada en estándares proporciona un nivel de seguridad mayor: Las normas, en general, son revisadas y verificadas con una frecuencia mucho mayor por las autoridades, en comparación con los sistemas propietarios.
  • Los estándares abiertos proporcionan a los clientes unas infraestructuras de control de acceso preparadas para su evolución en un futuro, así como posibilidades de integración de la plataforma iCLASS® SE® con productos de terceros a través de los DTK / SDK.

Seos® en comparación con MIFARE® DESFire® EV1:

  • iCLASS®, MIFARE® Classic e incluso DESFire® EV1 son soluciones propietarias. EV1 es propiedad de NXP®, y sólo puede funcionar con los chips NXP. Incluso en las últimas plataformas integradas NXP® JCOP / SE (que apoyan emulación DESFire®) y en tarjetas SIM con la emulación DESFire® (con sintaxis de comandos propietaria). Es decir, DESFire® depende medios: Seos® es una solución no propietaria.
  • La autenticación Seos® y su mensajería segura es muy similar a la de los pasaportes o tarjetas EMV, PERO NO EXACTAMENTE IGUAL:

- Los pasaportes, por ejemplo sólo pueden utilizar 3DES, dejando fuera AES (Seos® usa las dos), y aún utilizan la antigua y más débil CBC-MAC, en lugar de CMAC, como hace Seos®. Además, utilizan una clave de sesión con derivación no estándar).
- La autenticación y la mensajería segura de DESFire® (cualquier versión, en cualquier modo) es propietaria y sus problemas de seguridad son conocidos.

Seos® esta alineado con las recomendaciones del NIST: Seos® implementa el modo aprobado NIST y las recomendaciones de la Suite NSA (DESFire® no lo hace) para las operaciones criptográficas.

Seguridad multi-capa más allá de la tarjeta
Definición:
Seguridad por capas (defensa en capas) describe la práctica de combinar múltiples controles atenuantes de seguridad para proteger los recursos y datos.

 

¿Cómo se lleva esto a cabo en la plataforma SE?

  • Un objeto SIO® (Objeto de Identidad Segura) es una colección de objetos seguros (SO – Secured Object).
  • Cada SO puede contener desde uno sólo hasta muchos conjuntos de datos (ej. un formato de tarjeta de control de acceso).
  • Cada SO uno tiene un contexto criptográfico que define la criptografía utilizada para autenticar y cifrar o descifrar datos (ej. el cifrado y la autenticación AES).
  • Un SO se puede asegurar mediante claves específicas del cliente o mediante el aprovechamiento de los esquemas fundamentales de HID® como los formatos STANDARD o ELITE.
  • Mediante el soporte al programa "SE® ELITE", que controla una serie de calves establecidas, específicamente asignadas para la plataforma iCLASS®.
  • La criptografía del SO es agnóstica de la criptografía de chip subyacente y del protocolo de seguridad establecido por el soporte físico.
  • Separación de claves: Las claves que protegen al SO son gestionadas por diferentes políticas de seguridad que la claves expuestas al chip subyacente.
  • La plataforma soporta todo un conjunto completo de productos que leen SIO®, de forma que se puede gestionar, distribuir y procesar el objeto SIO® de diversas formas (incluyen iCLASS® SE® Encoder, Procesadores SIO®, etc...).

Beneficios:

Cuando a una defensa aislada se le pueda encontrar un fallo de seguridad entran en juego una serie de diferentes defensas (seguridad multi-capa), de forma una cubren las lagunas en las capacidades de protección de las otros (la forma más segura de encontrar los defectos es comprometer de forma seria a la credencial por un ataque).

En resumen: ¿Por qué una tarjeta SEOS®?

  • Es una tarjeta que ofrece más seguridad que cualquier tarjeta HF disponible en el mercado.
  • Es una solución de tarjeta Premium, fabricada con materiales de larga duración (multilaminado compuesto), y con un tamaño de la memoria extendida (16 KBytes).
  • Es una tarjeta programable basada en microprocesador, con un modelo de datos flexible y capacidad de gestión de la memoria (sistema basado en archivos) con soporte tanto para claves ELITE, así como para formatos estándar (incluyendo CORPORATE1000).
  • Es una tarjeta agnóstica con respecto al medio de aplicación: La misma credencial es portable a una amplia variedad de dispositivos basados en tarjetas inteligentes, incluyendo smartphones y tablets.
  •  Es una tarjeta que permite el aprovechamiento del modelo de datos SIO (con uno o muchos objetos seguros) apoyado por su modelo de seguridad multi-capa.
  •  Es una tarjeta que permite una migración simplificada hacia teléfonos NFC (ya que aplica el mismo paradigma y el mismo conjunto de datos SIO utilizado entre dispositivos).
  • Es una solución basada en estándares logrando así la máxima interoperabilidad con aplicaciones de terceros (por ejemplo, lectores de accesos integrados por terceros, medios de pago, etc…).
  • Es la solución ideal para despliegues multi-aplicaciones (para entornos exigentes).

¿QUÉ COMPONE UN SISTEMA DE CCAA?

Elementos de un Sistema de Control de Accesos (CCAA)

Cualquier sistema de control de accesos constará de cuatro elementos básicos. Dependiendo del tamaño y propósito del sistema, puede haber muchos tipos adicionales de dispositivos. Sin embargo, los cuatro elementos básicos son:

      • Las tarjetas.
      • Los lectores (posiblemente equipada con teclados).
      • Los paneles de control de acceso (controladores).
      • La interfaz del operador: el PC Servidor.

Vamos a comentar estos elementos de forma individual y determinar su lugar en el sistema de control de acceso. Vamos a utilizar el escenario de un individuo portador de una tarjeta y con intenciones de que se le conceda el acceso.

La Tarjeta

Cualquier tarjeta de acceso tiene grabados un conjunto de números binarios (unos y ceros) que se utilizan para identificar el titular de la tarjeta. HID® fabrica tarjetas que sean capaces de llevar este tipo de datos binarios, incluyendo:

      • Tarjetas de Banda Magnética.
      • Tarjetas de Banda Wiegand (de contacto).
      • Tarjetas de proximidad de 125 kHz.
      • Tarjetas de proximidad inteligentes de 13,56 MHz.

NOTA: HID® fabrica tarjetas que combinan dos o más de las tecnologías anteriores en una sola tarjeta.
El significado y la transmisión de los datos codificados en la tarjeta hacia el lector varían de acuerdo a la tecnología involucrada. En todos los casos, sin embargo, los datos en la tarjeta son una cadena de números binarios con una configuración y una longitud fija.
En la gran mayoría de los casos, los datos de la tarjeta se componen sólo del "formato" que finalmente se recibe por el controlador, previo paso por el lector.

En casos extremadamente raros, se porta un código adicional en la tarjeta que está vinculado a un grupo específico de lectores. Este código de identificación se puede verificar por un lector de dicho conjunto y sólo el dato correctamente formateado envía al controlador.
La tarjeta en sí no tiene conocimiento de la composición de su formato, ni es consciente de los privilegios de acceso para el titular de la tarjeta. Esa información sólo existe en el controlador, y, posiblemente, en el servidor (si está conectado ON-LINE).

El Lector

HID® fabrica lectores que son compatibles con cada uno de los cinco tipos de tarjetas mencionadas anteriormente. En todos los casos, cada lector sólo puede hablar con su correspondiente tipo de tarjeta, ya que cada una de las tecnologías tiene un interfaz personalizado.
NOTA: HID® tiene la opción de fabricar lectores multi-tecnología, destinados a los entornos de transición o migración.
NOTA: Cada tipo de lector utiliza su propia tecnología para leer los datos de la tarjeta. Todos los lectores son capaces de convertir esos datos al Protocolo Wiegand para la transmisión al controlador. (Algunos lectores también pueden comunicarse con el controlador por otros medios, tales como RS232 o Clock & Data)

  • Todos los lectores estándar utilizan alguna de las tecnologías comentadas y simplemente convierten los datos binarios de la tarjeta a Wiegand (u otro) protocolo, y la envían sin cambios al controlador.
  • Ciertos lectores con codificación propietaria reciben un código de identificación (ID) específico del sitio o lugar de la instalación donde se encuentran habilitadas las tarjetas de seguridad. Esos lectores despojan dicho código ID y envian sólo los datos binarios que quedan a su controlador correspondiente.

La tarjeta en sí no tiene conocimiento de la composición de su formato, ni es consciente de los privilegios de acceso para el titular de la tarjeta. Esa información sólo existe en el controlador, y, posiblemente, en el servidor (si está conectado ON-LINE).

El Controlador (Panel de Control de Accesos)

Cuando el controlador recibe los datos del lector, su software o firmware interno inicia el proceso de decidir si se concede o no el acceso. Esto normalmente se hace en varias etapas.

  • ¿La longitud del formato de datos coincide con lo que el controlador está esperando? Algunos controladores se han diseñado sólo para aceptar una determinada longitud de los datos (34 bits, por ejemplo) Si el dato enviado desde la tarjeta es demasiado largo o demasiado corto, el controlador puede ignorarlo por completo. Otros controladores pueden tener un tipo de instrucción especial de "acceso denegado" para una longitud de formato no coincidente.
  • ¿La estructura de formato tiene sentido al controlador? Si la longitud es aceptable, el controlador continuación, rompe la cadena binaria en sus partes componentes. Estos podrían incluir:
    - Código de instalación (FACILITY CODE)
    - Código del Sitio (SITE CODE)
    - Número de tarjeta (CARD NUMBER)
  • ¿Coincide el FACILITY CODE? En el controlador se examinarán los datos para determinar si la porción FACILITY CODE coincide con el que se ha programado en el controlador. Algunos controladores pueden soportar muchos FACILITY CODE diferentes, posiblemente incluso múltiples formatos. Si el FACILITY CODE no coincide, el acceso será denegado y un mensaje de registro generado.
  • ¿Concuerda el SITE CODE? Si el formato contiene un SITE CODE u otro identificador secundario, se manejará igual que el FACILITY CODE anterior.
  • ¿El número de tarjeta dentro del rango asignado? Si es así, el proceso de toma de decisión continuará. Si no, el acceso será denegado y se genera un registro.
  • ¿Está el número de tarjeta en la memoria? En caso afirmativo, el proceso continúa. Si no, se niega el acceso y se genera un mensaje del tipo tarjeta no reconocida.
  • ¿La tarjeta es válida para el lector en este día y hora? En caso afirmativo, se concederá el acceso y el relé de bloqueo se activará. Si no, se generará un mensaje de registro que identifique el motivo de la denegación.

controlador es el único dispositivo en el sistema en el que el formato binario de datos de la tarjeta puede ser decodificado y actuar en consecuencia. Sólo el controlador (y posiblemente el servidor) es consciente de la composición del formato y si los datos recibidos tienen sentido.

Las diferentes marcas de controladores reaccionan de muchas maneras a los formatos de datos de tarjetas incorrectos. Algunos tienen un mensaje de registro para todos los tipos imaginables de "acceso denegado". Los controladores simples pueden tener sólo un registro genérico. Otros países pueden ignorar por completo un formato incompatible y no darle ninguna reacción en absoluto.

Se deben conocer las capacidades del controlador para depurar completamente cualquier problema aparente con la tarjeta y con el rendimiento del lector.

El Servidor

Todos los sistemas de control de acceso tienen algún tipo de servidor o programa de PC para que los operadores lo utilicen. Aquí es donde un operador o un administrador pueden:

      • Añadir y eliminar los tarjetas o usuarios.
      • Asignar, modificar o eliminar los privilegios de acceso.
      • Crear y modificar horarios, listas de vacaciones, etc…
      • Configurar el hardware del sistema para puertas, puntos de alarma, etc…
      • Monitor de eventos del sistema en tiempo real.
      • Generación de informes históricos sobre todos los tipos de actividad del sistema.

Sólo en casos muy raros, en los sistemas grandes y complejos, el servidor puede tomar decisiones de acceso. En el 99,9% de los sistemas existentes, que tarea siempre se realiza por el controlador.

 

Continuará...

No Comments Yet.

Leave a comment