• Vírus: um programa anexado a um hospedeiro legítimo, que se instala sozinho no ambiente alvo, sempre que o programa hospedeiro é executado. Uma vez instalado, ele realiza suas ações criminosas sempre que lhe apraz, freqüentemente usando uma data como gatilho.
• Worm: um programa que varre um sistema, ou uma rede, replicando-se e buscando bloquear todos os recursos disponíveis, até torná-lo inoperante. Ao contrário do vírus, um worm normalmente não destrói dados.
• Cavalo de Tróia: um programa oferecido aos usuários de um sistema como sendo capaz de realizar uma função útil, mas que tem uma segunda função oculta. O exemplo mais comum é o spoof login, um programa que apresenta aos usuários um diálogo idêntico ao diálogo normal de obtenção de login (nome do usuário) e password (senha), mas que na realidade armazena as informações fornecidas pelos usuários em um arquivo, com o objetivo de uso posterior ilícito.

A discussão acima, sobre ameaças e métodos de ataque, leva-nos à conclusão de que para construir um sistema distribuído seguro, nós devemos projetar seus componentes partindo do princípio de que os agentes do sistema (pessoas e programas) não são confiáveis, até que provem o contrário. No entanto, é impossível produzir um sistema útil considerando que não há nenhum componente confiável. Assim sendo, o objetivo passa a ser produzir um sistema no qual um número mínimo de componentes sejam considerados confiáveis.

Os mecanismos de segurança para sistemas distribuídos baseiam-se no uso de três técnicas: criptografia, autenticação e controle de acesso.

A criptografia de mensagens possui três papéis principais na implementação de sistemas seguros. Em primeiro lugar, é usada para esconder informação privada nos lugares do sistema onde ela estiver exposta, como por exemplo num canal de comunicação, o qual é vulnerável a eavesdroping e message tampering. Esta aplicação de criptografia corresponde ao seu uso tradicional em atividades militares e de inteligência. Baseia-se no fato de que uma mensagem criptografada com uma chave específica só pode ser descriptografada por um agente que conheça a chave inversa correspondente. Nosso sistema de segurança usa criptografia com este objetivo.

A segunda utilidade desta técnica é apoiar mecanismos de autenticação que suportam a comunicação entre pares de agentes do sistema. Um agente que descriptografa uma mensagem com sucesso, usando uma chave inversa específica, pode assumir que a mensagem é autêntica se ela contém algum valor esperado. Então, se as chaves são mantidas em sigilo, uma descriptografia com sucesso autentica a mensagem decodificada como sendo proveniente de um agente específico. Nosso sistema de segurança também utiliza criptografia com este objetivo.

A terceira aplicação da técnica é a implementação de um mecanismo conhecido como assinatura digital. Este mecanismo simula o papel das assinaturas convencionais, verificando com um terceiro se a mensagem é uma cópia inalterada daquela produzida pelo agente específico. A habilidade de prover assinaturas digitais depende da existência de alguma coisa que o agente emissor da mensagem possa fazer que outros não possam. Isso pode ser atingido requisitando-se a um terceiro confiável a criptografia da mensagem de maneira convencional, ou em uma forma reduzida chamada digest. A mensagem resultante deste processo, ou o digest, age como uma assinatura que acompanha a mensagem. A autenticidade dessa assinatura pode ser verificada pelo agente receptor, requisitando-se ao mesmo terceiro confiável uma nova criptografia da mensagem. Nosso sistema de segurança não faz uso de assinatura digital.

A outra técnica que serve de base teórica para mecanismos de segurança de sistemas distribuídos é autenticação. Esta técnica é o meio pelo qual as identidades dos agentes clientes e servidores são estabelecidas de maneira confiável. O mecanismo utilizado para atingir esse objetivo baseia-se na posse de chaves de criptografia, isto é, podemos inferir que um agente tem a identidade que afirma, se ele possui a chave secreta apropriada. Assim como nos trabalhos de espionagem ou nas sociedades secretas, a posse da senha é exigida para autenticar o possuidor da identidade.

Os mecanismos de autenticação para sistemas distribuídos tomam a forma de um serviço de autenticação, quando implantados em um ambiente computacional. Esse serviço deve prover funcionalidades como geração, armazenamento e distribuição de todas as chaves de criptografia necessárias ao sistema. Nosso sistema de segurança implementa um servidor de autenticação, cujo protocolo será descrito mais adiante.

A última técnica relativa a segurança é controle de acesso. Os mecanismos de controle de acesso preocupam-se em assegurar que os acessos aos recursos de informação (por exemplo, arquivos, processos, ou portas de comunicação) e aos recursos de hardware (servidores de impressão, pools de processadores ou gateways de rede) estejam disponíveis apenas para os usuários autorizados a fazê-los. Realizar controle de acesso é a principal missão do nosso sistema de segurança. Esse controle é feito com base em informações obtidas de forma criptografada e mediante autenticação dos agentes que se comunicam.

A seguir, apresentamos o protocolo de autenticação no qual se baseou nosso sistema de segurança. Nesse protocolo é possível observar também operações de criptografia. Primeiramente, será dada uma visão esquemática do protocolo e, em seguida, ele será explicado em detalhes, através de um exemplo.

A: Objeto que inicia a comunicação;

B: Objeto parceiro de A na comunicação;

K_A: Chave secreta do objeto A;

K_B: Chave secreta do objeto B;

K_AB: Chave secreta usada exclusivamente para comunicação entre os objetos A e B;

N_A: Número gerado por A para certificar-se de que está se comunicando com S;

S: Servidor de autenticação no qual os objetos confiam;

{M}_k:Mensagem M criptografada usando a chave K.

Vamos entender esse processo através de um exemplo. Suponha que existe um usuário chamado João, o qual utiliza a versão 1.5 de um sistema de informações destinado à gerência de recursos humanos, denominado SRH. Transportando esse contexto para um sistema computacional, temos dois objetos que precisam se comunicar, de tal forma que nenhum outro elemento seja capaz de entender os dados que eles trocam: um usuário e uma versão de aplicação. Devido a essa capacidade de comunicação sigilosa chamamos ambos os objetos de principal. O sigilo da mensagem é obtido através de operações de criptografia e descriptografia, usando chaves secretas. Isto nos permite concluir que todo principal deve possuir uma senha, a qual será conhecida apenas por ele e por um servidor de autenticação em quem ele confie. Então, vamos completar nosso exemplo: a senha de João será sjoão e a senha de SRH 1.5 será ssrh15. Traduzindo os elementos desse contexto para o esquema apresentado anteriormente, temos o seguinte:

A: é o usuário João (é um principal que inicia uma comunicação);

B: é a versão de aplicação SRH 1.5 (é o principal parceiro de A na comunicação);

K_A: é a chave secreta de João - sjoão;

K_B: é a chave secreta de SRH 1.5 - ssrh15.

Para que o objeto João (A) consiga iniciar uma "conversa" segura com o objeto SRH 1.5 (B), os seguintes procedimentos de autenticação são executados:

(A è  S: A,B,N_A): João (A) envia uma mensagem ao servidor de autenticação (S), que conhece sua senha e a de muitos outros objetos, solicitando que este gere um ticket de acesso. Para tanto, João (A) informa seu nome (A), o nome do objeto com quem deseja se comunicar (B), SRH 1.5, e um identificador de mensagem (N_A). Note que, no passo 2, João (A) receberá de volta o identificador de mensagem (N_A), porém criptografado através da sua própria chave ({N_A} K_A), que só é conhecida por ele mesmo e pelo servidor de autenticação em quem ele confia (S). Assim sendo, João (A) terá certeza de que foi respondido pelo autenticador em quem confia (S) se, ao descriptografar o identificador de mensagem, encontrar exatamente o valor que enviou no passo 1 (N_A).

(S è A: {N_A, B, K_AB, {K_AB, A} K_B} K_A): após receber de João (A) a solicitação de um ticket de acesso para se comunicar com a versão de aplicação SRH 1.5 (B), o servidor de autenticação em quem os dois confiam (S) prepara as informações requisitadas e as envia para o João (A). Como isso funciona? Em primeiro lugar, o servidor de autenticação (S) procura no seu catálogo de principals os dois objetos envolvidos na conexão (João e SRH 1.5) e recupera suas respectivas chaves secretas. Em seguida, o autenticador (S) gera aleatoriamente uma chave secreta (K_AB) que deve ser usada nas trocas de mensagens entre João (A) e SRH 1.5 (B). O próximo passo é a preparação do ticket de acesso que foi solicitado ({K_AB, A} K_B). Note que essa informação está criptografada com a chave secreta de SRH 1.5 (K_B, portanto João (A) não conseguirá desvendá-la quando recebê-la, apenas SRH 1.5 será capaz disso. No passo 3, João (A) enviará o ticket para o SRH 1.5 (B) que, ao descriptografá-lo, descobrirá quem deseja contatá-lo (A - João) e qual chave secreta deve ser usada nessa conexão (K_AB). Finalmente, o servidor de autenticação (S) criptografa todas as informações que João (A) necessita, utilizando sua chave secreta, e lhas envia. Vale observar que, neste caso, B representa a referência de SRH 1.5, ou seja, é uma informação que permite localizar o objeto SRH 1.5 na rede, antes de interagir com o mesmo.

(Aè B: {K_AB, A} K_B): João (A) recebe as informações produzidas pelo servidor de autenticação (S) no passo 2 e realiza algumas tarefas antes de prosseguir no passo três. Em primeiro lugar, descriptografa a resposta do autenticador usando sua chave secreta. Em seguida, certifica-se de que o autenticador não é um impostor, isto é, verifica se o identificador de mensagem está correto. Depois, guarda a chave secreta de conexão entre João (A) e SRH 1.5 (B) (K_AB) para utilizá-la mais tarde, durante uma troca de mensagens. Finalmente, obtém a referência de SRH 1.5 (B) para enviar-lhe a mensagem registrada neste passo 3. Esta mensagem é simplesmente o ticket de acesso gerado pelo servidor de autenticação (S). João (A) envia o ticket para o SRH 1.5 (B) e espera receber como retorno um enigma, ou seja, um valor criptografado através da chave secreta de conexão entre João (A) e SRH 1.5 (B) (K_AB), o qual deve ser interpretado, convertido para outro valor e devolvido ao SRH 1.5, no intuito de provar-lhe que o objeto interlocutor é realmente João (A) e não um impostor.

(B è A: {N_B} K_AB): a chegada de um ticket em SRH 1.5 (B) indica que o objeto origem da mensagem deseja se comunicar de forma segura. Antes, porém, de começar o intercâmbio de informações, o SRH 1.5 (B) deve certificar-se de que não está interagindo com um impostor. Com esse objetivo, ele envia para seu interlocutor um enigma ({N_B}K_AB), criptografado com a chave secreta de conexão entre João (A) e SRH 1.5 (B) (K_AB), guardando uma cópia desse dado. Se o objeto interlocutor for realmente João (A), saberá interpretar o enigma.

(A è B: {N_B-1} K_AB): somente João (A) e SRH 1.5 (B) conhecem a chave de conexão K_AB. Quando recebe o enigma (N_B), João (A) descriptografa essa informação e a converte em outro valor, que representa a solução do enigma (N_B-1). Em seguida, criptografa esse valor usando a chave secreta K_AB e envia para SRH 1.5, que confere a informação e, caso esteja correta, estabelece a conexão. Se o objeto que interage com SRH 1.5 é um impostor, ele não conhece K_AB e conseqüentemente soluciona o enigma de forma equivocada. Neste caso, não será estabelecida a conexão entre os objetos.

Observe que em momento algum circulam pela rede as senhas dos objetos que se comunicam. Elas são usadas apenas para codificar e decodificar as mensagens de autenticação. Este é o grande mérito desse processo.