Criptografia Assimétrica com OpenSSL

O OpenSSL é um projeto open source que ajuda a aumentar a segurança na comunicação entre aplicações e garante a autenticidade da identidade de uma das partes comunicantes. Em outro artigo, mostrei como gerar um arquivo p7b. Nesse artigo, vou mostrar como utilizar o OpenSSL para trabalhar com chaves públicas e privadas (criptografia assimétrica).

Criação das Chaves

Vamos utilizar o algoritmo RSA para gerar a chave privada:

$openssl genrsa -out privkey.kp 2048

Esse comando produziu um arquivo chamado privkey.kp cujo conteúdo é:

—–BEGIN RSA PRIVATE KEY—–
MIIEpQIBAAKCAQEA0s2xwy0/awWsYBSTWV+C4MwgBgGw3lj6WiLiXD6oRdhVgEFQ
2PjUJPF0r90McWXmFvVyTlQIFqATtsI7XeMxaI8mecHZpaZWkuWwn9P5Y/oaEfnd
SwzdpugY1yveho39PBKBipuypcPhPEee/fHTeoQiua4FXiCUWhKMSqGBWN830sOw
fZwzKVw5N0JS0HFjiB/PO8TTy5hJ2p+Wb6S2uUwQdo8fwvvD1hNeJiJVH22s+fDh
mG9PDMpOrzXpRkiC9YzzXTRZwOn6oRtXTKIF5LdvpxwKSi641Yl2yCnUW7A7V9zY
UVIOh4m9blP+XGJvW22+l3dAd7gfyXyxZB0v9QIDAQABAoIBADhG4aYRdlTD9vjP
hWbesLoCxKnV2boCVxOpLHUj5RiAYJMU3NiP1VLngxdQE/pSEdMfQ5zVojMoGRs5
T1AJTy9yx/rJXalzdrlQyI5isLmYE02pPwLCNIpSfA81jvqs/WYEKsEuP8sxN/g3
xqJU5PhYPk0DwDsYx4IkYX+rDjUDJmKc6A35LRlCFrBOn46ABW7s5SZYm2dvJqY8
5DJYK1j/jmpO52Ua0nnL/jVxXtwZA/2Y83D34XxHVEaIekG9uKGL0xdoovNEfblB
by2b4A6TT3fkhwlZskAE/b4nX/udWvvkPtVWwTXqZqutdBGKy8MY7hggog4lmt0C
e1CkCQECgYEA8wE2vL2SjQfmDBHM9ipeChWGiObNPq2jIbcrzPAZz5PQJRR892oU
rzgiVwYam4bzj9WYvKVsOLAud3cMiDzmFJ+0MJSbj+vEv5zxuzCqLuURbde8eGth
NMf+I3vkhBp6Vp+T9mnnKDIkbqH3zwvu7Q6z2Rkjidjn0YEbpbSoNMkCgYEA3hOj
gTpXrg4K1l+Opdm0AkHAqaoZYshaUhUepvpjBVRheToTxX5x6g7sHIZ1saxC3Mgm
Q3j95qjMwwAFyF0ySVtIexkxgtcGyBnUgRVeTCKZRtNpawn8SQgruVL8LmHKdQfk
wqCEcGP5jL+oZDzrab+5D0RJQ3Stwnr8X5GAE80CgYEA35NJUkO0ty8COC6UfhQi
63I8km6PfdBx285UbTym8rXTdpowE8608zVZWunRxzBVnQtveHlWZZ2rUtzkWeB1
65m4Rk4kBjlsjsMOISS4H2dALuijjcN17wLmTq1pZSWbU2GE190+AVyI6oT4o7Ue
AVtamy6m5Of8+WOpFT9u1wkCgYEA3A3Bus/BCivH+Vx+0UDD6miVLIns1cGKHkPn
N7ZsYF+YprMx3ETLRA69UBa8kO4M4xFBOSKvFNy26ZMgJ8aRibb2P2Rbdzby9V0D
AVXXNsIh99iNYQ9n+kYqbV0ZniwwnX7Q4zqDgYrPQPS5O3pSG1trWQFlR35an5eW
dGyM6RECgYEA0NoXZz+u6kpcqvB2cH/8g3HmZ8Q8qCQnnn4SZM19XuyUQUkXv0wa
g+nqhWDNFygTcSiWbw3lk/07QRVXvuxOJbGr9CuLA+F0d06wcqEdlKCnZ/Vq0SGV
skwwsPsG8xdUGyX2Bg5mPM5X5NVEamR4oSrlTj0iTPMwLhMeUWVO1s0=
—–END RSA PRIVATE KEY—–

À partir da chave privada criada, criaremos uma chave pública. Lembre-se de armazenar a chave privada, pois ela não pode ser compartilhada. Nos certificados digitais, a chaves privada, dependendo do tipo do certificado, é gerada dentro de um dispositivo criptográfico entregue ao solicitante e a chave pública é armazenada em um hardware mantido pela Autoridade Certificadora. Esses são alguns dos conceitos da Infraestrutura de Chaves Públicas.

$openssl rsa -in privkey.kp -pubout -out pubkey.kp

Esse comando produziu um arquivo chamado pubkey.kp cujo conteúdo é:

—–BEGIN PUBLIC KEY—–
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0s2xwy0/awWsYBSTWV+C
4MwgBgGw3lj6WiLiXD6oRdhVgEFQ2PjUJPF0r90McWXmFvVyTlQIFqATtsI7XeMx
aI8mecHZpaZWkuWwn9P5Y/oaEfndSwzdpugY1yveho39PBKBipuypcPhPEee/fHT
eoQiua4FXiCUWhKMSqGBWN830sOwfZwzKVw5N0JS0HFjiB/PO8TTy5hJ2p+Wb6S2
uUwQdo8fwvvD1hNeJiJVH22s+fDhmG9PDMpOrzXpRkiC9YzzXTRZwOn6oRtXTKIF
5LdvpxwKSi641Yl2yCnUW7A7V9zYUVIOh4m9blP+XGJvW22+l3dAd7gfyXyxZB0v
9QIDAQAB
—–END PUBLIC KEY—–

Chaves Pública e Privada em um Mesmo Arquivo

Adicionalmente, suponha que você já tenha um arquivo, que chamaremos de keypair.kp, cujo conteúdo seja a concatenação das chaves privada e pública:

—–BEGIN RSA PRIVATE KEY—–
MIIEowIBAAKCAQEAzupZUuiV9mS1i1KRQKFyYeo6fwFZB1GumwPnkHi6xNgX3YgK
kZPN1agIKFuII795lP+GnB2/+mxbszXZx7Q2VjwaqZMiOBHCXJjZZe6lYRumbMUD
cEex1tcUhufpSsSXcxglNwYEPOeAeC96x4QLTpDNCf4fyY6IdZHQINEnKJdxT1Rv
7i00d8OeF2pk8z3Y1QJDrZQghjHEvpxqBqVBkPYrqtjAhMHwKZo5Zi7bcBM5vmJ3
b5iDs1MjvHYLgd0TPBQPiz3bKQ5CbDAuMFHw0XPTWz0luHbcsvKVK0PBSt0ciWeZ
TGeQs+xnaYmQpS/d5HPk8t2ygKuZdukBtSwVGQIDAQABAoIBABXPZfLzSTtbijdR
ULY7Tk873Uad4cB/v6PfWX1E/IrbLEjRmiuWJNAskg+O9l6uRCaMeKfkCuRen5vY
RUhjmoakdzsAo069sHsKMYApE42U2IoGikI/jGNU8Hj34QNcjYo4NVQDclbpIAWL
G6oEJRz27mXrP3aDa6bY49NRuIrymumsCksMT+jR1fW7sYMmDr8drdSyMn4LROSN
ntiSBG2Ab3ltiZPhGI/YTxru+C8xzU9htqVwvKqVtcEfNZ17g6fd/W29mTGB+B5S
zDjFmm5fTJW2iiEPpZ8hFYlo4lqXtTtALdJndMk4f8vbs8mfgRAB9qbuYqv2ijY/
EoSNFAECgYEA/EE+TtN8zoYf6LLE7FXIXKZX6VHrbbyQhFyrhJ8UC8vhemtTcli2
2nKzaJN4Vv5voXkKMlp4J3NL45VIIx6kupWMqEls3a6HLhZ5AnegVlNeK/kQFFaH
7Q9lpnntpFIHOQe4FrH8maEs1you2fvJafgRzpVUlmKPgVCsOnl5K3kCgYEA0fzI
KNig3044lKZAszXb/iPUHq4TdPcSiqeEjzMPd+Zmxx4hbrsjYPuAbMsTfiNMRC2p
3yECCuUSpuwlgVbf9Ol4PEd8PWaMDyLDYT/2tcS6YWErvVlFG9uhgyF1sh1fdNB+
Z61YK1/uOC7rQTYZt2NNiFL495CmUOTRk6loLqECgYBSr2gnGneskpZfBko6VZwJ
kpT6a9nJ7KdKW731CNffTgMox4lgz+eQD0zzmHM3wMsCmNRY0QLVm5tijApLSL4i
Uub6OqcuuwigeMlNn7y0zzrtGwTEReDkOcnOGeVlmWW4sekLt2ffS8+Q78jPtxK8
Y44isxw49zGm57SsriijsQKBgQCAP1yX5cZK2+EemHNHgIt9qbAxlKt5cjS2zhzd
wJef6O24iqRslorC/peu2lBrZ2967FClX+l5cfJ0VCGL3t0lHTo7xoUQkwLTc63U
RVaOKTqTot8t48mbfAYmqlbRk7LrCzNIasxAoXRCiBVSXJJUOKfvrI011fhdy4Jc
JsjkQQKBgEZsXhqYO+BK7IbOlVRwiN2kC6XlZl7lClpkjGPw7JVt0OZ/7EUni59O
e1UPHwflzdInOrog8UpVqJJp6Xp9hK14gIdtFMFIncak8DspCYdviYnaUJALXhO2
HjG1eqrp1E701fGJKHKFSonWogKa+7ecBgm9FaDHJcULfJorYeRf
—–END RSA PRIVATE KEY—–
—–BEGIN PUBLIC KEY—–
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzupZUuiV9mS1i1KRQKFy
Yeo6fwFZB1GumwPnkHi6xNgX3YgKkZPN1agIKFuII795lP+GnB2/+mxbszXZx7Q2
VjwaqZMiOBHCXJjZZe6lYRumbMUDcEex1tcUhufpSsSXcxglNwYEPOeAeC96x4QL
TpDNCf4fyY6IdZHQINEnKJdxT1Rv7i00d8OeF2pk8z3Y1QJDrZQghjHEvpxqBqVB
kPYrqtjAhMHwKZo5Zi7bcBM5vmJ3b5iDs1MjvHYLgd0TPBQPiz3bKQ5CbDAuMFHw
0XPTWz0luHbcsvKVK0PBSt0ciWeZTGeQs+xnaYmQpS/d5HPk8t2ygKuZdukBtSwV
GQIDAQAB
—–END PUBLIC KEY—–

Nesse caso, rode o openssl com os parâmetros abaixo para extrair a chave privada desse arquivo, remova o trecho referente à chave privada daquele arquivo e o renomeie para “pubkey.kp”:

$openssl rsa -in keypair.kp -out privkey.kp
$mv keypair.kp pubkey.kp

O conteúdo desse arquivo ficará assim:

—–BEGIN RSA PRIVATE KEY—–
MIIEowIBAAKCAQEAzupZUuiV9mS1i1KRQKFyYeo6fwFZB1GumwPnkHi6xNgX3YgK
kZPN1agIKFuII795lP+GnB2/+mxbszXZx7Q2VjwaqZMiOBHCXJjZZe6lYRumbMUD
cEex1tcUhufpSsSXcxglNwYEPOeAeC96x4QLTpDNCf4fyY6IdZHQINEnKJdxT1Rv
7i00d8OeF2pk8z3Y1QJDrZQghjHEvpxqBqVBkPYrqtjAhMHwKZo5Zi7bcBM5vmJ3
b5iDs1MjvHYLgd0TPBQPiz3bKQ5CbDAuMFHw0XPTWz0luHbcsvKVK0PBSt0ciWeZ
TGeQs+xnaYmQpS/d5HPk8t2ygKuZdukBtSwVGQIDAQABAoIBABXPZfLzSTtbijdR
ULY7Tk873Uad4cB/v6PfWX1E/IrbLEjRmiuWJNAskg+O9l6uRCaMeKfkCuRen5vY
RUhjmoakdzsAo069sHsKMYApE42U2IoGikI/jGNU8Hj34QNcjYo4NVQDclbpIAWL
G6oEJRz27mXrP3aDa6bY49NRuIrymumsCksMT+jR1fW7sYMmDr8drdSyMn4LROSN
ntiSBG2Ab3ltiZPhGI/YTxru+C8xzU9htqVwvKqVtcEfNZ17g6fd/W29mTGB+B5S
zDjFmm5fTJW2iiEPpZ8hFYlo4lqXtTtALdJndMk4f8vbs8mfgRAB9qbuYqv2ijY/
EoSNFAECgYEA/EE+TtN8zoYf6LLE7FXIXKZX6VHrbbyQhFyrhJ8UC8vhemtTcli2
2nKzaJN4Vv5voXkKMlp4J3NL45VIIx6kupWMqEls3a6HLhZ5AnegVlNeK/kQFFaH
7Q9lpnntpFIHOQe4FrH8maEs1you2fvJafgRzpVUlmKPgVCsOnl5K3kCgYEA0fzI
KNig3044lKZAszXb/iPUHq4TdPcSiqeEjzMPd+Zmxx4hbrsjYPuAbMsTfiNMRC2p
3yECCuUSpuwlgVbf9Ol4PEd8PWaMDyLDYT/2tcS6YWErvVlFG9uhgyF1sh1fdNB+
Z61YK1/uOC7rQTYZt2NNiFL495CmUOTRk6loLqECgYBSr2gnGneskpZfBko6VZwJ
kpT6a9nJ7KdKW731CNffTgMox4lgz+eQD0zzmHM3wMsCmNRY0QLVm5tijApLSL4i
Uub6OqcuuwigeMlNn7y0zzrtGwTEReDkOcnOGeVlmWW4sekLt2ffS8+Q78jPtxK8
Y44isxw49zGm57SsriijsQKBgQCAP1yX5cZK2+EemHNHgIt9qbAxlKt5cjS2zhzd
wJef6O24iqRslorC/peu2lBrZ2967FClX+l5cfJ0VCGL3t0lHTo7xoUQkwLTc63U
RVaOKTqTot8t48mbfAYmqlbRk7LrCzNIasxAoXRCiBVSXJJUOKfvrI011fhdy4Jc
JsjkQQKBgEZsXhqYO+BK7IbOlVRwiN2kC6XlZl7lClpkjGPw7JVt0OZ/7EUni59O
e1UPHwflzdInOrog8UpVqJJp6Xp9hK14gIdtFMFIncak8DspCYdviYnaUJALXhO2
HjG1eqrp1E701fGJKHKFSonWogKa+7ecBgm9FaDHJcULfJorYeRf
—–END RSA PRIVATE KEY—–

Se você quiser, pode acrescentar uma senha para proteção da chave privada:

$openssl rsa -in keypair.kp -out privkey.kp -des3 -passout pass:Teste123

Renomeie o arquivo “keypair.kp” para “pubkey.kp”. Abra o arquivo “pubkey.kp” e remova o trecho referente à chave privada. O arquivo se parecerá com esse:

—–BEGIN PUBLIC KEY—–
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzupZUuiV9mS1i1KRQKFy
Yeo6fwFZB1GumwPnkHi6xNgX3YgKkZPN1agIKFuII795lP+GnB2/+mxbszXZx7Q2
VjwaqZMiOBHCXJjZZe6lYRumbMUDcEex1tcUhufpSsSXcxglNwYEPOeAeC96x4QL
TpDNCf4fyY6IdZHQINEnKJdxT1Rv7i00d8OeF2pk8z3Y1QJDrZQghjHEvpxqBqVB
kPYrqtjAhMHwKZo5Zi7bcBM5vmJ3b5iDs1MjvHYLgd0TPBQPiz3bKQ5CbDAuMFHw
0XPTWz0luHbcsvKVK0PBSt0ciWeZTGeQs+xnaYmQpS/d5HPk8t2ygKuZdukBtSwV
GQIDAQAB
—–END PUBLIC KEY—–

Verificação

Vamos simular o envio de uma mensagem criptografada de um remetente para um receptor. O remetente possui a chave pública do receptor e a utilizará para criptografar a mensagem. Crie um arquivo qualquer e insira um pequeno texto nele. Criei o arquivo arquivo.txt:

$openssl rsautl -encrypt -inkey pubkey.kp -pubin -in arquivo.txt -out encriptado.ssl

Esse comando produziu o arquivo encriptado.ssl, que está criptografado e só poderá ser lido por quem detiver a chave privada relacionada à chave pública. É importante lembrar que na criptografia assimétrica, uma mensagem pode ser criptografada ou descriptografada com ambas as chaves, mas se uma for utilizada para criptografar, apenas a outra poderá ser utilizada para descriptografar:

$openssl rsautl -decrypt -inkey privkey.kp -in encriptado.ssl -out decripatado.txt

O arquivo decripatado.txt possui o texto original enviado pelo remetente.

Referências

1. [https://stackoverflow.com/questions/5244129/use-rsa-private-key-to-generate-public-key]
2. [https://rietta.com/blog/2012/01/27/openssl-generating-rsa-key-from-command/]
3. [https://blog.sleeplessbeastie.eu/2017/12/28/how-to-generate-private-key/]
4. [https://www.mkssoftware.com/docs/man1/openssl_genrsa.1.asp]
5. [https://www.devco.net/archives/2006/02/13/public_-_private_key_encryption_using_openssl.php]
6. [https://unix.stackexchange.com/questions/296697/how-to-encrypt-a-file-with-private-key]

Autorização Segura de Dispositivos com Certificado de Atributo na Internet das Coisas

Conforme o artigo Os Riscos de Segurança na Internet das Coisas, a Internet das Coisas é um conceito relacionado a objetos que podem interagir com o ambiente e entre si por diversos meios a qualquer momento e de forma autônoma para realizarem determinados objetivos. Devido a essa autonomia, esses objetos são chamados de “inteligentes”. Esses objetos são máquinas, várias delas utensílios domésticos, com um software embarcado que se comunicam utilizando o conceito máquina para máquina onde as principais tecnologias são sensores e redes sem fio. Estimativas mostram que a Internet das Coisas será composta de bilhões de dispositivos na próxima década, o que direcionará as estratégias de negócio das empresas e trará novos desafios à segurança: os cibercriminosos terão uma superfície de ataque maior, o que demandará meios mais seguros para se autenticar e autorizar dispositivos. Hoje, não há um padrão para autenticação ou autorização de dispositivos na Internet das Coisas, o que é importante para que a interoperabilidade das tecnologias seja mantida.

A autenticidade é considerada crítica para a confiabilidade da IoT [12] e é necessária uma forma de autenticação que valide a identidade de um dispositivo que deseja se comunicar com outro e também é necessária uma forma de recuperar as permissões dos dispositivos autenticados de forma segura e padronizada, o que é essencial para manter a interoperabilidade dos dispositivos na IoT. Não existem padrões específicos para autenticação e autorização M2M.

Um certificado digital X.509 é um padrão já estabelecido que tem por finalidade a autenticação forte, mas ele também poderia ser utilizado para a criação de um serviço de autorização embora com limitações [4][5]. Um mecanismo de autorização granular baseado em certificados de atributos pode ser uma solução para o problema da autorização confiável [12] e pode resolver outro problema inerente ao mundo IoT, que é a interoperabilidade dos dispositivos.

O objetivo desse artigo é mostrar que os certificados de atributo podem ser utilizados para a criação de mecanismos de autorização segura e granular para atender às necessidades da segurança na comunicação M2M na IoT que foram apresentadas no artigo Os Riscos de Segurança na Internet das Coisas. Para atingir esse objetivo, primeiro será demonstrada a falta de flexibilidade do uso de certificados digitais de chave pública em mecanismos de autorização.

Autorização de Dispositivos com Certificado Digital de Chave Pública

A quantidade de dispositivos que interagem para tornar a IoT possível demanda uma forma mais confiável e padronizada de autenticação. É necessário identificar que dispositivo está requerendo acesso para posteriormente autorizar o uso de recursos protegidos. O porte da IoT incide sobre vários domínios e envolve várias tecnologias proprietárias [6]. É necessária uma forma para permitir que os usuários de um sistema tenham a confiança de que as informações e os serviços sendo trocados possam de fato ser invocados.

Um dos princípios da comunicação M2M é a autenticação mútua [1]: somente dispositivos autenticados podem acessar a rede e outros dispositivos e qualquer dispositivo M2M deve se autenticar em um servidor antes de aceitar qualquer dado, como por exemplo comandos e atualizações. Isso garantirá que dados coletados por um servidor estão vindo de um dispositivo legítimo e é garantido ao dispositivo que ele está se comunicando com um servidor confiável.

Quando uma conexão segura é estabelecida utilizando TLS/SSL (Transport Layer Security/Secure Sockets Layer), a troca de mensagens ocorre entre o cliente – que sempre inicia a conexão – e um servidor [13]. O primeiro conjunto de mensagens é o protocolo de handshake (acordo entre as partes visando estabelecer uma conexão) e só depois de finalizado o handshake o cliente e o servidor iniciam o protocolo de transferência de dados. Os objetivos do handshake são:

• Estabelecer a variante do protocolo utilizada – SSLv3, TLVSv1, etc.;
• Enviar os dados de autenticação – um certificado X.509 por exemplo;
• Estabelecer um identificador de sessão para que a sessão possa ser reiniciada se necessário;
• Negociar o algoritmo criptográfico.

Os procedimentos de autenticação devem ser completados entre os dispositivos antes de inicializar a transferência de dados. Para haver transferência de dados, é necessário que as partes confiem uma na outra. Autenticação é justamente o processo de estabelecimento de confiança na identidade de uma entidade [8].

Todos os sistemas utilizam algo que identifique o usuário para posteriormente verificar o que esse usuário pode fazer (permissões de acesso) [8]. Isso significa que o dispositivo está sendo identificado, mas não significa necessariamente que sua identidade está sendo autenticada.

Normalmente, a autenticação de um usuário é feita a partir de um par composto por identificador e senha, mas nesse modelo a autenticação tem baixa confiabilidade, pois é relativamente simples para um cibercriminoso se apoderar dessas credenciais através de um ataque de força bruta, de dicionário ou engenharia social.

Uma das formas de melhorar a confiabilidade da autenticação é utilizando um par de chaves privada e pública junto com um certificado digital [1]. Esse par pode ser gerado individualmente durante a fabricação do dispositivo e pode ser instalado com o certificado correspondente.

Um certificado de chave pública (do inglês, public-key certificate – PKC) é um arquivo digital que agrega uma chave pública (a chave de um par de chaves que é conhecida publicamente), algumas outras informações sobre o proprietário e sobre o certificado em si que é assinado digitalmente com a chave privada da AC (Autoridade Certificadora) que o emitiu [7]. Uma AC é uma autoridade que é confiável por um ou mais usuários para criar e assinar certificados de chaves públicas. Para dar suporte ao gerenciamento de chaves públicas e serviços de autenticação, criptografia, integridade e não repúdio, é necessária uma infraestrutura de chaves públicas (do inglês, public-key infrastructure – PKI). Os certificados digitais X.509 foram projetados para representar identidades em esquemas multiplataforma e multidomínios.

Para que um usuário seja capaz de confiar na chave pública de outro usuário como forma de garantir autenticidade, essa chave deve ser obtida de uma fonte confiável, a AC, que certifica uma chave pública emitindo o certificado de chave pública que liga essa chave à entidade que é a proprietária da chave privada correspondente [7]. Emitir um PKC significa assinar uma coleção de informações (nome do usuário, período de validade, algoritmo de criptografia, etc.).

A verificação da validade de um certificado é feita testando-se sua expiração e sua revogação. A validação de data de expiração é trivial, pois esse é um dos atributos do certificado. Para que os serviços de autenticação possam realizar testes de revogação, a AC deve publicar a LCR (Lista de Certificados Revogados) [3]. Como a LCR é publicada periodicamente, as informações sobre a revogação podem não estar disponíveis imediatamente. Pode-se utilizar outro mecanismo, como o OCSP (Online Certificate Status Protocol) [9], que permite a verificação em tempo real de um certificado junto à entidade certificadora. É possível combinar os dois mecanismos na criação de um mecanismo de autenticação: primeiro, a consulta pode ser feita contra a OCSP; caso o serviço OCSP esteja indisponível, pode-se fazer o download da LCR para a verificação local.

Um PKC resolve o problema da autenticação incluindo um terceiro confiável – a AC – e disponibilizando informações e serviços que podem ser utilizados para validá-lo. O PKC também resolve o problema da criptografia da comunicação utilizando o conceito de chaves pública e privada: uma é utilizada para criptografar e a outra para descriptografar uma mensagem. Ele também pode conter as informações necessárias para se construir um mecanismo de autorização padronizado [4].

Autorização é a garantia de direitos, o que inclui a garantia de acesso baseada nos direitos de acesso [8]. Para construir um serviço de autorização, um dispositivo deve ser capaz de declarar suas capacidades e características para outro dispositivo de uma maneira verificável [11]: uma geladeira, por exemplo, pode ter um atributo que lhe dê autoridade para acessar a Internet em busca dos itens alimentícios que estão faltando e disponibilizar essas informações para seus proprietários. A própria geladeira ou o servidor onde ela se autenticou deve enviar seus atributos para um serviço de autorização no destino para que a geladeira seja autorizada.

Embora um certificado digital possa ser utilizado para a criação de um mecanismo de autorização, ele apresenta diversos pontos negativos quando utilizado para esse propósito [4] [11]. Dentre eles:

• Todos os atributos devem ser conhecidos e definidos antes da emissão do certificado, ou seja, para revogar um atributo, é necessário revogar o próprio certificado;
• A autenticação em uma determinada rede pode ser feita com certificado digital, mas supondo que os privilégios nessa rede são muito particulares, o mecanismo de autorização será definido localmente com atributos vindos de outras fontes;
• Informações de autorização frequentemente não têm o mesmo tempo de vida de uma chave pública;
• Quando a informação da autorização é inserida em uma extensão PKC, o resultado geral é menor do que o tempo de vida útil de um PKC;
• O proprietário do PKC normalmente não é autoritativo para a informação de autorização. Isso resulta em passos adicionais para o proprietário do PKC obter informações de autorização da fonte autoritativa.

O PKC não é flexível o bastante para lidar com atributos. Como exemplo, vamos supor que a autorização de um relógio “inteligente” que dentre outras capacidades acessa um serviço que faz geolocalização seja desenvolvido com base em certificado digital. O certificado digital emitido para esse dispositivo terá de ter um campo com o atributo referente à função de geolocalização. Para revogar apenas essa funcionalidade, seria necessário revogar e reemitir o próprio certificado, pois qualquer alteração em seu estado interno causaria perda da integridade.

A maior vantagem de se adotar um padrão para autorização é a garantia de interoperabilidade entre os dispositivos, pois se não fosse assim, cada fabricante criaria um mecanismo de autorização válido apenas para seus dispositivos em seus domínios. As limitações do PKC incentivam o desenvolvimento de serviços de autorização locais, o que acaba impactando na interoperabilidade dos dispositivos. Interoperabilidade é um pressuposto da IoT.

Autorização de Dispositivos com Certificado de Atributo

O propósito principal de uma PKI é a autenticação forte através do uso de certificados digitais, mas a autenticação não é suficiente para se determinar quem pode fazer o quê em um dado subsistema [2]. Um mecanismo de autorização mais granular [6] e especializado é necessário para preencher essa lacuna deixada pelo PKC.

Em muitos contextos, a identidade do dispositivo não é o critério utilizado para decisões de controle de acesso, mas as informações de autorização precisam estar relacionadas a uma identidade. Os certificados digitais de atributo (CA) X.509 estabelecem uma separação clara entre o processo de autenticação e o processo de autorização [4]. Um CA tem uma estrutura de dados semelhante à do PKC, mas sem uma chave pública. Esses atributos podem representar grupos, regras, autorização de segurança ou outras autorizações.

Um CA é assinado digitalmente por uma AA (Autoridade de Atributo) que liga valores de atributos (privilégios) a informações de identificação sobre seu proprietário [7], o que lhe garante autenticidade – ao assinar, a AA insere sua chave criptográfica no CA. A AA é responsável pela emissão, gerenciamento e revogação de certificados de atributos.

Os CAs oferecem um mecanismo de autorização segura para funções de controle de acesso [4] que podem ser utilizados pela AA. Há dois modelos para a divulgação ou publicação dos atributos: pull e push.

No modelo push, os CAs são entregues pela AA diretamente para o dispositivo, que será responsável por enviar seus CAs para um servidor, o que reduz a complexidade do serviço de autorização no servidor. Esse modelo é aplicável na comunicação inter-domínios onde as permissões de um cliente devem ser atribuídas dentro do domínio do servidor ao invés de dentro do domínio do cliente. Esse modelo só é confiável devido à assinatura digital do certificado de atributo, que permite ao serviço de autorização do servidor verificar a autenticidade e a integridade das informações.

No modelo pull, o cliente se autentica no servidor e o servidor faz a requisição dos atributos diretamente para um repositório acessível para a consulta mantido pela AA. Nesse modelo, para revogar um certificado, bastaria removê-lo do repositório. Dessa forma, o serviço de autorização não precisa se preocupar com revogação, pois o repositório tem apenas certificados válidos. Esse modelo é mais adequado para ambientes nos quais os privilégios dos clientes são definidos e atribuídos no próprio domínio do servidor. A AA, em geral, está localizada no mesmo domínio.

De posse dos CAs, o serviço de autorização faz as mesmas validações que um serviço de autenticação faz baseado no PKC: valida a data de expiração contra um atributo do próprio certificado e depois valida a revogação contra a LCR ou o OCSP.

Os CAs precisam ser modelados para representar o domínio do dispositivo e atender as necessidades do negócio. Pode-se utilizar algum modelo de referência, como o Controle de Acesso Baseado em Regras (do inglês, Role-Based Access Control – RBAC), onde as permissões são associadas à regras e o usuários recebem as regras apropriadas de acordo com seus papéis em um sistema, o que simplifica o gerenciamento das permissões. Uma regra serve de base para as políticas de controle de acesso. Pode-se, por exemplo, criar uma regra que agrega as permissões de um usuário padrão de uma rede e outra regra para o Administrador [10].

O X.509 delega para os serviços a decisão de dizer o que é acessado e por quais privilégios. Para auxiliar na modelagem dos privilégios, o X.509 dá suporte ao RBAC [2]:

• Simples: são certificados de atributo de definição de regras que contém as permissões atribuídas a cada regra e certificados de atributos de atribuição de regras que atribuem as regras aos dispositivos. Trata-se de um modelo centrado em perfis de acesso e suas permissões. Os serviços de autorização devem utilizar esses perfis para realizar a autorização;
• Hierárquico: as regras são organizadas hierarquicamente de modo que regras superiores herdam os privilégios atribuídos às regras inferiores. No X.509, regras podem ter outras regras como atributos;
• Restrito: permite que várias restrições sejam aplicadas às regras e atribuições de permissões. Um exemplo de aplicação é para papéis mutuamente exclusivos – um dispositivo só pode ser associado a um papel em um conjunto de papéis mutuamente exclusivos;
• Consolidado: combina os modelos hierárquico e restrito para impor limitações à hierarquia de papéis.

Resultados e Discussões

Para tornar a IoT mais segura contra aqueles que têm intenções maliciosas, deve-se investir em técnicas de criptografia que dificultem o roubo e o compartilhamento de dados, técnicas que melhorem a autenticação e mecanismos de controle de acesso autoconfiguráveis e granulares [12] como explicado aqui.

O PKC foi projetado para representar identidades em esquemas multiplataforma e multidomínios. Ele liga o identificador de uma entidade a uma chave pública gerada a partir de um algoritmo criptográfico assimétrico e sua autenticidade é garantida por um terceiro confiável – a AC. Sendo assim, ele pode ser utilizado em serviços de autenticação padronizados. Ele também resolve o problema da criptografia da comunicação, pois utiliza o conceito de chaves pública e privada: uma é utilizada para criptografar e a outra para decriptografar uma mensagem.

A revogação de um PKC pode ser verificada de forma mais eficaz através da combinação da CRL e do OCSP em um mecanismo de autenticação: primeiro, o serviço de autenticação faz a consulta contra o OCSP; caso o OCSP esteja indisponível, o serviço faz o download da CRL para a verificação local.

Um PKC não é flexível o bastante para lidar com atributos. Como exemplo, suponhamos que a autorização de um relógio “inteligente” que dentre outras capacidades acessa um serviço que faz geolocalização seja desenvolvido com base em PKC. O PKC emitido para esse dispositivo terá que ter um campo com o atributo referente à capacidade de geolocalização. Para revogar apenas essa capacidade, seria necessário revogar o próprio certificado, pois qualquer alteração em seu estado interno causaria perda da integridade.

Seria viável utilizar PKCs na IoT se fosse possível saber quais serão todas as capacidades de todos os dispositivos, garantir que esses atributos não possam ser revogados separadamente do PKC e que terão a mesma validade do PKC. A implicação é que PKCs seriam projetados para não expirar ou seriam reemitidos pelos fabricantes em um espaço de tempo muito curto, o que geraria um ônus para suas infraestruturas – eles teriam que ser capazes de gerenciar muitos certificados em um tempo aceitável.

Ao adotar um padrão para autorização garante-se a interoperabilidade entre os dispositivos, pois se não fosse assim, cada fabricante criaria um mecanismo de autorização válido apenas para seus dispositivos em seus domínios. As limitações do PKC incentivam o desenvolvimento de serviços de autorização locais, o que acaba impactando na interoperabilidade dos dispositivos e interoperabilidade é um pressuposto da IoT.

Em muitos contextos, a identidade do dispositivo não é o critério utilizado para decisões de controle de acesso, mas as informações de autorização precisam estar relacionadas a uma identidade. O propósito principal de um PKC é a autenticação, mas a autenticação não é suficiente para se determinar quem pode fazer o quê em um dado subsistema [2]. Os CAs estabelecem uma separação clara entre autenticação e autorização [4] e tornam o processo de autorização mais granular e, portanto, mais flexível.

De posse dos CAs, o serviço de autorização faz as mesmas validações que um serviço de autenticação faz baseado no PKC: valida a data de expiração contra um atributo do próprio certificado e depois valida a revogação contra a CRL ou o OCSP.

Os CAs precisam ser modelados para representarem o domínio do negócio materializado no dispositivo. Pode-se utilizar o modelo RBAC, onde as permissões são associadas às regras e os usuários recebem as regras apropriadas de acordo com seus papéis em um sistema, o que simplifica o gerenciamento das permissões.

O X.509 delega para os serviços a decisão de dizer o que é acessado e por quais privilégios. Um mecanismo de autorização baseado em CA com RBAC e um modelo de distribuição de atributos pode ser aplicado, por exemplo, para autorizar um relógio “inteligente” a dar partida em um carro “inteligente”. O appliance (dispositivo de hardware com software escrito especificamente para ele) do relógio recebe os atributos diretamente da AA utilizando distribuição push, pois são domínios diferentes, e os envia para o servidor do carro, que valida os atributos e autoriza as ações do relógio.

É possível utilizar esse mecanismo para fazer as atualizações de software, pois esse também é um caso de comunicação M2M. O fabricante pode ter um atributo que lhe autoriza a enviar as atualizações para correção de vulnerabilidades. O servidor recebe os atributos válidos diretamente do repositório da AA utilizando a distribuição pull, pois é o mesmo domínio, e se autentica no appliance. O serviço de autorização do appliance verifica os atributos do fabricante e autoriza a recepção da atualização.

Conclusão

A IoT trouxe uma nova realidade nas relações entre as pessoas e os objetos do cotidiano. Com a aplicação desse conceito, uma cidade inteligente poderia antecipar e agir autonomamente à falta d’água que ocorreu na cidade de São Paulo em 2015.

As perspectivas de negócios e o fim da limitação de endereços IP que o IPv6 proporcionou provam que a IoT crescerá até atingir dezenas de bilhões de dispositivos conectados na próxima década. Por esse motivo, questões relacionadas a padrões e em especial padrões ligados à segurança se tornam críticas para o sucesso.

A utilização de PKC padroniza e aumenta a segurança na autenticação de dispositivos e também pode ser utilizado para criptografar a comunicação utilizando o conceito de chaves pública e privada. Embora PKCs possam ser utilizados, eles não são ideias para a construção de um serviço de autorização, pois para incluir ou remover um atributo seria necessário reemitir ou revogar o próprio certificado.

Um CA traz a granularidade que falta ao PKC, mas para que possa ser utilizado deve-se escolher um modelo de divulgação de atributos – push para o mesmo domínio e pull para domínios diferentes. Os atributos devem ser modelados de acordo com o RBAC para construir uma solução flexível. O RBAC simples pode ser utilizado para compor perfis e dar suporte às políticas de autorização associadas aos dispositivos.

Para validação, o CA similar ao PKC: é emitido por um terceiro confiável – nesse caso a AA e não a AC – responsável por gerenciá-lo e os serviços de autorização podem utilizar o OCSP, a CRL e informações contidas no próprio certificado para validá-lo.

Com um CA, um mecanismo de divulgação dos atributos, a modelagem dos atributos com RBAC e a possibilidade de verificação da autenticidade e da validade dos atributos, é possível construir um mecanismo de autorização padronizado, flexível e seguro para a comunicação entre dispositivos na Internet das Coisas.

Referências

[1] Boswarthicks, O.; Elloumi, O.; Hersent, O. M2M Communications: A System Approach. 1.ed. Reino Unido: John Wiley e Sons Ltd, 2012. p. 2, 233 e 236.

[2] Chadwick, D; Otenko, A. Implementing Role Based Access Controls using X.509 Privilege Management – the PERMIS Authorisation Infrastructure. IS Institute, University of Salford, M5 4WT, England. Disponível em: [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.400.5794&rep=rep1&type=pdf]. Acesso em: 20 dez. 2014.

[3] Cooper, D. et al. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. IETF, 2008. Disponível em: [http://www.ietf.org/rfc/rfc5280.txt]. Acesso em: 20 dez. 2014.

[4] Farrel, S; Housley, R. An Internet Attribute Certificate Profile for Authorization. IETF, 2002. Disponível em: [http://www.ietf.org/rfc/rfc3281.txt]. Acesso em: 20 dez. 2014.

[5] GRAAF, Jeroen van de.; CARVALHO, Osvaldo. Reflecting on X.509 and LDAP, or
How separating identity and attributes could simplify a PKI. Disponível em:
[http://www.redes.unb.br/ceseg/anais/2004/2957.pdf]. Acesso em: 20 dez. 2014.

[6] IERC – European Research Cluster on the Internet of Things. Internet of Things – From Research and Innovation to Market Deployment. River Publishers, 2013. p. 90-92. Disponível em: [http://www.internet-of-things-research.eu/pdf/IERC_Cluster_Book_2014_Ch.3_SRIA_WEB.pdf]. Acesso em: 24 dez. 2014.

[7] ITU. Information technology – Open systems interconnection – The Directory: Public-key and attribute certificate frameworks. ITU, 2012. p. 14, 16, 19 e 21. Disponível em: [http://www.ietf.org/mail-archive/web/wpkops/current/pdf9ygpIVtdwl.pdf]. Acesso em: 23 dez. 2014.

[8] ITU. NGN identity management framework. ITU, 2009. p. 2, 15, 19-20. Disponível em: [http://www.itu.int/rec/T-REC-Y.2720-200901-I]. Acesso em: 15 jan. 2015.

[9] Myers, M. et al. X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP. IETF, 1999. Disponível em: [http://www.ietf.org/rfc/rfc2560.txt]. Acesso em: 23 dez. 2014.

[10] Sandhu, Ravi S.; Coyne, Edward J.; Feinstein, Hal L.; Youman, Charles E. Role-Based Access Control Models. IEEE Comput. 29, 1996.

[11] Schukat, M. Securing Critical Infrastructure. OSNA Cyber Security Research Group Discipline of IT National University of Ireland, Galway. Disponível em: [http://www.osna-solutions.com/wp-content/uploads/Securing-Critical-Infrastructure-Paper.pdf]. Acesso em: 23 dez. 2014.

[12] VERMESAN, Ovidiu; FRIESS, Peter. From Research and Innovation to Market
Deployment. Denmark: River Publishers, 2014. p. 7-8, 90-92. Disponível em:
[http://www.internet-of-things-
research.eu/pdf/IERC_Cluster_Book_2014_Ch.3_SRIA_WEB.pdf]. Acesso em: 24
dez. 2014.

[13] ZYTRAX. Survival guides – TLS/SSL and SSL (X.509) Certificates. Disponível em: [http://www.zytrax.com/tech/survival/ssl.html]. Acesso em: 5 jan. 2015.