Realizar implementac¸˜ao

Ap´os a definic¸˜ao do que deve ser feito, como deve ser feito e quais tecnologias ser˜ao apli- cadas, ´e poss´ıvel iniciar a implementac¸˜ao.

Nas etapas anteriores, ´e crucial que as tecnologias escolhidas tenham sido validadas e re- almente atendem aos requisitos definidos. Uma troca de tecnologia durante a implementac¸˜ao do sistema ´e bastante custosa. Fora isso, ´e importante que inspec¸˜oes peri´odicas sejam rea- lizadas a fim de garantir que a arquitetura de software ainda ´e seguida da forma que foi concebida – caso contr´ario, deve-se corrigir o c´odigo ou atualizar a arquitetura.

Cap´ıtulo 4

Aplicac¸˜ao I: Consumo de Energia

O crescimento da demanda de recursos de energia el´etrica motivou tanto o governo quanto a ind´ustria a buscarem formas alternativas de disponibilizar essa energia e, principalmente, de aperfeic¸oar o gerenciamento da rede el´etrica. Entretanto, aumentar a eficiˆencia e ba- lancear a malha energ´etica n˜ao ´e uma tarefa trivial [10]. Para isso, uma opc¸˜ao ´e utilizar medidores inteligentes (smart meters) que podem, periodicamente, medir e reportar o con- sumo energ´etico [56] e, com base nos dados detalhados, recomendac¸˜oes podem ser geradas. Quanto maior o n´ıvel de detalhe dos dados, melhor a recomendac¸˜ao e, consequentemente, a economia [57].

No entanto, a medic¸˜ao peri´odica e detalhada do consumo energ´etico causa preocupac¸˜oes com a privacidade dos consumidores, j´a que ´e poss´ıvel inferir informac¸˜oes pessoais a partir do que ´e coletado, como tipos de equipamentos na residˆencia ou a presenc¸a e o n´umero de moradores [58]. Em casos mais extremos, ´e poss´ıvel identificar o canal de televis˜ao sendo assistido [59].

No escopo desse estudo, duas aplicac¸˜oes foram investigadas: (i) consumo em grupos de residˆencias ou regi˜oes – visando o balanceamento energ´etico; (ii) c´alculo de consumo energ´etico mensal por consumidor – visando a reduc¸˜ao de custos e de erros de leitura. Com o uso de medidores inteligentes torna-se poss´ıvel a reduc¸˜ao ou at´e mesmo dispensa de visitas f´ısicas de agentes da concession´aria para aferic¸˜ao dos medidores nas residˆencias.

Nas subsec¸˜oes a seguir, a vis˜ao geral da arquitetura – que ´e uma instˆancia do modelo proposto no cap´ıtulo 3 – e seus requisitos ser˜ao apresentados, seguidos pela descric¸˜ao de cada componente arquitetural, detalhes sobre implementac¸˜ao e, por fim, experimentos realizados

4.1 Vis˜ao Geral 42

com as abordagens dispon´ıveis.

4.1

Vis˜ao Geral

Figura 4.1: Diagrama UML da aplicac¸˜ao para c´alculo de consumo de energia

A arquitetura de software, ilustrada pela Figura 4.1, possui os seguintes componentes: barramentos de mensagens (KafkaBus), medidores inteligentes (SmartMeter), agregado- res (IntelSGXAggregator e HomomorphicAggregator) e consumidores (IComponent). Os barramentos de mensagens s˜ao respons´aveis pela comunicac¸˜ao entre os medidores inte- ligentes, os agregadores e os consumidores. Ap´os serem produzidos, os dados ser˜ao publi- cados no barramento de mensagens e, em algum momento, ser˜ao tratados por agregadores. Estes podem realizar operac¸˜oes arbitr´arias, mas devem ser capazes de execut´a-las de forma segura. Posteriormente, os dados agregados ser˜ao consumidos por aplicac¸˜oes.

4.2

Elementos Arquiteturais

A Figura 4.2 cont´em uma vers˜ao simplificada da arquitetura proposta. Os Smart Meters representam os produtores, o Apache Kafka representa o barramento de mensagens e a agregac¸˜ao dos dados pode ser utilizando Intel SGX ou criptografia homom´orfica. Os detalhes ser˜ao listados a seguir.

4.2 Elementos Arquiteturais 43

Figura 4.2: Esquema simplificado da aplicac¸˜ao para c´alculo de consumo de energia

4.2.1

Barramentos de mensagens

Um barramento de mensagem ´e respons´avel pela troca de informac¸˜oes entre produtores, agregadores e consumidores de forma transparente. Um produtor pode criar mensagens sem saber maiores detalhes sobre os agregadores (como localizac¸˜ao f´ısica ou enderec¸o IP), por exemplo. Com isso, ´e poss´ıvel reduzir o acoplamento e garantir escalabilidade.

Cada componente da arquitetura deve se inscrever em um t´opico de mensagens. Todos os agregadores ou consumidores de um t´opico receber˜ao as mensagens enviadas pelos pro- dutores. Ademais, ´e permitido o consumo exclusivo de novas mensagens ou de todas as mensagens retidas de um certo t´opico. Por fim, a quantidade de mensagens armazenadas para um t´opico pode ser configur´avel.

Por ser cr´ıtico na comunicac¸˜ao entre todos os envolvidos, esse componente permite a troca segura de mensagens. Cada envolvido pode possuir um certificado emitido por uma autoridade certificadora que permitir´a sua autenticac¸˜ao e evitar´a que intrusos enviem ou rece- bam mensagens. Al´em disso, mensagens com conte´udo sens´ıvel devem estar criptografadas.

´

E papel do agregador transformar informac¸˜ao sens´ıvel e criptografada – como o consumo energ´etico instantˆaneo de uma residˆencia – em informac¸˜ao agregada – como o consumo em um intervalo maior de tempo ou o consumo de uma regi˜ao. .

4.2 Elementos Arquiteturais 44

4.2.2

Agregadores

Ap´os o consumo dos dados de um t´opico comum, ´e necess´ario realizar operac¸˜oes nos mes- mos. Tais operac¸˜oes, como soma, multiplicac¸˜ao ou agrupamento, s˜ao realizadas pelos agre- gadores. Dois agregadores s˜ao exemplificados na nossa implementac¸˜ao da arquitetura: um agregador homom´orfico e um agregador baseado em Intel SGX. Ambos s˜ao projetados para realizar operac¸˜oes de soma e ser˜ao detalhados nas sec¸˜oes a seguir.

Agregador Homom´orfico

Esse agregador faz uso da criptografia homom´orfica para realizar operac¸˜oes de forma segura e privada nos dados. A abordagem utilizada por esse componente ´e baseada no esquema proposto por BUSOM et al. [60], que faz uso do sistema de criptografia de ElGamal [61]. Tal sistema possui a propriedade homom´orfica multiplicativa mas com possibilidade de adic¸˜ao [62].

Para que esse tipo de agregac¸˜ao funcione ´e necess´ario que cada produtor p ∈ [1, n] de um t´opico comum possua os seguintes itens:

• Um n´umero primo grande q (de pelo menos 2048 bits) e um gerador g de ordem q do grupo multiplicativo G de Z∗q;

• Uma chave privada xp;

• Uma chave p´ublica yp = gxp;

• Um certificado certpa ser validado por uma autoridade certificadora;

Sempre que novos produtores se inscreverem em um t´opico de mensagens, uma fase de configurac¸˜ao ´e obrigat´oria a fim de permitir o envio das informac¸˜oes. O procedimento da configurac¸˜ao ´e descrito a seguir:

1. O agregador envia uma mensagem de requerimento de configurac¸˜ao;

2. Cada produtor envia ype certp ao t´opico;

3. O agregador verifica a validade de cada certpe insere uma mensagem com {y1, ..., yn}

4.2 Elementos Arquiteturais 45

4. Cada produtor verifica a validade de cada certp e calcula uma chave p´ublica global

y =

n

Y

p=1

yp.

Os passos acima s˜ao realizados para garantir que (i) existam somente medidores v´alidos em uma regi˜ao – evitando que um atacante forge um medidor e (ii) a chave p´ublica global seja utilizada na computac¸˜ao de valores intermedi´arios, permitindo que o valor agregado seja conhecido no final de cada coleta.

Os seguintes passos ser˜ao realizados a cada instante de tempo que for necess´aria uma coleta de dados para agregac¸˜ao:

1. O agregador envia uma mensagem de requerimento de dados ou, alternativamente, os produtores podem iniciar uma transmiss˜ao periodicamente;

2. Cada produtor p gera um n´umero aleat´orio zp ∈ Z∗q e calcula Cp = Ey(gvp+zp) =

(cp, dp), em que vp representa o valor coletado por p e a func¸˜ao Ey ´e a func¸˜ao de

criptografia de ElGamal – utiliza-se a chave p´ublica global y para encriptar valores;

3. Todos os valores Cp s˜ao publicados no t´opico do barramento de mensagens associado

`aquele produtor (por exemplo, a regi˜ao em que o medidor est´a instalado);

4. O agregador realiza sua computac¸˜ao: C =

n Y p=1 cp, n Y p=1 dp ! e insere C no t´opico;

5. Cada produtor calcula Tp = cxp.gzpe publica-o no t´opico;

6. O agregador pode, ent˜ao, obter D = d.

n Y p=1 Tp !−1 , em que d = n Y p=1 dp;

7. Por fim, ´e poss´ıvel obter V =

n

X

p=1

vp ao calcular loggD;

8. O agregador publica o resultado obtido no mesmo ou em outro t´opico do barramento de mensagens, de forma que ele fique dispon´ıvel para poss´ıveis consumidores.

Agregador Intel SGX

O agregador Intel SGX faz uso da tecnologia de mesmo nome para prover seguranc¸a e privacidade dos dados sens´ıveis sendo agregados, atrav´es do uso de ´areas protegidas de

4.2 Elementos Arquiteturais 46

mem´oria (enclaves), inacess´ıveis at´e mesmo por usu´arios com mais privil´egios. Em nossa implementac¸˜ao usamos o algoritmo de criptografia sim´etrica AES Galois/Counter Mode (AES-GCM) descrito por DWORKIN [63], com chave de tamanho de 128 bits, para a troca de mensagens confidenciais entre os produtores e o agregador. Este algoritmo permite verifi- car a autenticidade dos dados confidenciais recebidos por meio da detecc¸˜ao de modificac¸˜oes n˜ao intencionais ou modificac¸˜oes intencionais n˜ao autorizadas feitas aos dados. Al´em disso, torna a comunicac¸˜ao imune a ataques do tipo side-channel baseados em software.

As seguintes condic¸˜oes precisam ser satisfeitas para o correto funcionamento deste agre- gador:

• Cada produtor p ∈ [1, n] de um t´opico deve possuir uma chave sim´etrica kp;

• O agregador ter´a acesso a uma chave kp a partir do processo de atestac¸˜ao remota.

Para utilizar chaves de 128 bits na comunicac¸˜ao segura, cada produtor p ∈ [1, n] de um t´opico atesta o agregador, ou seja, verifica se o agregador est´a sendo executado em um en- clave SGX, por meio do processo de Atestac¸˜ao Remota, descrito por ANATI et al. [64]. Em poucas palavras, o processo de atestac¸˜ao remota aproveita os recursos do hardware para pro- duzir uma assinatura criptogr´afica do conte´udo dos enclaves SGX com uma chave somente acess´ıvel pelo processador da plataforma. O servic¸o de atestac¸˜ao fornecido pela Intel (IAS) pode verificar se as informac¸˜oes produzidas realmente vieram de um enclave SGX com o c´odigo correto. Esse processo tamb´em possui um esquema de troca de chave subjacentes baseado no protocolo de troca de chave Diffie-Hellman (ECDH) da curva el´ıptica. Como re- sultado, cada produtor ir´a (i) verificar o agregador com relac¸˜ao a sua integridade e (ii) derivar a chave de 128 bits kp para comunicac¸˜oes seguras – tamb´em derivada pelo agregador.

Ao receber dados confidenciais, o agregador pode decifrar as mensagens usando o mesmo algoritmo AES-GCM e, em seguida, executar a agregac¸˜ao nos dados confidenci- ais decifrados. A confidencialidade e a integridade dos dados s˜ao alcanc¸adas por meio das garantias fornecidas pelos enclaves SGX [65].

Para agregar uma coleta de dados feita em um instante de tempo, os seguintes passos ser˜ao realizados:

1. O agregador envia uma mensagem de requerimento de dados ou, alternativamente, os produtores podem iniciar uma transmiss˜ao periodicamente;

4.3 Requisitos Funcionais 47

2. Cada produtor p cria um valor aleat´orio (nonce) np, e calcula Cp, Mp = Ge(vp, np, kp),

onde Cp ´e o valor coletado por p ap´os a encriptac¸˜ao AES-GCM, Mp ´e o c´odigo de

autenticac¸˜ao de mensagem de vp, onde vp ´e o valor medido por p, e a func¸˜ao Ge ´e a

func¸˜ao de criptografia AES-GCM no modo de encriptac¸˜ao.

3. Cada produtor publica Cp, Mp, e np ao t´opico;

4. O agregador obt´em V = n X p=1 vp ao calcular n X p=1 Gd(Cp, np, kp, Mp), onde a func¸˜ao Gd

´e a func¸˜ao AES-GCM no modo decriptac¸˜ao, ao mesmo tempo em que verifica a inte- gridade de cada uma das mensagens recebidas no t´opico;

5. O agregador publica o resultado obtido no mesmo ou em outro t´opico do barramento de mensagens, de forma que ele fique dispon´ıvel para poss´ıveis consumidores.

Os dados confidenciais processados por este agregador est˜ao livres de vazamento de informac¸˜oes porque a mem´oria dentro de um enclave SGX ´e criptografada. Al´em disso, todos os dados s˜ao trocados usando uma conex˜ao segura estabelecida pelo processo de atestac¸˜ao remota. Esse processo tamb´em garante que o c´odigo em execuc¸˜ao dentro de um enclave SGX n˜ao tenha sido modificado.

4.3

Requisitos Funcionais

Essa arquitetura deve atender aos requisitos citados nas sec¸˜oes 3.1.10, 3.1.11, 3.1.12, assim como os requisitos funcionais a seguir.

4.3.1

Cadastrar Regi˜oes

Descric¸˜ao: A aplicac¸˜ao deve permitir que novas regi˜oes sejam criadas. Justificativa: Os dados devem ser agregados por regi˜ao, logo, ´e necess´ario que

o sistema permita que novas regi˜oes sejam criadas.

Vantagens: Essa separac¸˜ao ´e ´util para facilitar a divis˜ao da agregac¸˜ao dos da- dos em diferentes n´os.

4.3 Requisitos Funcionais 48