Atenção:
Este post complementa e amplia o aspecto prático do anterior “Chaves Públicas de Autenticação: Criptografia assimétrica” (https://bladochico.qaplaweb.com.br/2018/06/18/chaves-publicas-de-autenticacao-criptografia-assimetrica/), tanto que Introdução e Base Teórica são os mesmos do mais antigo.
Introdução
Inicialmente deve-se ter em mente que as Chaves Públicas de Acesso fazem parte do elenco de ferramentas de segurança da informação e que se utiliza da criptografia assimétrica, o que nos coloca frente a frente com a situação de operações que não podem ser desfeitas por uma simples operação inversa, como, por exemplo, a função quadrática no domínio dos números reais, que não pode ser desfeita com uma radiciação.
Base Teórica
A explicação de tais características nos remete à teoria dos conjuntos. Inicialmente devemos nos lembrar que na criptografia assimétrica encontramos a situação matemática de função sobrejetora, que é aquela cujo conjunto imagem é coincidente com o conjunto contradomínio, ou seja, não há qualquer elemento do contradomínio que não seja elemento do conjunto imagem da tal função, e em contrapartida não encontramos a situação matemática de função injetora, que é aquela que a cada elemento do domínio corresponde diferente valor no contradomínio, não havendo, portanto, um mesmo elemento na imagem sendo obtido por dois (ou mais) elementos do domínio, tão pouco bijetoras, isto porque são utilizados algoritmos não reversíveis, ou seja uma vez aplicada a função aos dados sendo encriptados, não há uma operação contrária que os desencripte
Na criptografia assimétrica empregamos funções de transferência do tipo sobrejetoras que, absolutamente, não sejam dos tipos injetoras ou bijetoras.
Recordemos das seguintes definições:
- Uma função injetora é aquela que leva todos os elementos de seu domínio a diferentes, porém não todos os elementos do seu contradomínio;
- Uma função sobrejetora é aquela que leva todos os elementos de seu domínio a todos os elementos de sua imagem, ainda que ocorram coincidências no contradomínio;
- Uma função é bijetora é aquela que leva todos os elementos de seu domínio a todos e diferentes elementos de seu contradomínio.
Em termos de teoria dos conjuntos diremos que dado um conjunto domínio da função de transferência, corresponde a esta função um conjunto imagem que é subconjunto do contradomínio.
Nas funções sobrejetoras encontramos a situação de conjunto imagem coincidente com o conjunto contradomínio. Característica emprestada às funções bijetoras, que emprestam das injetoras a característica de levar todos os elementos de seu conjunto domínio ao seu conjunto contradomínio. Temos então que as bijetoras são um caso especial das injetoras e das sobrejetoras simultaneamente.
Analogia com o mundo real
Uma analogia para encriptação de chave pública é a de uma caixa de correio. A caixa de correio é exposta e acessível ao público – sua localização (o endereço da rua) é, em essência, a chave pública. Qualquer um que saiba o endereço pode chegar e colocar uma mensagem escrita na caixa de correio. Porém, apenas a pessoa que possui a chave pode abrir a caixa, neste caso a chave privada, e ler a mensagem. Ou de forma mais simplória, a chave pública apenas “fecha a porta”, já a chave privada (e somente ela) “abre a porta”. Ambas precisam ser usadas em conjunto, já que uma não desempenha o papel da outra.
Aplicação em sistema de informação
O processo real efetivo
O par de chaves pública e privada é composto por duas chaves criptográficas relacionadas de forma exclusiva (basicamente números aleatórios longos).
A Chave Pública é o que seu nome sugere – pública. Ela é disponibilizada a todos por meio de um repositório ou diretório acessível ao público. Por outro lado, a Chave Privada deve permanecer confidencial para seu respectivo proprietário.
Como o par de chaves é matematicamente relacionado, tudo o que é criptografado com uma Chave Pública só pode ser descriptografado por sua Chave Privada correspondente e vice-versa.
Para interagir com outra máquina o equipamento originador da conexão gera, a partir da chave privada, uma chave pública que é transmitida para o equipamento destinatário que verifica a existência de tal chave pública na lista de chaves em seu chaveiro (lista de chaves autorizadas) e existindo a conexão é efetivada. Caso não exista, dependendo das configurações dos equipamentos uma solicitação de senha de usuário pode ser requerida para completar a conexão, ou está é simplesmente recusada.
Utiliza-se a chave pública da contraparte para criptografar a mensagem a ser enviada, então o envio efetivo acontece. Ao receber o pacote de dados a contraparte aplica a sua chave privada para decriptar o pacote recebido. Ocorrendo sucesso nesta operação o pacote de dados enviado é aceito, ou se não lograr sucesso na decriptação, ele será descartado e a comunicação falha.
Caso a comunicação seja sniffada (interceptada) o espião/intruso não tem a chave apropriada para decriptar o pacote, ficando assim sem acesso a seu conteúdo como desejado, garantindo a segurança dos dados e conexões.
A criptografia de chave pública pode, portanto, atingir a confidencialidade e esta forma de criptografia é utilizada em situações de SSH, SFTP, e-mail e outras mais.
Uso em sistemas Linux
Há arquivos de configuração para a operação no papel de cliente ou de servidor. O arquivo ssh_config, localizado em /etc/ssh é usado pelo cliente, entre outras coisas, para definir o nome do arquivo das chaves. O arquivo sshd_config, também localizado em /etc/ssh. É usado pelo servidor, por exemplo, serve para definir se a autenticação por chave pública é permitida e para indicar arquivo, e sua localização, para conter o chaveiro com as chaves públicas. Nos apêndices estão as páginas MAN relativas aos dois arquivos de configuração para se obter um detalhamento mais aprofundado.
Geração do par de chaves
geração de chave é feita usando o comando ssh-keygen, com ele é possível determinar o tipo de encriptação da chave (dsa, ecdsa, ecdsa-sk, ed25519, ed25519-sk, ou rsa), atualmente RSA (Rivest-Shamir-Adleman) é o mais seguro e utilizado, possibilitando autenticar e transmitir dados criptografados até seu destino. A quantidade de bits usada na criação também pode ser controlada com o comando sendo 768 bits a quantidade mínima, 2048 a quantidade padrão e 4096 bits a quantidade máxima (e mais segura).
A geração de um par de chaves rsa do tamanho padrão é efetuado com o comando:
ssh-keygen -t rsapara usar 4096 bits o comando é:
ssh-keygen -t rsa -b 4096A sequência de operação do comando inclui confirmar o arquivo onde a chaves serão geradas, caso haja uma chave pré-existente a confirmação de sobrescrita da chave antiga, e a solicitação de uma frase de segurança (opcional, porém recomendada para sistemas com necessidade de alta segurança), para então a chave ser criada e algumas saídas em tela serem oferecidas.
A seguir é mostrado todo o ciclo de geração do par de chaves para um usuário (cada usuário pode gerar seu par de chaves de uso individual e exclusivo). Admitindo que a chave será do tipo rsa com 4096 bits, contida em arquivos de nome padrão (definido nos arquivos de configuração previamente citados), sobrescreverá uma eventual pré-existente e não usará a frase de segurança.
$ ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/administrator/.ssh/id_rsa):
/home/administrator/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/administrator/.ssh/id_rsa
Your public key has been saved in /home/administrator/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:cX01bPPrsh7hv96KmpXz3JOk/FNe2+ggosHgJxC1jKU administrator@excelsior
The key's randomart image is:
+---[RSA 4096]----+
| o ...|
| * . . =.|
| E o . . . o o|
| . o . .|
| . . S . .|
| o o ...oo|
| o + . . *o+o*|
| o o . + X+B+|
| . o.o+X**|
+----[SHA256]-----+
Com isto foram regerados os arquivos id_rsa e id_rsa.pub contidos no diretório .ssh do usuário que gerou o par de chaves.
Distribuição da CHAVE PÚBLICA
O usuário pode fazer a distribuição da chave pública por meio manual ou por meio de um comando apropriado.
A distribuição manual consiste em efetuar cópia do arquivo da chave pública para os destinos desejados usando os meios disponíveis, seja por ftp, scp, ou qualquer outro que exija sua interação franca com o sistema remoto. Lembrando que além de prover a cópia para o sistema remoto o arquivo deve ser transferido para o diretório apropriado no sistema de arquivos do tal sistema.
Já por meio do comando ssh-copy-id parte do processo é automatizada, restando ao usuário realizar umas poucas operações com a finalidade de suprir alguma confiabilidade ao processo.
A forma geral do comando é ssh-copy-id username@hostname, podendo receber opções de chamada, como por exemplo -p port para efetuar a conexão por uma porta não padrão (a porta padrão é a 22) caso tenha sido alterada na configuração, assim como -i identificação_de_arquivo_de_chave_pública para utilizar um arquivo de chave pública não padrão (conforme configurado em arquivo de configuração).
A seguir é mostrado todo o processo de distribuição de uma chave pública, no caso do usuário transfer, para um sistema remoto, neste caso grisson, cujo port de conexão não é o padrão (22), mas sim o port 8622, em três exemplos, sendo dois falhos e um com sucesso.
Tentativa indicando um arquivo de chave pública inexistente
$ ssh-copy-id -i .ssh/id_rsb transfer@grisson
/usr/bin/ssh-copy-id: ERROR: failed to open ID file '.ssh/id_rsb.pub': No such file
Tentativa indicando um arquivo de chave pública existente, mas sem especificar o port configurado
$ ssh-copy-id -i .ssh/id_rsa.pub transfer@grisson
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: ".ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: ERROR: ssh: connect to host grisson port 22: Connection refused
Tentativa usando arquivo padrão de chave pública e o port configurado
$ ssh-copy-id -p 8622 transfer@grisson
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/transfer/.ssh/id_rsa.pub"
The authenticity of host '[grisson]:8622 ([192.168.0.7]:8622)' can't be established.
ECDSA key fingerprint is SHA256:lFZtjd+gvftrWbBfRh3/kj5tmw0H7RCcaLIUDillNF8.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
transfer@grisson's password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh -p '8622' 'transfer@grisson'"
and check to make sure that only the key(s) you wanted were added
.É importante observar que foi necessário fornecer a senha do usuário transfer, do sistema remoto, para que este aceitasse completar a operação. Esta observação implica que não se pode distribuir uma chave pública para um usuário inexistente no sistema remoto, a seguir é mostrado o ciclo de tentativa de distribuição de chave pública de um usuário não existente no sistema remoto.
$ ssh-copy-id -p 8622 isis@grisson
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/isis/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
isis@grisson's password:
Permission denied, please try again.
isis@grisson's password:
Permission denied, please try again.
isis@grisson's password:
isis@grisson: Permission denied (publickey,password)
.Após a terceira tentativa de autenticação o processo foi encerrado pelo sistema remoto.
Distribuição de CHAVES PÚBLICAS de usuários inexistentes no sistema remoto
No entanto, é possível a um usuário inexistente no sistema remoto se passar por outro que exista, e é uma situação válida, digamos para que esse tal usuário possa efetuar conexão com o sistema remoto para transferir pacotes de dados, por exemplo.
A seguir é mostrado como este processo pode ser efetuado.
isis@sistemalocal:~$ ssh-copy-id -p 8622 transfer@grisson
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/isis/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
transfer@grisson's password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh -p '8622' 'transfer@grisson'"
and check to make sure that only the key(s) you wanted were added.
A ideia é que com o usuário local inexistente no sistema remoto se efetue a distribuição de sua chave pública usando a identificação remota de um usuário existente no sistema remoto, com ou sem a própria chave pública distribuída para o sistema.
Isto torna possível que seja criado um usuário apenas para efetuar transferências de arquivos entre sistemas remotos que não possa efetuar login nos sistemas, o que empresta alguma segurança a mais no geral.
Medidas adicionais para aumento da segurança
Em adição ao uso de chaves públicas de autenticação alguns ajustes nos arquivos de configuração do servidor e do cliente ssh são recomendados se não necessários.
No arquivo /etc/ssh/ssh_config garanta que a opção PermitRootLogin esteja ajustada para no e IgnoreRhosts para yes. Desta forma impede-se que o usuário root faça login por ssh (portanto remotamente) e a modalidade legada de acesso rlogin seja recusada (uma vez que não necessita de senha).
Já no arquivo /etc/ssh/sshd_config a opção Port pode ser alterada do padrão 22 para outro número de porta, o que coloca um nível a mais de dificuldade para o invasor por ele ter de encontrar o port correto para tentar a conexão. Outra possibilidade é permitir apenas conexão remota com chaves públicas alterando a opção PasswordAuthentication para no de forma que não se possa efetuar o login remoto com a autenticação padrão por senha, obrigando todos os usuários a terem suas chaves públicas implantadas no computador.
Considerações finais
Além de uma superficial visão geral sobre a teoria por trás das Chaves e Autenticação Assimétricas, foi visto como criar chaves de autenticação para os usuários do sistema com o comando ssh-keygen. Foi visto também como distribuir chaves públicas de autenticação com o comando ssh-copy-id e como fazê-lo para usuários inexistentes no sistema remoto com base em um existente. Em adição algumas configurações básicas, porém fundamentais para elevar a segurança do sistema com uso de ssh para conexões remotas foram pontuadas.
Referências
Comodo. Public Key and Private Keys. Disponível em <https://www.comodo.com/resources/small-business/digital-certificates2.php> acessado em 09/ago./2021
GONÇALVES, Amanda. O que é função. Escola Brasil – Rede Omnia. Disponível em: <https://brasilescola.uol.com.br/o-que-e/matematica/o-que-e-funcao.htm>, acesso em 13/jun./2018
MAN pages do SSH_CONFIG e SSHD_CONFIG do Linux Ubuntu 20.04
MULLER, Mateus. Como configurar Chave PÚBLICA e Chave PRIVADA no SSH. Youtube. 2017. Disponível em <https://www.youtube.com/watch?app=desktop&v=7BEsfupYngE> acessado em 09/ago./2021
Wikipedia. Criptografia de chave pública. 2019. Disponível em <https://pt.wikipedia.org/wiki/Criptografia_de_chave_p%C3%BAblica> acessado em 09/ago./2021
Lista de Abreviaturas e Siglas
DSA Digital Signature Algorithm
ECDSA Elliptic Curve Digital Signature Algorithm
ECDSA-SK Elliptic Curve Digital Signature Algorithm Security Key
FTP File Transfer Protocol
ID Identification (identificação)
RSA Rivest-Shamir-Adleman
SCP Secure Copy
SFTP SSH File Transfer Protocol / Secure File Transfer Protocol
SSH Secure Socket Shell