SEGURIDAD EN MACHINE TYPE COMMUNICATION
SANTIAGO CARVAJAL TORRES
ASESOR:
YEZID ENRIQUE DONOSO MEISEL, Ph D.
UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN BOGOTÁ D.C. - COLOMBIA
CONTENIDO
CONTENIDO ... 2
INDICE DE FIGURAS ... 5
RESUMEN ... 6
INTRODUCCIÓN ... 7
2. DESCRIPCIÓN GENERAL ... 9
2.1 Objetivo ... 9
2.1.2 Objetivos específicos ... 9
2.3 Contexto ... 9
2.4 Identificación e importancia del problema a resolver ... 10
3. REQUERIMIENTOS DE SEGURIDAD EN MTC ... 11
3.1 Autenticación ... 11
3.2 Autenticación de la capa de capacidades de servicio M2M (Service Layer Capabilities) y de
las aplicaciones M2M ... 11
3.3 Confidencialidad de transferencia de datos... 11
3.4 Integridad de los datos ... 12
3.5 Prevención del abuso de la conexión de red ... 12
3.6 Privacidad ... 12
3.7 Múltiples actores ... 12
3.8 Validación de la integridad de los dispositivos y Gateways ... 12
3.9 Ambientes Seguros y Confiables ... 13
3.10 Credenciales de seguridad y actualizaciones al nivel de aplicación ... 13
4. SEGURIDAD DE MTC ... 14
4.1 MTC Framework de seguridad ... 14
4.1.1 Utilización del Marco de Seguridad ... 15
4.1.2 MTC Características Seguridad en los medios de comunicación ... 16
4.1.3 Funciones de seguridad de nivel de aplicación ... 17
4.2 Alternativas de Seguridad en el Bootstrapping (Kmr) ... 17
4.2.1 Bootstrapping en red asistida... 18
4.2.2 Bootstrapping en redes Independientes ... 19
4.3 Procedimientos de Conexión (KMC) y la Asociación del nivel de seguridad de la aplicación
(KMA)... 20
4.4 Ambientes de dominio Seguro ... 21
4.5 Security Capability (xSec) ... 21
4.6 Funciones de validación de Integridad ... 23
5. ANÁLISIS DE LAS SOLUCIONES DE SEGURIDAD EN M2M ... 24
5.1 Enfoques Contra Secuestro ... 24
5.1.1 Cifrado y protección de la integridad ... 24
5.1.2 Filtro basado en direcciones IP ... 24
5.2 Soluciones de llave pública ... 25
5.2.1 Certificados Digitales y Firmas... 26
5.2.2 Uso de los Certificados en el servicio de Bootstrapping M2M ... 26
5.3 Soluciones basadas en tarjetas inteligentes ... 29
5.4 Métodos basados en pre-aprovisionamiento de llaves simétricas ... 30
5.5 Protocolo para el Bootstrap basado en encriptación de identidad ... 31
5.6 Seguridad para grupos de dispositivos M2M ... 33
6. TARJETAS INTELIGENTES EN M2M ... 36
6.1 Introducción ... 36
6.2 Privacidad y seguridad en M2M ... 36
6.3 Soluciones de seguridad basadas en Hardware ... 37
6.4 Elementos independientes seguros y Ambientes de confianza ... 39
6.4.1 Ambientes de confianza – necesidad de un ambiente seguro ... 39
6.4.2 Necesidad de certificados de seguridad ... 40
6.4.3 Ventajas del modelo “Smart-Card” ... 41
6.5 Administración remota de los elementos seguros de M2M ... 42
6.5.1 Modelos existentes ... 43
6.5.2 Estandarizar es la Solución ... 43
6.5.3 Beneficios ... 44
7. CANALES SEGUROS CON TARJETAS INTELIGENTES (UICC) ... 45
7.1 Propiedades de los canales Seguros ... 45
7.2 Ciclo de vida ... 45
7.2.1 Descubrimiento de canales seguros ... 45
7.2.2 Descubrimiento de extremos disponibles ... 45
7.2.3.1 Asociaciones de seguridad ... 46
7.2.3.2 Master SA ... 46
7.2.3.3 Conexión SA ... 47
7.2.4 Acuerdo de llaves ... 47
7.2.5 Vencimiento y contador límite para las llaves ... 48
7.2.6 Operación de canal seguro ... 49
7.2.7 Suspensión del canal seguro y reanudación ... 49
7.2.8 Terminación de un canal seguro ... 49
7.3 Tipos de canales ... 50
7.4 Mecanismos para la gestión del material de seguridad ... 50
8. SOLUCIONES DEL MERCADO CON SMARTCARDS ... 52
8.1 MovaSim ... 52
8.2 G&D ... 53
8.3 Gemalto M2M ... 53
8.4 STMicroelectronics: ... 56
8.5 M2MOne ... 57
9. DISCUSIÓN ... 59
9.1 Conclusiones ... 59
9.2 Trabajo Futuro ... 60
INDICE DE FIGURAS
Ilustración 1: Elementos funcionales de la arquitectura para el Bootstraping ... 14
Ilustración 2: Flujo de Alto Nivel de los eventos de Bootstraping. ... 16
Ilustración 3: Proceso de validación de integridad ... ¡Error! Marcador no definido.
Ilustración 4: Tabla comparativa de las diferentes soluciones de seguridad ... 39
Ilustración 5: Plataforma UICC de la ETSI ... 42
Ilustración 6: Arquitectura M2M-Sim ... 52
Ilustración 7: Portafolio de productos Intel ... 54
Ilustración 8: Tarjetas Inteligentes de Gemalto ... 55
Ilustración 9: Tarjetas Inteligentes STMicroElectronics ... 56
Ilustración 10: Tabla comparativa de tarjetas inteligentes M2MOne ... 57
RESUMEN
El presente documento es un proyecto de grado en el área de redes de próxima generación o Next
Generations Networks (NGN), con enfoque en la seguridad actual de este nuevo contexto. Se
pretende analizar las especificaciones de seguridad declaradas por el Instituto Europeo de
Estándares de Telecomunicaciones (European Telecommunications Standards Institute - ETSI) y
mostrar las posibles soluciones que pueden dar soporte a los problemas de seguridad,
específicamente de confidencialidad, autenticación e integridad.
La motivación del presente trabajo es mostrar cuales son las soluciones con las que se pueden
atacar los problemas de seguridad, analizando sus ventajas y desventajas en el contexto M2M.
Además, se pretende hacer un enfoque en la seguridad declarada por los estándares y un enfoque
INTRODUCCIÓN
La comunicación machine–to–machine ha tenido un crecimiento en los últimos años en diferentes
contextos de la vida humana. Esta comunicación surge como producto de la necesidad de
satisfacer ciertos requerimientos sin que exista necesariamente una intervención humana, para así
lograr sistemas automatizados y eficientes que ayuden en el contexto de eHealth, eSafety,
SmartCities, entre otros.
Esta comunicación permite que diversos dispositivos de diferente gama y con fines distintos
puedan comunicarse entre sí, para poder brindar una solución aún mejor. Con el tiempo, el
desarrollo y evolución de los diversos dispositivos del contexto M2M son cada vez mejores y se
busca que tengan una integración con otros dispositivos. Sin embargo, el crecimiento y desarrollo
de productos tecnológicos, sensores y dispositivos; han complicado su integración y comunicación
dado el desarrollo individual de ciertas interfaces, protocolos de comunicación y otros aspectos que
complican la comunicación entre dispositivos. Es por ello que la comunicación M2M, busca
estandarizar y lograr una comunicación y “plataforma” horizontal que logre este objetivo.
Entre los aspectos que se deben buscar en la estandarización de esta comunicación “máquina a máquina” se encuentra la seguridad. La seguridad es de vital importancia en el contexto M2M,
sobre todo por el tipo de servicios que se busca emplear en este contexto. La seguridad, en este
orden de ideas, se puede entender como disponibilidad, integridad, confidencialidad y
autenticación de los cuales se busca profundizar en integridad, confidencialidad y autenticación.
Estos elementos de seguridad necesitan de una especial atención sobre todo porque no se cuenta
con una única solución. Como se ha mencionado anteriormente, en el contexto M2M son múltiples
los dispositivos y entes que están constantemente en una acción, por lo que poseen diferentes
características y en especial diferentes capacidades para el procesamiento y manejo de la
seguridad.
La estructura de este documento es la siguiente: primero se presentan los objetivos, objetivos
específicos, el contexto y la identificación del problema en el Capítulo 2. Luego, en el Capítulo 3 se muestran los requerimientos de seguridad definidos en los estándares de la ETSI TC en el
contexto M2M. Seguido de los requerimientos, en el Capítulo 4 se busca presentar el Framework de seguridad de la plataforma MTC que se ha definido en los estándares, tratando los temas de
jerarquía de llaves, procedimientos de Bootstrapping, procedimientos de conexión y entorno de
ambiente seguro o entornos de confianza. Después de analizar los estándares definidos, se quiere
hacer una revisión de todas las posibles soluciones o alternativas de seguridad que puedan ser
capítulos, se busca hacer un análisis más a fondo de una solución de seguridad que promete mucho en el contexto M2M y es la “Tarjeta Inteligente”. En el Capítulo 6 se hace un estudio de la tarjeta inteligente en el contexto de M2M. Luego, en el Capítulo 7, se muestra a un nivel más técnico la comunicación de canales seguros a las tarjetas inteligentes definidos en los estándares
ETSI TC. Y concluyendo el tema de tarjetas inteligentes, el Capítulo 8 muestra algunas soluciones actuales que se encuentran en el mercado y que hacen uso de tarjetas inteligentes. Por último, el
documento finaliza con la discusión de las conclusiones sobre el trabajo realizado y el trabajo
2. DESCRIPCIÓN GENERAL
2.1 Objetivo
El objetivo de este proyecto es generar un marco de referencia sobre la seguridad de la plataforma
MTC, identificando y explicando los aspectos de seguridad que los estándares ETSI definen sobre
esta y las posibles soluciones que se pueden dar en el contexto de M2M, realizando énfasis en la
solución de Tarjetas Inteligentes.
2.1.2 Objetivos específicos
Describir los requerimientos de seguridad dictaminados por los estándares ETSI de la
plataforma MTC.
Identificar y describir los aspectos generales de la seguridad que define la ETSI.
Describir el Framework de seguridad de la plataforma MTC.
Describir las diferentes soluciones de seguridad aplicables al contexto de M2M.
Describir y analizar el papel de las Tarjetas Inteligentes en el contexto M2M
Buscar soluciones actuales del mercado que involucren Smart-Cards
2.3 Contexto
Con la evolución de las tecnologías de información, es difícil imaginar ahora un desarrollo de la
sociedad sin la participación de máquinas, software especializado y sobretodo de las redes virtuales de comunicación y, en específico, la red de redes: “La Internet”. Esto ha permitido a la
sociedad una evolución gigantesca en los últimos años, y ha permitido convertir procesos de
extremada complejidad en tareas cada vez más simples y de menor tiempo, generando una mayor
eficiencia y rendimiento.
Los sistemas han ayudado al control de información, seguimiento, simulación y procesos
complicados con los datos de pequeñas tiendas, compañías y gobiernos; generando alternativas y
soluciones a los diversos problemas que puedan surgir en la sociedad. Actualmente, la
participación de los sistemas se puede encontrar en todos los campos de la información. Sin
embargo, cuando hablamos de sistemas que nos permitan controlar el medio físico, encontramos
que son pocos los sistemas que dan soporte a este campo y son pocos los que permiten generar
una integración.
Por esta razón, se han generado nuevas propuestas y modelos que buscan suplir esta nueva
necesidad de tener el control del mundo físico y dar solución a diferentes contextos como lo son la
pues, estas propuestas pretenden conectar los diferentes tipos de dispositivos a la red para
permitir observar y controlar el mundo físico a través de Internet.
Estas nuevas tecnologías permiten el desarrollo de aplicaciones que den soporte a los procesos de
negocio reemplazando y automatizando labores que requieran de intervención física. Sin embargo,
no sólo se necesita la comunicación por software a través de la red de un dispositivo con una
persona, sino también la comunicación de dispositivos entre sí. Para ello, ha surgido una nueva
tecnología que es la comunicación máquina a máquina o M2M (machine-to-machine); la cual
permite la interacción entre máquinas o sistemas finales de forma automática e independiente de la
interacción humana.
Dado este nuevo surgir de necesidades y tecnologías, parte esencial es que los servicios y
funcionalidades que se ofrezcan sean servicios confiables y seguros, ya que pretenden soportar
procesos de negocio que pueden ser delicados y riesgosos hasta para la misma vida humana. Por
ello, se ha intentado fortalecer con diversos estándares y trabajos independientes, el análisis y la
presentación de soluciones de seguridad que han de ser implementadas en este tipo de
comunicación para asegurar la disponibilidad, integridad, confidencialidad y autenticación de los
dispositivos.
2.4 Identificación e importancia del problema a resolver
Las soluciones M2M están surgiendo como necesidad de la automatización e integración de los
diversos dispositivos y para permitir la comunicación de estos sin necesidad de intervención
humana. Este hecho trae consigo una serie de implicaciones que se tienen que tener en cuenta
antes de implementar los grandes sistemas o soluciones que esta tecnología conlleva. Sistemas
como eHealth o eSecurity son sistemas críticos que brindan una solución muy interesante en su
contexto. Sin embargo, no quisiéramos que nuestra información viajara libremente por dispositivos
y que otros puedan interceptarlos, o aún más peligroso, alterar nuestra información en cuestiones
de salud, lo que ante una emergencia puede implicar el poner en riesgo nuestra vida. Ante esta
situación, y muchas otras en diversos contextos M2M, quisiéramos asegurarnos que la
comunicación entre máquinas sea efectivamente entre máquinas autenticadas y fiables, y que no
exista ninguna posibilidad de que un atacante conozca o controle nuestra información. Por ello, se
ha querido hacer un esfuerzo y énfasis en reconocer, determinar y proponer diferentes tipos de
soluciones de seguridad que permitan asegurar la comunicación y consigo los procesos que
3. REQUERIMIENTOS DE SEGURIDAD EN MTC
La plataforma Machine Type Commuication o MTC, al abarcar comunicaciones entre dispositivos,
tratar con información delicada y poder generar respuestas afectando no solamente la red sino sus
participantes y el entorno físico, ha definido ciertos requerimientos de seguridad necesarios para
proteger la confidencialidad e integridad de sus usuarios. Es por ello que antes de entrar a
observar y analizar la seguridad de la Machine Type Commuication o MTC, queremos presentar a
continuación los requerimientos de seguridad que la ETSI TC [3] muestra para la implementación
de la plataforma MTC, abarcando temas de confidencialidad, integridad, autenticación y
autorización.
3.1 Autenticación
El sistema M2M debe soportar autenticación mutua de parte del core M2M y el dispositivo (D) o
Gateway (G), y una autenticación unidireccional del dispositivo o Gateway M2M con el Core M2M.
Por ejemplo, una autenticación mutua puede ser requerida entre el proveedor del servicio y las
entidades que soliciten el servicio. Las partes escogen el nivel de seguridad de la autenticación de
acuerdo al tipo de servicio e información que se maneje.
Cada servicio debe ser capaz de realizar procesos de autenticación independientemente de otros
servicios. Los dispositivos M2M que se conectan a través del Gateway, pueden autenticarse de
manera directa con el sistema M2M o autenticarse de manera “indirecta” con el Gateway.
3.2 Autenticación de la capa de capacidades de servicio M2M (Service Layer
Capabilities) y de las aplicaciones M2M
Cuando hay una solicitud de acceso a un servicio o información por parte del dispositivo o Gateway
M2M, estos serán capaces de autenticarse mutuamente con el SC o aplicación M2M de la que se
recibe la solicitud.
3.3 Confidencialidad de transferencia de datos
El sistema M2M debe ser capaz de soportar la confidencialidad apropiada para los diferentes
casos de transferencia de datos. Una aplicación particular puede requerir o no una mayor
3.4 Integridad de los datos
El sistema M2M debe ser capaz de soportar un proceso de verificación de la integridad de los
datos intercambiados.
3.5 Prevención del abuso de la conexión de red
El sistema M2M debe ser capaz de prevenir el uso no autorizado de la red por parte de los
dispositivos y Gateways M2M.
3.6 Privacidad
El sistema M2M debe ser capaz de proteger la privacidad.
3.7 Múltiples actores
El sistema M2M tiene múltiples actores, por ende, el sistema debe proporcionar para los diferentes
actores sus servicios, manteniendo la seguridad end-to.end del servicio. Por ejemplo, un servicio
M2M puede involucrar tres diferentes actores que contribuyen a la proporción del servicio. El
proveedor de la red celular puede ser diferente al proveedor que presta el servicio M2M. Un tercero puede ser el operador M2M o el operador de la red virtual (MVNO por sus siglas en inglés: “mobile virtual network operator”) que estaría en medio del proveedor de la red celular y el proveedor de la
aplicación o servicio.
3.8 Validación de la integridad de los dispositivos y Gateways
El sistema M2M debe ser capaz de soportar mecanismos de validación de integridad para los
dispositivos o Gateways M2M. Sin embargo, es opcional para los dispositivos o Gateways el
soportar los mecanismos de validación de la integridad. Si el dispositivo o Gateway soporta el
mecanismo de validación de integridad y si la validación falla, el dispositivo o Gateway no podrá
ser autenticado. El mecanismo de validación puede ser iniciado por el sistema M2M o puede ser
iniciado de manera autónoma por parte del dispositivo y Gateway en cualquier momento.
El sistema M2M puede obtener de manera remota el historial de logs de los dispositivos o
Gateways para la detección de tampering. Los dispositivos o Gateways pueden o no soportar esta
3.9 Ambientes Seguros y Confiables
Los dispositivos que soporten validación de integridad, deben proveer un ambiente seguro y
confiable. Este ambiente seguro o Trusted Enviroment (TrE), debe ser una entidad lógica que
provea de un entorno de confianza para la ejecución de funciones sensibles o almacenamiento de
información sensible. Toda la información proveniente de las ejecuciones en ambiente seguro debe
ser desconocida para toda entidad externa no autorizada. El TrE debe realizar funciones sensibles,
como el almacenamiento de llaves secretas y proveer calculaciones criptográficas de las llaves,
que son necesarias para realizar la validación del dispositivo y verificar su integridad.
3.10 Credenciales de seguridad y actualizaciones al nivel de aplicación
El sistema M2M debe permitir proveer remotamente las siguientes características a nivel de
aplicación, siempre y cuando las políticas de seguridad lo permitan:
Actualizaciones de aplicaciones de seguridad y firmware de dispositivos y Gateways M2M.
Actualizaciones de seguridad de aplicaciones del contexto de seguridad (aquellas que
poseen llaves de seguridad o proveen algoritmos de seguridad) de los dispositivos o
Gateways M2M.
Esta funcionalidad debe ser protegida y resistente contra tampering. El TrE o elementos de
4. SEGURIDAD DE MTC
Esta sección cubre algunas de las características de seguridad del MTC, las cuales están siendo
estandarizadas por la ETSI TC M2M [5]. Entre los diferentes temas que se tratan en la ETSI TC
M2M, se han acordado las siguientes características y mecanismos de seguridad: varias variantes
de Bootstrapping, que son mecanismos para el establecimiento de material de llave compartida
entre el MTC y los dispositivos de la red, diversas variantes de mecanismos seguros de conexión y
las propiedades de seguridad comunes para el conexiones [9]; así como también la arquitectura de
seguridad, jerarquía de llaves, y entidades lógicas que realizan diferentes funciones de seguridad.
4.1 MTC Framework de seguridad
El marco de seguridad de MTC se describe brevemente en la Ilustración 1. La figura muestra el
dominio del dispositivo (lado izquierdo) y el dominio de red (lado derecho). Todo el marco está
centralizado en las capas de la capacidad del servicio M2M (SCL), tanto en el dispositivo (DSCL)
como en la red (NSCL), así como en las interfaces entre las aplicaciones y los propios SCL,
llamados dIa, mId, y mIa. Las diferentes capas SCL se comunican con otras a través de la interfaz
mId.
Ilustración 1: Elementos funcionales de la arquitectura para el Bootstraping
Las capacidades de comunicación genérica de dispositivos (Device Generic Communication -
DGC) y la comunicación genérica de Red (Network Generic Communication - NGC) se encargan
de la terminación de los protocolos de la interfaz MID. Tanto el dispositivo como la red cuentan con
funcionalidades de seguridad (Seguridad de dispositivos M2M - DSEC y la seguridad de la red
(MAS) cuando los dispositivos se conectan a la red y quieren establecer conexiones M2M. En la
parte superior de esta estructura de seguridad están las aplicaciones de dispositivos (DAS) y
aplicaciones de red (NAS) que se comunican entre sí.
Además de las entidades que se muestran en la Ilustración 1, también puede haber dispositivos
Gateway M2M que actúan como dispositivos M2M hacia la red, pero proporcionan la interfaz de
comunicación de tipo M2M para un grupo de dispositivos M2M detrás de esta puerta de enlace. El
Gateway M2M ejecuta aplicaciones M2M con capacidades de servicios, y actúa como un proxy
entre los dispositivos y la red. De esta manera, el Gateway puede proporcionar servicios a otros
dispositivos conectados a él que no puedan conectarse de manera directa con la red. De tales
dispositivos se pueden incluir, por ejemplo, diferentes tipos de sensores.
4.1.1 Utilización del Marco de Seguridad
El marco de seguridad requiere de interacción entre las aplicaciones, la red o redes y el dispositivo.
La Ilustración 2, muestra a un alto nivel el flujo de eventos que se requieren para que el servicio
M2M pueda ser usado. A este hecho se le llama Bootstrapping y es lo que sucede justo antes de
usar el servicio M2M. En la parte izquierda, de arriba a abajo, está el flujo de eventos de la red (N),
en el centro está el flujo de eventos del dispositivo (D), y en el lado derecho el flujo de eventos
entre el dispositivo y la red.
En primer lugar, tanto en la red como en el dispositivo, las aplicaciones M2M (DA y NA) se
registran localmente ante el DSCL y NSCL respectivamente. Cuando el dispositivo se conecta a la
red, pasa a través de la secuencia de arranque de la red y las fases de registro en la misma. A
continuación, se ejecuta la fase Bootstrap del servicio M2M. En esta etapa, el dispositivo recibe
una identidad (ID) y una llave raíz llama una M2M Root Key (Kmr). Los diferentes servicios M2M
Bootstrapping serán explicados en la sección 4.2.
El Kmr es entonces la llave raíz de todas las demás llaves utilizadas en el marco de seguridad de
M2M. En general, el servicio M2M Bootstrapping, incluye la generación del Kmr que ocurre una vez
cada asociación entre el dispositivo y el proveedor de servicios. Por otro lado, la consecución de
este evento sería la conexión de servicio M2M, la cual puede ocurrir varias veces y para cada
nueva conexión hay una nueva y única llave Kmc, que se utiliza para derivar llaves de nivel de
aplicación.
Para cada aplicación, hay una llave separada llamada Application Key M2M (KMA). Una llave Kma
es utilizada por las aplicaciones para derivar aún más llaves. Por ejemplo, las llaves de protección
de tráfico como la integridad y llaves de cifrado. Estas llaves de protección de tráfico se usan en la
Por último, en la etapa de registro SCL, la DSCL se registra con NSCL. Tanto el DSCL como el
NSCL conocen las aplicaciones en el dispositivo como en la red, y poseen contextos de seguridad
que les permite comunicarse de forma segura.
Ilustración 2: Flujo de Alto Nivel de los eventos de Bootstrapping.
4.1.2 MTC: Características de seguridad en los medios de comunicación
La interfaz entre el dispositivo y la red (mId) tiene varias propiedades de seguridad. El mId
proporciona datos de origen de autenticación, integridad y protección de repetición,
confidencialidad y privacidad. Sin embargo, no todas las aplicaciones pueden beneficiarse de estas
características siempre.
La ETSI TS 102 690 [3] define tres alternativas diferentes para la aplicación de las características
de seguridad en el MID. La primera alternativa es la seguridad basada en la red de acceso (o capa
de enlace), en cuyo caso el marco de seguridad se basa en la seguridad de la red de acceso y, por
lo tanto, no se necesita negociar la seguridad a nivel de transporte o de aplicación. La segunda
alternativa consiste en la capa de transporte, o la capa de seguridad del canal, que se puede
alternativa es la capa que el marco de seguridad M2M considera “seguridad a nivel de aplicación”, proporcionado, por ejemplo, por seguridad XML.
La idea es que el marco M2M soporte múltiples redes de acceso con diferentes propiedades de
seguridad para que diferentes aplicaciones se beneficien de las diferentes alternativas de
implementación de seguridad. Por ejemplo, los sensores simples y con poca capacidad de
procesamiento, no tendrían que realizar una negociación de seguridad a nivel de aplicación, más
bien se podría basar en la seguridad de la red de acceso LTE.
4.1.3 Funciones de seguridad de nivel de aplicación
Para las aplicaciones, el marco de seguridad M2M proporciona control de acceso para la escritura
y lectura de datos desde el dispositivo y la red. Sin embargo, se debe tener una especial atención para que la funciones de seguridad en los dispositivos se ejecuten en un entorno llamado “entorno seguro” [5], que proporciona características de seguridad adicionales para las aplicaciones M2M.
Esto requiere de cierta configuración física para lograr la seguridad en los dispositivos M2M, pero
proporciona soporte para la validación de integridad, almacenamiento seguro, informes de estado
de seguridad y así sucesivamente. Todas estas características permiten que las aplicaciones M2M
puedan realizar, por ejemplo, transacciones monetarias. Desde esta perspectiva, las características
de seguridad de la infraestructura de seguridad M2M proporcionan un buen punto de partida para
construir una variedad de aplicaciones.
4.2 Alternativas de Seguridad en el Bootstrapping (Kmr)
La seguridad del Framework de M2M está basada en material secreto compartido entre los
dispositivos y la red. Este secreto compartido es la llave raíz de M2M, denominada Kmr. Esta llave
no sólo se utiliza como base para la autenticación mutua entre los dispositivos y la red, sino
también como la llave raíz para la conexión y las llaves de nivel de aplicación. Existen múltiples
opciones para inicializar la llave Kmr en los dispositivos y la red:
A la hora de fabricación o de deployment: El dispositivo o Gateway M2M puede ser aprovisionado de un Kmr dentro de un dominio de entorno seguro durante la fabricación o
distribución.
Mediante Red de acceso asistido: El dispositivo o Gateway M2M puede aprovechar información clave que se deriva de credenciales de red de acceso, y hacer uso de esa
información clave para la creación del Kmr en un entorno seguro en el dispositivo o
Gateway M2M.
Red de acceso independiente. El Kmr puede ser provisionado en un entorno protegido en el dispositivo o Gateway M2M ajeno a la red de acceso. Este escenario es aplicable
cuando el operador de red y el proveedor de servicios M2M son independientes y no
guardan una relación entre sí, o no desea utilizar las credenciales de acceso de red para el
arranque de las credenciales de la capa de servicio M2M.
A continuación se describirá brevemente el Bootstrapping en la red asistida e independiente.
4.2.1 Bootstrapping en red asistida
La ETSI TC [5] define tres opciones de Bootstrapping a través de red asistida, que permiten el
aprovisionamiento del Kmr a través de la derivación de las credenciales de la red. En otras
palabras, la autenticación de red de acceso se utiliza también para el Bootstrap del Kmr M2M.
Estas situaciones requieren que el proveedor de red de acceso y el proveedor de servicios M2M
compartan una relación de negocios y confianza. Las opciones que define la ETSI TC son:
Generic Bootstrapping Architecture (GBA). Esta alternativa se ejecuta para gateways que soporten GBA y dispositivos equipados con una sim, ya sea una Universal Subscriber
Identity Module, (USIM), IP Multimedia Services Identity Module (ISIM), cdma SIM (CSIM)
o (R-)UIM (User Identity Module). Los operadores de red deben seguir las
especificaciones del TS33.220, ETSI TS 187 003 y S.S0109-0 para el soporte de GBA con
Sim [9].
Protocolo de Autenticación Extensible (EAP- based) SIM y autenticación y acuerdo de llaves (AKA) basados en las credenciales. Las Implementaciones con SIM o credenciales AKA basados con credenciales EAP-Based para el procedimiento de
Bootstrap M2M deberán utilizar EAP-SIM (RFC4186) o EAP -AKA (RFC4187, RFC5448)
con EAP / PANA (Protocolo de realización de la autenticación para acceso a la red)
(RFC5191). Recordemos que el procedimiento de Bootstrap con EAP / PANA es
independiente a las credenciales y los métodos de autenticación, por lo que es similar a las
redes de acceso independiente de los métodos que utilizan EAP / PANA [9].
Bootstrap usando autenticación de acceso a la red con EAP-Based. En este enfoque, el procedimiento de Bootstrapping M2M es un subproducto de la autenticación de acceso a
la red. Más específicamente, el procedimiento de acceso a la autenticación de red se usa
también para la generación de Kmr y así, en lugar de autenticar el dispositivo o Gateway
dos veces (una para el acceso a la red y otra para el Bootstrapping M2M), se autentica una
4.2.2 Bootstrapping en redes Independientes
El mecanismo automático de Bootstrap M2M que se realiza de forma independiente de las
operaciones de red de acceso, tiene diversas propiedades; entre las que se pueden mencionar las
siguientes:
Está alineado con la arquitectura M2M, donde cada dispositivo establece una sesión
segura con las capacidades de servicio M2M, y no con otros nodos de dispositivos.
No requiere abastecimiento manual de llaves en los servidores durante el deployment de
dispositivos M2M.
Se asegura de que el dispositivo M2M y el servidor de descubrimiento de servicio M2M se
autentiquen mutuamente entre sí durante el procedimiento de Bootstrapping. Esto evita
que cualquier servidor intermedio (u otra entidad) esté entre el dispositivo y el servidor
M2M Bootstrap servicio M2M, para obtener así acceso a la llave Kmr.
En caso de que el dispositivo M2M cambie a un nuevo proveedor de servicios M2M, evita
que el nuevo operador obtenga la antigua Kmr y permite que el nuevo operador haga un
Bootstrapping para una nueva Kmr.
Hay tres alternativas para la red de acceso independiente:
EAP- Ibake (Identidad Basada autenticado Key Exchange) sobre PANA. Este mecanismo establece el Kmr entre el dispositivo y la red de M2M. El protocolo Bootstrap se
basa en Ibake, que será tratado más adelante en el capítulo 5.5. Por ahora, el
procedimiento de arranque se puede resumir en una encriptación basada en identidad
(IBE). Específicamente, un ID públicamente conocido para cada dispositivo, como por
ejemplo un MAC, que se utiliza para derivar su llave pública IBE. La llave privada puede
ser suministrado al dispositivo M2M por la red (es decir, a través del mId, de una manera
segura), o puede ser aprovisionado previamente por el fabricante. Cuando Ibake se usa
para el Bootstrap, el dispositivo M2M y Servicio de Función de Bootstrapping M2M utilizará
las llaves IBE a fin de obtener de manera segura la llave Kmr.
EAP- TLS sobre PANA. El dispositivo M2M y la red realizan una autenticación mutua EAP –TLS usando el dispositivo y los certificados de servidor. EAP- TLS se ejecuta en la parte
superior de la EAP utilizando PANA como protocolo de transporte y EAP- TLS como
método EAP. El Kmr se genera en base a la EAP-TLS Extended Master Session Key
(EMSK). Una tercera parte de confianza proporciona los certificados del dispositivo y del
servidor.
TLS sobre Protocolo de Control de Transmisión (TCP) con certificados de dispositivo. Este método utiliza TLS con certificados de dispositivo y servidor para la autenticación mutua del dispositivo M2M y de la red, pero conlleva el protocolo TLS a
través de TCP en lugar de la EAP/ PANA. Una vez que se establece una conexión segura
autenticada mutuamente, la red de forma remota provisiona el ID del nodo y la llave Kmr al
entorno seguro del dispositivo.
Tenga en cuenta que cuando se utilizan certificados, un tercero de confianza que proporciona la
raíz de la jerarquía de certificados debe existir. Esto se aplica especialmente cuando se
proporcionan los certificados durante el tiempo de fabricación y cuando el proveedor de servicio
M2M es independiente del fabricante.
4.3 Procedimientos de Conexión (KMC) y la Asociación del nivel de seguridad de la aplicación (KMA)
Cuando el dispositivo M2M y la red M2M tienen ya a su disposición la llave raíz Kmr, se puede usar
esta para realizar la autenticación mutua y luego negociar la llave de conexión, es decir, la llave
Kmc. Esta llave se usa para obtener las credenciales para la protección o inscripción de los
mensajes o tráfico. Alternativamente, la llave Kmc se utiliza para derivar llaves específicas de la
aplicación (es decir, llaves Kma), que a su vez se utilizan para la protección del tráfico en los end
points de las aplicaciones.
El procedimiento de conexión de servicio M2M se puede establecer sobre la base de diferentes
protocolos [6]:
Procedimiento de conexión M2M basado en GBA. Este protocolo aplica en escenarios en los que el operador de red móvil (MNO) y el proveedor de servicios de M2M son la
misma entidad, la llave de largo plazo almacenada en el SIM se puede utilizar en los
procedimientos de GBA.
Procedimiento de conexión M2M basadas en EAP / PANA. En este escenario, el dispositivo y la red se autentican mutuamente entre sí con un método de EAP sobre el
protocolo PANA sobre la base de la llave raíz Kmr, que ya ha sido aprovisionado en el
Bootstrapping. Al final de la autenticación mutua basada en EAP y la entrega de la llave de
sesión Maestra (MSK) al servidor de autenticación de red, se generará una llave Kmc a
partir de la MSK por el NSCL y el DSCL.
Procedimiento de conexión M2M basadas en TLS- PSK (llave pre-compartida). Este procedimiento utiliza TLS – PSK para el establecimiento de Kmc entre un dispositivo M2M
y de la red, con la ayuda de un MAS con la que el dispositivo M2M ya ha establecido un
Para un mayor detalle de los procesos de Bootstrapping y conexión, la ETSI en sus estándares [5]
[6] muestra con mayor detalle como son estos procesos o podemos también consultar material en
español del proyecto de grado de Parrado N. [12].
4.4 Ambientes de dominio Seguro
Los Ambientes de dominio seguro o “Trusted Enviroments” , hacen referencia a una entidad lógica
que está aislada de las demás entidades del contexto M2M con el fin de proteger y garantizar la
seguridad de funciones sensibles, incluyendo el almacenamiento y la manipulación de datos
sensibles, tales como credenciales, llaves y material clave, del dispositivo [5].
El proveedor de servicios M2M es el encargado del control y administración de estos ambientes
seguros, independientemente que estos estén en un dispositivo o Gateway externo a la
infraestructura de NSCL.
Por otro lado, los Dispositivos M2M o Gateways también pueden contener un entorno de confianza
y un entorno Seguro, utilizado para la validación de integridad en la cual:
• Este dominio Seguro se dotará con una llave que se utiliza para firmar las
validaciones de integridad.
• Este dominio Seguro podrá usar criptografía asimétrica para el aprovisionamiento y la validación de los valores de referencia de confianza. Los valores de referencia
de confianza pueden ser aprovisionados mediante certificados digitales.
4.5 Security Capability (xSec)
A continuación se muestra una descripción de una capacidad de servicio del M2M encargada de la
seguridad en las capas de servicios de una red o Network, de un dispositivo y un Gateway.
La capacidad de seguridad (xSEC) permite el registro a los niveles de servicio, siendo el único
camino necesario para permitir que un dispositivo o Gateway pueda realizar operaciones con los
servicios de red [9]. Este servicio de registro incluye autenticación mutua, autorización y
Bootstrapping. La descripción de alto nivel de estas funciones se proporciona a continuación.
La autenticación mutua: Para que a un dispositivo o Gateway se le permita acceder a ciertos recursos que son administrados por el operador de M2M, es necesario que estos
sean autenticados. Por el lado del NSCL, NSEC es la capacidad de servicio que conecta
con el MAS, es decir, el servidor que tiene acceso a la información de suscripción del
registrarse con la infraestructura (NSCL) del operador M2M, NSEC obtiene material de
autenticación del MAS y material clave del dispositivo (o Gateway), mientras que al mismo
tiempo proporciona suficiente información de autenticación a través de la cual el NSCL
también se autentica con el DSCL o GSCL. Como tal, NSEC puede ser considerado como
el "autenticador " en la autenticación, autorización y contabilización1 (AAA por sus siglas en
ingles). El material de autenticación se genera a partir de la llave raíz. Como resultado de
un procedimiento de autenticación mutua, una llave de sesión simétrica de mutuo acuerdo
es generada y se almacena dentro de xSec (NSEC por un lado y DSEC GSEC o en el
otro). La llave de sesión se utiliza para derivar más material clave para aplicaciones en la
creación de conexiones de datos seguras a través de la interfaz mId, así como la
autorización a nivel de aplicación. Tenga en cuenta que diferentes operadores M2M
pueden estar equipados con diferentes tipos de servidores de autenticación. Esto es
particularmente importante cuando dichos operadores desean reutilizar sus infraestructuras
existentes de servicios de autenticación (como HSS o servidores AAA), que también
pueden usar para otros tipos de servicios, como el acceso a la red. Así pues, la aplicación
de NSEC ha de tener en cuenta las tecnologías de autenticación más comúnmente
desplegadas con el fin de facilitar diferentes protocolos de autenticación.
Autorización: Tras la autenticación mutua con éxito, el MAS proporciona información de autorización para el NSEC. Dicha información, específica qué recursos pueden ser usados
por una aplicación particular en un dispositivo particular. Con base en la información y en el
conjunto de llaves de sesión, NSEC genera llaves particulares para cada aplicación. Tenga
en cuenta que no todas las operaciones realizadas por la NSCL corresponden a
operaciones realizadas por GSEC y DSEC. Por ejemplo, sólo el NSEC tiene una
comunicación con el MAS, mientras que el DSEC o GSEC tienen una relación con un
entorno seguro en el dispositivo o Gateway, en el que se realizan todas las operaciones
de seguridad de confidencialidad, como las funciones confidenciales de derivación de
llaves que hacen uso de la llave raíz. Por otro lado, hay ciertas funcionalidades que son
similares, tales como la derivación de material de llaves de sesión que se utiliza para
establecer sesiones seguras en el mId.
Bootstrapping: En ciertos casos, NSEC puede ser usado incluso antes de la activación de una suscripción de usuario. Como se discutió en capítulos anteriores, el servicio de
Bootstrapping permite a un dispositivo o Gateway asociarse permanentemente con la
infraestructura de un operador de M2M en particular, a través del arranque (Bootstrap) de
una llave raíz común permanente, junto con otros parámetros de servicio y
1
configuraciones. En este contexto, cada vez que sea necesario, el NSCL debe facilitar el
Bootstrapping de la llave raíz, permitiendo que el dispositivo o Gateway se comunique con las funciones de servicio de Bootstrapping M2M (MSBF – por sus siglas en inglés) a través
de la infraestructura del NSCL. Dado que el MSBF puede ser propiedad del proveedor de
servicios M2M, los dispositivos o Gateways deben ser autenticados una primera vez con el
fin de ser autorizados para llegar al MSBF. Esta primera autenticación, se realiza de nuevo
por el NSEC.
4.6 Funciones de validación de Integridad
Dispositivos M2M y Gateways pueden, opcionalmente, soportar procesos de Validación de
Integridad (IVal) [6]. El proceso de validación de integridad nace como respuesta a los
requerimientos de seguridad en los cuales se necesita un énfasis en los procesos de arranque de
los dispositivos y Gateways.
El proceso de validación de integridad consiste en verificar la integridad del código ejecutable
comparando el resultado de una medición (como un hash criptográfico) del código ejecutable con
su valor de referencia de confianza. Si estos valores concuerdan, el código del archivo ejecutable
es verificado con éxito. La única excepción permitida para no verificar cierto código es de aquellos
que son implementados físicamente, en cuyo caso dicho código ejecutable puede ser excluido de
los procedimientos IVal.
Cada código ejecutable se identificará individualmente por los ambientes o entornos seguros y
para cada una de las comprobaciones de integridad se hace una comparación con el valor de
referencia de confianza correspondiente, que se obtiene a partir de la memoria de cada uno de
estos. Por ende, el valor de referencia de confianza debe estar protegido por la autenticidad y la
integridad, de lo contrario, no se puede utilizar y el proceso seria inválido.
El entorno de confianza mide la integridad del código ejecutable en el dispositivo o Gateway M2M.
Para ello, hace uso de ciertas medidas que se caracterizan por ser un sello que registra el tiempo
de modificación y que se almacenan en el entorno de confianza o entorno seguro. El entorno
seguro compara las medidas con el valor de referencia de confianza. Si el IVal falla no se permitirá
ejecutar el archivo o código.
La validación de la integridad de un dispositivo o Gateway M2M es exitosa si todo el código
5. ANÁLISIS DE LAS SOLUCIONES DE SEGURIDAD EN M2M
Para satisfacer los diferentes requerimientos de seguridad de M2M se necesitan no una sino
diversas soluciones que puedan brindar un nivel de seguridad y confianza al usuario y al sistema.
A continuación se presentan las diferentes soluciones [1].
5.1 Enfoques Contra Secuestro
5.1.1 Cifrado y protección de la integridad
Diferentes soluciones de seguridad proponen el uso de las operaciones de cifrado con el fin de
detectar y prevenir ataques de secuestro. La idea primordial detrás del cifrado es proteger la
integridad de los mensajes mediante el hashing del contenido del paquete usando una clave
secreta conocida sólo a los participantes de la sesión y añadiéndolo al final del mensaje. Es así,
como el destinatario puede utilizar la misma clave secreta para producir el resultado hash, y
compararla con la que se adjunta en el mensaje recibido. Si coinciden, entonces el receptor está
seguro acerca de la autenticidad del mensaje.
Con este nivel de seguridad, vemos que solo se puede producir una alteración de los datos si el
atacante conoce la llave secreta de la sesión, además de la identidad del dispositivo. Por otro lado,
además de ofrecer protección de la integridad de los mensajes, el cifrado de los mensajes asegura
la identidad del dispositivo, ya que también está protegido de una posible suplantación.
Sin embargo, muchas de estas operaciones criptográficas son muy pesadas en términos de
procesamiento, por lo que dispositivos M2M de bajo costo no pueden soportar esta medida de
protección. Además, la protección de todo el tráfico de un usuario añade una enorme sobrecarga
en la red que no es soportable por las redes celulares, mientras que el cifrado de datos de usuario
se utiliza ampliamente. Es así, que para algunos casos de naturaleza esporádica y que se requiera
de una protección necesaria a la integridad del mensaje, se puede usar esta solución ya que, a
pesar de que sea un proceso pesado, no afecta severamente a la red al ser procesos esporádicos.
5.1.2 Filtro basado en direcciones IP
La idea de esta solución es comprobar la dirección IP de origen de los paquetes en los enrutadores
intermedios a lo largo de una red de enrutamiento, con el fin de detectar ataques de suplantación o
buscan el camino inverso para la dirección IP de origen. Sin embargo, esta solución es insuficiente
en el contexto M2M por dos razones:
El dispositivo de la víctima y del atacante pueden estar cerca y no usar enrutadores
intermedios.
Dependiendo de la implementación, los paquetes de una aplicación pueden no incluir
ningún detalle de la identidad del dispositivo.
Otra implementación que utiliza información de la dirección IP, es la que lleva a cabo la supervisión
de los patrones de tráfico. El objetivo principal de tales mecanismos es detectar anomalías en la
red mediante la observación de dispositivos que han sido atacados y, como consecuencia, poder
observar si estos patrones han cambiado recientemente. Por ejemplo, si se envía tráfico a nuevos
puntos de destino con paquetes no comunes del patrón.
Esta solución ayuda a la detección de ataques de gusanos, por ejemplo. Sin embargo, esta técnica
es menos eficiente en el contexto M2M, ya que un atacante puede evadir esta medida de
seguridad al usar un gran conjunto de datos de direcciones IP e identidades temporales. Con esto,
el análisis y estudio del tráfico no puede identificar de forma efectiva un tráfico malicioso, ya que se
distribuye uniformemente a través de los nodos.
5.2 Soluciones de llave pública
Como se ha mencionado, el método Bootstrapping consiste en aprovisionar un par de llaves, una
pública y una privada, junto con un certificado de la llave pública. Hemos visto que este par de
llaves se pueden generar de forma individual durante la fabricación y pueden estar preinstaladas
junto con el certificado correspondiente. Después de esto, durante la instalación, el dispositivo
podría ejecutar un protocolo de llaves públicas para obtener así la llave raíz.
Esta solución es muy conocida y relativamente sencilla, sin embargo este método incluye la
necesidad de una infraestructura de llaves públicas a gran escala (PKI) que, potencialmente,
puede manejar un billón de dispositivos.
El sistema PKI es el conjunto de hardware, software, personas, políticas y procedimientos
necesarios para crear, gestionar, distribuir, usar, almacenar y revocar certificados digitales. En esta
solución se define la entidad intermediaria que administra y autoriza los certificados de los usuarios, la cual se denomina “certificate authority” (CA). Para cada dispositivo, la identidad del dispositivo, la llave pública, su unión, las condiciones de validez y otros atributos se incluyen en los
certificados de llave pública, emitidos por la CA. La función principal de la CA es la publicación de
lo que la confianza en la llave pública del dispositivo se basa en la confianza de la gente en la
validez de la llave del CA.
5.2.1 Certificados Digitales y Firmas
El certificado digital certifica la propiedad de una llave pública a un ente o persona. Esto permite, a
otras entidades poder confiar en firmas creadas a partir de la llave privada que corresponde a la
llave pública que se certifica. En este modelo, basado en relaciones de confianza, el CA es un
tercero de confianza tanto por el propietario del certificado como el que confía en el certificado
En otras palabras, un certificado es un "documento" digital que contiene tanto una identidad y una
llave pública, uniéndolos con una firma digital, que se construye por la CA. Cualquier persona en
posesión de la llave pública del CA puede verificar la firma del CA en el certificado presentado. Con
esto, el CA garantiza que la llave pública en el certificado pertenece a la entidad cuya identidad se
encuentra en el mismo certificado.
El estándar mundialmente aceptado para los certificados digitales se llama X.509. Un certificado
X.509 contiene la información que se firmó y, por lo tanto, se garantiza que sea verdadera y no
haya sido modificada. Esta información puede incluir el número de serie, el período de validez, el
nombre del emisor (es la identidad de la entidad emisora ), nombre del sujeto (esto es la identidad
de la parte de la certificación, que puede ser un dispositivo, servidor de autenticación, etc), llave
pública (la llave pública de la parte que se certifica), entre otros. La firma digital se produce
utilizando la llave privada de la entidad emisora.
5.2.2 Uso de los Certificados en el servicio de Bootstrapping M2M
En la siguiente sección, se analizan los diferentes enfoques posibles para Bootstrapping usando
certificados, incluyendo el enfoque adoptado por el estándar OMA DM.
Procedimientos OMA DM
Los procedimientos OMA DM (Device Management) se llevan a cabo utilizando un servidor de DM
que almacena los objetos de gestión (MOs en inglés) para ser transferidos a un cliente utilizando el
protocolo de DM. Con OMA DM, los dispositivos hacen Bootstrapping en cualquiera de las tres
formas siguientes:
En el proceso de fabricación.
Con una tarjeta inteligente (Smart Card).
Después de establecer una comunicación inicial entre el dispositivo y el servidor de DM, este último
le envía la clave raíz al dispositivo.
En los casos en el que el servidor provee del material al dispositivo, se llevan a cabo los siguientes
pasos:
El servidor de DM y el dispositivo se autentican mutuamente utilizando información secreta que
conocen ambas partes. La información secreta que es compartida puede basarse en un PIN de
usuario o un PIN de red. Los certificados también se pueden usar para este caso.
El servidor DM envía el mensaje de arranque con un mecanismo “push”. Por ende, el servidor debe conocer la dirección del dispositivo o algún otro mecanismo para lograr la comunicación con el
dispositivo antes de iniciar la rutina de carga. Este mensaje de arranque contiene información
suficiente para que el dispositivo sea autorizado y pueda iniciar una sesión con el servidor DM.
Esta transferencia es única.
Para la realización del Bootstrapping y para el registro regular del dispositivo, el dispositivo y el
servidor DM se pueden autenticar entre sí de varias maneras, tales como:
La seguridad de clave pre compartida capa de transporte (TLS PSK), donde la clave pre
-compartida se proporciona por el fabricante o el servidor DM.
TLS con certificados de servidor y autenticación de cliente basados en digest, donde se
utiliza una contraseña de cliente para autenticar al cliente.
TLS con certificados tanto del cliente y servidor, donde el certificado de cliente se
aprovisiona ya sea por el fabricante o por el servidor DM.
Bootstrapping mediante certificados
A continuación se presentan los diferentes enfoques en los que se podrá hacer Bootstrapping
usando certificados:
El dispositivo es pre-aprovisionado con un certificado de una CA que sea de confianza
para todos los proveedores de servicios M2M. Tal CA puede ser una sola CA de confianza,
que mantenga relaciones con todos los proveedores de servicios posibles, así como
mantener relaciones de confianza todos los fabricantes de dispositivos. Además, el
dispositivo también es pre-aprovisionado con una o más llaves públicas de los proveedores
de servicio que están afiliados al CA.
El dispositivo es pre-aprovisionado con tantos certificados como el número total de
entidades emisoras de certificados que son de confianza por todos los proveedores de
servicios de candidatos en el momento de fabricación. En los casos en que tales entidades
suministrado con un certificado de cada CA. El dispositivo también está pre - aprovisionado
con una o más llaves públicas de CA que están afiliadas a los proveedores de servicios.
El dispositivo es provisionado con un certificado de un CA durante el proceso de
Bootstrapping. Tal CA debe ser de confianza por el proveedor de servicios. En tal caso, el
dispositivo necesita ser aprovisionado previamente con credenciales que se utilizan para la
autenticación del dispositivo antes de la recepción del certificado.
En los casos anteriores, siempre que un certificado ha de ser provisionado al dispositivo, una o
más entidades de certificación deben ser contactadas. Más específicamente, en el caso en el que
el fabricante provisiona los certificados en el proceso de fabricación, estos deben tener al menos
tantos certificados como el número de entidades de certificación raíz que son de confianza por los
diferentes proveedores de servicios M2M existentes.
Por otro lado, la revocación de los certificados se basa en listas de revocación de certificados (CRL) o en protocolos de revocación como el “online certifcate status protocol” (OCSP). Estas
consultas, que se realizan a los CRL, requieren tráfico adicional iniciado por el dispositivo.
Teniendo en cuenta este factor y los millones de dispositivos M2M que se pronostican, se deduce
un aumento en el uso de ancho de banda y la ocupación de recursos. Las bases de datos de CRL
tienen que estar siempre disponibles con el fin de atender las consultas. Dado que la base de
datos de CRL sólo contiene la lista de certificados revocados, a menudo devuelve un resultado no
concluyente de que el " certificado en cuestión no se encuentra en una base de datos".
De acuerdo con lo mostrado anteriormente, se pretenden indicar a continuación algunas
preocupaciones o debilidades que poseen los métodos criptográficos en el contexto del
Bootstrapping en M2M.
Para los casos de las redes celulares, los métodos de llave pública no hacen parte de los
principales estándares de los celulares existentes sino que usan los mecanismos de autenticación
de capa de enlace y protocolos de clave simétrica (3GPP, 3GPP2, etc.). Además, cualquier método
de Bootstrapping con llaves públicas usando la administración “Over The Air” implicaría que no se pueda acceder a la red celular sin antes realizar el Bootstrapping, lo cual afectaría a celulares
existentes que no estén de acuerdo con la estandarización que se pretende. Por lo tanto, los
métodos de llave pública para el Bootstrapping sólo sirven después de un cambio de las normas y
estándares en la red celular.
Por otro lado, la necesidad de una PKI para la gestión y aprovisionamiento de certificados es
fundamental para un funcionamiento seguro de los métodos de llave pública. En el contexto de
M2M, cualquier método de llave pública se limita al Bootstrapping del dispositivo que se realizará
una vez por dispositivo, por lo que el costo de una única transacción por dispositivo por medio del
de certificados de " una transacción por dispositivo " es muy caro. Recordemos que los sistemas de
PKI para llave pública son para uso a largo plazo y presupuestado para soportar muchas
transacciones. Este hecho, afectaría también lo que se pretende en el contexto de M2M en donde
los dispositivos ligeros y económicos (por ejemplo para el contexto climático) subirían de precio.
Por otra parte, el PKI debería gestionar miles de millones de llaves, lo cual no es una tarea
escalable dado el complejo ecosistema.
Además, las llaves privadas en un entorno de llave pública tienen que ser almacenadas de forma
segura. Este hecho, en el contexto de M2M que posee millones de dispositivos de bajo costo,
puede comprometer su seguridad física, por lo que no se puede asumir un esquema en donde se
proporcione protección a largo plazo de los certificados y claves privadas.
5.3 Soluciones basadas en tarjetas inteligentes
El uso de tarjetas inteligentes (tarjetas SIM para los sistemas GSM o UICC en general) es una de
las opciones atractivas para los escenarios con despliegue de M2M a través de las redes celulares.
Desde finales de 1990, las tarjetas SIM han sido ampliamente utilizadas por los operadores
móviles en los teléfonos y otros dispositivos para lograr la conexión a las estaciones celulares.
Este hecho permite que los celulares M2M, donde los dispositivos son de forma predeterminada
equipados con tarjetas inteligentes, puedan usar las tarjetas sim y proporcionar el nivel de
seguridad y autenticación necesario para su uso en el servicio M2M.
Por otro lado, los estándares de red de la 3GPP demandan el uso de ciertos tipos de tarjetas
inteligentes como la UICC con SIM o USIM aplicaciones, a cualquier dispositivo que esté
conectado a la red. En estos contextos, el uso de tarjetas inteligentes es obligatorio para los
dispositivos M2M. Las tarjetas inteligentes contienen una clave secreta permanente previamente
provisionada y codificada por el fabricante de tarjetas inteligentes; dicha clave se puede utilizar
para la generación de llaves de sesión para el uso de la capa de servicio M2M o capa de
aplicación.
El generar y proporcionar llaves para las capas de servicio o aplicación sugiere que las
aplicaciones o servicios que se prestan confían en el dueño de la tarjeta inteligente (generador de
llaves). Por lo tanto, si una llave generada se va a utilizar para establecer sesiones seguras entre el
dispositivo y un proveedor de servicios M2M, este último debe tener una relación de confianza con
el operador de red. Esta relación de confianza es muy conveniente cuando el operador de red
ofrece servicios M2M. Del mismo modo, en caso de que el proveedor de red sea distinto al
proveedor de aplicaciones y el proveedor M2M confíe en el proveedor de red, éste puede
proporcionar una llave o usar la llave de la tarjeta sim para una sesión segura end-to-end en la
de aplicaciones a los dispositivos y por lo tanto las aplicaciones M2M pueden utilizar llaves
derivadas de la llave permanente almacenada en la tarjeta inteligente. Claramente, si el operador
de la red celular no es de confianza por la aplicación o el proveedor de servicios, se debe usar un
método independiente para el aprovisionamiento de llaves que no se base en la tarjeta inteligente.
Las tarjetas inteligentes no son apropiadas para los casos en que todo el servicio o nivel de
seguridad reside exclusivamente en ellas. Esto es porque las tarjetas inteligentes tienen un
problema de aprovisionamiento de claves raíz en la tarjeta inteligente, que se deja a menudo al
fabricante de la tarjeta y puede ser un procedimiento patentado (en su mayoría manual) que se
realiza cuando los clientes compran un servicio. Tales métodos, no serían escalables en las
implementaciones M2M, que pueden estar compuestos por miles de millones de dispositivos.
Sin embargo, más importante aún que el uso fundamental de tarjetas inteligentes en la telefonía
celular, es permitir la portabilidad de suscripción, es decir, que el usuario final pueda cambiar y
conectarse a la red a través de una suscripción válida sin la intervención del operador. Esta
característica tiene poco o ningún valor en el contexto M2M, y de hecho cualquier módulo de
identidad extraíble se abre la posibilidad de ser adulterado por maliciosos usuarios finales, que
utilizan estas tarjetas en otros dispositivos y roban el servicio. Además, cuando el proveedor de
servicio M2M cambie, las tarjetas inteligentes deberán ser reemplazadas, por lo que se requiere de
una sustitución de millones de tarjetas inteligentes y, potencialmente, puede ser muy costoso. Por
otra parte, esto no puede lograrse sin la intervención humana.
5.4 Métodos basados en pre-aprovisionamiento de llaves simétricas
Un dispositivo M2M puede autenticarse mutuamente con el proveedor de servicios en el caso en
que ambos estén aprovisionados previamente con la misma llave, que se puede utilizar para
realizar operaciones criptográficas simétricas durante cada registro del dispositivo. Tal llave, puede
ser una llave almacenada de forma permanente en el dispositivo, dentro de un entorno seguro; y
de esta manera, por el lado del proveedor de servicios, se espera que las llaves simétricas se
almacenen típicamente en una base de datos segura, que interactúe con un servidor de
autenticación, tal como un servidor de HSS o AAA.
Dada la diversidad de escenarios discutidos anteriormente con respecto a las implementaciones de
dispositivos M2M, no es posible a priori, suponer que el proveedor de servicio M2M está implicado
en el proceso de despliegue del dispositivo y la distribución de servicios específicos al cliente. Por
otro lado, debido a la diversidad y costos de los dispositivos M2M, en la mayoría de casos éstos no
están equipados con una interfaz de usuario que puede ser usada para el aprovisionamiento
manual de llaves después de la compra. Por lo tanto, en la solución de llaves previamente
Instalar una llave en el dispositivo en el proceso de fábrica. Típicamente, la llave se
almacena dentro del entorno seguro del dispositivo.
Opcionalmente, dependiendo del caso, deberá suministrar también la misma llave a los
proveedores de servicios. Para ello, se usan servidores de back-office que interactúan con
bases de datos de seguridad de los fabricantes. Este caso suele ser en el que los
proveedores de servicios compran directamente los dispositivos al fabricante.
Por otro lado, es muy común el escenario donde el cliente compra el dispositivo por aparte sin
tener ninguna relación comercial con la operadora o el fabricante. Para este caso, el fabricante
puede no tener una relación con ningún participante en el contexto M2M por lo que, en efecto,
simplemente hacen y venden dispositivos M2M para el público. Debido a la ausencia de relaciones
de confianza por parte del fabricante del dispositivo, se debe tener cierta prevención y por lo
general no se pueden utilizar las llaves permanentes del fabricante para establecer sesiones de
servicio de la capa de seguridad. Sin embargo, tales llaves pre-aprovisionadas se pueden utilizar
para dos propósitos: para la autenticación mutua inicial entre el dispositivo y el proveedor de
servicio o el dispositivo y el proveedor de la aplicación, y para uso en un procedimiento seguro, que
genera una nueva llave compartida permanente, que no se debe obtener de forma implícita o
explícita de las entidades no confiables, como el fabricante en este caso.
5.5 Protocolo para el Bootstrap basado en encriptación de identidad
En la Sección 5.2, discutimos los retos que se introducen por la adopción de soluciones PKI en el contexto M2M. Los protocolos de encriptación basados en la identidad o “Identity Based Encyption” (IBE) se han propuesto como métodos alternativos a los protocolos de llave pública, que requieren
de la existencia de un sistema PKI.
La idea base detrás del IBE, reside en que la llave pública de un dispositivo de usuario sea una
función matemática de la identidad que se asocia con esta llave. Por lo tanto, no hay necesidad del
uso de certificados para identificar un ente, dado que la llave pública se deriva intrínsecamente de
la identidad, usando un algoritmo conocido. Tenga en cuenta que con la IBE, los mensajes se
cifran con la llave pública del destinatario IBE. Esta última es la única entidad que puede descifrar
estos mensajes, utilizando la llave privada conocida solo por él (el destinatario). Dicha clave
privada es emitida por una función de generación de llaves IBE (IBE Key Generation Function o “KGF”), a través del uso de un secreto de dominio y funciones criptográficas conocidas públicamente. El único material criptográfico que se requiere por el remitente del mensaje para
cifrar un mensaje, es un conjunto de parámetros criptográficos conocidos públicamente que se