Вы находитесь на странице: 1из 13

Trabalho de Redes de Computadores I Professor Otto Aluno: Marcos Muniz Calr Filho

Kerberos

I. II.

III.

IV. V.

VI.

Introduo O que faz o Kerberos i. Explicando como funciona ii. Autenticao de servio iii. O Ticket Granting Server iv. Cross-Realm Authentication Como Utilizar o Kerberos i. Para o usurio ii. Para o administrador Inicializando o servidor Kerberos Resgistrando Principals Kerberizando aplicaes Limitaes do Kerberos Tpicos relacionados i. Criptografia ii. DES iii. Segurana em sistemas de computao Bibliografia

Introduo:

Kerberos um protocolo desenvolvido para fornecer poderosa autenticao em aplicaes usurio/servidor, onde ele funciona como a terceira parte neste processo, oferendo autenticao ao usurio. Para garantir a segurana, ele usa criptografia de chave simtrica, com o DES. O Kerberos foi desenvolvido como parte do Project Athena, do Massachussets Institute of Technology (MIT). Seu nome vem da mitologia, onde Cerberus (Kerberus para os gregos) um co com trs cabeas que tem por misso proteger a entrada do inferno de Hades.

O que faz o Kerberos:


Para explicar o que faz o Kerberos, vamos usar algumas analogias baseadas The Moron's Guide to Kerberos, Version 1.2.2. Na vida real, usamos rotineiramente uma autenticao, na forma de (por exemplo) uma carteira de motorista. A carteira de motorista fornecida por uma agncia, na qual podemos supor confivel, e contm dados pessoais da pessoa como nome, endereo e data de nascimento. Alm disto pode conter algumas restries, como necessidade de culos para dirigir, e mesmo algumas restries implcitas (a data de nascimento pode ser usada para comprovar maioridade). Finalmente, a identificao tem um prazo de validade, a partir do qual considerada invlida. Para ser aceita como autenticao, algumas regras devem ser observadas: ao apresentar a carteira, no se pode ocultar parte dela (como foto ou data de nascimento). Alm disto, quem verifica a autenticao deve reconhecer a agncia que forneceu a autenticao como vlida (uma carteira de motorista emitida no Brasil pode no ser aceita fora do territrio nacional). Kerberos trabalha basicamente da mesma maneira. Ele tipicamente usado quando um usurio em uma rede tenta fazer uso de um determinado servio da rede e o servio quer se assegurar de que o usurio realmente quem ele diz que . Para isto, o usurio apresenta um ticket, fornecido pelo Kerberos authenticator server (AS), assim como a carteira de motorista fornecida pelo DETRAN. O servio ento examina o ticket para verificar a identidade do usurio. Se tudo estiver ok o usurio aceito. O ticket deve conter informaes que garantam a identidade do usurio. Como usurio e servio no ficam face a face uma foto no se aplica. O ticket deve demonstrar que o portador sabe alguma coisa que somente o verdadeiro usurio saberia, como uma senha. Alm disto, devem existir mecanismo de segurana contra um atacante que "pegue" um ticket e use mais tarde. Explicando como funciona: Vejamos como o Kerberos trabalha. Usurios e servios que utilizem o Kerberos possuem chaves armazenadas no AS. As chaves dos usurios so derivadas de senhas escolhidas por estes, e as chaves dos servios so geradas aleatoriamente.

Para esta explicao, imaginemos que as mensagens so escritas em papel, e so criptografadas colocando-as em uma caixa-forte, associada a uma chave. 1. Primeiro o usurio envia uma mensagem ao AS: "Eu, J. Random User, gostaria de falar com o servidor Foo". 2. Quando o AS recebe a mensagem, ele faz duas cpias de uma nova chave registrada. Estas chaves so chamadas de chaves de sesso. Elas sero usadas nas trocas diretas entre servio e usurio. 3. Ele coloca uma das chaves de sesso na Caixa 1, junto com um pedao de papel com o nome "Servidor Foo" escrito. A caixa trancada com a chave do usurio (o AS conhece todas as chaves de usurio e todas as chaves de servio). 4. Por que este papel aqui? Devemos nos lembra que a caixa na realidade apenas uma mensagem criptografada, e que a chave de sesso uma seqncia randmica de bytes. Se a Caixa 1 somente contivesse a chave de sesso, o usurio no teria como reconhecer se a resposta veio do AS, ou no saberia se a decriptao teve sucesso. Pela adio da mensagem "Servidor Foo", o usurio (mais precisamente a aplicao do usurio) poderia saber se a caixa veio do AS, e se a decriptao obteve sucesso. 5. Ele coloca a outra chave de sesso em uma Caixa 2, junto com um pedao de papel com o nome "J. Random User". Esta caixa fechada com a chave do servio. 6. Ele envia ambas as caixas ao usurio. 7. Na verso 4 do Kerberos, a Caixa 2 era colocada (sem necessidade) dentro da caixa 1, mas na verso 5 isto foi corrigido. 8. O usurio destranca a Caixa 1 com sua chave, extraindo assim a chave de sesso e o papel com o nome "Servidor Foo" escrito nele. 9. O usurio no consegue abrir a Caixa 2 (ela foi trancada com a chave do servio, que s o AS e o servio conhecem). Ento ele coloca um pedao de papel com a hora corrente numa Caixa 3, e tranca esta com chave de sesso, e envia ambas ao servio. 10. O servio abre a Caixa 2 com sua prpria chave, extraindo a chave de sesso e o papel com "J. Random User" escrito nele. Ele abre a Caixa 3 com a chave de sesso para extrair o pedao de papel com a hora corrente nele. Estes itens demonstram a identidade do usurio. O timestamp colocado na Caixa 3 para prevenir que algum faa uma cpia da Caixa 2 (devemos nos lembrar que as caixas so na verdade mensagens eletrnicas) e a utilize para se passar pelo usurio mais tarde. Como os relgios da rede nunca so perfeitamente sincronizados, uma pequena margem (em geral 5 minutos) permitida entre o timestamp e a hora atual. Alm disto, o servio mantm um lista das autenticaes recebidas recentemente para garantir que elas no foram reenviadas. A chave de servio gerada aleatoriamente e armazenada em um arquivo especial chamado de SECRETE KEY FILE. O Kerberos assume que este seguro, que ningum pode copi-lo e se passar pelo servio. No Kerberos, a Caixa 2 chamada de ticket, e a Caixa 3 de authenticator. O authenticator tipicamente contm mais informaes do que as listadas acima.

Algumas destas informaes so adicionadas em decorrncia do fato de que as mensagens so eletrnicas (por exemplo, existem checksum). Pode existir tambm uma chave secreta usada para criptografar as mensagens que sero trocadas entre usurio e servio aps a autenticao, garantindo assim a privacidade. Autenticao de servio: Algumas vezes o usurio pode querer o servio seja autenticado no retorno. Para isto, o servio pega o timestamp do authenticator (Caixa 3), acrescenta um ao seu valor, coloca em uma Caixa 4, junto com um pedao de papel com o nome "Servidor Foo" escrito nele, tranca esta caixa com a chave de sesso e envia de volta ao usurio. Ao receber a Caixa 4, o usurio abre com a chave de sesso, e verifica o timestamp. Se for maior que o enviado, significa que o servio conseguiu abrir a Caixa 2 (decriptografar o ticket). Isto acontece na verso 4 do Kerberos. Na verso 5 o servio faz mais que somente adicionar uma unidade ao timestamp. O Ticket Granting Server: Existe um problema no esquema apresentado acima. Ele ser usado toda vez que o usurio requisitar um servio, e a cada vez que isto acontecer ele ter que entrar com sua senha (destrancar a Caixa 1 com a chave do usurio). Uma primeira soluo seria armazenar a chave do usurio gerada a partir da sua senha. Mas armazenar a chave do usurio muito perigoso, pois com uma cpia desta um invasor se passaria pelo usurio at que sua senha fosse modificada. O Kerberos resolve este problema introduzindo um novo agente chamado de ticket granting server (TGS). O TGS logicamente distinto do AS, mas eles podem residir na mesma maquina. A funo do TGS a seguinte: antes de acessar qualquer servio, o usurio requisita um ticket para contatar o TGS, como se ele fosse um servio qualquer. Este ticket chamado de ticket granting ticket (TGT). Depois de receber o TGT, a qualquer momento que o usurio desejar requisitar um servio, ele ir requerer um ticket no mais do AS, mais sim do TGS. Alm disto, a resposta no ser criptografada com a chave secreta do usurio, mas sim com a chave de sesso providenciada pelo AS para ser usada entre usurio e TGS. O contedo desta resposta uma chave de sesso que ser usada com o servio regular. O resto da comunicao continua como descrito acima. Este mecanismo funciona de maneira semelhante a um visitante num local de trabalho. Voc mostra sua identificao( pode ser a carteira de motorista) e recebe uma identificao de visitante. Agora quando quiser entrar numa das vrias salas, ao invs de apresentar sua identificao oficial a cada sala (corre-se o risco de ter a identidade perdida ou roubada), basta mostrar a identidade de visitante. Se sua identidade de visitante for perdida ou roubada, voc poder torna-la invalida e substitu-la rapidamente e com facilidade, algo que no acontece com sua carteira de motorista.

A vantagem que enquanto senhas usualmente so vlidas por meses, O TGT vlido somente por um curto perodo de tempo, tipicamente 8 horas. Depois deste tempo, o TGT no pode ser usado por ningum, nem usurio nem invasor. Este TGT, como qualquer ticket que o usurio obtm armazenado no credentials cache. Existe um nmero de comandos que permitem ao usurio manipular seu prprio credentials cache. Cross Realm Authentication: Um nico AS e um nico TGS funcionam bem se o nmero de requisies for pequeno, mas com o crescimento da rede, cresce o nmero de requisies de servios, e o AS/TGS passa a ser um gargalo no processo de autenticao. Em outras palavras pode-se dizer que o sistema no esta escalado, o que muito ruim para um sistema distribudo como o Kerberos. Entretanto o Kerberos oferece a vantagem de se dividir a rede em realms. Esta diviso muitas vezes feita sobre limites organizacionais. Cada realm tem seu prprio AS e seu TGS. Para realizar uma cross-realm authenticathion (o usurio em um realm acessa um servio noutro realm) necessrio primeiro que o realm do usurio registre um remote TGS (RTGS) no realm do servio. Note que quando o TGS foi adicionado, uma comunicao a mais foi somada ao protocolo. Aqui uma outra comunicao foi adicionada: primeiro o usurio contata o AS para acessar o TGS, ento ele contata o TGS para acessar o RTGS. Finalmente ele contata o RTGS para acessar o servio. Em muitos casos, onde coexistem muitos realms, ineficiente registrar cada realm em cada outro realm. Para evitar isto, a verso 5 do Kerberos permite uma hierarquia de realms, de maneira que para contatar um servio num outro realm, pode ser necessrio contatar RTGS em um ou mais realms imediatos. O nome de cada um destes realms gravado no ticket.

Como utilizar o Kerberos:


Para o usurio: Para o usurio utilizar o Kerberos, primeiro ele deve estabelecer um Kerberos principal. Um Kerberos principal algo parecido com uma conta em uma mquina. O nome do principal do tipo your_name@YOUR.REALM. A parte antes de @ uma string voc escolhe (normalmente a mesma coisa que seu login name). A parte posterior o nome do realm. Associado a cada principal existe um nome, uma senha e algumas outras informaes. Estes dados so armazenados na base de dados do Kerberos. Esta base de dados criptografada com uma chave mestra do Kerberos, pode ser replicada para servidores escravos, e ela no pode ser examinada por qualquer um.

Para o usurio, o Kerberos quase transparente. Existe um nmero de servios setados para requerer autenticao via Kerberos. Para usar um destes servios, o usurio precisa obter um TGT primeiro. O comando para isto kinit:
% kinit Password for your_name@YOUR.RELAM

Quando o usurio entrar sua senha, o programa kinit far uma requisio ao AS para contatar o TGS. A senha ser usada para computar a chave secreta do usurio (observe que a senha ser digitada apenas uma vez e no trafegar pela rede), que ser usada para decriptar parte da resposta do AS (a parte que contm a confirmao da requisio e a chave de sesso). Se a senha estiver correta, o usurio ter um TGT. Pode-se verificar isto usando o comando klist:
% klist Ticket cache: /var/tmp/krb5cc_1234 Default principal: your_name@YOUR.REALM Expires Valid starting 24-Jul-95 12:58:02 24-Jul-95 20:58:02

Service principal krbtgt/YOUR.REALM @YOUR.REAL

O campo Ticekt cache mostra qual arquivo contm as credenciais do usurio. O principal default aquele fornecido pelo TGT. A sada uma lista dos ticket existentes, Assim se o usurio apenas requisitou o TGT, este ser o nico ticket e o nico principal ser do servio o do TGS (krbtgt). Pode-se observar que os ticket so vlidos por um determinado perodo de tempo, neste caso 8 horas. Se o usurio estiver usando uma verso kerberizada do rlogin, este programa ir usar o TGT do credentials cache para requisitar um ticket para o rlogin daemon na mquina em que est logado. Isto acontece automaticamente como pode-se notar abaixo:
% rlogin newhost.domain last login: Fri 21 12:04:40 from ...

A nica maneira de se notar a diferena listando o credentials cache:


% klist Ticket cache: /var/tmp/krb5cc_1234 Default principal: your_name@YOUR.REALM Expires Valid starting 24-Jul-95 12:58:02 24-Jul-95 20:58:02 24-Jul-95 13:03:33 24-Jul-95 21:03:33

Service principal krbtgt/YOUR.REALM @YOUR.REALM host/newhost.domain @YOUR.REALM

O significado do Service principal o seguinte: A primeira parte, antes da barra, o nome do principal. A Segunda parte, entre a barra e o @ chamado de instance. Para servios normalmente o hostname da mquina onde o servio est sendo executado, no caso de servios do Kerberos (como kinit) ele o nome do realm. Para usurios, normalmente nulo (neste caso no existe nem a barra), ou quando o usurio acessa algum servio privilegiado, existe uma indicao disto ( como your_name/admin ou your_name/secure). O ltimo componente, aps o @ o nome do realm.

Por default, o rlogin deixa qualquer ticket que ele tenha obtido no cache. Isto no um problema de segurana, a menos que algum tenha acesso ao terminal em que o usurio esteja logado, Caso o usurio no deseje deixar os credentials no cache, ele pode destru-los usando o comando kdestroy:
% kdestroy % klist klist: No credentials cache file found while setting cache flags (ticket cache /var/temp/krbrcc_1234)

O comando kdestroy remove todos os ticket (incluindo o TGT) do cache. Para o administrador: Para o administrador a coisa um pouco mais complexa. O AS e o TGS (normalmente o mesmo executvel) devem ser configurados e iniciados. Principals devem ser registrados, e o mais importante, os servios devem ser disponibilizados para uso do Kerberos. Inicializando o servidor Kerberos: Tipicamente, o administrador deve seguir os seguintes passos para inicializar o servidor Kerberos: 1. Instalar os arquivos binrios. Clientes podem ser colocados em um diretrio comum. Certos binrios (como ksu e todos os root processes) devem instalados pelo root para funcionarem corretamente. Em geral, make install da fonte de instalao far tudo para o administrador. 2. Editar o arquivo krb5.conf. Este arquivo contm as opes de configurao para os clientes, como onde esto todos os KDCs, qual KDC local, quais maquinas pertencem a quais realms, etc.. 3. Editar o arquivo /.k5login. Cada linha consiste de um nico nome de principal, que indica os direitos para o ksu. Ele apenas uma lista de controle de acesso. 4. Editar o arquivo /etc/services. 5. Editar o arquivo /etc/inetd.conf. Idealmente todos os servios devem estar fora do ar. Existem algumas verses Kerberizadas de comandos BSD que podem ser includos. Para fazer com que o daemon passe a responder esta nova verso deste arquivo, o administrador pode encontrar o inetd do processo e enviar o comando kill HUP para o processo. 6. Editar o arquivo /etc/rc.<hostname>, adicionando linhas para fazer com que os daemons krb5kdc e kadmin sejam iniciados quando a mquina bootada. 7. Criar a base de dados 8. Adicionar entradas para usurios e servios. 9. Executar os servidores krb5kdc e kadmin em background. Eles faro isto por default a partir disto. Registrando principals: Uma vez inicializada a base de dados, pode-se executar o kadmin para adicionar principals.

Kerberizando aplicaes: Esta a parte mais difcil do uso do Kerberos. Reconstruir uma aplicao para que ela passe a usar o Kerberos chamado de kerberizar a aplicao. A aplicao kerberizada deve: 1. 2. 3. 4. Encontrar a identidade do usurio. Localizar o cache de credentials do usurio. Checar para ver se existe um ticket para o servio requisitado. Se no existir, usar o TGT e a chave de sesso para enviar uma requisio para obter um.

Isto nem sempre uma programao trivial. Entretanto existem aplicaes prkerberizadas como POP e R-comandos Berkeley (por exemplo rlogin).

Limitaes do Kerberos:

O Kerberos bastante adequado para aplicaes usurio/servidor e no ponto a ponto. Como o cachemento das chaves, ticket e principals so feitos no diretrio /tmp, necessrio que as estaes de trabalho sejam seguras. Apresenta problemas com multi-homed hosts, que utilizam mais de um endereo IP. Os relgios devem estar sincronizados (em geral a diferena no pode ultrapassar cinco minutos) devido ao timestamp. vulnervel contra senhas fracas, possibilitando que um invasor intercepte uma mensagem e utilize um ataque dicionrio para descobrir a senha do usurio. Existe a possibilidade de modificao, por um atacante, das aplicaes kerberizadas.

Bibliografia

TUNG, BRYAN - "The Moron's Guide to Kerberos, Version 1.2.2" . NEUMAN, B. CLIFFORD e TS'O, THEODORE - "Keberos: An Authentication Service For Computer Networks" IEEE Communications Magazine, Volume 32, No 9, pag. 33-38, Set 1994. NEUMAN, B. CLIFFORD e STUBBLEBINE, G. STUART - "A Note on the use of Timestamps as Nonces". NEUMAN, B. CLIFFORD - "Protection and Security Inssues for Future Systems". RFC 1510. NUNES, ANTNIO CARLOS NUNES e CARLE, EMERSON - "RSA: um mtodo seguro de criptografia?". RIVEST, R. L. e SHAMIR, A. e ADLEMAN, L. - "A methode of obtaining digital signatures and public-key criptosystems". BELLOVIN, M. STEVEN e MERRITT, MICHAEL - "Limitations of the Kerberos Authentication System". NAKAMURA, EMILIO T. - "Kerberos Um sevio de Autenticao para redes de computadores". UNICAMP Trabalho para a disciplina Tpicos de Computadores II.

Criptografia: A criptografia (do grego kripts que significa escondido, oculto mais grpho que significa grafia, escrita) a arte ou cincia de escrever em cdigos, de forma que apenas o destinatrio decifre e compreenda a mensagem. Criptografia transforma um texto compreensvel, denominado texto original (plaintext) ou texto claro (cleartext), em uma informao transformada, chamada de texto cifrado (ciphertext) ou texto cdigo (codetext) ou simplesmente cifra (cipher), que tem a aparncia de um texto gerado aleatoriamente incompreensvel. O ato de transformar os dados para uma forma ilegvel denominado como cifrar, e procura garantir a privacidade, mantendo a informao escondida de pessoas no autorizadas, mesmo que estas possam visualizar os dados criptogarfados. O processo inverso e conhecido por decifrar. Ao cifrarmos ou decifrarmos uma mensagem, precisamos de informaes confidenciais, denominadas chaves. Os algoritmos de criptografia podem ser classificados em dois tipos, de acordo com o tipo de chave que usam: de chave simtrica e de chave assimtrica. Chave Simtrica: Tambm conhecidos por chave nica, utilizam a mesma chave tanto para a cifragem como para a decifragem. Este mtodo bastante limitado, pois emissor e receptor devem conhecer antecipadamente a chave, e bastante difcil de se conseguir um meio seguro de se passar a chave secreta (se fosse simples, poderamos simplesmente enviar os dados por esse meio). Um exemplo de algoritmo que usa esse mtodo o DES, e um aplicativo que o utilize o Kerberos. Chave Assimtrica: Tambm chamados de algoritmos de chave pblica e privada, utilizam chaves diferentes para cifrar e de cifrar os dados. Em um sistema de chave assimtrica cada pessoa tem duas chaves: uma chave pblica que pode ser divulgada e outra privada que deve ser mantida em segredo. Mensagens cifradas com a chave pblica s podem ser decifradas com a chave secreta e vice versa. Podemos observar o funcionamento das chaves assimtricas com o auxlio de um exemplo (retirado da pgina Verdade @bsoluta). Se Frank e Andra quiserem se comunicar secretamente usando a criptografia com chave assimtrica, eles tero de fazer o seguinte: 1. Frank escreve uma mensagem e a criptografa utilizando a chave pblica de Andra. A chave est disponvel para qualquer pessoa. 2. Frank envia a mensagem atravs da internet para Andra.

3. Andra recebe a mensagem e a decriptografa utilizando sua chave privada (s ela conhece). 4. Andra l a mensagem. Se quiser responder ela dever fazer o mesmo, a diferena que dessa vez a chave pblica de Frank ser utilizada. Como apenas Andra tem acesso a sua chave privada, somente ela poder decifrar a mensagem. A grande vantagem que no s Frank pode enviar mensagens criptografadas para Andra, mas qualquer pessoa, basta conhecer a chave pblica de Andra, alm disto, emissor e receptor no precisam combinar chaves antecipadamente. Pode-se tambm criar uma assinatura digital com chaves assimtricas. Para isso basta inverter o processo: Frank criptografa a mensagem com sua prpria chave privada e envia a Andra. Para decriptografar deve-se usar a chave pblica de Frank. Agora qualquer pessoa pode ler a mensagem, mas tem-se a certeza de foi Frank que a enviou (acreditando-se que somente ele conhece sua chave privada). Pode-se combinar os dois mtodos para Frank enviar uma mensagem secreta e assinada para Andra: 1. Frank escreve a mensagem e a criptografa usando sua chave privada (assinatura da mensagem). 2. Em seguida, ele criptografa a mensagem com a chave pblica de Andra (tornando-a secreta). 3. Frank envia a mensagem duplamente criptografada para Andra atravs da internet. 4. Andra recebe a mensagem. 5. Ela decriptografa a mensagem duas vezes. Primeiro com sua chave privada e depois com a chave pblica de Frank. 6. Agora Andra pode ler a mensagem e tem certeza de que ningum a leu e que veio de Frank. Tambm tem certeza de que no foi alterada, pois para isso o invasor teria de ter acesso a chave privada de Frank. O maior problema das chaves assimtricas que ela computacionalmente intensiva, sendo necessrio muito tempo para criptografar uns poucos pargrafos. Um algoritmo que faz criptografia assimtrica o RSA, e um exemplo de aplicativo que a utilize o PGP que possibilita correio eletrnico criptografado. Pode-se combinar os melhores aspectos da criptografia com chave simtrica e assimtrica, codificando a mensagem com o mtodo da chave simtrica e criptografando a chave simtrica com o mtodo da chave assimtrica. Com isso beneficia-se da velocidade do mtodo simtrico e da facilidade de distribuio de chaves do mtodo assimtrico. Por exemplo se Frank quiser enviar uma mensagem secreta para Andra, mas usando a combinao explicada acima:

1. Frank escreve a mensagem e a codifica usando a criptografia com chave simtrica com uma chave gerada aleatoriamente apenas para esta mensagem. Isto conhecido como chave de sesso (session key). 2. Frank criptografa essa chave de sesso com a chave pblica de Andra (isto no toma muito tempo por que a chave no muito grande). 3. Frank envia a mensagem criptografada e a chave de sesso criptografada para Andra. 4. Andra decriptografa a chave de sesso com sua chave privada. 5. Em seguida, decriptografa a mensagem usando a chave de sesso que acabou de receber. 6. Andra agora pode ler a mensagem.

Data Encryption Standart(DES): O algoritmo de criptografia DES foi desenvolvido na dcada de 70 pelo National Bureau of Standarts com ajuda da National Security Agency. O propsito era criar um mtodo padro para proteo de dados. A IBM criou o primeiro rascunho do algoritmo, chamando-o de LUCIFER. O DES tornou-se oficialmente norma federal americana em novembro de 1976. Fundamentalmente DES realiza somente duas operaes sobre sua entrada: deslocamento de bits e substituio de bits. A chave controla exatamente como esse processo ocorre. Ao fazer estas operaes repetidas vezes e de uma maneira nolinear, chega-se a um resultado que no pode ser revertido a entrada original sem o uso da chave.

O algoritmo trabalha com 64 bits de dados a cada vez. Cada bloco de 64 bits de dados sofre de 1 a 16 iteraes (16 o padro DES). Para cada iterao um pedao de 48 bits da chave de 56 bits entra no bloco de encriptao representado pelo retngulo tracejado no diagrama acima. A decriptao o processo inverso. O mdulo "F" mostrado no diagrama o corao do DES. Atualmente ele consiste de diferentes transformadas e substituies no-lineares. Uma maneira de se aumentar a segurana ao utilizar o DES usar o DES TRPLO, onde criptografa-se a mensagem, e a chave (em geral a chave usando-se chave assimtrica), junta-se chave criptografada mais mensagem criptografada e faz-se nova criptografia usando DES. Isto aumenta enormemente a dificuldade de se quebrar a criptografia. O DES foi desenvolvido h mais de 20 anos, e nestes 20 anos no apareceu nenhuma descrio de um caminho de quebr-lo, exceto pela fora bruta.

Necessidade de Segurana: No incio da era da informtica, a segurana das informaes e dos sistemas computacionais no era uma questo to importante, pois estes recursos tinham um acesso limitado, ficando confinados a uma mainframe protegido de qualquer acesso externo. Com a evoluo da informtica, o surgimento dos PCs e de redes de computadores, tornou-se possvel um compartilhamento de recursos e das informaes. Este compartilhamento aumentou a facilidade do usurio acessar estas informaes, e consequentemente cresceu tambm a probabilidade de intrusos compartilharem tambm deste acesso. Isto fez crescer muito a importncia da segurana nos sistemas de informtica. Diferentemente dos antigos sistemas mainframes, os atuais sistemas distribudos possuem um grande nmero de pontos de acesso, sendo praticamente impossvel identificar e restringir o acesso a todos eles, por isso a vulnerabilidade destes ltimos ser muito maior que dos primeiros. Hoje, existe a necessidade de redes corporativas se comunicarem entre si atravs de redes abertas, mas garantindo a segurana dos seus sistemas. Os princpios bsicos da segurana em sistemas de comunicao compreendem:

Confidencialidade tem por objetivo proteger a informao de acessos no autorizados. Integridade deve garantir a veracidade da informao protegendo-a de modificaes no autorizadas. Autenticidade visa garantir a identidade dos parceiros numa conexo, atravs da autenticao dos usurios. Disponibilidade objetiva prevenir interrupes na operao da rede garantindo a disponibilidade da informao.

Os usurios esto interconectados com as suas aplicaes distribudas atravs de redes abertas no confiveis que podem ser compartilhadas por outros usurios, os quais no esto autorizados a acessar determinados sistemas. Assim sendo necessrio identificar e autenticar o usurio que solicitar conexo ao sistema bem como verificar se ele possui autorizao para acessar os recursos solicitados. A identificao o processo inicial para verificar se esse usurio esta cadastrado ao sistema, normalmente essa identificao feita atravs de um user id. A autenticao pode ser de um dos trs tipos bsicos: 1. Confiana na mquina onde o usurio est logado. Neste caso no existe autenticao. Usado numa rede privada, onde existe o controle de todos os hosts conectados a rede. 2. O host deve provar sua identidade, e o servidor confia nas "palavras" do host. 3. Ex.: rlogin e rsh, onde a checagem feita atravs do IP. 4. O usurio deve provar sua identidade para cada servio requisitado e viceversa. 5. Ex.: Kerberos.