Contenido


Diseñar y construir soluciones IoT seguras, Parte 1

Protegiendo dispositivos y gateways IoT

Desde la autenticación, incluyendo la autenticación basada en certificados, pasando por la autorización, hasta la validación de ID de aplicaciones

Comments

Contenido de la serie:

Este contenido es la parte # de # de la serie: Diseñar y construir soluciones IoT seguras, Parte 1

Manténgase en contacto por contenidos adicionales de esta serie.

Este contenido es parte de la serie:Diseñar y construir soluciones IoT seguras, Parte 1

Manténgase en contacto por contenidos adicionales de esta serie.

El Internet de las Cosas (IoT) presenta enormes oportunidades para las empresas y los consumidores, especialmente en las áreas de cuidado de la salud, almacenaje, transporte y logística. Junto con esta amplia adopción, los desarrolladores se enfrentan a nuevos retos para asegurar que las aplicaciones del IoT sean suficientemente seguras, porque estas aplicaciones manejan muchos datos sensibles. Ya se han informado de muchas violaciones de la seguridad de las soluciones IoT, así que cuando los desarrolladores diseñan e implementan dichas soluciones, se deben enfocar incluir la seguridad en sus aplicaciones IoT.

Esta serie de artículos se enfoca en los niveles arquitectónicos de una aplicación IoT que esté basada en plataformas en nube de IBM. Los artículos de esta serie describen un enfoque basado en la solución, para minimizar los riesgos de seguridad de las aplicaciones del IoT mediante la utilización de los servicios que ya están disponibles en las plataformas en nube de IBM. Los artículos proporcionan técnicas comprobadas para proteger las aplicaciones IoT.

La Parte 1 de esta serie describe los diferentes enfoques para proteger los dispositivos o gateways. La Parte 2 se enfoca en los aspectos de seguridad de la red y el nivel de transporte, que incluye la IBM Watson IoT Platform. La Parte 3 proporciona los requisitos de seguridad para el nivel de aplicaciones y un enfoque de implementación para una aplicación IoT de analítica que se crea en la plataforma IBM Bluemix.

Ya que las aplicaciones del IoT recopilan más y más datos que no estaban expuestos anteriormente, —a menudo privados—, y permiten el acceso a varias funciones de control a través de Internet, la seguridad se convierte en un reto principal.

Fundamentos básicos de seguridad del IoT

Las soluciones IoT implican a una compleja red de dispositivos inteligentes, como vehículos, máquinas, edificios o electrodomésticos del hogar, que tienen incorporados electrónica, software, sensores y conectividad de red, lo que habilita que esas "cosas" recopilen e intercambien datos. Las "cosas" del Internet de las Cosas permiten que los desarrolladores proporcionen una amplia gama de nuevos servicios basados en estos dispositivos físicos conectados y habilitados para la nube. Ya que las aplicaciones del IoT recopilan más y más datos que no estaban expuestos anteriormente,—a menudo privados—, y permiten el acceso a varias funciones de control a través de Internet, la seguridad se convierte en un reto principal. Por lo tanto, una aplicación IoT debe:

  • Prevenir la violación del sistema o que se ponga en peligro.
    Cada nivel de la aplicación IoT debe implementar medidas preventivas efectivas para mantener alejados a los hackers. Por ejemplo, usted necesita endurecer el dispositivo para asegurar que la comunicación entre el dispositivo y la nube sea segura.
  • Soportar una supervisión continua.
    Incluso los sistemas más seguros todavía tienen muchas vulnerabilidades. Además, la mejor solución segura actual (tanto de hardware como de software) puede no ser suficientemente buena para prevenir ataques en el futuro. Por lo tanto, usted debe complementar sus medidas de seguridad con una supervisión continua y la constante actualización del sistema para protegerlo contra las más recientes formas de ataques.
  • Ser resiliente.
    Finalmente, si ocurriese una violación, se debe minimizar el daño y el sistema se debe recuperar tan rápido como sea posible.

Vulnerabilidades del IoT

Los desarrolladores tienen muchas maneras para aplicar tecnologías IoT para crear soluciones IoT. Pueden crear un simple sistema de vigilancia del hogar que proporciona alertas a teléfonos y relojes inteligentes, o pueden crear complejos sistemas del cuidado de la salud que recopilan datos y controlan una red de dispositivos de los pacientes—y muchas oportunidades para soluciones que todavía no hemos imaginado.

Pero conectar objetos como automóviles, hogares y máquinas expone muchos datos delicados, como la ubicación de personas en un edificio o los registros médicos de pacientes. Se deben proteger estos datos de acuerdo con los principios claves para la seguridad de los datos, la triada de la CIA: confidencialidad, integridad y disponibilidad.

Cualquier dispositivo que tenga una conectividad de red es vulnerable. Los datos personales que los dispositivos IoT recopilan siempre son valiosos para los hackers y ladrones de identidades. También, un ataque cibernético sobre las soluciones IoT tiene el potencial de dañar servicios e infraestructuras críticas. Por ejemplo, los hackers atacaron un Jeep Cherokee mientras estaba siendo conducido en una autopista. Por lo tanto, proteger las aplicaciones del IoT no solo es crítico para la reputación de la empresa, sino también para la salud física y para el bienestar de los clientes y usuarios de la solución.

Las vulnerabilidades de seguridad de los dispositivos conectados de los hospitales fueron demostradas en un estudio de dos años. Uno de los principales problemas que encontraron estaba relacionado con los servicios Web incorporados que permitían que los dispositivos se comunicasen con otros y alimentasen digitalmente los datos directamente en los registros médicos del paciente—¡sin un mecanismo de cifrado o autenticación adecuado! Un estudio similar demostró las vulnerabilidades de seguridad de los monitores de bebés.

Retos en el diseño de la seguridad del IoT

Mientras que la importancia de la seguridad del IoT está ampliamente entendida y acordada, el diseño y la implementación real de la seguridad del IoT traen nuevos retos y oportunidades para la creatividad. En el diseño de la mayoría de las aplicaciones, los desarrolladores siempre se enfrentan a encontrar el término medio entre la seguridad y la usabilidad. Para las soluciones IoT, se vuelve incluso más problemático. Los dispositivos IoT a menudo tienen un poder de computación y una capacidad de memoria limitados, haciendo que sea difícil utilizar complejos algoritmos criptográficos que requieran de más recursos de los que proporcionan los dispositivos.

Otro reto es actualizar regularmente los dispositivos IoT con arreglos y actualizaciones de seguridad. Desplegar parches de seguridad para todos los dispositivos puede ser muy difícil en redes de dispositivos poco fiables o de ancho de banda bajo, y muchas de las medidas de seguridad existentes, como la seguridad de navegador Web, pueden no estar disponibles para las aplicaciones IoT.

Además, pude ser que se tengan que desarrollar o mejorar mecanismos de seguridad para los nuevos protocolos que son diseñados específicamente para el Internet de las Cosas, tales como Message Queuing Telemetry Transport (MQTT) y Constrained Application Protocol (CoAP). Por lo tanto, cuando diseña aplicaciones IoT, es particularmente importante tener en cuenta desde el principio las consideraciones de seguridad.

Desarrollando aplicaciones del IoT seguras

La mayor parte de sus soluciones IoT están formadas por tres niveles principales. Los componentes de la solución IoT que son ejecutados en cada nivel tienen que incorporar medidas de seguridad específicas para protegerse contra múltiples vulnerabilidades.

  • Nivel de Dispositivos/Gateways: Proteger contra un servidor "falso" que envía comandos maliciosos, o proteger contra un hacker que intenta escuchar los datos de sensores privados que están siendo enviados desde los dispositivos. Las consideraciones de seguridad para este nivel se discuten en la Parte 1 (este artículo).
  • Nivel de Red/Transporte: Proteger contra un dispositivo "falso" que envía mediciones falsas que pueden corromper los datos que persisten en la aplicación. Las consideraciones de seguridad para este nivel serán discutidas en la Parte 2.
  • Nivel de aplicaciones: Proteger contra el uso inválido de datos, o proteger contra la manipulación de los procesos analíticos que se ejecutan en el nivel de la aplicación. Las consideraciones de seguridad para este nivel serán discutidas en la Parte 3.

El nivel de aplicaciones de un dispositivo IoT proporciona a los hackers la mayor superficie de ataque. La capa de aplicaciones incluye a todos los dispositivos que tengan conectividad con el dispositivo IoT, lo que puede incluir las aplicaciones web locales, las basadas en la nube y las móviles.

Para todas las aplicaciones del IoT la seguridad de las aplicaciones debe ser una parte intrínseca del ciclo de la vida del desarrollo de las aplicaciones (SDLC), particularmente durante las etapas de diseño, desarrollo y pruebas. Dentro de la etapa de planificación o diseño de una aplicación IoT, debe haber una evaluación formal "de arriba hacia abajo" de los requisitos de seguridad y privacidad de la aplicación planificada.

El diagrama de abajo muestra los tres niveles de la aplicación IoT típica que utiliza IBM Watson IoT Platform en el nivel de la red/transporte y la plataforma en nube IBM Bluemix en el nivel de la aplicación.



La siguiente tabla describe brevemente cada nivel y las consideraciones de seguridad en las que se deben enfocar los desarrolladores.

Nivel Descripción Consideraciones de seguridad
Aplicación Las aplicaciones del IoT se despliegan en la plataforma Bluemix.
  • Seguridad de la aplicación
  • Llamada API segura para la IBM Watson IoT Platform
  • Seguridad de Node-RED
  • descifrado de mensajes
  • Mensaje de verificación de checksum
Red/Transporte IBM Watson IoT Platform proporciona la plataforma de mensajería basada en MQTT para las aplicaciones del IoT.
  • Autenticando dispositivos (sólo pueden enviar datos los dispositivos confiables)
  • Autorización
  • Seguridad de la API
  • Configuración de seguridad
  • Transporte seguro
Dispositivos/Gateways Los dispositivos (directamente o a través de gateways) publican los datos del sensor en la IBM Watson IoT Platform y reciben las instrucciones para ejecutar las funciones de control.
  • Autenticación
  • Cifrado del mensaje de carga
  • Suministro y verificación de certificados
  • Transporte MQTT seguro
  • Arranque seguro
  • Firewalls
  • Actualizaciones de firmware y parches

Protegiendo dispositivos

La seguridad de los dispositivos se enfoca en garantizar que en la solución se utiliza un conjunto de dispositivos confiables, y que esos dispositivos pueden confiar en el broker o en la aplicación que está enviando los comandos de control. Este artículo discute varios tipos de mecanismos de seguridad que se pueden utilizar para establecer esa confianza.

Además, desarrollamos (en JavaFX) un programa de simulador de dispositivos que demuestra esos mecanismos de seguridad:

  • Autenticación del ID/Contraseña de Usuario
  • Autenticación de Una sola contraseña (OTP)
  • Autenticación de ID único de servidor
  • Autenticación de carga de mensaje

Vea la siguiente captura de pantalla del simulador de dispositivos.

 

Usted puededescargar el código para el programa del simulador de dispositivos, y seguir las instrucciones del archivo léeme para compilarlo y ejecutarlo localmente.

MQTT es el protocolo de mensajería más popular para los dispositivos y aplicaciones IoT, y es soportado por muchos de los principales actores en el campo del IoT. MQTT proporciona un protocolo de comunicaciones ligero y fácil de usar para las soluciones IoT.

El propio MQTT especifica algunos mecanismos de seguridad, pero todas las implementaciones comunes soportan los estándares de seguridad de última generación, tales como SSL/TLS para la seguridad en el transporte. Para sus aplicaciones, el MQTT no impone la utilización de un enfoque de seguridad en particular, sino que se lo deja al diseñador de la aplicación. Por lo tanto, las soluciones IoT se pueden basar en el contexto de la aplicación y en requisitos de seguridad específicos.

La mayor parte de los despliegues del MQTT utilizan la seguridad en la capa de transporte (TLS), así que los datos son cifrados y se valida su seguridad. De igual manera, para controlar el acceso, la mayor parte de las implementaciones del MQTT (incluyendo la que se encuentra en IBM Watson IoT Platform) también utilizan las funciones de autorización del servidor MQTT.

Además del programa simulador de dispositivos, hemos proporcionado un cliente broker de aplicaciones que muestra los mensajes MQTT que se reciben desde el dispositivo y envía comandos de muestra al dispositivo. Esta aplicación de muestra del cliente broker de aplicaciones genera la clave OTP para la autenticación del dispositivo, y envía un ID de aplicación único para que los dispositivos verifiquen la aplicación. Este cliente genera mensajes de comando —tanto válidos como inválidos—para probar los diferentes escenarios.

Usted puededescargar el código para el cliente broker de aplicaciones, y seguir las instrucciones del archivo léame para construirlo y ejecutarlo localmente.

Autenticación de dispositivos

En MQTT la autenticación forma parte del nivel de seguridad de transporte y de aplicaciones. En nivel de transporte, el TLS puede garantizar al servidor la autenticación del cliente mediante la utilización de certificados del cliente, y del servidor al cliente mediante la validación del certificado del servidor. En el nivel de aplicaciones, el protocolo MQTT proporciona la autenticación del nombre de usuario/contraseña.

Los desarrolladores pueden utilizar varios enfoques para garantizar que el dispositivo adecuado esté registrado con el broker. Seleccionar el enfoque adecuado depende de las necesidades de seguridad de la solución, y de la capacidad del dispositivo de ejecutar el enfoque necesario.

La sección de abajo describe algunos de estos enfoques. Eclipse Paho es utilizada como librería del cliente MQTT para las muestras de código.

Autenticando con el nombre de usuario y la contraseña

Para la identificación del dispositivo el protocolo MQTT proporciona los camposnombre de usuario y contraseña en el mensaje CONNECT. El cliente debe enviar un nombre de usuario y una contraseña cuando se conecta a un broker MQTT.

El nombre de usuario es una cadena de caracteres con codificación UTF-8, y la contraseña está formada por datos binarios. Cada uno tiene un máximo de 65535 bites. El protocolo MQTT no cifra el nombre de usuario ni la contraseña, y a no ser que se utilice el cifrado en el transporte, son enviados en un formato de texto claro.

Listado 1. Campos de nombre de usuario y contraseña
try {
    MqttClient securedClient = new MqttClient(broker, clientId, persistence);
    MqttConnectOptions connOpts = new MqttConnectOptions();
    connOpts.setCleanSession(true);
    connOpts.setUserName(userName);
    connOpts.setPassword(password.toCharArray());
    System.out.println("Connecting to broker: "+broker);
    securedClient.connect(connOpts);
    System.out.println("Connected");
} catch(MqttException me) {
    System.out.println("reason "+me.getReasonCode());
    System.out.println("msg "+me.getMessage());
    System.out.println("loc "+me.getLocalizedMessage());
    System.out.println("cause "+me.getCause());
    System.out.println("excep "+me);
    me.printStackTrace();
}

Autenticando con un token de acceso

Si el cliente recuperó con éxito un token de acceso, puede enviarlo al broker en el mensaje CONNECT mediante la utilización del campo contraseña. El nombre de usuario podrá entonces ser una cadena de caracteres para el reconocimiento del token de acceso. El límite de tamaño de una contraseña en MQTT es de 65535 bites, así que el token no puede ser más largo que ese límite.

El broker puede utilizar el token para realizar múltiples validaciones, tales como:

  • Verificar la validez de la firma desde el token
  • Verificar si ya ha pasado la fecha de caducidad del token
  • Verificar el servidor de autorizaciones para ver si el token fue revocado

Cuando las aplicaciones publican o suscriben se pueden utilizar las mismas validaciones que se utilizan cuando el dispositivo se conecta con el broker MQTT. Sin embargo, al publicar o suscribir, el broker también debe autorizar a la aplicación. Esta autorización se puede hacer de dos maneras:

  • El token incluye la autorización para el cliente en la petición de ámbito.
  • El broker tiene un origen de terceros, como una base de datos o u directorio LDAP, que busca las autorizaciones para el cliente.

Las aplicaciones de IBM Watson IoT Platform pueden ser autenticadas por el ID, la clave y el token de la aplicación. Se puede generar la clave y el token de la aplicación IoT durante el registro de la aplicación y se pueden utilizar cuando se conecta a IBM Watson IoT Platform, como se muestra en el ejemplo de abajo:

Listado 2. Claves y tokens de la aplicación
Propiedades de la aplicación

# Un id único que usted mismo elige, quizás, abcdefg123456
appid=<El_id_de_su_aplicación>

# El campo de clave que usted copió anteriormente de la información de Claves de la Aplicación
key=<Key>

# El campo de Autentificación de Token que usted copió anteriormente de la información de Claves de la Aplicación
token=<Token>

Código de la aplicación durante la conexión:

strAuthMethod = props.getProperty("key");
strAuthToken = props.getProperty("token");

handler = new AppMqttHandler();
handler.connect(serverHost, clientId, strAuthMethod, strAuthToken, isSSL);

Autenticar con la Autenticación de contraseña de una única vez (OTP)

Además de los mecanismos de autenticación proporcionados por MQTT, las aplicaciones del IoT podrían tener que implementar medidas de seguridad adicionales para identificar el dispositivo adecuado. Este artículo describe un enfoque para implementar la autenticación basada en OTP para esas situaciones. La autenticación OTP puede ser un mecanismo útil para proteger un dispositivo contra el uso inadecuado, mediante la eliminación del riesgo de que usuarios no autorizados consigan acceder.

Con este método, solo los usuarios autenticados son capaces de iniciar la comunicación de datos con la aplicación IOT después del arranque del dispositivo. Ya que algunos dispositivos no tienen la capacidad de introducir datos mediante un teclado, se puede implementar un simple cambio de la propiedad para habilitar o deshabitar este esquema de seguridad en base al tipo de dispositivo. Si la autenticación OTP está habilitada, después del iniciar el dispositivo, este envía una solicitud OTP a la aplicación broker del IoT mediante la utilización de un mensaje MQTT normal. En el gráfico de abajo se muestra el flujo detallado.

 

Listado 3 muestra cómo la autenticación OTP se puede activar y desactivar mediante la utilización de una propiedad del dispositivo. Si la autenticación OTP está habilitada, después del iniciar el dispositivo, este envía una solicitud OTP a la aplicación broker del IoT mediante la utilización de un mensaje MQTT normal.

Listado 3. Solicitud de OTP
		// Crea la solicitud para la OTP
		JSONObject idObj1 = new JSONObject();
		try {
			idObj1.put("event", "server_otp_request");
			idObj1.put("deviceId", deviceIdentifier);
		} catch (JSONException e1) {
			System.out.println("Ocurrió una excepción");
			e1.printStackTrace();
		}
		new SendMessageToServer("server_otp_request", idObj1).start();
		System.out.println("solicitud otp enviada....");
	}

La aplicación IoT genera una OTP, la envía de forma separada al propietario del dispositivo y envía una notificación al dispositivo, como se muestra en el siguiente código.

Listado 4. Generar OTP
			otp = IOTSecurityUtil.generateOTP();

			JSONObject jsonObj = new JSONObject();
			try {
				jsonObj.put("cmd", "server_otp_response");
				jsonObj.put("otp", otp);
				jsonObj.put("appid", strAppId);
				jsonObj.put("time",
                new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new Date()));

		     // El servidor empieza una cuenta atrás de 5 minutos durante la cual
		     // la OTP es válida.
				task = new TimeOutTask();
				t = new Timer();
				t.schedule(task, 30000000L);

			} catch (JSONException e) {
				e.printStackTrace();
			}
			System.out.println("Sending otp  -  " + otp);

			// Comando de publicación para un dispositivo específico
			// iot-2/type/<type-id>/id/<device-id>/cmd/<cmd-id>/fmt/<format-id>
			new SendMessageToDevice(strDeviceId, "server_otp_response", jsonObj)
					.start();

Como se muestra en Listado 5, la OTP se introduce en el dispositivo y este la envía a la aplicación broker. La aplicación broker válida la OTP enviada por el dispositivo y envía al dispositivo un mensaje de éxito/fallo (OTP incorrecta o desconexión por tiempo). El dispositivo puede volver a intentar la autenticación OTP basándose en volver a intentar la cuenta desde la configuración.

Si la autenticación OTP no tiene éxito incluso después de volver a intentar, se cierra la aplicación. Si la autenticación OTP no está habilitada, el dispositivo la omitirá después de su arranque.

Listado 5. Validar autenticación OTP
	if (receivedOTP.equals(otp)) {
	    if (task.isTimedOut) {
		// El usuario tardó más de 100 segundos y por lo tanto la OTP no es válida
		System.out.println("Time out!");
		otpValidated = false;
		otpTimeOut = true;
	    } else {
		System.out.println("OTP validado..");
		otpValidated = true;
		otpTimeOut = false
	    }
	} else {
	    System.out.println("OTP Incorrecta..");
	    otpValidated = false;
	    otpTimeOut = false;
	}

	JSONObject otpRespObj = new JSONObject();
	try {
		otpRespObj.put("cmd", "server_otp_validate");
		otpRespObj.put("isOTPValid", String.valueOf(otpValidated));
		otpRespObj.put("isTimeOut", String.valueOf(otpTimeOut));
		otpRespObj.put("appid", strAppId);
		otpRespObj.put("time", new SimpleDateFormat(
						"yyyy-MM-dd HH:mm:ss").format(new Date()));
	} catch (JSONException e) {
		e.printStackTrace();
	}
	System.out.println("Resultado de la validación OTP -  " + otpValidated);
	// Publicar comando en un dispositivo específico	    new sendMessageToDevice(strDeviceId, "server_otp_validate",
		otpRespObj).start();

  }

Autenticación basada en certificados

Algunos brokeres (como HiveMQ, un broker MQTT que puede ser utilizado para habilitar las capacidades de M2M e IoT para las empresas) soportan certificados de dispositivo que el broker puede utilizar como parte de un proceso de autenticación mutua. En las aplicaciones donde los requisitos de seguridad sean muy estrictos y los dispositivos puedan suministrar certificados, usted debería considerar este tipo de autenticación.

Este artículo utiliza HiveMQ para demostrar la autenticación basada en certificados y de SSL bidireccional. Para la comunicación del dispositivo sólo utiliza un protocolo MQTT estándar. Los códigos de muestra incluidos que hacen la demostración de la cifración/descifrado de la carga han sido probados tanto en IBM Watson IoT Platform como en HiveMQ.

Si tiene realizar el seguimiento y todavía no tiene HiveMQ, debería instalarlo. Se puede descargar, instalar e iniciar fácilmente siguiendo los pasos resumidos en hivemq.com. Es posible utilizar plug-ins opcionales para recuperar los mensajes retenidos desde HiveMQ. El cliente MQTT funciona con HiveMQ de la misma manera que con IBM Watson IoT Platform.

El programa de simulación de dispositivos y la demo del cliente broker de aplicaciones MQTT demuestran la autenticación basada en certificados. Tanto el dispositivo como la aplicación realizan una verificación de certificados mutua con HiveMQ.

Usted puededescargar el código para la demo de autenticación de certificados, y seguir las instrucciones del archivo léeme para compilarlo y ejecutarlo localmente.

Generando el certificado

Siga los pasos de abajo para generar un certificado para la autenticación. Este procedimiento utiliza la keytool que forma parte del Java Runtime Environment.

  1. Generar la clave y el keystore del dispositivo
    keytool -genkey -alias iotdevice1 -keyalg RSA -keypass devicepass -storepass devicepass -keystore iot_device_keystore.jks -storetype jks
  2. Exportar el certificado del dispositivo desde el keystores
    keytool -export -alias iotdevice1 -storepass devicepass -file iotdevice1.cer -keystore iot_device_keystore.jks
  3. Añadir el certificado del dispositivo en el truststore del broker
    keytool -import -v -trustcacerts -alias iotdevice1 -file iotdevice1.cer -keystore iot_broker_truststore.jks -keypass devicepass -storepass brokerpass -storetype jks
  4. Generar la clave y el keystore del broker
    keytool -genkey -alias broker -keyalg RSA -keypass brokerpass -storepass brokerpass -keystore iot_broker_keystore.jks -storetype jks
  5. Exportar el certificado del broker
    keytool -export -alias broker -storepass brokerpass -file broker.cer -keystore iot_broker_keystore.jks
  6. Añadir el certificado al truststore del dispositivo
    keytool -import -v -trustcacerts -alias broker -file broker.cer -keystore iot_device_truststore.jks -keypass brokerpass -storepass brokerpass -storetype jks

Se puede extender el mismo enfoque a varios dispositivos. Todos los certificados del dispositivo se pueden añadir al truststore y el certificado del broker debe estar en el truststore de todos los dispositivos.

Configurar HiveMQ para la autenticación basada en certificados

Como se muestra en Listado 6, HiveMQ se configura con el keystore y el truststore del broker mediante el uso del archivo config.xml .

Listado 6. HiveMQ configurado con el keystore y el truststore del broker
<tls-tcp-listener>
            <port>8883</port>
            <bind-address>0.0.0.0</bind-address>
            <tls>
                <keystore>
                    <path><Your path>\iot_broker_keystore.jks</path>
                    <password>brokerpass</password>
                    <private-key-password>brokerpass</private-key-password>
                </keystore>
                <truststore>                  
                        <path>C:\certificates\iot_broker_truststore.jks</path>
                        <password>brokerpass</password>
                </truststore>
                <client-authentication-mode>REQUIRED</client-authentication-mode>
            </tls>
        </tls-tcp-listener>

Después se configura el manejador del MQTT con el keystore y el truststore del dispositivo como se muestra en el siguiente código:

Listado 7. Manejador del MQTT configurado con el keystore y el truststore del dispositivo
if (isSSL) {
		java.util.Properties sslClientProps = new java.util.Properties();

            // Establece las propiedades del SSL
		sslClientProps.setProperty("com.ibm.ssl.protocol", "TLSv1.2");
		sslClientProps.setProperty("com.ibm.ssl.contextProvider", "SunJSSE");

            // Establece las propiedades de keystore
		sslClientProps.setProperty("com.ibm.ssl.keyStore", "<Your_path>/iot_device_keystore.jks");
            sslClientProps.setProperty("com.ibm.ssl.keyStorePassword", "devicepass");
		sslClientProps.setProperty("com.ibm.ssl.keyStoreType", "JKS");
		sslClientProps.setProperty("com.ibm.ssl.keyManager", "SunX509");

            // Establece las propiedades del truststore
		sslClientProps.setProperty("com.ibm.ssl.trustStore", "<Your_path>/iot_device_truststore.jks");
		sslClientProps.setProperty("com.ibm.ssl.trustStorePassword", "brokerpass");
		sslClientProps.setProperty("com.ibm.ssl.trustStoreType", "JKS");
		sslClientProps.setProperty("com.ibm.ssl.trustManager", "SunX509");

            // 'options' es una instancia de MqttConnectOptions
		options.setSSLProperties(sslClientProps);
	}

Autenticar con certificados del cliente

Mientras que la autenticación basada en certificados proporciona un alto nivel de seguridad para algunas aplicaciones, no es fácil implementar este enfoque, y gestionar los ciclos de vida de los certificados para múltiples dispositivos puede ser caro. Pero si alguna empresa ya tiene implantada una infraestructura similar y gestiona todos los componentes MQTT (dispositivos y brokeres), se puede considerar este enfoque.

IBM Watson IoT Platform no soporta la autenticación basada en certificados del cliente. Sin embargo, es posible implementarla con otros brokeres, como HiveMQ.

MQTT puede utilizar TLS para la cifración del transporte. Para utilizar TLS, el servidor debe tener un par de claves públicas/privadas. Cuando tiene lugar la negociación (handshake) del TLS, los clientes necesitan validar el certificado X509 del servidor—que también contiene la clave pública del servidor—antes de establecer una conexión segura.

Para implementar el protocolo de negociación del TLS, además de los certificados de servidor, los clientes también pueden tener un par de claves públicas/privadas. El cliente envía su certificado (que incluye la clave pública del cliente) como parte de la negociación del TLS después de que se haya validado el certificado del servidor. Entonces el servidor es capaz de verificar la identidad del cliente y puede cancelar la negociación si hay un error en la verificación del certificado del cliente. Esta práctica permite la autenticación del cliente antes de que sea establecida una conexión segura.

Implementar los certificados del cliente tiene las siguientes ventajas:

  • Verificación de la identidad de los clientes MQTT
  • Autenticación de los clientes MQTT en el nivel del transporte
  • Bloqueo de los clientes MQTT no válidos antes de que se envíen los mensajes MQTT CONNECT

Si usted utiliza certificados del cliente, sólo los clientes confiables pueden establecer una conexión segura. Esta configuración puede ahorrar recursos en el lado del broker, especialmente si desde ese lado se utilizan mecanismos de autenticación caros (como búsquedas en la base de datos o llamadas a un servicio web). Debido a que la autenticación tiene lugar en la negociación del TLS, la autenticación se realiza antes de que se haya establecido una conexión.

Aunque esta certificación del cliente X509 brinda una capa de seguridad extra, este tipo de autenticación conlleva un costo. Con los certificados del cliente el suministro del cliente MQTT es más complejo y se necesita un mecanismo de revocación de certificados.

  • Desplegar certificados del cliente: Para utilizar los certificados del cliente, se debe definir un proceso de suministro. Este proceso se define cuando las empresas tienen control sobre sus dispositivos y tienen un proceso de actualización del firmware bien definido. Los certificados del cliente se pueden suministrar durante la actualización del firmware. Para gestionar el ciclo de la vida (incluido el vencimiento) de los certificados de los dispositivos se requieren otras consideraciones.
  • Revocación del certificado: Si no se puede confiar más en el certificado de un cliente (por ejemplo, si fue filtrado), entonces es importante invalidarlo. Si el certificado fue filtrado y clientes maliciosos están utilizándolo, el servidor necesita una manera de identificar el certificado no válido y de prohibir que los clientes se conecten con ese certificado.

Autorización del dispositivo

Un mecanismo de autorización que garantice que no haya una fuga de datos entre dos dispositivos.

MQTT es un protocolo de publicación/suscripción basado en temas. Cada mensaje se publica sobre un tema identificado, y cada suscripción tiene un filtro de temas que puede incluir comodines. Así que, la autorización se realiza en términos de publicación/suscripción y nombres de temas. La mayor parte de los servidores MQTT tienen alguna manera de otorgar la autoridad para publicar y suscribir sobre los temas.

En IBM Watson IoT Platform, se impone esta autorización mediante la implementación de patrones de mensajería seguros. Después de haber autenticado los dispositivos, sólo se les autoriza a publicar y suscribir en un espacio de temas restringido, por ejemplo:

  • /iot-2/evt/+/fmt/+
  • /iot-2/cmd/+

Todos los dispositivos trabajan en el mismo espacio de temas. Las credenciales de la autenticación proporcionadas por el cliente que se conecta, dictan a qué dispositivo llegará el alcance de IBM Watson IoT Platform para el tema. Esta configuración evita que los dispositivos sean capaces suplantar a otro dispositivo. La única manera de suplantar a otro dispositivo es mediante la obtención de las credenciales de seguridad en riesgo de ese dispositivo.

Autorización de aplicaciones con OAuth 2.0

Cuando las empresas quieran utilizar su mecanismo de autorización centralizado para los dispositivos MQTT, podrán utilizar una infraestructura basada en OAuth. OAuth 2.0 habilita la separación del servidor de autorización del servidor de recursos, como un servidor MQTT. Cuando se utiliza OAuth 2.0, el cliente presenta sus credenciales al servidor de autorización, quién entonces realiza la verificación de autenticación y devuelve un token de acceso que concede el permiso para acceder a un recurso.

El token de acceso es utilizado para conectar al servidor MQTT. El servidor MQTT valida el token de acceso, usualmente mediante la comunicación con el servidor de autorización, después otorga acceso al recurso. El flujo está representado en el siguiente diagrama:

Validación del ID de la aplicación

La validación del ID de la aplicación es un nivel de seguridad extra entre la aplicación IoT y el dispositivo para asegurar que ninguna aplicación falsa pueda enviar comandos al dispositivo. Este mecanismo se puede utilizar tanto de seguridad en el arranque como mecanismo de comunicación de la seguridad. Mediante la utilización de este esquema, el dispositivo almacena el ID único de la aplicación IoT y lo valida cuando procesa los comandos que provienen de la aplicación IoT.

Si la aplicación IoT envía un ID único no válido con un comando, el comando será ignorado por el dispositivo. Si el dispositivo tiene capacidad de almacenamiento, el ID único de la aplicación IoT podría ser cifrado y almacenado. En ese caso, la solicitud de ID único no es necesaria después de cada reinicio.

El flujo detallado se muestra en el siguiente diagrama:

 

El diagrama de arriba representa los siguientes aspectos del flujo:

  • La validación del ID de la aplicación puede activarse y desactivarse en base a la capacidad del dispositivo.
  • Durante el reinicio, si la validación y el almacenamiento del ID de la aplicación estuviesen habilitados, el dispositivo intentará restaurar el ID único de la aplicación IoT a partir de un archivo cifrado.
  • Si el dispositivo no pudiese cargar el ID de la aplicación único, iniciaría una solicitud para obtener la aplicación.
  • Cuando recibe la solicitud, la aplicación IoT envía el ID único al dispositivo.
  • El dispositivo almacena el ID único en la memoria y en un archivo (si tuviese capacidad de almacenamiento).
  • Después de eso, el dispositivo espera el mismo ID de aplicación en cada comando proveniente de la aplicación IoT.
  • Si hay una discordancia, el dispositivo ignorará el comando.

La siguiente captura de pantalla de la aplicación de muestra del simulador de dispositivos muestra la utilización del ID de la aplicación. En cada instancia, el ID único de la aplicación que llega con el comando es validado contra el ID de la aplicación almacenado, y el comando es ejecutado o ignorado en consecuencia.

Proteger dispositivos de otros problemas de seguridad

Además de los problemas de autenticación, autorización y comunicaciones de los que hemos hablado hasta ahora, los dispositivos IoT tienen que protegerse de otras múltiples formas de ataques, mediante la utilización de estos tipos de medidas de seguridad:

  • Arranque seguro.
    El arranque seguro es importante para proteger de los ataques al código de arranque.La autenticidad e integridad del dispositivo se debe verificar durante el proceso de arranque inicial. Para verificar la autenticidad del dispositivo se puede utilizar una firma digital que se adjunta al software del dispositivo.
  • Actualización del firmware del dispositivo.
    El dispositivo debe estar protegido de todos los ataques maliciosos conocidos y desconocidos. Para garantizar que todos los dispositivos obtienen las actualizaciones normales, se debe desarrollar un mecanismo para instalar los parches de seguridad normales.
  • Registro y supervisión de incidentes.
    Todos los incidentes posibles de seguridad tienen que ser registrados y continuamente monitorizados. Toda actividad sospechosa en el dispositivo debería desencadenar inmediatamente quítela remoción del registro del dispositivo del broker.

Transporte seguro

IBM Watson IoT Platform soporta TLS 1.2, que puede ser utilizado para proteger los mensajes en el trayecto entre el dispositivo y el broker. Se puede eliminar el riesgo de hackeo del canal y los accesos a los mensajes no autorizados protegiendo la capa de transporte subyacente mediante el uso de SSL. En IBM Watson IoT Platform, se utiliza el puerto 8883 para las condiciones que soportan SSL, tal como se muestra en el código de abajo.

Listado 8. Comunicación del cliente cifrada
//tcp://<org-id>.messaging.internetofthings.ibmcloud.com:1883
//ssl://<org-id>.messaging.internetofthings.ibmcloud.com:8883
	if (isSSL) {
		connectionUri = "ssl://" + serverHost + ":" + DEFAULT_SSL_PORT;
	} else {
		connectionUri = "tcp://" + serverHost + ":" + DEFAULT_TCP_PORT;
	}

	//Si se utiliza SSL no olvide utilizar TLSv1.2
	if (isSSL) {
		java.util.Properties sslClientProps = new java.util.Properties();
		sslClientProps.setProperty("com.ibm.ssl.protocol", "TLSv1.2");
		options.setSSLProperties(sslClientProps);
	}

El error de la librería de arranque del IoT de IBM para Android e iOS No se encontró el código de referencia hace que sea más fácil utilizar MQTT y SSL en su aplicación. Puede utilizar la clase de encapsulado IoTClient proporcionada, como se muestra en el siguiente código:

Listado 9. Clase de encapsulado IoTClient
IoTClient iotClient = IoTClient.getInstance(
        context,
        orgId,
        deviceId,
        deviceType,
        authToken
);

try {
    IMqttToken mqttToken = iotClient.connectDevice(
            new DemoIoTCallbackHandler(),
            new DemoIoTActionListenerHandler(),
            (usingSSL ? createSslSocketFactory(context) : null)
    );

    mqttToken.waitForCompletion(DemoIoTApplication.DEFAULT_MQTT_CONNECT_TIMEOUT);
}
catch(MqttException e) {
    Log.e(“Error al conectar a IBM Watson IoT Platform: “+e);
}

El método createSslSocketFactory está definido de la siguiente manera.

Listado 10. El método createSslSocketFactory
private SocketFactory createSslSocketFactory(Context context) {
    SocketFactory factory = null;

    try {
        ProviderInstaller.installIfNeeded(context);

        KeyStore ks = KeyStore.getInstance("bks");
        ks.load(
                context.getResources().openRawResource(R.raw.iot), 
                "password".toCharArray());

        TrustManagerFactory tmf = TrustManagerFactory.getInstance("X509");
        tmf.init(ks);

        TrustManager[] tm = tmf.getTrustManagers();

        SSLContext sslContext = SSLContext.getInstance("TLSv1.2");
        sslContext.init(null, tm, null);

        factory = sslContext.getSocketFactory();
    }
    catch (Exception e) {
        Log.e(TAG, "Error al crear la factoría SSL : "+e);
    }

    return factory;
}

Mensajes cifrados de forma personalizada

Las opciones flexibles para imponer la seguridad multicapa y el cifrado pueden tranquilizar a los usuarios y proteger los datos sensibles para evitar que sean comprometidos. Los usuarios a veces prefieren un cifrado personalizado en vez de la protección SSL, o se pueden ver forzados a utilizarla cuando no se soporta la comunicación segura.

En este esquema, la aplicación cifra el mensaje antes de enviarlo al broker MQTT. Se intercambia la clave entre el dispositivo y la aplicación IoT y se utiliza para cifrar y descifrar los mensajes. IBM Watson IoT Platform actualmente no soporta la implicación personalizada, pero algunos otros brokeres MQTT, como HiveMQ, sí lo hacen.

En la Parte 2 de esta serie se describen detalles sobre las comunicaciones basadas en cifrados personalizados.

Conclusión

El enfoque correcto para la autenticación de dispositivos depende de la solución que usted esté diseñando y de los tipos de datos que estará manejando. Algunos puntos claves a recordar:

  • Utilice conexiones seguras si los datos del IoT son delicados. Tanto la autenticación como la comunicación segura (cifrado) son muy importantes.
  • Utilice el OTP cuando se requiera un nivel extra de seguridad, y cuando la seguridad física del dispositivo no sea alta, por ejemplo, cuando cualquiera pueda acceder al dispositivo físico.
  • Basándose en las capacidades del broker, utilice mecanismos como el OAuth para soportar proveedores de autorización externos.
  • Controle rigurosamente las autorizaciones a las suscripciones, probablemente mediante la utilización de cadenas de caracteres con temas fijos específicos, lo que previene que un cliente malicioso realice un número masivo de suscripciones.
  • Limite el tamaño de los mensajes para garantizar que ningún cliente o dispositivo pueda bloquear el broker por sí solo.
  • Si la gestión de certificados no es un problema, considere la emisión de certificados del cliente y sólo acepte conexiones de clientes con certificados.

Recursos para Descargar


Temas relacionados


Comentarios

Inicie Sesión o Regístrese para agregar comentarios.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Internet of Things
ArticleID=1034408
ArticleTitle=Diseñar y construir soluciones IoT seguras, Parte 1: Protegiendo dispositivos y gateways IoT
publish-date=06272016