Machine type communication

Texto completo

(1)MACHINE TYPE COMMUNICATION. NATALIA PARRADO CEPEDA. 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 11 DE NOVIEMBRE DE 2012. Machine Type Communication. 1 de89.

(2) CONTENIDO Índice De Figuras ........................................................................................................................ 4 Resumen ..................................................................................................................................... 6 1 Introducción .............................................................................................................................. 7 2 Descripción general .................................................................................................................. 8 2.1 Objetivos ..................................................................................................................... 8 2.1.1 Objetivo General ......................................................................................... 8 2.1.2 Objetivos específicos .................................................................................. 8 2.3 Contexto ..................................................................................................................... 8 2.4 Identificación e importancia del problema a resolver ................................................. 9 3 Especificación de la solución ................................................................................................... 11 3.1 Terminología usada .................................................................................................. 11 3.2 Introducción MTC ..................................................................................................... 12 3.3 Arquitectura MTC ..................................................................................................... 13 3.3.1 Overview Arquitectura MTC ..................................................................... 13 3.3.2 Arquitectura global de MTC ...................................................................... 14 3.3.3 Arquitectura Funcional de MTC ................................................................ 17 3.4 Procedimientos en MTC ........................................................................................... 26 3.4.1 Network Bootstrap .................................................................................... 26 3.4.2 Registro de red ......................................................................................... 26 3.4.3 Servicio de Bootstrap M2M ...................................................................... 27 3.4.4 Servicio de conexión M2M ....................................................................... 27 3.4.5 Registro de los SCL de dispositivo y Gateway con el SCL del dominio de red (D/GSCL con NSCL) ................................................................. 27 3.4.6 Registro de aplicaciones........................................................................... 27 3.4.7 Review ...................................................................................................... 28 3.5 Identificación M2M en MTC ...................................................................................... 28 3.5.1 Identificadores M2M ................................................................................. 28 3.6 Direccionamiento M2M en MTC ............................................................................... 30 3.6.1 Punto de contacto M2M (PoC) ................................................................. 31. Machine Type Communication. 2 de89.

(3) 3.6.2 Localización de Aplicaciones .................................................................... 31 3.6.3 Uso del PoC M2M por el sistema ............................................................. 32 3.7 Seguridad M2M con MTC......................................................................................... 33 3.7.1 Jerarquía de llaves ................................................................................... 33 3.7.2 Detalle capacidad de servicio para seguridad (SEC) ............................... 36 3.7.3 Seguridad sobre la interfaz mId ................................................................ 38 3.8 Bootstrapping M2M con MTC ................................................................................... 39 3.8.1 Bootstrapping asistido por la Red de Acceso ........................................... 39 3.8.2 Bootstrapping independiente de la Red de Acceso ................................. 43 3.9 Servicio de conexión M2M con MTC ........................................................................ 49 3.9.1 Servicio de Conexión basado en EAP/PANA. .......................................... 50 3.9.2 Servicio de conexión M2M basado en TLS. ............................................. 51 4 Implementación de la solución ................................................................................................. 56 4.1 Escenarios de aplicación M2M ................................................................................. 56 4.2 Descripción plataforma MTC .................................................................................... 57 4.2.1 Overview Arquitectura OpenMTC ............................................................. 57 4.2.2 Funcionalidad OpenMTC .......................................................................... 58 4.2.3 Demos OpenMTC: Smart Home .............................................................. 71 5 Alternativas en el mercado ....................................................................................................... 77 5.1 Koneki ....................................................................................................................... 77 5.1.1 Generalidades y características. .............................................................. 78 5.2 OpenGate ................................................................................................................. 80 5.2.1 Generalidades y características. .............................................................. 80 5.2.2 Middleware OpenGate para comunicación M2M ..................................... 82 5.2.3 Aplicación de OpenGate en la industria ................................................... 83 6 Discusión .................................................................................................................................. 86 6.1 Conclusiones ............................................................................................................ 86 6.2 Trabajo futuro ........................................................................................................... 86 7 Referencias .............................................................................................................................. 88. Machine Type Communication. 3 de89.

(4) ÍNDICE DE FIGURAS Figura 1. Capas de servicio en MTC ................................................................................................. 14 Figura 2. Arquitectura de alto nivel de MTC, tomado de [2] ............................................................. 15 Figura 3. Puntos de referencia en MTC, tomado de [2] .................................................................... 19 Figura 4. Service Capabilities y su interacción con los puntos de referencia, tomado de [2] ........... 21 Figura 5. OMA Device-Manager........................................................................................................ 23 Figura 6. TR-069 ............................................................................................................................... 24 Figura 7. Procedimientos en MTC, tomado de [2] ............................................................................ 26 Figura 8. Elementos framewwork de seguridad MTC, tomado de [2] ............................................... 33 Figura 9. Jerarquía de llaves en MTC, tomado de [2] ....................................................................... 34 Figura 10. Bootstrapping GBA basado credenciales de la red de Acceso, tomado de [2] ............... 40 Figura 11. Bootstrapping EAP basado en credenciales de la red de acceso, tomado de [2] ........... 42 Figura 12. Bootstrapping EAP/PANA independiente de la Red de acceso, tomado de [2] .............. 45 Figura 13. Bootstrapping TLS/TCP independiente de la red de acceso, tomado de [2]................... 48 Figura 14. Conexión M2M basado en EAP ....................................................................................... 50 Figura 15. Flujo de llamadas para el Servicio de Conexión M2M basado en TLS-PSK cuando se usa seguridad mId del objeto o seguridad del canal, tomado de [2]................................................. 53 Figura 16. Flujo de llamadas para el Servicio de Conexión M2M basado en TLS-PSK cuando se usa seguridad mId de la Red de Acceso, tomado de [2] .................................................................. 54. Machine Type Communication. 4 de89.

(5) Figura 17. Servicio de conexión basado en GBA, tomado de [2] ..................................................... 55 Figura 18. OpenMTC, tomado de [1]................................................................................................. 57 Figura 19. Arquitectura de la OpenMTC, tomado de [1] ................................................................... 58 Figura 20. Service Capabilities ofrecidos en OpenMTC, tomado de [1] ........................................... 59 Figura 21. Capacidad GC en OpenMTC tomado de [1] .................................................................... 60 Figura 22. Comunicación c-s síncrona, tomado de [1]...................................................................... 61 Figura 23. Comunicación cliente-servidor semi asíncrona, tomado de [1] ....................................... 62 Figura 24. Comunicación cliente-servidor asíncrona, tomado de [1] ................................................ 63 Figura 25. AE en OpenMTC tomado de [1] ....................................................................................... 65 Figura 26. Uso de la capacidad GRAR en OpenMTC, tomado de [1] .............................................. 66 Figura 27. Elementos arquitecturales IMS M2M, tomados de [1] ..................................................... 69 Figura 28. Flujo de mensajes SIP arquitectura IMS M2M, tomado de [1] ........................................ 71 Figura 29. Elementos demo Smart Home, tomado de [1] ................................................................. 72 Figura 30. Comunicación en Smart Home de la OpenMTC ............................................................. 74 Figura 31. Aplicación Monster mostrando parámetros y acciones disponibles para dispositivos .... 75 Figura 32. Actividades de desarrollo con Koneki, tomado de [11]. ................................................... 78 Figura 33. Ambiente de desarrollo de Koneki, tomado de [12]. ........................................................ 78 Figura 34. APIs OpenGate, tomado de [14] ...................................................................................... 83. Machine Type Communication. 5 de89.

(6) RESUMEN Este documento el reporte de proyecto de grado desarrollado en el área de Next Generations Networks (NGN) donde se explora la especificación de una nueva plataforma para comunicación máquina. a. máquina. (M2M). realizada. por. el. Instituto. Europeo. de. Estándares. de. Telecomunicaciones (European Telecommunications Standards Institute - ETSI), llamada Machine Type Communication (MTC). La motivación de este trabajo es establecer cuáles son sus principales características y cuál es su potencial con respecto a otras propuestas en tecnología existentes en la actualidad. Adicionalmente, se explora una implementación para la plataforma MTC desarrollada por el grupo FOKUS de Fraunhofer y la Universidad Técnica de Berlín.. Machine Type Communication. 6 de89.

(7) 1 INTRODUCCIÓN La comunicación machine-to-machine surge como una necesidad de que los dispositivos que son usados diariamente por las personas, tengan la capacidad de intercambiar información relacionada a su estado con otros dispositivos o con una entidad que les dicte qué hacer en una situación específica, permitiendo tener un mayor control sobre cómo se comporta el ambiente físico. Las capacidades de estos dispositivos son cada vez mayores y han evolucionado por ejemplo de sensores simples a cámaras de alta definición, lo que implica un aumento en los requerimientos de comunicación entre dispositivos, pasando de alarmas a transmisión de video de alta definición en tiempo real. Por lo anterior, es necesario desarrollar un sistema que les permita a máquinas comunicarse entre sí, de una manera eficiente dependiendo de sus capacidades y que soporte una gran cantidad de dispositivos conectados a la vez. Para el desarrollo de este proyecto se tomó como referencia el estándar de la plataforma MTC para comunicación M2M desarrollado por la ETSI [1] y se recolectó la información más relevante para describirla en términos de funcionalidad, entidades involucradas e interacción entre estas. Adicionalmente, se investigó la plataforma OpenMTC desarrollada por el grupo FOKUS de Fraunhofer y La Universidad Técnica de Berlín, para su comparación con lo definido en el estándar. Finalmente, se exploraron otras herramientas para comunicación M2M en el mercado y los servicios que ofrecían. La estructura de este documento es la siguiente: primero se presentan los objetivos, el contexto y el problema identificado en la sección de Descripción general. Seguido, en la sección de Especificación de la solución, se presenta un glosario para un mayor entendimiento del documento, se introduce la plataforma, se define su arquitectura explicando las entidades involucradas y sus funciones, se describen los procedimientos que realiza y se profundiza en cómo son realizados. A continuación se habla de los escenarios de aplicación para la plataforma y se especifica la implementación de la plataforma OpenMTC en la parte de Implementación de la solución. Luego, se describen algunas herramientas existentes en el mercado para el desarrollo de soluciones M2M en la sección de Alternativas en el mercado. El documento finaliza con la discusión de las conclusiones y el trabajo futuro del proyecto en la sección de Discusión. Agradezco al profesor Yezid Enrique Donoso Meisel y al estudiante doctoral Carlos Andrés Lozano Garzón por su asesoría y colaboración durante el desarrollo de este proyecto de grado.. Machine Type Communication. 7 de89.

(8) 2 DESCRIPCIÓN GENERAL 2.1 OBJETIVOS 2.1.1 Objetivo General El objetivo de este proyecto es generar un marco de referencia para el diseño de soluciones M2M, identificando su funcionalidad, principales requerimientos, actores involucrados y la forma en que estos interactúan entre sí. Adicionalmente, se pretende explorar la plataforma OpenMTC,. y. comparar su funcionalidad y arquitectura, con las definidas para comunicación M2M. 2.1.2 Objetivos específicos •. Definir la problemática que trata de abordar MTC como plataforma.. •. Definir la funcionalidad de MTC como plataforma genérica para comunicación M2M y los servicios que brinda como plataforma de convergencia.. •. Identificar la visión global de la arquitectura de MTC y entidades involucradas, así como su funcionamiento y capacidades.. •. Describir la forma en que se comunican las entidades involucradas en una propuesta MTC.. •. Establecer la relación existente con otras plataformas de comunicación como EPC e IMS.. •. Identificar y describir escenarios concretos de aplicación.. 2.3 CONTEXTO Desde siempre, el desarrollo de nuevas tecnologías pretende facilitar de alguna forma las labores que realiza una persona, ya sea en su hogar o dentro de una empresa, con el fin de responder a requerimientos de eficiencia cada vez mayores. Particularmente, las tecnologías de información. Machine Type Communication. 8 de89.

(9) han evolucionado de tal forma que las tareas que se tienen que realizar son cada vez más sencillas, requieren menos tiempo e incluso se pueden llegar a automatizar, por lo que se requiere una menor intervención por parte de las personas. Así, el impacto que tienen las tecnologías de información en la sociedad es cada vez más alto y son cada vez más las propuestas que buscan lograr un beneficio particular en algún sector específico del mercado. Sin embargo, tareas relacionadas a controlar el medio físico que nos rodea, representan una mayor dificultad y están limitadas por varios factores, por ejemplo, una persona que no se encuentre en su casa no puede controlar qué electrodomésticos consumen energía a menos de que pueda prenderlos o apagarlos directamente, o un técnico en un edificio no podrá saber que el aire acondicionado se ha dañado a menos de que alguien más se lo informe. Por esta razón, han surgido propuestas como Ciudades Inteligentes (Smart Cities), cuyo objetivo es dotar a máquinas usadas en la industria y en la vida cotidiana, con dispositivos y sensores que controlan cualquier tipo de parámetro para poder actuar con mayor rapidez bajo una condición específica. De la misma forma, nace el concepto de El Internet de Las Cosas (Internet of Things IoT), una tecnología que permite conectar sensores y actuadores a internet, de tal forma que el mundo físico pueda accederse a través de software. Estas nuevas propuestas en tecnología introducen el desarrollo de aplicaciones que soportan nuevos procesos de negocio, en los que los objetos o dispositivos son integrados a la red de información para convertirse en componentes activos de una organización. Por ejemplo, los datos resultantes de la medición de las condiciones ambientales de un edificio, pueden ser combinados para brindar un control eficaz y automático de los sistemas de calefacción con valores medidos en tiempo real. La tecnología posibilitadora para las nuevas propuestas en tecnología como Ciudades Inteligentes y El Internet de Las Cosas, es la comunicación máquina a máquina (machine-to-machine - M2M). La comunicación M2M, es un paradigma en el que máquinas/dispositivos interactúan entre sí o con otros sistemas finales de forma autónoma e independiente de la interacción humana. Permite de manera general, automatizar la recolección de datos, control remoto, diagnóstico, mantenimiento, seguimiento de estados, entre otros procesos, gracias a la interacción que hay entre dispositivos y sistemas de otro tipo.. 2.4 IDENTIFICACIÓN E IMPORTANCIA DEL PROBLEMA A RESOLVER. Machine Type Communication. 9 de89.

(10) En el panorama actual, las soluciones M2M que existen se basan en infraestructuras monolíticas que no interoperan con otras plataformas y que no llegan a cumplir con las necesidades y características específicas de escenarios de comunicación M2M a gran escala. Por esta razón surge la necesidad de desarrollar una plataforma genérica para M2M que actúe como mediador entre dispositivos conectados y plataformas de servicios, y que soporte una gran cantidad de conexiones con diferentes requerimientos de QoS. De la misma forma, esta plataforma debe tener en cuenta la escalabilidad, cobertura, eficiencia en energía, eficiencia en el espectro, eficiencia en costo, heterogeneidad, cooperación, movilidad y seguridad.. Machine Type Communication. 10 de89.

(11) 3 ESPECIFICACIÓN DE LA SOLUCIÓN En esta sección se presenta la documentación de la plataforma MTC que se basa en el estándar definido por la ETSI. Inicia con la terminología usada y a continuación, se desarrolla teóricamente cómo es la arquitectura, cuáles son los procedimientos, se especifican la identificación y direccionamiento para componentes M2M, las características de seguridad de la plataforma, el servicio para Bootstrap y el servicio de conexión.. 3.1 TERMINOLOGÍA USADA Esta sección define qué significan las siglas usadas en este documento. SCL: Capa de Servicio (Service Capability Layer) en la arquitectura de MTC. NSCL, GSCL o DSCL: Respectivamente, una capa de servicio de red (Network Service Capability Layer), Gateway (Gateway Service Capability Layer), o dispositivo (Device Service Capability Layer). SC: Capacidad de Servicio (Service Capability), funcionalidad prestada por una capa de servicio. D/G: Indica que se está hablando de un componente del dispositivo (D). o Gateway (G). indistintamente. D/GSC: Indica que se está hablando de un Service Capability del dispositivo (D) o Gateway (G) indistintamente. NA, GA o DA: Se refiere respectivamente a una aplicación de red (Network Application) de Gateway (Gateway Application) o de dispositivo (Device Application). D’: Se refiere a un dispositivo que no implementa capacidades de servicio M2M. Kmr, Kmc, Kma: Son las llaves usadas para los procedimientos de seguridad y respectivamente se refiere a la llave raíz M2M, llave de conexión M2M y llave de aplicación M2M.. Machine Type Communication. 11 de89.

(12) 3.2 INTRODUCCIÓN MTC MTC es la plataforma pensada para comunicación M2M; su objetivo principal es aprovechar las redes móviles de próxima generación para que dispositivos (sensores y actuadores), puedan comunicarse ya sea con un servidor o entre máquinas. Sirve como una capa de convergencia horizontal para lenguaje M2M que soporta múltiples dominios verticales de aplicación: industria, cuidado médico, logística, transporte, seguridad, entre otras cosas. Hay 3 elementos generales en la comunicación M2M que se pretenden soportar en MTC: Una terminal que envía información: Es el dispositivo que transmite información y actúa de forma automática. •. Puede actuar por petición remota.. •. Puede ser móvil o fijo.. •. Es gestionado remotamente.. •. Tiene un dispositivo de monitoreo del medio físico como un sensor.. La red para facilitar la comunicación M2M: Es la red que posibilita el intercambio de mensajes entre los sistemas finales. •. Incluye la red de acceso y la red core.. •. Permite conectividad, por lo que maneja AAA 1 y seguridad, gestión de sesión, QoS 2, facturación y gestión de movilidad.. •. Soporta el tráfico de datos de las terminales.. •. Soporta la señalización de las terminales.. 1 Authentication, authorization, and accounting 2 Calidad de Servicio (Quality of Service).. Machine Type Communication. 12 de89.

(13) Red core u otra terminal que automatiza los servicios: Es el sistema que se encarga de procesar la información de una terminal. •. Puede agregar dispositivos.. •. Toma decisiones automáticas mediante el procesamiento y control de la información que recibe de los dispositivos.. •. Responde a información recibida mediante comunicación con otras máquinas a través de notificaciones e instrucciones.. •. Responde a comunicación en tiempo real.. Entre las ventajas de MTC en comparación con escenarios actuales de comunicación M2M están: •. MTC permite un gran número de aplicaciones potenciales en diferentes dominios por lo que impacta diferentes ambientes y mercados.. •. Conecta un gran número de dispositivos a internet, formando el Internet de Las Cosas.. •. Mientras algunas implementaciones usan tecnologías de radio de corto alcance, las soluciones MTC basadas en tecnologías de acceso móvil ofrecen mayor facilidad en la implementación, mayor escalabilidad y mayor eficencia en la comunicación.. •. Las soluciones MTC son más adecuadas para soportar servicios que requieren entrega inmediata y confiable de datos a servidores M2M que están distantes.. 3.3 ARQUITECTURA MTC En esta sección se define de manera general la arquitectura de la plataforma MTC, incluyendo sus entidades, función e interacción entre estas.. 3.3.1 Overview Arquitectura MTC. Machine Type Communication. 13 de89.

(14) Todos los elementos arquitecturales y servicios ofrecidos por MTC giran en torno a la definición de tres Service Capability Layers o capas de servicio, las cuáles se tratan como una entidad concreta o un nodo en el dominio correspondiente (dominio de red, Gateway o dispositivo), y agrupan las funcionalidades que pueden realizarse. Estas capas de servicio son: •. Capa de Servicio de Red (Network Service Capability Layer - NSCL).. •. Capa de Servicio de Gateway (Gateway Service Capability Layer - GSCL).. •. Capa de Servicio de Dispositivo (Device Service Capability Layer - DSCL).. Figura 1. Capas de servicio en MTC. 3.3.2 Arquitectura global de MTC En esta sección se abordan los elementos que hacen parte de la arquitectura de MTC definida por la ETSI desde una perspectiva de alto nivel. Es este caso, como se muestra en la Figura 2 se diferencian dos dominios principales: El dominio de Dispositivo y Gateway M2M y el dominio de red. A continuación se definen los elementos arquitecturales para cada dominio.. Machine Type Communication. 14 de89.

(15) Figura 2. Arquitectura de alto nivel de MTC, tomado de [1]. 3.3.2.1 Dominio de Red El dominio de red tiene los siguientes elementos: la red de acceso, la red core, los Service Capabilities M2M y las aplicaciones M2M. Red de Acceso La red de acceso es la red usada para dar conectividad entre la red core y el dominio de Dispositivo o Gateway. Como ejemplo de las posibles tecnologías a utilizar están xDSL, satélite, UTRAN, eUTRAN, WiMAX, entre otras. Red Core La red core es la red del operador y provee conectividad IP, funciones de control de servicios y de red, interconexión con otras redes y Roaming. M2M Service Capabilities. Machine Type Communication. 15 de89.

(16) Los Service Capabilitities (SCs) o capacidades de servicio, son un agrupamiento lógico de funciones M2M que comparten varias aplicaciones. Estas funciones son expuestas a las aplicaciones a través de un conjunto de interfaces o puntos de referencia (ver punto 3.3.1 Overview Arquitectura MTC), lo que simplifica y optimiza el desarrollo y despliegue de aplicaciones al ocultar características y propiedades de la red. Aplicaciones M2M Son aplicaciones que ejecutan la lógica de los servicios y utilizan los Service Capabilities disponibles a través de una interfaz pública. En este caso, las aplicaciones que residen en el dominio de red son llamadas Network Appplications (NAs).. Funciones de gestión M2M Son todas las funciones requeridas para gestionar los SCs M2M en el dominio de red. Entre estas funciones, se incluye una función para Bootstrap 3 del servicio M2M llamada MSBF que se realiza dentro de un servidor apropiado y cuyo rol es facilitar la inicialización de credenciales de seguridad de capa de servicio para un dispositivo o Gateway M2M y los Services Capabilities en el dominio de red. Funciones de gestión de red Se refiere a todas las funciones requeridas para manejar las redes de acceso y de core, e incluyen el aprovisionamiento, control, gestión de fallas entre otras.. 3.3.2.2 Dominio de Dispositivo y Gateway En el dominio de dispositivo y Gateway se tiene el dispositivo M2M, la red local para comunicación M2M y el Gateway M2M. Dispositivo M2M Es un elemento que puede ejecutar aplicaciones M2M usando Service Capabilities M2M y generalmente puede tratarse de una terminal que posee sensores y actuadores, de manera que puede transmitir información sobre su estado y recibir instrucciones de qué acciones debe realizar.. 3 Se refiere al “arranque” que carga las configuraciones iniciales de un componente.. Machine Type Communication. 16 de89.

(17) Con este propósivo, es necesario que se comunique con otros dispositivos a través de la red local, o con un servidor u otra entidad a través del dominio de red. Cuando el dispositivo implementa capacidades de servicio M2M, se conoce como dispositivo D, de lo contrario se conoce como dispositivo D'. Adicionalmente, hay dos maneras en las que un dispositivo puede conectarse al dominio de red: •. Directamente.. La conexión es directa a través de la red de acceso y en este caso, el dispositivo realiza procedimientos como registro, autenticación, autorización, gestión y aprovisionamiento con el dominio de red, por lo que tiene que ser un dispositivo D. Por lo anterior, el dispositivo es capaz de proveer servicio a otros dispositivos conectados con él que están ocultos del dominio de red. •. Usando un Gateway como proxy. El dispositivo se conecta al dominio de red a través de un Gateway M2M. En este caso el Gateway actúa como un proxy del dominio de red hacia los dispositivos conectados, de esta forma, los procedimientos de autenticación, autorización, gestión y aprovisionamiento con el dominio de red son re direccionados por el Gateway M2M. Los dispositivos M2M se pueden conectar al dominio de red por medio de varios Gateways M2M.. Gateway M2M Es un elemento que como los dispositivos M2M, ejecuta aplicaciones M2M usando capacidades de servicio M2M y que actúa como un proxy entre el Dominio de Red y un dispositivo M2M. Red de Área M2M Es la red que provee conectividad entre dispositivos M2M y Gateways M2M. Algunos ejemplos incluyen redes de área personal como IEEE 802.15.1, Zigbee, Bluetooth, IETF ROLL, ISA100.11a, entre otras, o redes locales como PLC, M-BUS, Wireless M-BUS y KNX.. 3.3.3 Arquitectura Funcional de MTC. Machine Type Communication. 17 de89.

(18) En este punto se describen los elementos funcionales para la arquitectura MTC. Se especifican principalmente, los puntos de referencia o interfaces que exponen los servicios y los Service Capabilities ofrecidos en cada capa de servicio.. 3.3.3.1 PUNTOS DE REFERENCIA Los puntos de referencia corresponden a interfaces para la interacción de aplicaciones con los Service Capability Layers y de SCs entre sí. En general, soportan los siguientes procedimientos: •. Registro de un DSCL o un GSCL con el NSCL y de una aplicación con su respectivo SCL.. •. Peticiones para lectura o escritura de información en el NSCL, GSCL o DSCL.. •. Peticiones para realizar acciones de gestión sobre el dispositivo.. •. Subscripción y notificación de eventos.. •. Peticiones para la creación de listas o grupos de dispositivos y Gateways.. En los puntos continuación se detallan los diferentes puntos de referencia soportados por la plataforma MTC.. Machine Type Communication. 18 de89.

(19) Figura 3. Puntos de referencia en MTC, tomado de [1]. mId Es una interfaz que ofrece un mecanismo genérico para que los diferentes SCLs puedan interactuar entre sí y entre los procedimientos que soporta están el registro de un GSCL o DSCL con el NSCL y la comunicación entre los SCs en el dispositivo o Gateway M2M y los SCs en el dominio de red, para lo que usa funciones de la red core. mIa La interfaz mIa ofrece un mecanismo genérico para interacción de aplicaciones de red (NAs) con el NSCL y permite a una NA registrarse con el NSCL y acceder a los SCs de ese NSCL. dIa La interfaz dIa ofrece un mecanismo genérico para que las aplicaciones de dispositivo/Gateway (DAs/GAs) puedan interactuar con el DSCL/GSCL y entre los procedimientos que soporta están: el registro de una DA con el DSCL o GSCL dependiendo de si reside en un dispositivo D o D'; el registro de una GA con el GSCL; el acceso de una DA en un dispositivo a los SCs dentro del. Machine Type Communication. 19 de89.

(20) mismo dispositivo o dentro de un Gateway M2M dependiendo de si reside en un dispositivo D o D'; el acceso de una GA a los SCs dentro del Gateway M2M.. 3.3.3.2 Service Capabilities Son las capacidades de servicio que ofrecen las diferentes capas de servicio o SCLs. Estas funciones son expuestas a aplicaciones u otras SCLs a través de los puntos de referencia mId, mIa y dIa. Generalmente, los SCs son instanciados en el dispositivo, Gateway y red, pero en algunos casos, un SC puede ser instanciado por sólo uno de ellos, por lo que no siempre están en las diferentes partes del sistema. Adicionalmente, no es mandatorio según el estándar de la ETSI [1], la implementación de los SCs como entidades aparte. En el estándar se definen 11 SCs: 1. Application Enablement (xAE). 2. Generic Communication (xGC). 3. Reachability, Addressing and Repository (xRAR). 4. Remote Entity Management (xREM). 5. Interworking Proxy (xIP). 6. Communication Selection (xCS). 7. SECurity (xSEC). 8. History and Data Retention (xHDR). 9. Transaction Management (xTM). 10. Compensation Broker (xCB). 11. Telco Operator Exposure (xTOE).. Machine Type Communication. 20 de89.

(21) Figura 4. Service Capabilities y su interacción con los puntos de referencia, tomado de [1]. A continuación, se detalla la funcionalidad de cada Service Capability. APPLICATION ENABLEMENT (AE) Es el punto de contacto para que las aplicaciones M2M puedan acceder a funcionalidades implementadas en las SCLs. Sus funciones son las siguientes: •. Expone funcionalidades de los SCL a través de las interfaces mIa y dIa.. •. Soporta el registro de una aplicación en el SCL correspondiente.. •. Enruta peticiones de la aplicación a los SCs correspondientes.. •. Enruta peticiones a otras aplicaciones que estén dentro del mismo SCL a través del área de red.. GENERIC COMMUNICATION (GC) Es el punto de contacto para comunicación entre SCLs y sus funciones son las siguientes: •. Redirecciona mensajes entre SCLs.. Machine Type Communication. 21 de89.

(22) •. Establece la sesión de transporte y negocia una llave en caso de que se requiera una sesión segura.. •. Provee integridad/confidencialidad en los datos intercambiados con dispositivos y Gateways M2M.. REACHABILITY, ADDRESSING AND REPOSITORY (RAR) Es quien se encarga de almacenar la información de las aplicaciones y los SCLs y tiene las siguientes funciones: •. Permite que los datos de aplicaciones y SCLs estén disponibles, ya sea a petición, por subscripciones, o de acuerdo a permisos.. •. Permite crear, borrar y listar un grupo de dispositivos o Gateways M2M.. •. Almacena información relacionada al registro de aplicaciones con sus SCLs respectivos.. •. Maneja suscripciones y notificaciones de eventos.. •. Mapea el nombre de un dispositivo o Gateway M2M (o grupo de los mismos), con la siguiente información: o. Conjunto de direcciones enrutables.. o. Accesibilidad a un dispositivo o Gateway M2M.. REMOTE ENTITY MANAGEMENT (REM) Se encarga de proveer Configuration Management (CM), Performance Management (PM) y Fault Management (FM). Tiene las siguientes funciones: •. CM: Brinda un conjunto de objetos de gestión (management objects) para un dispositivo/Gateway o grupo de estos.. •. Recoge y almacena datos con respecto al PM y FM.. •. Gestiona el ciclo de vida de las aplicaciones M2M.. Machine Type Communication. 22 de89.

(23) •. Funciona como un dispositivo de gestión remota de dispositivos y Gateways.. •. Realiza la actualización del software o firmware en dispositivos y Gateways M2M.. •. Gestiona la red de área M2M.. Adicionalmente, el modelo para la funcionalidad REM debe estar acorde con alguno de los estándares para control remoto de dispositivos, OMA Device Manager [4], o TR – 06 [5]. OMA Device Manager Es un protocolo para gestión de dispositivos desarrollado por Open Mobile Alliance. De manera general, un servidor maneja los dispositivos y un cliente representa el dispositivo manejado. Adicionalmente, usa XML para intercambio de datos y la comunicación que usa el mecanismo request-response, es iniciada por el servidor de forma asíncrona. En la Figura 5 se muestra el protocolo OMA-DM.. Figura 5. OMA Device-Manager, tomado de [15]. TR – 069 Es un estándar desarrollado por el Broadband Forum que define una capa de aplicación para control remoto de dispositivos y fue pensado para una configuración y mantenimiento automático. Machine Type Communication. 23 de89.

(24) de estos. Se basa en SOA/HTTP y provee comunicación entre dos elementos principales: el customer-premises equipment (CPE) y el Auto Configuration Server (ACS). En la Figura 6 se muestra TR-069:. Figura 6. TR-069, tomado de [16]. INTERWORKING PROXY (IP) Esta es la funcionalidad que provee interoperabilidad entre los diferentes SCLs y dispositivos o Gateways que no son del estándar. TELCO OPERATOR EXPOSURE (TOE) Esta funcionalidad sólo se encuentra en la NSCL y permite el uso de los servicios de la red core que están expuestos por el operador. COMMUNICATION SELECTION (CS) Esta funcionalidad provee selección de red basado en políticas cuando elemento puede alcanzarse a través de varias redes o bearers. Sus funciones son las siguientes: •. Provee una red o servicio de comunicación alternativo cuando se presentan fallas en la conexión mediante otra red o servicio de comunicación primario.. •. El NCS realiza esta función cuando se desea acceder a dispositivos y Gateways desde el NSCL.. •. El GCS y DCS realiza esta función cuando se desea acceder al NSCL desde el GSCL o DSCL.. SECURITY (SEC). Machine Type Communication. 24 de89.

(25) Esta funcionalidad provee autenticación mutua y acuerdo de llaves cuando la comunicación entre dispositivos, Gateways y el dominio de red tiene que ser segura. Tiene las siguientes funciones: •. En el caso del NSEC, puede verificar el status de validación de integridad reportado por un dispositivo o Gateway M2M.. •. En el caso de los dispositivos y Gateways, reportan el status de validación de integridad al NSC.. Esta funcionalidad es explicada en detalle en el punto 3.7.2 Detalle capacidad de servicio para seguridad (SEC). HISTORY AND DATA RETENTION (HDR) Esta funcionalidad almacena información sobre el intercambio de información en los puntos de referencia e internamente en el SCL correspondiente. Sus funciones son: •. Interactúar con otros SCs en el mismo SCL para determinar qué información será guardada y cómo obtenerla de estos.. •. En el caso del GHDR y DHDR, estos reportan datos históricos al NHDR.. TRANSACTION MANAGEMENT (TM) Esta funcionalidad permite el manejo transaccional de operaciones que se realizan las entidades del sistema. Tiene las siguientes funciones: •. Maneja las solicitudes individuales de operaciones.. •. Realiza. commit. cuando. todas. las. operaciones. individuales. han. finalizado. satisfactoriamente, o roll-back si cualquiera falla. COMPENSATION BROKERAGE (CB) Involucra 3 roles: Cliente (cualquier aplicación que consume un servicio del proveedor), Proveedor (cualquier aplicación que provee un servicio) y Broker (implementado en este Capability). Un Broker representa un tercero de confianza que va a facturar clientes en función del consumo de servicios de un proveedor.. Machine Type Communication. 25 de89.

(26) 3.4 PROCEDIMIENTOS EN MTC Esta sección describe de manera general los procedimientos involucrados en la funcionalidad de MTC y el flujo de estos se especifican en la Figura 7:. Figura 7. Procedimientos en MTC, tomado de [1]. 3.4.1 Network Bootstrap Inicializa un dispositivo o Gateway M2M con los datos de configuración iniciales necesarios para conectarse y registrarse a la red de acceso (móvil o fija). El detalle de este procedimiento está fuera del alcance de este documento.. 3.4.2 Registro de red. Machine Type Communication. 26 de89.

(27) Involucra el registro del dispositivo o Gateway M2M con la red de acceso. Como ejemplo, durante el registro de red en redes 3GPP, el dispositivo o Gateway M2M se autentica con la red de acceso y los extremos acuerdan un conjunto de llaves para esa sesión. En adición, el registro incluye asignación de una dirección IP, autorización para usar ciertos servicios e inicialización de operaciones de facturación. El detalle de este procedimiento está fuera del alcance de este documento.. 3.4.3 Servicio de Bootstrap M2M Involucra el aprovisionamiento de credenciales de seguridad que serán usadas en los procesos de registro y conexión. Adicionalmente, provee una lista de identificadores que sirven como punto de contacto con los nodos y aplicaciones M2M. Este procedimiento se detalla en el punto 3.8 Bootstrapping M2M con MTC.. 3.4.4 Servicio de conexión M2M Este procedimiento realiza la conexión de un nodo M2M con el dominio de red e incluye las siguientes operaciones: •. Autenticación mutua de los extremos conectados por medio de la interfaz mId.. •. Acuerdo opcional de la llave de conexión M2M (Kmc).. •. Establecimiento opcional se una sesión segura sobre la interfaz mId usando comunicación encriptada.. Esta función está detallada en el punto 3.9 Servicio de conexión M2M con MTC.. 3.4.5 Registro de los SCL de dispositivo y Gateway con el SCL del dominio de red (D/GSCL con NSCL) El registro de un DSCL o GSCL con el NSCL se hace con el fin de poder usar los servicios M2M que ofrece el SCL en el dominio de red y como prerrequisito, se tiene que establecer una conexión entre el nodo de dispositivo o Gateway M2M y el nodo de Red.. 3.4.6 Registro de aplicaciones. Machine Type Communication. 27 de89.

(28) El registro de aplicaciones que se da entre una aplicación y su SCL local se hace con el fin de usar los SCs ofrecidos por los SCLs y como resultado, el SCL recibe un contexto de la aplicación. Adicionalmente, dos aplicaciones conectadas a un mismo SCL pueden comunicarse entre sí pero en el caso de dos aplicaciones en SCLs diferentes, tiene que haber una comunicación M2M entre esos SCLs para que estas aplicaciones se puedan comunicar.. 3.4.7 Review El registro de un SCL del dominio del dispositivo o Gateway con el SCL en el dominio de red, permite la comunicación entre estos nodos y la utilización de servicios expuestos por el dominio de red. El registro de una aplicación con su respectivo SCL, permite a la aplicación interactuar con el SCL y usar los servicios expuestos por los Service Capabilities en ese SCL, de esta forma, para que una DA/GA pueda interactuar con el DSCL/GSCL tiene que registrarse primero y lo mismo ocurre para un NA que quiere interactuar con el NSCL. El registro de aplicaciones de dispositivo y Gateway con sus respectivos SCLs, más el registro de los SCLs de dispositivo y Gateway con el NSCL, permite a una aplicación DA o GA interactuar con el NSCL a través del DSCL o GSCL.. 3.5 IDENTIFICACIÓN M2M EN MTC En esta sección se describen los identificadores M2M usados en diferentes procedimientos de comunicación M2M.. 3.5.1 Identificadores M2M La ETSI define los siguientes identificadores: 1. Identificador de Aplicación (App-ID) 2. Identificador de Nodo M2M 3. Identificador de Service Capability (SCL-ID). Machine Type Communication. 28 de89.

(29) 4. Identificación de Servicio de Conexión (M2M-Connection-ID) 5. Identificador de Proovedor de Servicio (M2M-SP-ID) 6. Identificador MSBF (MSBF-ID) 7. Identificador MAS (MAS-ID) Estos identificadores y las entidades a las cuales corresponden son explicados a continuación.. 3.5.1.1 Identificador de Aplicación (App-ID) Una aplicación M2M es aquella que utilizan los Service Capabilities expuestos en las SCLs y pueden ser aplicaciones de red (NA), de dispositivo (DA) o de Gateway. El App-ID identifica una aplicación (NA, GA, DA o D’A), registrada con el SCL con el propósito de interactuar con esa aplicación y cuando varias aplicaciones se conectan a un mismo SCL, cada una tiene un App-ID globalmente único.. 3.5.1.2 Identificador del M2M Service Bootstrap Function (MSBF-ID) El M2M Service Bootstrap Function (MSBF) es la función para hacer Bootstrap del servicio M2M. El rol del MSBF es facilitar el bootstrapping de credenciales permanentes de seguridad en el dispositivo o Gateway M2M y los SCs en el dominio de red. El MSFB-ID es un valor estático asignado al MSBF por el proveedor de servicio M2M, que lo identifica de forma única globalmente.. 3.5.1.3 Identificador del M2M Authentication Server (MAS-ID) Un M2M Authentication Server (MAS) puede ser un servidor AAA (autenticación, autorización y accounting), cuyo rol es ser una locación segura que almacena las credenciales de seguridad generadas por el MSBF. La función MSBF puede estar contenida dentro del MAS, o en otro caso, comunicar las credenciales de seguridad definidas a través de una interfaz apropiada (por ejemplo Diameter en el caso de que el MAS sea un servidor AAA). El MAS-ID es un valor estático asignado al MAS por el proveedor de servicio M2M, que lo identifica de forma única globalmente.. 3.5.1.4 Identificador del Proveedor de Servicio (M2M-SP-ID) El M2M-SP-ID es un valor estático que se asigna a un proveedor de servicio M2M.. Machine Type Communication. 29 de89.

(30) 3.5.1.5 Identificador del Nodo M2M (M2M-Node-ID) Un nodo M2M es una representación lógica de un componente en el dispositivo, Gateway o Red M2M ya sea un SCL, la función de Bootstrap M2M (si está), o el Servicio de Conexión M2M. El nodo M2M se instancia en el procedimiento de Bootstrap o es pre-provisionado por el proveedor de servicio. El M2M-Node-ID es asignado por el MSBF a un nodo M2M durante el Bootstrapping e identifica el nodo de manera global. Este identificador va a ser usado luego en el setup de la conexión M2M.. 3.5.1.6 Identificador del Service Capability Layer (SCL-ID) Una Service Capability Layer es una capa de servicio bien sea del dispositivo, Gateway o red, que contiene los Service Capabilities o funcionalidades que van a usar las aplicaciones M2M. El SCL-ID identifica un SCL de manera global y es asignado por el MSBF (durante el bootstrapping) a un NSCL, o es asignado por el NSCL (durante el registro), a un GSCL o DSCL. Este identificador es usado en los procedimientos de acceso a recursos. En la especificación, tanto el SCL-ID como el M2M-Node-ID tienen el mismo valor y el tiempo de vida de este identificador es el mismo que el del SCL correspondiente.. 3.5.1.7 Identificador de Servicio de Conexión (M2M-Connection-ID) El Servicio de Conexión M2M (Service Connection M2M), es la conexión entre un dispositivo o Gateway M2M y el NSCL. Se instancia en el DSCL o GSCL y es autenticado y autorizado por el NSCL. Se usa para facilitar que los SCLs y las aplicaciones en cada extremo se comuniquen entre sí y se basa en conectividad en la parte más baja de las capas física, de enlace y de red. El servicio puede “bajarse”, re-establecerse y refrescarse y de la misma forma, puede proveer su propia seguridad mediante TLS o IPSec. El M2M-Connection-ID es asignado por un nodo de red M2M o el MAS (dependiendo del procedimiento de conexión M2M), durante el procedimiento de conexión M2M e identifica un Servicio de conexión en un NSCL.. 3.6 DIRECCIONAMIENTO M2M EN MTC. Machine Type Communication. 30 de89.

(31) Esta sección describe cómo son direccionables las diferentes entidades en la comunicación M2M soportada por la plataforma MTC. En la comunicación M2M, el objetivo es alcanzar el SCL M2M con el que una aplicación M2M está registrada y finalmente, la aplicación de dispositivo o Gateway correcta en la que reside la aplicación objetivo. Tanto la accesibilidad como el enrutamiento hacia o desde aplicaciones DA, D’A y GA M2M, siempre están asociados con el SCL con el que esas aplicaciones están registradas y el cual reside en un Dispositivo o Gateway M2M conectado a la red de acceso. Un punto de contacto M2M (M2M PoC) provee el conjunto de información necesario para alcanzar un SCL desde una perspectiva de red, es decir que el PoC M2M contiene información que se puede resolver en una dirección de red. A continuación se describe cómo es la accesibilidad a una aplicación M2M mediante un Punto de Contacto (Point of Contact – PoC) M2M.. 3.6.1 Punto de contacto M2M (PoC) EL PoC M2M es usado por el sistema para comunicarse con un GSCL o DSCL. En cuanto la comunicación con el SCL se logra, cualquier aplicación registrada en el SCL puede ser accedida mediante su identificador. El PoC de un SCL se provee al sistema al momento de registro del SCL, de esta forma, para dispositivos D’, el M2M PoC se provee al registrarse el GSCL. Para dispositivos D, el M2M PoC se provee al registrarse el DSCL. La información que contiene el PoC depende de la red de acceso y las capacidades de transporte M2M del dispositivo.. 3.6.2 Localización de Aplicaciones Para localizar una aplicación M2M, sea una GA, DA o D’A se siguen dos pasos: 1. Primero se localiza el SCL con el que está registrada la aplicación, para esto: a. Para DAs asociadas con dispositivos D se usa el M2M PoC del DSCL. b. Para DAs asociadas con dispositivos D’ y GAs, se usa el M2M PoC del GSCL 2. El SCL localiza la aplicación usando el identificador con el que está registrada la aplicación.. Machine Type Communication. 31 de89.

(32) 3.6.3 Uso del PoC M2M por el sistema El PoC tiene la información usada por el sistema M2M para localizar información de enrutamiento relacionada con un SCL. Esta información la provee el SCL registrado al momento de registrarse. La información de enrutamiento relacionada con un SCL (y finalmente a la aplicación deseada), en un sistema M2M depende de las características de la red de acceso. En general la información de enrutamiento más sencilla relacionada con un SCL se logra cuando una IP pública es asignada a un dispositivo o gateway M2M puesto que es posible confiar en que un DNS resuelve la dirección sea directa o dinámicamente. En este caso el PoC M2M para un SCL registrado tiene una URI conforme a la sintaxis definida: •. URI = scheme:/fullyqualifieddomainname/path/; o. •. URI=scheme://ip-address/path/. 3.6.3.1 PoC M2M relacionado a SCLs asociados a una red fija En este caso, la URI del SCL registrado debe ser como se define anteriormente. Si la dirección IP es privada, la dirección se construye basándose en la IP del protocolo PPP relacionado, es decir, una IP pública que luego se mapea a la dirección IP privada correspondiente.. 3.6.3.2 PoC M2M relacionado a SCLs asociados a las redes móviles SI la IP registrada para el SCL no es confiable y por lo tanto no puede ser incluida en el PoC, se debe incluir en PoC del SCL información apropiada como lo definen las diferentes redes de acceso. Cada red de acceso deberá especificar los medios que le permiten a un Proveedor de Servicio (SP) M2M encontrar la dirección IP asociada con un SCL en esa red de acceso, y en consecuencia, especificar la información que debe incluirse en el PoC M2M para el SCL registrado. En el caso en el que un SP M2M tenga conexiones a múltiples redes de acceso, hay necesidad de establecer. un enlace entre el SCL que está registrado y la red de acceso. Eso se hace. directamente en el SCL listando explícitamente, la red de acceso al momento de registro o actualización, de otra forma el SP podrá derivarlo usando en enlace sobre el que ocurrió el registro.. Machine Type Communication. 32 de89.

(33) 3.7 SEGURIDAD M2M CON MTC Esta sección describe las funciones fundamentales de seguridad y la jerarquía de llaves que se usan con este fin. Los elementos arquitecturales y los puntos de referencia en el contexto del framework de seguridad se pueden observar en la Figura 8. Se pueden apreciar algunos SCs como el de seguridad (SEC), comunicación (GC) y Manejo remoto de entidades (REM).. Figura 8. Elementos framewwork de seguridad MTC, tomado de [1]. Los requerimientos para autenticación y acuerdo de llaves (key agreement), aprovisionamiento y procedimientos de conexión M2M, se basan en una clara definición de la jerarquía de las llaves del Nodo M2M, la cual es definida a continuación.. 3.7.1 Jerarquía de llaves La jerarquía de llaves M2M incluye 3 llaves: la llave Kmr o Llave Raíz M2M, la llave Kmc o Llave de Conexión M2M y la llave Kma o Llave de Aplicación M2M.. Machine Type Communication. 33 de89.

(34) Figura 9. Jerarquía de llaves en MTC, tomado de [1]. El ciclo de vida de la llave Kmr es mayor o igual al ciclo de vida de la llave Kmc, y de la misma forma, el ciclo de vida de la llave Kmc es mayor o igual al ciclo de vida de la llave Kma. La llave Kmr es inicializada en el Ambiente Seguro del nodo de dispositivo o Gateway y tiene el rol de permitir autenticación entre el nodo de dispositivo o Gateway M2M con el proveedor de servicio M2M. Luego se deriva la llave Kmc de la Kmr y tras la derivación, la llave Kmc es válida mientras el servicio de conexión del nodo de dispositivo o Gateway M2M es válido. Cada llave Kma es luego derivada de la Kmc y esta tiene validez mientras la llave Kmc de la que se derivó sea válida.. 3.7.1.1 Descripción de llaves usadas A continuación se detalla cada una de las llaves. Kmr – Llave raíz M2M o M2M Root Key Esta llave se usa para autenticación mutua entre el Nodo de dispositivo o Gateway M2M y el Proveedor de Servicio M2M, lo que quiere decir que el Nodo M2M lo usa para autenticar al Proveedor de Servicio, y el Proveedor de Servicio para autenticar el Nodo. También es usada para derivar una llave de conexión (M2M Connection Key - Kmc) a través de autenticación y key agreement entre un Nodo de dispositivo o Gateway M2M y un Nodo de Red M2M. La llave Kmr es emparejada con un único Nodo M2M y Proveedor de Servicio M2M a través del identificador M2M-Node-ID. En el caso Nodo de red M2M, la llave Kmr es almacenada en un Ambiente Seguro dentro del MAS y de esta forma está protegida de acceso o manipulación por. Machine Type Communication. 34 de89.

(35) entidades no autorizadas. Por otro lado, en el caso del nodo de dispositivo o Gateway M2M, la llave se almacena y usa dentro de un Dominio de Ambiente Seguro (Secured Environment Domain), controlado por el Proveedor de Servicio M2M. Adicionalmente, existe una sola llave Kmr por cada conjunto de credenciales para un Nodo de dispositivo o Gateway M2M. Kmc – Llave de conexión M2M o M2M Connection Key Esta llave se deriva de la llave Kmr tras una autenticación exitosa del nodo de dispositivo o Gateway M2M y se utiliza para auntenticar el nodo de dispositivo o Gateway M2M con el nodo de red M2M. Tras la derivación, esta llave es llevada del MAS (en el cual se deriva en un Ambiente Seguro de la misma forma que la llave Kmr), a la función NSEC, en la cual se almacena en el dominio de Ambiente Seguro del cual nunca sale. La llave Kmc expira al terminarse el servicio de conexión M2M y para cada procedimiento de conexión M2M de un nodo de dispositivo o Gateway con un nodo de red, hay una llave Kmc diferente sea que el nodo D/G se conecte al mismo nodo de red o a uno diferente. Kma – Llave de aplicación M2M o M2M Application Key Esta llave es opcional y se usa para establecer sesiones seguras de aplicación entre las capacidades de servicio NGC y DGC o NGC y GGC. La llave Kma se deriva de la llave Kmc y es compartida entre el nodo de dispositivo o Gateway y la función NGC. Se usa en autenticación y autorización de aplicaciones M2M en el dispositivo o Gateway M2M y para proteger el tráfico de los datos de la aplicación. Por ejemplo, si se usa HTTP como protocolo sobre la interfaz mId, y se usa TLS-PSK4 como método para establecer una sesión segura HTTP sobre mId con una aplicación, la llave Kma para esa asociación funciona como el PSK para TLS. Cualquier otra llave que es derivada de la Kma después de esa asociación de seguridad, se usa para asegurar el transporte de datos sobre la interfaz mId, por ejemplo, para facilitar operaciones de encripción y protección de integridad para los datos transferidos entre las capacidades NGC y DGC o NGC y GGC.. 4 Pre-Shared Key Ciphersuites for Transport Layer Security, disponible en http://tools.ietf.org/html/rfc4279. Machine Type Communication. 35 de89.

(36) 3.7.1.2 Dominios de Ambiente Seguro Un Dominio de Ambiente Seguro se refiere a entidades lógicas que están aisladas de una forma segura las unas de las otras, sea que estén en un mismo Ambiente Seguro o en diferentes. Las funciones sensibles, que incluyen el manejo de credenciales de seguridad y “key material”, deben estar protegidas en un Dominio de Ambiente Seguro controlado por un tercero de confianza. Estos Dominios de Ambiente Seguro que residen en dispositivos o Gateways M2M y pueden ser controlados por un tercero como el operador de la red de acceso o el Proveedor de Servicio M2M. Un Proveedor de Servicio M2M que posee un dispositivo o Gateway M2M, debe controlar su propio Dominio de Ambiente Seguro. Por su lado, los proveedores de Aplicaciones M2M, pueden controlar un Dominio de Ambiente Seguro independiente en un dispositivo o Gateway M2M.. 3.7.2 Detalle capacidad de servicio para seguridad (SEC) A continuación se detalla cómo la funcionalidad de seguridad en cada dominio específico (red, dispositivo y Gateway), suple los requerimientos de seguridad para el manejo de llaves y procedimientos de conexión al servicio M2M.. 3.7.2.1 Capacidad de Servicio de Seguridad en el dominio de red (NSEC) Esta capacidad realiza autenticación mutua de los Nodos de dispositivo o Gateway M2M, con el Nodo de Red M2M, y deriva las llaves que son usadas por la funcionalidad de comunicación genérica del dominio de red (NGC), para establecer sesiones de transporte seguro con las funcionalidades GGC y DGC en el Gateway y dispositivo respectivamente. A continuación se mencionan las funciones específicas de esta capacidad mediante las cuales se soportan la gestión de llaves Y el servicio de conexión M2M. Gestión de llaves •. Obtiene la llave o llaves de conexión M2M, del servidor MAS.. •. De acuerdo a la jerarquía de llaves establecida anteriormente (ver punto 3.7.1 Jerarquía de llaves), genera la llave Kma para aplicaciones autorizadas a usar servicios de la capa. Machine Type Communication. 36 de89.

(37) NSCL, derivándola de la llave Kmc dentro del Ambiente Seguro en el que se almacena la llave Kmc. AL finalizar, entrega la llave Kma a la funcionalidad NGC. Servicio de Conexión M2M •. El Servicio de Conexión M2M se provee a través de la autenticación mutua entre el nodo de dispositivo/Gateway M2M y el servidor MAS del Proveedor de Servicio M2M, y el acuerdo de la llave de conexión M2M. La autenticación mutua se da a través del uso de la llave raíz como llave secreta entre los nodos y el MAS.. •. La funcionalidad del NSEC sirve como entidad autenticadora; tiene una interfaz con el MAS para obtener el material necesitado para realizar la autenticación y el acuerdo de llaves con los nodos de dispositivo o Gateway.. •. Comunica la información de llaves a la funcionalidad NGC, que lo usa para establecer sesiones seguras de transporte de datos sobre la interfaz mId.. 3.7.2.2 Capacidad de Servicio de Seguridad en el Gateway y el Dispositivo (G/DSEC) Las capacidades GSEC y DSEC tienen las mismas funciones y realizan las mismas operaciones (conceptualmente), dentro de un Dominio de Ambiente Seguro en el nodo de Gateway o dispositivo M2M según sea el contexto. Esas operaciones realizadas por la capacidad GSEC o DSEC se mencionan a continuación: Gestión de llaves •. Obtiene la llave de conexión M2M y la protege de accesos no autorizados.. •. Para aplicaciones que usan servicios de la capa GSCL en el caso de la capacidad GSEC, o que corren en el dispositivo en el caso de la capacidad DSEC, genera las llaves de aplicación derivándolas de la Kmc y las entrega a la funcionalidad GGC/DGC. La derivación de la llave Kma se hace dentro del Ambiente Seguro que almacena la llave Kmc.. Servicio de Conexión M2M •. Inicia el Servicio de Conexión M2M lo que involucra autenticación mutua con el Proveedor de Servicio M2M para lo cual usa la llave raíz almacenada en el Ambiente Seguro del nodo. Machine Type Communication. 37 de89.

(38) de Gateway o dispositivo M2M. De esta forma se deriva la llave Kmc y a continuación las llaves Kma de las aplicaciones. •. La capacidad GSEC soporta opcionalmente procedimientos de sincronización de tiempo seguro.. Adicionalmente, las capacidades de seguridad en cada dominio pueden realizar procedimientos de validación de integridad. Para obtener mayor detalle de estos procedimientos, revisar el punto 8.2.4 de [1].. 3.7.3 Seguridad sobre la interfaz mId El punto de referencia mId entre las capas NSCL y D/G SCL, debe soportar autenticación del origen de los datos, integridad y retransmisión, confidencialidad y privacidad. Hay 3 formas en las que la interfaz mId puede asegurarse, y se ven en los puntos a continuación:. 3.7.3.1 Seguridad basada en la red de acceso En caso en que la capa de la red de acceso sobre la que se apoya la interfaz mId, es criptográfica o físicamente segura, y hay un acuerdo pre-establecido entre la red de acceso y la red M2M, entonces se puede usar la red de acceso como capa subyacente de seguridad en reemplazo de la capa de seguridad M2M.. 3.7.3.2 Seguridad basada en el canal Un canal de comunicación seguro puede ser construido entre las capas NSCL y D/GSCL, por ejemplo, usando TLS o IPsec. Las llaves Kmc o Kma deben ser usadas como llaves secretas compartidas entre los extremos para realizar la autenticación. Este canal sólo puede construirse después de establecer el servicio de conexión M2M y una vez que se establece el canal, se usan protocolos mId sobre ese canal.. 3.7.3.3 Seguridad basada en el objeto Una implementación M2M puede depender de seguridad basada a nivel del objeto. Cuando se usa seguridad a nivel de canal, todos los datos transferidos sobre la interfaz mId están sujetos al mismo. Machine Type Communication. 38 de89.

(39) nivel de seguridad. Ese nivel de seguridad, está determinado por el nivel más alto que se necesite sobre los datos, por lo que si por ejemplo, sólo una pequeña parte de los datos necesita ser encriptada, toda la comunicación se encripta y se envía por el canal. Para reducir esta ineficiencia se usa seguridad en la misma capa en que los datos son transmitidos, así cada elemento puede ser protegido individualmente y encriptado sin preocuparse de cómo son tratados los otros datos.. 3.8 BOOTSTRAPPING M2M CON MTC El Servicio de Bootstrapping M2M es usado principalmente con el objeto de proveer la llave raíz M2M en el nodo de dispositivo o Gateway M2M y en el servidor MAS. Adicionalmente, puede generar los siguientes identificadores (abordados en el punto 3.5 Identificación M2M en MTC): un identificador de nodo M2M o M2M-Node-ID; un identificador de capa de servicio M2M o SCL-ID; cualquier otro identificador de la capa NSCL, para que sea usado por el nodo de dispositivo o Gateway M2M como punto de contacto.. 3.8.1 Bootstrapping asistido por la Red de Acceso Este punto define los escenarios en los que el servicio de Bootstrapping M2M usa las credenciales de seguridad de la Red de Acceso para generar las llaves de los nodos.. 3.8.1.1 Servicio de Bootstrap M2M basado en Generic Bootstrapping Arquitecture (GBA) En este caso, el Servicio de Bootstrap M2M. se realiza en Gateways que soportan GBA y en. dispositivos equipados con una USIM, ISIM, CSIM o (R-)UIM. El procedimiento de Bootstrapping M2M basado en GBA tiene los siguientes elementos adicionales: •. Bootstrapping Server Function (BSF). •. Home Subscriber Server (HSS): Base de datos asociada con el USIM/ISIM/CSIM/(R)UIM.. Machine Type Communication. 39 de89.

(40) •. M2M Service Bootstrap Function (MSBF): En este caso actúa como Network Application Function (NAF).. Los siguientes son los pasos que sigue el procedimiento de Bootstrapping M2M en alto nivel Figura 10:. Figura 10. Bootstrapping GBA basado credenciales de la red de Acceso, tomado de [1]. Paso 0. Los identificadores externos de los Nodos de dispositivo/Gateway M2M son enviados al Proveedor de Servicio M2M, posteriormente pueden mapearse con el identificador de nodo M2MNode-ID. De la misma forma, estos identificadores se envían a la Red de Acceso de modo que el BSF puede acceder a ellos localmente. Paso 1. Después de un registro exitoso de los nodos de dispositivo/Gateway con la Red de Acceso, el nodo lleva a cabo el procedimiento de Bootstrapping GBA hacia el BSF (Bootstrapping Server Function), usando el vector de auntenticación AV que el BSF obtiene del HSS (Home Subscriber Server). De la misma forma el BSF obtiene opciones de seguridad del usuario (User Security Settings -USS), del HSS lo que puede contener una configuración de seguridad específica para M2M. Paso 2. El nodo de dispositivo o Gateway M2M realizan una autenticación HTTP por el mecanismo de Digest usando una llave específica de la función NAF (en este caso, del MSBF).. Machine Type Communication. 40 de89.

(41) Durante la autenticación por medio del Digest, el nodo de dispositivo o Gateway M2M envía un identificador de transacción GBA llamado B-TID (que se obtiene del paso 1), al MSBF. Luego, el MSBF usa este identificador para obtener sus identificadores externos de y opcionalmente, los USS M2M específicos del BSF. Finalmente, comprueba los identificadores externos obtenidos con la información de dispositivo y Gateway M2M obtenida en el paso 0, para saber qué nodo está autorizado para interactuar con la capa NSCL. Si la autenticación por medio del Digest es exitosa, los nodos M2M y el MSF saben que están compartiendo la misma llave del NAF (MSBF), que es usada como llave raíz M2M. Adicionalmente, al finalizar el paso 2, el MSBF puede enviar los identificadores de nodo M2MNode-ID y/o de capa de servicio SCL-ID, al nodo de dispositivo o Gateway M2M, así como otros identificadores de la capa NSCL. Paso 3. El MSBF envía la llave raíz generada en el paso 2, junto con los identificadores M2MNode-ID y SCL-ID asociados (si fueron provisionados por la función MSBF) al servidor MAS. Para mayor detalle del procedimiento de Bootstrapping GBA, revisar [6].. 3.8.1.2 Servicio de Bootstrap M2M basado en Extensible Authentication Protocol Method (EAP) En este caso, el procedimiento de Bootstrapping M2M es producto del procedimiento de autenticación con la red de acceso. La autenticación con la red de acceso es el procedimiento que permite la generación de la llave raíz, de esta forma, en vez de autenticar dos veces el nodo de dispositivo o Gateway M2M (una vez con la red de acceso y otra para el Bootstrapping M2M), todas las llaves generadas de la autenticación son usadas en este procedimiento. Cuando se desean obtener las credenciales M2M a través del uso de EAP, esto se puede hacer de dos formas: mediante el uso de credenciales SIM 5, o mediante el uso de credenciales AKA6. El procedimiento de Bootstrapping M2M basado en EAP es agnóstico a las credenciales de autenticación y métodos usados. Que las credenciales se basen en credenciales de la red de. 5 Subscriber Identity Modules 6 Authentication and Key Agreement. Machine Type Communication. 41 de89.

(42) acceso (como SIM o AKA), o que sean independientes de la red de acceso (como IBAKE 7 o TLS), no hace ninguna diferencia en los procedimientos que se usan con el método EAP. Los elementos involucrados son el dispositivo o Gateway M2M, el NAS o Network Access Server, la capa de servicio de red NSCL, el servidor MAS y el servidor AAA que se usa para autenticar mutuamente el dispositivo/Gateway y la red. Como es responsabilidad del servidor AAA generar la llave Kmr, éste asume virtualmente el rol del MSBF en el contexto de arquitectura M2M, adicionalmente el servidor MAS y el servidor AAA pueden estar en el mismo equipo.. Figura 11. Bootstrapping EAP basado en credenciales de la red de acceso, tomado de [1]. Los pasos Bootstrapping EAP en la Figura 11 son los siguientes: Paso 1: Autenticación con la red de acceso basada en EAP.. Se usa el método EAP para autenticar el dispositivo o Gateway con el servidor AAA vía el NAS. El método EAP utilizado depende de la red de acceso. 1a). El método EAP entre el dispositivo o Gateway y el NAS se lleva a cabo a través de una. capa baja (802.1, 802.16, entre otros). 1b). El método EAP entre el servidor AAA y el NAS mediante un protocolo AAA (DIAMETER,. RADIUS, entre otros).. 7 Identity-Based Authenticated Key Exchange. Machine Type Communication. 42 de89.

(43) Al finalizar la sesión de autenticación se genera una llave EMSK (Extended Master Session Key), tanto en dispositivo o Gateway M2M como en servidor AAA. Paso 2: Servicio de Conexión M2M que entrega la llave generada del servidor AAA al servidor MAS. La llave raíz en el servidor AAA se obtiene a partir de la llave EMSK mediante la siguiente función: Kmr = hash (EMSK, “ETSI M2M Device-Network Root Key” | M2M-Node-ID | M2M-SP-ID) •. La llave EMSK se obtiene del método EAP descrito en el paso 1.. •. Los identificadores que están como parámetros de la función hash son enviados explícitamente del NAS al dispositivo o Gateway M2M, o deducidos de alguna forma por el dispositivo o Gateway M2M (el mecanismo para deducirlos está fuera del alcance de este documento).. •. La llave raíz no se genera necesariamente cada vez que cambia la llave EMSK, por el contrario, si la llave EMSK cambia, es necesario volver a generar la llave Kmr sólo cuando se va a usar.. 2a. En este paso está el procedimiento de conexión M2M entre el dispositivo o Gateway M2M y la capa de servicio de red NSCL. En este caso, se genera una llave Kmr usando la llave EMSK más reciente. 2b. En este paso se realiza autenticación del dispositivo o Gateway M2M con el servidor MAS. 2c. En este paso, el servidor MAS le pide la llave Kmr al servidor AAA para poder realizar la autenticación del paso 2b, y el servidor AAA la genera de la llave EMSK más reciente. 3.8.2 Bootstrapping independiente de la Red de Acceso Los escenarios de este caso son aquellos en los que no existe una relación entre el proveedor de la red de acceso y el Proveedor de Servicio M2M, o entre el fabricante del dispositivo o Gateway M2M y el Proveedor de Servicio M2M. Hay principalmente 3 métodos que soportan este mecanismo de Bootstrapping:. Machine Type Communication. 43 de89.

(44) •. Usando EAP-IBAKE sobre EAP/PANA.. •. Usando EAP-TLS sobre EAP/PANA.. •. Usando TLS sobre TCP.. 3.8.2.1 Usando PANA como protocolo de transporte en el método EAP En este caso, el Nodo de dispositivo o Gateway M2M implementa la funcionalidad de peer EAP, y el MSBF implementa la funcionalidad de autenticador EAP. PANA [7], se usa para transportar los atributos relacionados con el procedimiento de bootstrapping y los atributos EAP, entre el Nodo de dispositivo o Gateway M2M y el Nodo de Red M2M. En este caso, el Nodo de dispositivo o Gateway M2M implementa la funcionalidad de un cliente PANA (PaC), mientras que el MSBF debe implementar la funcionalidad de un Agente de Autenticación PANA (PAA). Un protocolo AAA (como RADIUS o DIAMETER), puede ser usado para transportar los atributos EAP y relacionados con el bootstrapping entre el Nodo de dispositivo o Gateway M2M y el MSBF. Cuando se usa un protocolo AAA el Nodo de Red M2M debe implementar un cliente AAA y el MSBF debe implementar la funcionalidad de servidor AAA. En la Figura 12, se puede observar el procedimiento de Bootstrapping M2M con el método EAP/PANA:. Machine Type Communication. 44 de89.

(45) Figura 12. Bootstrapping EAP/PANA independiente de la Red de acceso, tomado de [1]. Paso 1. Se lleva el registro con la red de acceso. Paso 2. Los ID pre-aprovisionados del dispositivo o Gateway M2M, y otro conjunto de parámetros potencialmente requeridos son pasados al MSBF. Paso 3. El Nodo de dispositivo o Gateway M2M envía una petición de Servicio de Bootstrapping M2M (representada por un mensaje de iniciación del cliente PANA), al Nodo de Red M2M. Esta petición contiene los IDs pre-aprovisionados para el dispositivo o Gateway M2M, así como los parámetros adicionales que sean necesarios. Paso 4. El Nodo de Red M2M recibe la petición de Bootstrapping del paso 3 y provee una serie de parámetros que son pertinentes al intercambio de llaves que se lleva a cabo después. En el mensaje se pueden incluir uno a varios identificadores de Proveedor de Servicio M2M (M2M2-SPID), el identificador de la capa de servicio de red NSCL (SCL-ID), el identificador del MSBF (MSBFID) y el ID pre-aprovisionado del dispositivo o Gateway M2M que está en el MSBF o MAS.. Machine Type Communication. 45 de89.