Conteúdo


Projete e desenvolva soluções de IoT seguras, Parte 1

Protegendo dispositivos e gateways de IoT

Da autenticação, inclusive autenticação baseada em certificado, até autorização e validação de ID do aplicativo

Comments

Conteúdos da série:

Esse conteúdo é a parte # de # na série: Projete e desenvolva soluções de IoT seguras, Parte 1

Fique ligado em conteúdos adicionais dessa série.

Esse conteúdo é parte da série:Projete e desenvolva soluções de IoT seguras, Parte 1

Fique ligado em conteúdos adicionais dessa série.

A Internet of Things (IoT) apresenta enormes oportunidades para negócios e consumidores, especialmente nas áreas de assistência médica, armazenamento, transporte e logística. Juntamente com essa adoção generalizada, os desenvolvedores enfrentam novos desafios para garantir que os aplicativos de IoT sejam suficientemente seguros, porque manipulam muitos dados sensíveis. Como já foram relatadas várias violações de segurança em soluções de IoT, os desenvolvedores precisam dar ênfase ao desenvolvimento da segurança em seus aplicativos de IoT na hora de projetar e desenvolver tais soluções.

O foco desta série de artigos são as camadas arquiteturais de um aplicativo de IoT baseado em plataformas de nuvem IBM. Os artigos da série descrevem uma abordagem baseada em solução para minimizar riscos de segurança em aplicativos de IoT utilizando serviços que estão prontamente disponíveis em plataformas de nuvem IBM. Eles fornecem técnicas testadas para proteger aplicativos de IoT.

A Parte 1 da série descreve as várias abordagens para proteger dispositivos ou gateways. A Parte 2 dá ênfase aos aspectos de segurança da camada de rede e transporte, que inclui a IBM Watson IoT Platform. A Parte 3 fornece os requisitos de segurança para a camada de aplicativos, bem como uma abordagem de implementação para um aplicativo de IoT de analytics que é criado na plataforma do IBM Cloud.

À medida que os aplicativos de IoT coletam uma quantia cada vez maior de dados não expostos anteriormente—e, muitas vezes, privados—e permitem o acesso a várias funções de controle pela Internet, a segurança se torna um grande desafio.

Informações básicas sobre a segurança da IoT

As soluções de IoT envolvem uma rede complexa de dispositivos inteligentes, como veículos, máquinas, edificações ou eletrodomésticos, que possuem sistemas eletrônicos, softwares, sensores e conectividade de rede, permitindo que essas "coisas" coletem e troquem dados. As "coisas" na Internet of Things (em português, Internet das Coisas) capacitam os desenvolvedores a fornecer uma ampla gama de novos serviços com base em tais dispositivos físicos conectados e ativados por nuvem. À medida que os aplicativos de IoT coletam uma quantia cada vez maior de dados não expostos anteriormente—e, muitas vezes, privados—e permitem o acesso a várias funções de controle pela Internet, a segurança se torna um grande desafio.Portanto, um aplicativo de IoT precisa:

  • Evitar violações ou comprometimentos do sistema.
    Cada camada do aplicativo de IoT precisa implementar medidas preventivas para impedir a entrada de hackers. Por exemplo, é necessário reforçar o dispositivo para garantir que a comunicação entre ele e a nuvem seja segura.
  • Oferecer suporte ao monitoramento contínuo.
    Até mesmo os melhores sistemas protegidos ainda deixam muitas vulnerabilidades. Além disso, a melhor solução segura no momento (em termos de hardware e software) pode não ser suficientemente boa para evitar ataques no futuro. Por conseguinte, deve-se complementar as medidas de segurança com monitoramento contínuo e upgrade constante do sistema para proteger contra as formas mais recentes de ataque.
  • Ser resiliente.
    Por fim, se uma violação ocorrer, o dano precisa ser minimizado e o sistema precisa se recuperar o mais rápido possível.

Vulnerabilidades da IoT

São muitas as maneiras em que os desenvolvedores podem aplicar tecnologias de IoT para criar soluções de IoT. Podem criar um sistema simples de monitoramento residencial que fornece alertas para smartphones e smartwatches ou podem criar sistemas complexos de assistência médica que coletam dados e controlam uma rede de dispositivos de pacientes,—além de muitas oportunidades para soluções que ainda não conseguimos imaginar.

No entanto, a conexão de objetos como carros, residências e máquinas expõe muitos dados sensíveis, tais como a localização das pessoas em uma edificação ou os registros médicos de pacientes. Esses dados precisam ser protegidos em conformidade com os principais princípios de segurança de informações, ou seja, a tríade da Agência Central de Inteligência dos Estados Unidos: confidencialidade, integridadee disponibilidade.

Qualquer dispositivo com conectividade de rede é vulnerável. Os dados pessoais coletados por dispositivos de IoT sempre têm valor para hackers de dados e ladrões de identidade. Além disso, um ataque cibernético a soluções de IoT tem o potencial de incapacitar serviços e infraestruturas físicos. Por exemplo, hackers atacaram um Jeep Cherokee enquanto estava sendo dirigido em uma estrada. Portanto, aplicativos de IoT seguros não são essenciais apenas para a reputação da empresa, mas também para a saúde física e para o bem-estar dos clientes e usuários da solução.

Em um estudo de dois anos, foram demonstradas as vulnerabilidades de segurança de dispositivos conectados em hospitais. Um dos principais problemas encontrados estava relacionado a serviços da web integrados que permitiam que os dispositivos se comunicassem entre si e alimentassem dados digitais diretamente para os registros médicos dos pacientes—sem um mecanismo adequado de autenticação ou criptografia! Um estudo semelhante demonstrou as vulnerabilidades de segurança de babás eletrônicas.

Os desafios do projeto de segurança da IoT

Embora a importância da segurança da IoT seja amplamente entendida e aceita, o projeto e a implementação reais dessa segurança geram novos desafios e oportunidades para criatividade. No projeto de praticamente qualquer app, os desenvolvedores sempre precisam fazer uma troca entre segurança e usabilidade. No caso das soluções de IoT, isso se torna ainda mais problemático. Muitas vezes, os dispositivos de IoT têm energia de computação e capacidade de memória limitadas, o que dificulta o uso de algoritmos criptográficos complexos que exigem mais recursos do que eles oferecem.

Outro desafio é atualizar os dispositivos de IoT com correções e atualizações regulares de segurança. Colocar patches de segurança em todos os dispositivos de uma vez pode ser uma tarefa muito difícil em redes de dispositivos não confiáveis e com baixa largura de banda; ademais, muitas medidas de segurança existentes, como segurança do navegador da web, podem não estar disponíveis para aplicativos de IoT.

Além disso, mecanismos de segurança talvez precisem ser desenvolvidos ou aprimorados para os novos protocolos que são criados especificamente para a Internet of Things, tais como Message Queuing Telemetry Transport (MQTT) e Constrained Application Protocol (CoAP). Portanto, é extremamente importante incluir as considerações de segurança desde o início ao projetar apps de IoT.

Desenvolvendo aplicativos de IoT seguros

Em sua maioria, as soluções de IoT têm três camadas principais. Os componentes da solução de IoT executados em cada camada precisam incorporar medidas específicas de segurança para proteger contra várias vulnerabilidades.

  • Camada de Dispositivos/Gateways: Protegem contra um servidor "falso" que envia comandos maliciosos ou protegem contra um hacker que tenta ouvir dados privados de um sensor que estão sendo enviados a partir dos dispositivos. As considerações de segurança para essa camada são discutidas na Parte 1 (deste artigo).
  • Camada de Rede/Transporte: Protegem contra um dispositivo "falso" que envia medições falsas capazes de corromper os dados que persistem no aplicativo. As considerações de segurança para essa camada serão discutidas na Parte 2.
  • Camada de Aplicativos: Protegem contra o uso inválido dos dados ou protegem contra a manipulação de processos analíticos que são executados na camada de aplicativos. As considerações de segurança para essa camada serão discutidas na Parte 3.

Em um dispositivo de IoT, a camada de aplicativos oferece a maior superfície de ataques para hackers. Essa camada inclui qualquer aplicativo que tenha conectividade com o dispositivo de IoT, o que pode incluir aplicativos locais da web, aplicativos baseados em nuvem e apps móveis.

A segurança do aplicativo precisa ser uma parte intrínseca do ciclo de vida de desenvolvimento do software (SDLC) para todos os aplicativos de IoT, especialmente durante os estágios de projeto, desenvolvimento e teste. No estágio de planejamento ou projeto de um aplicativo de IoT, precisa acontecer uma avaliação completa dos requisitos de segurança e privacidade do aplicativo planejado.

O diagrama abaixo mostra as três camadas de um aplicativo típico de IoT que usa a IBM Watson IoT Platform na camada de rede/transporte e a plataforma de nuvem do IBM Cloud na camada de aplicativos.



A tabela a seguir descreve resumidamente cada camada e as considerações de segurança que os desenvolvedores precisam priorizar.

Camada Descrição Considerações de segurança
Aplicativos Os aplicativos de IoT são implementados na plataforma do IBM Cloud.
  • Segurança do aplicativo
  • Chamada segura da API para a IBM Watson IoT Platform
  • Segurança do Node-RED
  • Decriptografia de mensagens
  • Checagem da soma de verificação da mensagem
Rede/Transporte A IBM Watson IoT Platform oferece uma plataforma de sistema de mensagens baseada em MQTT para os aplicativos de IoT.
  • Autenticação de dispositivos (apenas dispositivos confiáveis podem enviar dados)
  • Autorização
  • Segurança da API
  • Configuração de segurança
  • Transporte seguro
Dispositivos/Gateways Os dispositivos (diretamente ou por meio de gateways) publicam os dados do sensor na IBM Watson IoT Platform e recebem instruções para executar funções de controle.
  • Autenticação
  • Criptografia da carga útil da mensagem
  • Provisão e verificação de certificado
  • Transporte seguro por MQTT
  • Inicialização segura
  • Firewalls
  • Atualizações e correções de firmware

Protegendo dispositivos

O foco da segurança do dispositivo é assegurar que um conjunto confiável de dispositivos seja utilizado na solução e que tais dispositivos possam confiar no broker ou aplicativo que está enviando os comandos de controle. Este artigo fala sobre vários tipos de mecanismos de segurança que podem ser usados para estabelecer tal confiança.

Além disso, desenvolvemos (em JavaFX) um programa de simulador de dispositivo que demonstra estes mecanismos de segurança:

  • Autenticação de ID do Usuário/Senha
  • Autenticação de senha descartável (OTP)
  • Autenticação de ID exclusivo do servidor
  • Autenticação da carga útil da mensagem

Consulte a captura de tela a seguir do simulador de dispositivo.

 

É possível fazer o download do código referente ao programa de simulador de dispositivo e seguir as instruções no arquivo leia-me para desenvolvê-lo e executá-lo localmente.

O MQTT é o protocolo de sistema de mensagens mais popular para dispositivos e aplicativos de IoT, recebendo suporte de muitos dos principais nomes no campo da IoT. O MQTT oferece um protocolo de comunicação leve e fácil de usar para soluções de IoT.

Ele mesmo especifica alguns mecanismos de segurança, mas todas as implementações comuns oferecem suporte a padrões de segurança de ponta, como SSL/TLS para segurança no transporte. Não impõe a utilização de uma abordagem específica de segurança para seus aplicativos, deixando isso para o designer do aplicativo. Por conseguinte, as soluções de IoT podem ser baseadas no contexto do aplicativo e em requisitos específicos de segurança.

Como a maioria das implementações do MQTT usa segurança da camada de transporta (TLS), os dados são criptografados e sua integridade é validada. Da mesma forma, a maioria das implementações do MQTT (inclusive a da IBM Watson IoT Platform) também usa funcionalidades de autorização no servidor MQTT para controlar o acesso.

Além do programa de simulador de dispositivo, é oferecido um aplicativo cliente de broker que exibe as mensagens do MQTT recebidas do dispositivo e envia amostras de comandos para ele. Esse aplicativo de amostra do aplicativo cliente de broker gera a chave OTP para autenticação do dispositivo e envia o ID exclusivo do aplicativo para verificação do aplicativo pelos dispositivos. O cliente gera mensagens de comando —mensagens válidas e inválidas—com o objetivo de testar diferentes cenários.

É possível fazer o download do código para o aplicativo cliente de brokere seguir as instruções no arquivo leia-me para desenvolvê-lo e executá-lo localmente.

Autenticação do dispositivo

A autenticação faz parte da segurança no nível de transporte e aplicativo no MQTT. No nível de transporte, a TLS pode garantir a autenticação do cliente para o servidor utilizando certificados de cliente, bem como do servidor para o cliente validando o certificado de servidor. No nível do aplicativo, o protocolo MQTT oferece autenticação de nome de usuário/senha.

Os desenvolvedores podem utilizar várias abordagens para assegurar que o dispositivo certo seja registrado com o broker. A seleção da abordagem certa depende das necessidades de segurança da solução e da capacidade do dispositivo de executar a abordagem necessária.

As seções abaixo descrevem algumas dessas abordagens. Eclipse Paho é utilizada como a biblioteca do cliente do MQTT para as amostras de código.

Autenticando com um nome de usuário e senha

O protocolo MQTT fornece os campos username e password na mensagem CONNECT para a autenticação do dispositivo. Um cliente precisa enviar um nome de usuário e senha quando se conecta com um broker MQTT.

O nome de usuário é uma cadeia de caractere codificada em UTF-8; a senha é composta por dados binários. Cada um tem, no máximo, 65535 bytes. O protocolo não criptografa o nome de usuário ou a senha e, exceto se a criptografia de transporte for utilizada, eles são enviados em formato de texto não criptografado.

Lista 1. Campos nome de usuário e senha
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 com um token de acesso

Se o cliente tiver recuperado um token de acesso com êxito, ele pode ser enviado ao broker na mensagem CONNECT usando o campo password . O nome de usuário pode ser uma cadeia de caractere especial para reconhecer o token de acesso. O tamanho limite de uma senha no MQTT é de 65535 bytes; portanto, o token não pode ultrapassar esse limite.

O broker pode utilizar o token para realizar várias validações, tais como:

  • Verificar a validade da assinatura do token
  • Verificar se a data de vencimento do token já passou
  • Verificar o servidor de autorização para ver se o token foi revogado

As mesmas validações que são utilizadas quando o dispositivo se conecta com o broker MQTT podem ser usadas quando aplicativos são publicados ou assinados. No entanto, ao publicar ou assinar, o broker também precisa autorizar o aplicativo. Essa autorização pode ser feita de duas maneiras:

  • O token inclui a autorização para o cliente na solicitação de escopo.
  • O broker faz uma origem de terceiros, como um banco de dados ou diretório do LDAP, procura as autorizações para o cliente.

Os aplicativos da IBM Watson IoT Platform podem ser autenticados pelo ID, chave e token do aplicativo. A chave e o token do aplicativo de IoT podem ser gerados durante o registro do aplicativo e podem ser usados na hora de conectar à IBM Watson IoT Platform, como mostrado no exemplo abaixo:

Lista 2. Chaves e tokens do aplicativo
Propriedades do app

# Um ID exclusivo escolhido por você, talvez abcdefg123456
appid=<Your_application_id>

# O campo Key das informações de App Keys que copiou
anteriormente key=<Key>

# O campo Auth Token das informações de App Keys que copiou
anteriormente token=<Token>
Código do app durante a conexão:

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

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

Autenticando com autenticação de senha descartável (OTP)

Além dos mecanismos de autenticação fornecidos pelo MQTT, os aplicativos de IoT talvez precisem implementar uma segurança adicional para identificar o dispositivo adequado. Este artigo descreve uma abordagem para implementar a autenticação baseada em OTP para tais situações. A autenticação de OTP pode ser um mecanismo útil para proteger um dispositivo contra o uso inadequado eliminando o risco de acesso por usuários não autorizados.

Com esse método, apenas usuários autenticados são capazes de iniciar a comunicação de dados com o aplicativo de IoT após a inicialização do dispositivo. Como nem todos os dispositivos têm capacidade de entrada em teclado, um comutador de propriedade simples pode ser implementado para ativar ou desativar esse esquema de segurança com base no tipo de dispositivo. Quando a autenticação de OTP está ativada, o dispositivo envia uma solicitação de OTP para o aplicativo de broker da IoT após a inicialização usando um sistema de mensagens normal do MQTT. O fluxo detalhado é mostrado no gráfico abaixo.

 

Lista 3 mostra como a autenticação de OTP pode ser ligada e desligada com uma propriedade do dispositivo. Quando a autenticação de OTP está ativada, o dispositivo envia uma solicitação de OTP para o aplicativo de broker da IoT após a inicialização usando um sistema de mensagens normal do MQTT.

Lista 3. Solicitação de OTP
		// Create the request for OTP
		JSONObject idObj1 = new JSONObject();
		try {
			idObj1.put("event", "server_otp_request");
			idObj1.put("deviceId", deviceIdentifier);
		} catch (JSONException e1) {
			System.out.println("Exception occurred");
			e1.printStackTrace();
		}
		new SendMessageToServer("server_otp_request", idObj1).start();
		System.out.println("otp request sent....");
	}

O app de IoT gera um OTP, envia-o para o proprietário do dispositivo separadamente e envia uma notificação para o dispositivo, como mostrado na listagem a seguir.

Lista 4. Gerar 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()));

		     // Server starts a timer of 5 mins during which the
		     // OTP is valid.
				task = new TimeOutTask();
				t = new Timer();
				t.schedule(task, 30000000L);

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

			// Publish command to one specific device
			// iot-2/type/<type-id>/id/<device-id>/cmd/<cmd-id>/fmt/<format-id>
			new SendMessageToDevice(strDeviceId, "server_otp_response", jsonObj)
					.start();

Como mostrado na Lista 5, a OTP é inserida no dispositivo e o dispositivo a envia para o app do broker. O app do broker valida a OTP enviada pelo dispositivo e envia uma mensagem de sucesso/falha (OTP incorreta ou tempo limite atingido) para o dispositivo. O dispositivo pode tentar novamente a autenticação de OTP com base em uma contagem de novas tentativas da configuração.

Se a autenticação de OTP não for concluída com sucesso mesmo após uma nova tentativa, o aplicativo será encerrado. Se a autenticação de OTP não estiver ativada, o dispositivo vai ignorá-la após a inicialização.

Lista 5. Validar a autenticação de OTP
	if (receivedOTP.equals(otp)) {
	    if (task.isTimedOut) {
		// User took more than 100 seconds and hence the OTP is invalid
		System.out.println("Time out!");
		otpValidated = false;
		otpTimeOut = true;
	    } else {
		System.out.println("OTP validated..");
		otpValidated = true;
		otpTimeOut = false
	    }
	} else {
	    System.out.println("Incorrect OTP..");
	    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("Result of OTP validation -  " + otpValidated);
	// Publish command to one specific device
	    new sendMessageToDevice(strDeviceId, "server_otp_validate",
		otpRespObj).start();

  }

Autenticação baseada em certificado

Alguns brokers (como o HiveMQ, um broker MQTT que pode ser utilizado para ativar recursos de M2M e IoT para empresas) fornecem suporte a certificados de dispositivo que o broker pode usar como parte de um processo de autenticação mútua. Em aplicativos em que os requisitos de segurança são muito rigorosos e os dispositivos podem fornecer certificados, esse tipo de autenticação deve ser considerado.

Este artigo usa o HiveMQ para demonstrar a autenticação SSL bidirecional baseada em certificado. Utiliza apenas o MQTT padrão como protocolo para a comunicação do dispositivo. As amostras de código inclusas que demonstram a criptografia/decriptografia da carga útil foram testadas na IBM Watson IoT Platform e no HiveMQ.

Se o HiveMQ ainda não estiver instalado, você deve instalá-lo caso queira continuar. É fácil fazer o download, instalar e iniciar seguindo as etapas descritas em hivemq.com. Plug-ins opcionais podem ser usados para recuperar as mensagens retidas do HiveMQ. O cliente MQTT funciona com o HiveMQ da mesma maneira que funciona com a IBM Watson IoT Platform.

O programa de simulador de dispositivo e a demonstração do aplicativo cliente de broker do MQTT demonstram a autenticação baseada em certificado. O dispositivo e o aplicativo executam uma verificação mútua de certificado com o HiveMQ.

É possível fazer o download do código referente à demonstração de autenticação de certificadoe seguir as instruções no arquivo leia-me para desenvolvê-lo e executá-lo localmente.

Gerando o certificado

Siga as etapas abaixo para gerar um certificado para a autenticação. Esse procedimento usa a keytool que está no mesmo pacote que o Java Runtime Environment.

  1. Gerar a chave do dispositivo e o keystore
    keytool -genkey -alias iotdevice1 -keyalg RSA -keypass devicepass -storepass devicepass -keystore iot_device_keystore.jks -storetype jks
  2. Exportar o certificado do dispositivo do keystore
    keytool -export -alias iotdevice1 -storepass devicepass -file iotdevice1.cer -keystore iot_device_keystore.jks
  3. Incluir o certificado do dispositivo no truststore do broker
    keytool -import -v -trustcacerts -alias iotdevice1 -file iotdevice1.cer -keystore iot_broker_truststore.jks -keypass devicepass -storepass brokerpass -storetype jks
  4. Gerar a chave do broker e o keystore
    keytool -genkey -alias broker -keyalg RSA -keypass brokerpass -storepass brokerpass -keystore iot_broker_keystore.jks -storetype jks
  5. Exportar o certificado do broker
    keytool -export -alias broker -storepass brokerpass -file broker.cer -keystore iot_broker_keystore.jks
  6. Incluir o certificado no truststore do dispositivo
    keytool -import -v -trustcacerts -alias broker -file broker.cer -keystore iot_device_truststore.jks -keypass brokerpass -storepass brokerpass -storetype jks

A mesma abordagem pode ser estendida para diversos dispositivos. Todos os certificados de dispositivos devem ser incluídos no truststore do broker e o certificado do broker deve estar no truststore de todos os dispositivos.

Configurando o HiveMQ para autenticação baseada em certificado

Como mostrado no Lista 6, o HiveMQ é configurado com o keystore do broker e o truststore do broker usando o arquivo config.xml .

Lista 6. HiveMQ configurado com o keystore do broker e o truststore
<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>

Em seguida, o manipulador MQTT é configurado com o keystore e o truststore do dispositivo, como mostrado na listagem a seguir:

Lista 7. Manipulador MQTT configurado com o keystore do dispositivo e o truststore
if (isSSL) {
		java.util.Properties sslClientProps = new java.util.Properties();

            // Set the SSL properties
		sslClientProps.setProperty("com.ibm.ssl.protocol", "TLSv1.2");
		sslClientProps.setProperty("com.ibm.ssl.contextProvider", "SunJSSE");

            // Set the keystore properties
		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");

            // Set the trust store properties
		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' is an instance of MqttConnectOptions
		options.setSSLProperties(sslClientProps);
	}

Autenticando com certificados de cliente

Apesar de a autenticação baseada em certificado oferecer um alto nível de segurança para alguns aplicativos, não é fácil implementar essa abordagem e o gerenciamento dos ciclos de vida dos certificados para vários dispositivos pode ser dispendioso. Contudo, se uma empresa já tem uma infraestrutura semelhante em vigor e gerencia todos os componentes do MQTT (dispositivos e brokers), a abordagem pode ser considerada.

A IBM Watson IoT Platform não fornece suporte para a autenticação baseada em certificado de cliente. Pode, no entanto, ser implementada com outros brokers, como o HiveMQ.

O MQTT pode usar TLS para a criptografia do transporte. Para utilizar a TLS, o servidor precisa ter um par de chaves públicas/privadas. Quando o handshake da TLS é realizado, os clientes precisam validar o certificado X509 do servidor—que também contém sua chave pública—antes que uma conexão segura possa ser estabelecida.

Além dos certificados de servidor, os clientes também podem ter um par exclusivo de chaves públicas/privadas para implementar o protocolo de handshake da TLS. O cliente envia seu certificado (que inclui a chave pública do cliente) como parte do handshake da TLS após o certificado ser validado. Em seguida, o servidor consegue verificar a identidade do cliente e pode cancelar o handshake em caso de falha na verificação do certificado de cliente. Essa prática permite a autenticação do cliente antes de uma conexão segura ser estabelecida.

A implementação dos certificados de cliente tem estas vantagens:

  • Verificação da identidade dos clientes MQTT
  • Autenticação dos clientes MQTT no nível de transporte
  • Bloqueio de clientes MQTT inválidos antes do envio das mensagens MQTT CONNECT

Se você usa certificados de cliente, somente clientes confiáveis podem estabelecer uma conexão segura. Essa configuração pode economizar recursos no lado do broker, especialmente se mecanismos dispendiosos de autenticação MQTT (como consultas ao banco de dados ou chamadas de serviços da web) forem usados nele. Como a autenticação ocorre no handshake da TLS, ela é feita antes que uma conexão possa ser estabelecida.

Embora os certificados de cliente do X509 proporcionem uma camada extra de segurança, esse tipo de autenticação tem um custo. A provisão do cliente MQTT é mais complexa com certificados de cliente; um mecanismo de anulação de certificado é necessário.

  • Implementando certificados de cliente: Para usar certificados de cliente, um processo de provisão deve ser definido. Esse processo é definido quando empresas têm controle dos seus dispositivos e possuem um processo bem definido de atualização de firmware. Os certificados de cliente podem ser fornecidos durante a atualização de firmware. Outras considerações são necessárias para gerenciar o ciclo de vida (inclusive o vencimento) de certificados nos dispositivos.
  • Anulação de certificado: Quando não é mais possível confiar em um certificado de cliente (por exemplo, se ele foi vazado), torna-se importante invalidá-lo. Se o certificado foi vazado e está sendo utilizado por clientes maliciosos, o servidor precisará de uma maneira de identificar o certificado inválido e proibir clientes de se conectarem a ele.

Autorização do dispositivo

Um mecanismo de autorização impedirá o vazamento de dados entre dois dispositivos.

O MQTT é um protocolo de publicação/assinatura baseado em tópico. Cada mensagem é publicada em um tópico nomeado, enquanto cada assinatura tem um filtro de tópico que pode incluir curingas. Portanto, a autorização é em termos de publicação/assinatura e nomes de tópicos. A maioria dos servidores MQTT tem alguma maneira de conceder autoridade para publicar e realizar assinaturas em tópicos.

Na IBM Watson IoT Platform, essa autorização é imposta por meio da implementação de padrões seguros de sistema de mensagens. Depois de autenticados, os dispositivos são autorizados apenas a publicar e assinar um espaço de tópico restrito, por exemplo:

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

Todos os dispositivos funcionam com o mesmo espaço de tópico. As credenciais de autenticação que são fornecidas pelo cliente de conexão determinam para qual dispositivo esse espaço de tópico será investigado pela IBM Watson IoT Platform.Essa configuração evita que os dispositivos sejam capazes de personificar outro dispositivo. A única maneira de personificar outro dispositivo é obtendo credenciais comprometidas de segurança para ele.

Autorização do aplicativo com OAuth 2.0

Em casos em que as empresas desejam usar o mecanismo centralizado de autorização para dispositivos MQTT, é possível utilizar uma estrutura baseada em OAuth. O OAuth 2.0 possibilita a separação do servidor de autorização de um servidor de recurso, como um servidor MQTT. Quando o OAuth 2.0 é usado, o cliente apresenta suas credenciais para o servidor de autorização, que, em seguida, executa a verificação de autenticação e gera um token de acesso que concede permissão para acessar um recurso.

Depois, o token de acesso é usado para se conectar ao servidor MQTT. O servidor MQTT valida o token de acesso, geralmente se comunicando com o servidor de autorização, e concede acesso ao recurso. O fluxo é representado no diagrama a seguir:

Validação do ID do aplicativo

A validação do ID do aplicativo é um nível extra de segurança entre o aplicativo de IoT e o dispositivo para impedir um aplicativo falso de enviar comandos ao dispositivo. Esse mecanismo pode ser usado como um mecanismo de segurança na inicialização e de segurança na comunicação. Ao utilizar tal esquema, o dispositivo armazena o ID exclusivo do aplicativo de IoT e o valida quando processa os comandos que estão vindo desse aplicativo.

Se o aplicativo de IoT enviar um ID exclusivo inválido com um comando, o comando será ignorado pelo dispositivo. Se o dispositivo tiver capacidade de armazenamento, o ID exclusivo do aplicativo de IoT poderá ser criptografado e armazenado. Nesse caso, a solicitação de ID exclusivo não é necessária após cada reinicialização.

O fluxo detalhado é mostrado no diagrama a seguir:

 

O diagrama acima representa os aspectos a seguir do fluxo:

  • A validação do ID do aplicativo pode ser ligada e desligada com base na capacidade do dispositivo.
  • Durante a reinicialização, se a validação do ID do aplicativo estiver ativada e o armazenamento do ID exclusivo do aplicativo estiver ativado, o dispositivo tentará restaurar o ID exclusivo do aplicativo de IoT a partir de um arquivo criptografado.
  • Caso não consiga carregar o ID exclusivo do aplicativo, o dispositivo inicia uma solicitação para obter o aplicativo.
  • Após receber a solicitação, o aplicativo de IoT envia o ID exclusivo para o dispositivo.
  • O dispositivo armazena o ID exclusivo na memória e em um arquivo (se tiver capacidade de armazenamento).
  • Depois disso, o dispositivo espera o mesmo ID do aplicativo em cada comando que vem do aplicativo de IoT.
  • Se houver uma incompatibilidade, o comando será ignorado pelo dispositivo.

A captura de tela a seguir do aplicativo de amostra do simulador do dispositivo mostra o uso do ID do aplicativo Em cada instância, o ID exclusivo do aplicativo que vem com o comando é validado com relação ao ID do aplicativo armazenado; o comando é executado ou ignorado de acordo.

Protegendo dispositivos de outros problemas de segurança

Além dos problemas de autenticação, autorização e comunicação que foram discutidos até o momento, os dispositivos de IoT precisam ser protegidos de várias outras formas de ataque usando esses tipos de medidas de segurança:

  • Inicialização segura.
    Uma inicialização segura é importante para proteger o código de inicialização de ataques. A autenticidade e a integridade do dispositivo devem ser verificadas durante o processo de inicialização inicial. Uma assinatura digital ligada ao software do dispositivo pode ser usada para verificar a autenticidade do dispositivo.
  • Upgrade do firmware do dispositivo.
    O dispositivo deve ser protegido de todos os ataques maliciosos conhecidos e desconhecidos. Um mecanismo para instalar patches regulares de segurança deve ser desenvolvido a fim de assegurar que todos os dispositivos recebam upgrades regulares.
  • Criação de logs e monitoramento de incidentes.
    Todos os possíveis incidentes de segurança precisam ser registrados e monitorados continuamente. Qualquer atividade suspeita no dispositivo deve acionar imediatamente a remoção de registro do dispositivo do broker.

Transporte seguro

A IBM Watson IoT Platform oferece suporte para a TLS 1.2, que pode ser usada para proteger as mensagens em andamento entre o dispositivo e o broker. O risco de hackeamento de canal e acesso não autorizado às mensagens pode ser eliminado se a camada de transporte subjacente for protegida usando SSL. Na IBM Watson IoT Platform, a porta 8883 é utilizada para conexões suportadas por SSL, como mostrado na listagem abaixo.

Lista 8. Comunicação criptografada de cliente
//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;
	}

	//If SSL is used, do not forget to use TLSv1.2
	if (isSSL) {
		java.util.Properties sslClientProps = new java.util.Properties();
		sslClientProps.setProperty("com.ibm.ssl.protocol", "TLSv1.2");
		options.setSSLProperties(sslClientProps);
	}

A biblioteca do inicializador da IoT IBM para o erro de Android e iOS Reference source not found facilita a utilização de MQTT e SSL no seu aplicativo. É possível usar a classe do wrapper IoTClient fornecida, como mostrado na listagem a seguir:

Lista 9. Classe do wrapper 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 connecting to IBM Watson IoT Platform: “+e);
}

O método createSslSocketFactory é definido conforme segue.

Lista 10. O 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 creating SSL factory: "+e);
    }

    return factory;
}

Personalizar mensagens criptografadas

Opções flexíveis para impor segurança e criptografia em várias camadas podem tranquilizar os funcionários e impedir dados sensíveis de serem comprometidos. Às vezes, os usuários preferem criptografia personalizada à proteção SSL ou poderão ser forçados a usá-la quando não houver suporte para uma comunicação segura.

Nesse esquema, o aplicativo criptografa a mensagem antes de enviá-la para o broker MQTT. A cifra é trocada entre o dispositivo e o aplicativo de IoT e é utilizada para criptografar ou decriptografar as mensagens. Atualmente, a IBM Watson IoT Platform não fornece suporte para a criptografia personalizada, mas alguns outros brokers do MQTT fazem isso, como o HiveMQ.

Os detalhes da comunicação personalizada baseada em criptografia são descritos na Parte 2 desta série.

Conclusão

A abordagem ou abordagens corretas para a autenticação de dispositivos dependem da solução que está sendo projetada e do tipo de dados que ela vai manipular. Alguns pontos importantes que devem ser lembrados:

  • Utilize conexões seguras caso os dados de IoT sejam sensíveis. A autenticação e a comunicação segura (criptografada) são muito importantes.
  • Utilize o OTP quando um nível extra de segurança for necessário e quando a segurança do dispositivo físico não for alta; por exemplo, quando qualquer pessoa puder acessar o dispositivo físico.
  • Com base nas capacidades do broker, use mecanismos como OAuth para fornecer suporte a provedores externos de autorização.
  • Controle rigorosamente a autorização a assinaturas, provavelmente utilizando cadeias de caractere específicas de tópico fixo, o que impede um cliente malicioso de fazer um número elevado de assinaturas.
  • Limite o tamanho das mensagens para impedir um cliente ou dispositivo de bloquear o broker por conta própria.
  • Se o gerenciamento de certificado não for um problema, considere a possibilidade de emitir certificados de cliente e aceitar conexões apenas de clientes com certificados.

Recursos para download


Temas relacionados


Comentários

Acesse ou registre-se para adicionar e acompanhar os comentários.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Internet of Things
ArticleID=1034415
ArticleTitle=Projete e desenvolva soluções de IoT seguras, Parte 1: Protegendo dispositivos e gateways de IoT
publish-date=05242016