Nesta secção irá proceder-se uma visão geral sobre a arquitetura que é proposta nesta dissertação.
Figura 5.2: Esquema de alto nível de uma arquitetura para uma plataforma IoT com mecanis- mos de segurança de dados aplicados
Na Figura 5.1 está presente um esquema de uma arquitetura de uma plataforma IoT convencional, isto é, sem mecanismos de segurança de dados aplicados.
Como foi explicado na Secção 2.1, todos os sistemas IoT têm três componentes a muito alto nível: os produtores de dados, uma plataforma IoT e os consumidores de dados. Efetuando a ligação ao esquema apresentado na Secção 2.3, os produtores situam-se na camada mais baixa do sistema (primeira camada do modelo de referência da Cisco), os consumidores nas camadas mais altas do sistema (camada 6 e 7 do modelo de referência) e a plataforma IoT que engloba todas as restantes camadas do modelo de referência.
Na Figura 5.2 está presente um esquema de arquitetura da plataforma IoT onde foram aplicados mecanismos de segurança ao nível dos dados. Todos os componentes presentes na Figura 5.1 necessitaram de ser alterados e foi necessário adicionar 3 entidades/componentes adicionais. De notar que a plataforma IoT representada nestas figuras, inclui vários componentes elementares presentes na Figura 2.4. É o caso da base de dados, domínio de rede, componente de enriquecimento e barramento de mensagens. Nenhum destes componentes necessitou de ser alterado, no entanto, a plataforma IoT sofreu adições de novos componentes.
A essência nesta solução está no facto de não poder dar o acesso total aos dados mesmo que seja aos seus consumidores. Isto porque, se tal acontecer, a privacidade dos utilizadores donos destes dados pode ser posta em causa, pois nem os consumidores dos dados, nem a plataforma IoT podem ser, muitas vezes, confiáveis. Para tal é necessário efetuar uma transformação dos dados originais para que o consumidor não
tenha acesso aos dados na sua íntegra, mas sim a uma determinada transformação desses dados que, mesmo não sendo os originais, pode proporcionar informação útil ao consumidor enquanto que, ao mesmo tempo, o acesso detalhado aos dados é evitado. Este processamento sobre os dados existente de forma a poder fornecer o anonimato desejado poderia ser efetuado de forma automática através de mecanismos de anonimato como k-anonimato. Mesmo que a utilização destes mecanismos possa ser fiável no que toca à manutenção da privacidade, não é garantido que os dados sejam realmente úteis para os consumidores. Para além disso, existe ainda o problema de o utilizador não dar a autorização necessária para que o consumidor tenha acesso aos dados. Finalmente, outro problema do k-anonimato é o facto de este não funcionar sobre dados cifrados. Tal implicaria que os dados chegassem à plataforma em claro, o que se está a tentar evitar nesta dissertação.
A transformação destes dados terá de ser efetuada através de um certo programa (código). Este terá de ser elaborado pelo próprio consumidor de dados uma vez que pode ser malicioso ou pode criar uma transformação/generalização dos dados não suficientemente correta e não respeitando a privacidade do utilizador. Assim, este programa terá de ser validado. Esta validação é feita através de uma certificação desse código, adicionando opcionalmente uma asserção assinada (Secção 5.2) contendo certas condições de processamento/utilização dos dados também certificadas. A inclusão desta asserção não foi implementada, no entanto a sua inclusão é simples de ser efetuada caso a entidade que valida o código necessite de estabelecer certas restrições de utilização do código. Esta certificação de código terá de ser efetuada por uma entidade confiável terceira, pois não poderíamos atribuir este papel a outro componente/entidade. Ao efetuar uma distribuição de poderes como esta, estamos a aumentar o nível de segurança de todo o sistema, sendo que um atacante que tome controlo sobre uma destas entidades não poderá comprometer a privacidade dos donos dos dados que estão a ser atacados. De forma a executar o código certificado, deve existir uma entidade para o fazer: o componente de processamento ilustrado na Figura 5.2. Esta terá acesso aos dados em claro, uma vez que é a entidade que, exclusivamente, irá fazer o processamento e transformar os dados. Este componente não necessita de ter interface com o utilizador e tem o único propósito de efetuar esse processamento e enviar os resultados de volta. Este componente terá de poder criar ambientes de execução para a execução de código não permitindo o acesso ao sistema fora do seu ambiente de execução. Este pode pertencer e ser registado no domínio seguro do utilizador ou então pertencer a uma entidade terceira confiável onde o utilizador terá que alugar e registar-se pelo serviço a fim de utilizar recursos computacionais para efetuar essa execução. Uma vez que se pretende distribuir os poderes sobre os diversos tipos de informação por entidades/componentes diferentes, caso tais componentes não possam pertencer ao domínio do utilizador, convém que uma
TTP seja utilizada para tal.
O consumidor necessita de autorização por parte do utilizador dos dados para lhes poder aceder e efetuar o processamento referido acima. Para tal, é introduzido, finalmente, a TTP de autorização (Figura 5.2). Este componente pode pertencer ao domínio de segurança do utilizador. Caso contrário, o utilizador necessitará de aderir a um serviço deste género, pertencente a uma entidade terceira confiável. Este componente ou entidade terá de ter uma interface com o utilizador. Este último irá ter o poder de autorizar e verificar a autenticidade dos registos dos seus equipamentos produtores (gateways/dispositivos), de autorizar explicitamente, e com a sua própria intervenção, o acesso aos seus dados privados, terá também de armazenar informação do utilizador (caso seja uma entidade externa confiável) e guardar e associar chaves criptográficas usadas na cifra dos dados com identificadores não persistentes dos seus equipamentos produtores. No caso de uso que se tem vindo a considerar dos medidores de eletricidade inteligentes, caso o utilizador permita que o fornecedor de serviços em que estão registados os equipamentos assim como o próprio utilizador, aceda aos seus dados privados de forma a que estes sejam transformados, é emitida uma asserção Security Assertion Markup Language (SAML), cujas condições de utilização são assinadas. Esta asserção constitui uma prova de que, qualquer que seja o lugar onde esta chegue, determinada entidade tenha acesso a determinados dados utilizando um determinado código certificado e utilizando uma determinada TTP de processamento para o efeito. Esta asserção será mais tarde validada pelo componente de processamento.
A arquitetura que aqui é proposta introduz vários componentes TTPs. No entanto, existem dois componentes que não necessitam de ser uma entidade terceira por si só. Estes dois componentes são o de processamento e o de autorização. Como será explicado com detalhe, mais à frente, caso estes dois componentes estejam sob o controlo dos utilizadores fisicamente e, portanto, dentro de um perímetro seguro, o sistema ganha uma maior segurança e não é necessário confiar em entidades externas adicionais.
O componente TTP certificador de código terá de ser uma entidade terceira confiável pelo utilizador e pela TTP de processamento que o utilizador tem sob controlo.