Com  o uso cada vez mais comercial da Internet, a necessidade de um método seguro de criptografia e comunicação dos dados transmitidos entre cliente e servidor tornou-se óbvia. Este é o ponto de atuação do SSL.

     SSL é uma camada do protocolo de rede, situada exatamente abaixo da camada de aplicação (Figura 1), com a responsabilidade de gerenciar um canal de comunicação seguro entre o cliente e o servidor. O SSL foi desenvolvido pela Netscape Communications Corporation e, atualmente é implementado na maioria dos browsers da WWW tais como o Netscape e o Internet Explorer. A palavra-chave https:// é usualmente empregada para designar uma conexão segura. O SSL encontra-se atualmente na versão 3.0.

Figura 1

     O SSL preenche os seguintes critérios que o fazem aceitável para o uso nas transmissões das mais sensíveis informações, como dados pessoais e números do cartão de crédito. A aplicação pode optar entre utilizar todos ou somente uma parte desses critérios dependendo do tipo e natureza das transações que estão sendo efetuadas.

     Digamos que uma mensagem é transmitida de A para B. Neste caso A usa a chave pública de B para criptografar a mensagem, tornando B a única pessoa que pode decodificar a mensagem, usando a sua chave privada. Nós não podemos entretanto ter certeza quanto a identidade de A.

     De modo a garantir a autenticidade de A no caso anterior, um sistema de códigos um pouco mais complexo é necessário. A mensagem de A para B é primeiramente criptografada com a chave privada de A e posteriormente com a chave pública de B. Para decodificar a mensagem B usa primeiro sua chave privada e depois a chave pública de A. Agora B pode ter certeza de que A é realmente quem diz ser, pois ninguém mais poderia criptografar a mensagem usando a chave privada de A. Isso é desenvolvido pelo SSL com o uso de certificados.

     No SSL, a integridade é garantida pelo uso do MAC (Message Authentication Code) com as necessárias funções da tabela hash. Na geração de uma mensagem, o MAC é obtido por aplicação das funções da tabela hash e é codificado junto com a mensagem. Após a mensagem ser recebida sua validade pode ser checada comparando-se o MAC com o resultado obtido pela reversão das funções hash . Isto previne mensagens alteradas por terceiros durante a transmissão.

     A segurança das transações é dependente das chaves de criptografia. Se uma dessas chaves cair em mãos erradas, pode ser facilmente duplicada e usada para comprometer a segurança. Um sistema totalmente seguro deve ser capaz de detectar impostores ou, ainda melhor, se prevenir contra a duplicação das chaves. Isto é executado por um hardware baseado em ficha única.O SSL não suporta sozinho esta implementação, mas a realiza em conjunto com Fortezza.

     O protocolo SSL suporta uma variedade de diferentes algoritmos criptográficos, ou Ciphers, para uso em operações de autentificação do servidor e do cliente, transmissão de certificados, e estabelecimento de sessões. Clientes e servidores podem suportar um Cipher diferente, ou um conjunto de Ciphers, dependendo de fatores como qual versão de SSL eles (cliente e servidor) suportam, políticas da companhia a respeito da força aceitável de criptografia, e restrições governamentais para exportação do software SSL. Além de outras funções, é o protocolo de Handshake do SSL que determina como cliente e servidor negociam quais conjuntos de cipher vão usar para se autenticar um para o outro, para transmitir certificados, e para estabelecer sessões.

     Os conjuntos de ciphers descritos acima se referem aos seguintes algoritmos:

     Algoritmos de troca de chaves como KEA e RSA Key Exchange governam a maneira pela qual clientes e servidores determinam as chaves simétricas que usarão durante uma sessão com SSL. O mais comumente usado é o RSA Key Exchange.

     Quando um cliente e um servidor trocam informações durante o Handshake do SSL, eles identificam o algoritmo habilitado mais forte que eles tenham em comum e, passam a usá-lo na sessão. Para servir ao maior grupo possível de usuários, os administradores podem habilitar o maior conjunto de algoritmos de cifragem possível.Alguns organizadores desabilitam os algoritmos mais fracos para evitar uma conexão SSL com tais algoritmos.

     Fortezza é um sistema de criptografia usado pelas agências do governo americano para manejar informações sensíveis porém não confidenciais. Ele provê uma implementação de hardware de dois ciphers desenvolvidos pelo governo: Fortezza KEA e SKIPJACK. O cipher Fortezza para SSL usa o KEA ao invés do RSA Key Exchange, e o DSA para autentificação do cliente.    

     A chave pública de criptografia RSA é amplamente usada para autentificação e codificação na indústria de computadores. A Netscape tem licença junto a RSA Data Security Inc. para usar tal chave em seus produtos, especificamente para autentificação.

     Criptografia com chave pública é a técnica que usa um par de chaves assimétricas para criptografar e decodificar. Cada par de chaves consiste numa chave pública e outra privada. A chave pública é feita pública através de uma distribuição. A chave privada nunca é distribuída, sendo mantida sempre em segredo.

     O dado que é criptografado com uma chave pública somente pode ser decodificado com a chave privada. Alternativamente, o dado criptografado com a chave privada somente pode ser decodificado com a chave pública. Esta é a propriedade que faz com que a Criptografia com chave pública seja tão usada.

     Autentificação é o processo de verificação da identidade para que uma entidade tenha certeza de que a outra entidade é quem ela realmente diz ser. No exemplo abaixo, envolvendo Roberto e Camila, podemos verificar que a criptografia com chave pública é facilmente utilizada para verificar a identidade. Supondo que Camila queira autenticar Roberto:

       Camila ==> Roberto            mensagem aleatória

       Roberto ==> Camila            mensagem criptografada com 

                                               a chave privada de Roberto                

     A menos que você saiba exatamente o que está criptografando, nunca é uma boa idéia criptografar alguma coisa  com sua chave privada e depois enviar para outra pessoa. Essa criptografia pode ser usada contra você (lembre-se, só você poderia ter feito a criptografia pois só você tem a chave privada).

     Portanto, ao invés de criptografar a mensagem enviada por Camila, Roberto constrói uma mensagem digest,  e a criptografa. Uma mensagem digest é derivada da mensagem aleatória, de maneira que possui úteis propriedades, descritas a seguir:

     Com o uso do digest, Roberto pode portanto se proteger. Ele cria um digest da mensagem aleatória enviada por Camila e, então criptografa o resultado. O digest criptografado é então mandado de volta para Camila, que pode computar o mesmo digest e autenticar Roberto decodificando a mensagem recebida e comparando os valores.

     A técnica descrita acima é conhecida como assinatura digital. Conseqüentemente nosso protocolo de autentificação será incrementado:

       Camila ==> Roberto            Oi, você é o Roberto?

       Roberto ==> Camila            Camila, aqui é o Roberto.

                                               { digest [Camila, aqui é o Roberto] }

                                               chave privada - Roberto       

     Roberto envia primeiro a versão não criptografada da mensagem "Camila, aqui é o Roberto". Então ele manda a versão criptografada - digest. Camila pode agora facilmente verificar se Roberto é realmente Roberto.    

     Como Roberto pode disponibilizar sua chave pública de uma maneira segura? Vejamos como o protocolo de autentificação nos parece:

       Camila ==> Roberto            Oi

       Roberto ==> Camila            Oi, eu sou o Roberto, 

                                               'chave pública do Roberto'     

       Camila ==> Roberto            Prove isso

       Roberto ==> Camila            Camila, aqui é o Roberto

                                              { digest [Camila, aqui é o Roberto] }

                                               chave privada - Roberto   

     Com esse protocolo qualquer um pode se passar por Roberto. Tudo o que se precisa é de uma chave pública e outra privada. Você mente para Camila e diz que é Roberto, e manda sua chave pública. Então você prova isso criptografando alguma coisa usando sua chave privada, e Camila não poderá dizer que você não é Roberto.

     Para resolver esse problema foi criado um certificado. O certificado tem o seguinte conteúdo:

     O certificado é assinado usando a chave privada do emissor do certificado. Certificados são um meio padrão de ligar uma chave pública a um nome.

     Por meio dessa tecnologia de certificado, todos podem examinar o certificado de Roberto para ver se está sendo forjado. Assumindo que Roberto tenha rígido controle sobre sua chave privada, e que seja realmente Roberto quem obteve o certificado, então tudo está bem. Agora vejamos como fica o protocolo:

       Camila ==> Roberto            Oi

       Roberto ==> Camila            Oi, eu sou o Roberto, 'Certificado - Roberto'

       Camila ==> Roberto            prove

       Roberto ==> Camila            { digest [Camila, aqui é o Roberto] }

                                                chave privada - Roberto    

     Agora quando Camila receber a primeira mensagem de Roberto, poderá examinar o certificado, checar a assinatura (usando o digest e a decodificação com a chave pública), e então checar a pessoa, confirmando ou não a autenticidade de Roberto. Ela pode então acreditar que a chave pública é a chave pública de Roberto, e pedir que Roberto prove sua identidade. Roberto segue o mesmo processo descrito anteriormente, gerando o digest e respondendo para Camila. Ela verifica a mensagem de Roberto usando a chave pública tirada do certificado.

     Suponha que uma pessoa que chamaremos de X faça o seguinte:

       Camila ==> X            Oi

       X ==> Camila            Oi, eu sou o Roberto, 'Certificado - Roberto'

       Camila ==> X            prove

       X ==> Camila            ?????

     Portanto X não conseguiu convencer Camila na mensagem final. X não tem a chave privada de Roberto, portanto não conseguiu construir uma mensagem que Camila acredita estar vindo de Roberto.

     Uma vez que Camila tenha autenticado Roberto, ela pode fazer uma outra coisa - pode mandar uma mensagem que somente Roberto pode decodificar:

       Camila ==> Roberto            { segredo } - criptografado com a

                                                chave publica de Roberto  

     A única maneira de ler o segredo é decodificando a mensagem acima com a chave privada de Roberto. Trocas de segredos é outro poderoso meio de uso da criptografia com chave pública. Mesmo que tenham outras pessoas observando a comunicação entre Roberto e Camila, ninguém a não ser Roberto pode ler o segredo. 

     Essa técnica fortalece a segurança na internet. Camila conhece o segredo porque ela o gerou. Roberto conhece o segredo porque possui a chave privada e pode decodificar a mensagem enviada por Camila. Como os dois conhecem o segredo, podem agora iniciar um algoritmo de cifragem simétrica para o envio de mensagens entre eles. Vejamos como fica agora o protocolo:

       Camila ==> Roberto            Oi

       Roberto ==> Camila            Oi, eu sou o Roberto, 'Certificado - Roberto'

       Camila ==> Roberto            prove

       Roberto ==> Camila            Camila, aqui é o Roberto

                                               { digest [ Camila, aqui é o Roberto] } 

                                                chave privada - Roberto           

       Camila ==> Roberto            Ok Roberto, aqui está um segredo

                                                {segredo} chave pública - Roberto

       Roberto ==> Camila            {mensagem qualquer} -chave secreta          

     Apesar de X (o invasor) não conseguir descobrir o segredo que Camila e Roberto estão trocando, ele pode interferir na conversa danificando-a. Por exemplo, se X está situado entre Camila e Roberto,pode escolher passar a maior parte da informação de um lado para outro, porém deturpando certas mensagens:

       Camila ==> X            Oi

       X ==> Roberto           Oi

       Roberto ==> X           Oi, eu sou o Roberto, 'Certificado - Roberto'

       X ==> Camila            Oi, eu sou o Roberto, 'Certificado - Roberto'

       Camila ==> X            prove

       X ==> Roberto           prove

       Roberto ==> X           Camila, aqui é o Roberto

                                       { digest [Camila, aqui é o Roberto] }

                                       chave privada - Roberto

       X ==> Camila            Camila, aqui é o Roberto

                                       { digest [Camila, aqui é o Roberto] }

                                       chave privada - Roberto

       Camila ==> X            Ok Roberto, aqui está um segredo 

                                       {segredo} chave pública - Roberto

       X ==> Roberto           Ok Roberto, aqui está um segredo 

                                       {segredo} chave pública - Roberto

       Roberto ==> X           {mensagem qualquer} - chave secreta

       X ==> Camila             mensagem alterada

                                        [ {mensagem qualquer} - chave secreta]

     X passa os dados entre Camila e Roberto até que eles troquem um segredo. Então X altera a mensagem de Roberto para Camila. Neste ponto Camila acredita em Roberto, portanto ela vai considerar a mensagem alterada como verdadeira, e usá-la. Note que X não sabe o segredo - tudo o que ele fez foi danificar a mensagem criptografada com a chave secreta.

     Para prevenir este tipo de dano, Camila e Roberto podem introduzir um código de autentificação de mensagem - MAC (message authentication code) no seu protocolo. Um MAC é um pedaço de dado que é computado usando um segredo e alguns dados transmitidos. O algoritmo digest descrito acima tem justamente as mesmas propriedades da construção de uma função MAC, que pode defender contra os ataques de X.

       MAC := Digest [mensagem qualquer, segredo]    

     Devido ao fato de que X não conhece o segredo, ele não pode computar o valor certo do digest. Se X alterar aleatoriamente uma mensagem, sua chance de sucesso é tão menor quanto maior for o digest. Por exemplo, usando MD5 ( um bom algoritmo de criptografia digest criado pela RSA), Camila e Roberto podem enviar um MAC de 128 bits com suas mensagens. As chances de X descobrir o MAC correto é de 1 em 18,446,744,073,709,551,616 - ou para propósitos práticos, nenhuma.

     Vejamos agora como fica o protocolo:

       Camila ==> Roberto            Oi

       Roberto ==> Camila            Oi, eu sou o Roberto, 'Certificado - Roberto'

       Camila ==> Roberto            prove

       Roberto ==> Camila            Camila, aqui é o Roberto

                                               { digest [Camila, aqui é o Roberto] } 

                                               chave privada - Roberto

      Camila ==> Roberto            Ok Roberto, aqui está um segredo

                                              {segredo} chave pública - Roberto

      Roberto ==> Camila           {mensagem qualquer,MAC}chave secreta       

     X terá problemas agora para alterar as mensagens trocadas por Camila e Roberto. Quando uma mensagem for alterada, o valor MAC vai também ser alterado possibilitando com que Camila ou Roberto descubram a fraude.

     O SSL suporta vários protocolos de alto nível, e um deles é o protocolo Handshake, que é usado para coordenar os estados entre cliente e servidor. Durante o handshaking ocorrem os seguintes eventos:

     Certificados são trocados entre o cliente e o servidor para provar suas identidades. A chave pública do servidor é retirada desse certificado.

     O cliente então gera um grupo de chaves aleatórias, que serão usadas para a criptografia dos dados, e para a geração dos MACs. As chaves aleatórias são criptografadas usando a chave pública do servidor e então enviadas para o servidor.

     O algoritmo de criptografia das mensagens e a função hash para a integridade, são negociadas. Esse processo de negociação pode ser feito da seguinte maneira: o cliente apresenta a lista de algoritmos suportados, e o servidor seleciona o mais forte que seja comum para os dois. Identificadores da escolha do algoritmo de criptografia e da função hash são armazenados no cipher spec field do estado corrente para ser usado pelo Record Protocol.O método de compressão também é determinado durante o handshaking.

     Ela age comprimindo os dados, usando o algoritmo de compressão selecionado no estado corrente. Todos os dados são protegidos usando os algoritmos de criptografia e MAC definidos no Cipher Spec corrente, que é parte do estado corrente. O algoritmo MAC utiliza um Message Authentication Code e uma função hash para assegurar a integridade dos dados. 

     Os processos descritos acima são reversíveis na Camada Record, no outro lado do canal de comunicações, onde os dados são decodificados, verificados, expandidos e reunidos antes de serem enviados para clientes em alto nível.

     Para encerrar uma sessão, uma das partes envia uma mensagem comunicando esse fato (Close Notify). Caso o cliente queira estabelecer nova sessão com o servidor, pode fornecer seu identificador de sessão em sua mensagem de início, dando assim continuidade a sessão estabelecida anteriormente.

     A segurança na World Wide Web entre links internacionais é comprometida pela política de segurança de certos países como Suécia, França e Estados Unidos. A tecnologia de criptografia de dados é considerada por esses países de grande importância militar, havendo portanto um controle na exportação de tais tecnologias. Nos Estados Unidos as implementações em SSL usam criptografias de 128 bits, enquanto que para produtos destinados a exportação são permitidos somente criptografias de 40 bits.

     Tal política levou as companhias americanas, como a Netscape, a implementar duas versões dos seus produtos: uma voltada para o mercado interno com 128 bits de criptografia, e outra para exportação com 40 bits de criptografia.     

E-mail: beto-ufrj@mailbr.com.br