Criptografia e segurança de redes Capítulo 17

Apresentação em tema: "Criptografia e segurança de redes Capítulo 17"— Transcrição da apresentação:

1 Criptografia e segurança de redes Capítulo 17
Quarta Edição por William Stallings Slides de Lawrie Brown Tradução: Rodrigo Moutinho Slides de Lawrie Brown para “Criptografia e segurança de redes”, 4/e, por William Stallings, Capítulo 17 – “Segurança na Web”.

2 Capítulo 17 – Segurança na Web
Use a mente. Acorde para a realidade. — Da canção, "I've Got You under My Skin“ de Cole Porter Nota de abertura.

3 Segurança na Web A web é muito usada por empresas, órgãos do governo e indivíduos Mas a Internet & Web são vulneráveis Tem uma variedade de ameaças Integridade Confidencialidade Negação de serviços Autenticação Necessidade de mecanismos adicionais de segurança O amplo mundo da Web é muito usado por empresas, órgãos do governo e indivíduos. Mas a Internet e a Web são altamente vulneráveis a compromissos de vários tipos, com uma diversidade de ameaças como mostrado. Pode ser descrito como ataques passivos inclusive escutas de tráfego de rede entre navegadores e servidores, e ganho de acesso a informações em um Web site que supostamente teriam que ser restrito, e ataques ativos inclusive personificando outro usuário, alterando mensagens em transito entre cliente e servidor, e alterando informações em um Web site. A Web tem necessidade de mecanismos adicionais de segurança para responder a essas ameaças.

4 SSL (Secure Socket Layer)
Serviço de segurança na camada de transporte Originalmente desenvolvido pelo Netscape Versão 3 projetada com contribuição pública Subseqüentemente se tornou a Internet padrão conhecida como TLS (Transport Layer Security) Usa TCP para fornecer confiança nos serviços ponta a ponta (end-to-end) SSL tem duas camadas de protocolos SSL provavelmente é o mais amplo serviço de segurança usado na Web. Ele é implementado na camada de transporte; cf IPSec (IP Security) na camada de rede; ou vários mecanismos de camada de aplicação eg. S/MIME & SET (later). SSL foi projetada para uso do TCP para fornecer confiança nos serviços ponta a ponta (end-to-end). Netscape originou o SSL. A versão 3 do protocolo foi projetada com revisão e contribuição pública da indústria e foi publicada como um esboço de documento da Internet. Subseqüentemente, o grupo de trabalho IERF TLS foi formado para desenvolver um norma comum. SSL não é um simples protocolo no entanto duas camadas são mostradas a seguir.

5 Arquitetura SSL Protocolo de registro SSL
Protocolo de estabelecimento de sessão SSL Protocolo de mudança de especificação de cifra SSL Protocolo de alerta SSL Protocolo de registro SSL A figura do Stallings 17.2 mostra a pilha de protocolos SSL. O Protocolo de Registro SSL oferece serviços básico de segurança para vários protocolos de camadas superior. Em particular o Hypertext Transfer Protocol (HTTP), que oferece o serviço de transferência para interação cliente/servidor Web, pode operar em cima do SSL. Três protocolos da camada superior são definidos como parte do SSL: o Protocolo de Estabelecimento de Sessão (Handshake Protocol), o Protocolo de Mudança de Especificação de Cifra (Change Cipher Spec Protocol) e o Protocolo de Alerta (Alert Protocol). Esses protocolos específicos do SSL são usados no gerenciamento de trocas SSL.

6 Arquitetura SSL Conexão SSL Sessão SSL
um transiente, peer-to-peer, relacionamento de conexão associado a uma sessão SSL Sessão SSL uma associação entre um cliente e um servidor criados pelo Protocolo de Estabelecimento de Sessão definem um conjunto de parâmetros criptográficos podem ser compartilhados entre várias conexões Dois conceitos importantes são a conexão SSL e a sessão SSL: Conexão: A conexão é uma rede de transporte que oferece a um tipo adequado de serviço, como conexões transientes, relacionamentos peer-to-peer, associados com uma sessão Sessão: Um sessão SSL é associada entre um cliente e um servidor, criado pelo Protocolo de Estabelecimento de Sessão. Sessões definem o conjunto de parâmetro de segurança criptográficos, que podem ser compartilhados entre várias conexões. Sessões são usada para evitar a trabalhos negociação de novos parâmetros de segurança para cada conexão.

7 Serviços de Protocolo de Registro SSL
integridade da mensagem usa um MAC com chave secreta compartilhada similar ao HMAC mas com um preenchimento diferente confidencialidade usando criptografia simétrica com chave secreta compartilhada definida pelo Protocolo de Estabelecimento de Sessão AES, IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40, RC4-128 mensagem é comprimida antes de ser criptografada Protocolo de Registro SSL oferece dois serviços para conexões SSL: Integridade da mensagem: O Protocolo de Estabelecimento de Sessão define uma chave secreta compartilhada que é usada para formar um código de autenticação de mensagem (MAC), que é similar ao HMAC Confidencialidade: O Protocolo de Estabelecimento de Sessão define uma chave secreta compartilhada que é usada para criptografia convencional dos dados a serem transportados pelo SSL. A mensagem é comprimida antes de ser concatenada com o MAC e criptografada, com uma gama de cifras suportadas como é mostrado a seguir.

8 Operação do protocolo de registro SSL
Dados da aplicação Fragmentar Compactar Adicionar MAC A figura do Stallings 17.3 mostra completamente a operação do protocolo de registro SSL. O protocolo de registro pega a mensagem da aplicação a ser transmitida, fragmenta os dados em blocos gerenciáveis, opcionalmente comprimi os dados, aplica o MAC, criptografa, adiciona um cabeçalho, e transmite a unidade resultante em um segmento TCP. Os dados recebidos são decriptografados, verificados, descompactados e remontados e, então, entregues a camada superior de aplicação. Criptografar Anexar cabeçalho de registro SSL

9 Protocolo de mudança de especificação de cifra SSL
um dos três protocolos específicos do SSL que utilizam o Protocolo de Registro SSL uma mensagem única faz com que o estado pendente vire o estado atual por isso atualiza o conjunto de cifras a ser usado O Protocolo de mudança de especificação de cifra SSL é um dos três protocolos específicos do SSL que utiliza o Protocolo de Registro SSL, e é o mais simples, consistindo em uma única mensagem. Seu propósito é fazer com que o estado pendente seja copiado para o estado atual, o que atualiza o conjunto de cifras a ser usado na conexão.

10 Protocolo de alerta SSL
transmite alertas relacionados ao SSL para as partes envolvidas gravidade alerta (1) ou fatal (2) alerta específico fatal: unexpected_message, bad_record_mac, decompression_failure, handshake_failure, illegal_parameter alerta: close_notify, no_certificate, bad_certificate, unsupported_certificate, certificate_revoked, certificate_expired, certificate_unknown compactados e criptografados como todos os dados SSL O Protocolo de alerta é usado para transmitir alertas relacionados ao SSL para as partes envolvidas. Assim como as outras aplicações que usam SSL, as mensagens de alertas são compactadas e criptografas, conforme especificados pelo estado atual. Cada mensagem nesse protocolo consiste em dois bytes, o primeiro tem valor alerta (1) ou fatal (2) para transportar o grau de gravidade da mensagem. O segundo byte contem um código que indica o alerta específico. O primeiro grupo a ser mostrado são os alertas fatais, os outros são os avisos.

11 Protocolo de estabelecimento de sessão SSL
permite servidor e cliente fazer: autentiquem um ao outro negociem um algoritmo de criptografia e de MAC Negociem chaves criptográficas a serem usadas compreende uma série de mensagens em fases Estabelecer capacidades de segurança Autenticação de servidor e troca de chaves Autenticação de cliente e troca de chaves Término A parte mais complexa do SSL é o Protocolo de Estabelecimento de Sessão. Esse protocolo permite que o servidor e o cliente se autentiquem um ao outro e negociem um algoritmo de criptografia e MAC e chaves criptográficas a serem usadas para proteger dados envidados em um registro SSL. O Protocolo de Estabelecimento de Sessão é usado antes de quaisquer dados de aplicação sejam transmitidos. Esse protocolo é composto por uma série de mensagens trocadas entre cliente e servidor, que pode ser vista em 4 fases: Fase 1: Estabelecer capacidades de segurança – Essa fase é usada pelo cliente para iniciar a conexão lógica e estabelecer as capacidades de segurança que serão associadas a ela. Fase 2: Autenticação de servidor e troca de chaves – O servidor inicia essa fase enviando um certificado, caso precise ser autenticado. Fase 3: Autenticação de cliente e troca de chaves – O cliente deve verificar se o servidor forneceu um certificado válido, caso exigido, e verificar se os parâmetros server_hello são aceitáveis. Fase 4: Término – A fase completa a configuração de uma conexão segura. O cliente envia uma mensagem change_cipher_spec e copia o CipherSpec pendente para o CipherSpec atual.

12 SSL Handshake Protocol
Fase 1 Estabelecer qualificações de segurança, incluindo versão de protocolo, ID de sessão, conjunto de cifras, método de compactação e números aleatórios iniciais. Fase 2 O servidor pode enviar certificado, troca de chaves e solicitar certificado. O servidor sinaliza o final da fase da mensagem hello. Fase 3 O cliente envia o certificado se solicitado. O cliente envia a troca de chaves. O cliente pode enviar a verificação de certificado. Fase 4 Trocar conjunto de cifras e encerrar o protocolo de estabelecimento de sessão. Observação: transferência sombreadas são mensagens opcionais ou dependentes de situação que nem sempre são enviadas. Cliente Servidor Tempo A figura do Stallings 17.6 mostra a troca inicial necessária para estabelecer a conexão lógica entre cliente e servidor. Essa troca pode ser vista com quatro fazer previamente discutidas.

13 TLS (Transport Layer Security)
padronização IETF na RFC 2246 similar ao SSLv3 com pequenas diferenças grava no formato de número de versão usa HMAC para MAC funções pseudo-aleatórias para expandir segredos tem outros códigos de alerta algumas diferenças nas cifras disponíveis mudanças nos tipos de certificados e negociações mudanças nas cifras computacionais e nos enchimentos TLS é uma iniciativa de padronização IETF cujo objetivo é produzir um padrão de Internet que seja uma versão do SSL. O TLS é definido como um padrão proposto para a Internet (Proposed Internet Standard) na RFC 2246, a qual é muito semelhantes à SSLv3, mas com um número de pequenas diferenças nas áreas indicadas, como discutidos no texto.

14 Secure Electronic Transactions (SET)
especificação aberta de criptografia e segurança para proteger transações envolvendo cartões de crédito pela Internet desenvolvido em 1996 pela MasterCard e Visa não é um sistema de pagamentos no entanto é um conjunto de protocolos e formatos de segurança canal de comunicações seguro entre todas as partes confiança no uso de certificados digitais X.509v3 privacidade, para disponibilizar as informação apenas para quem precisa SET é uma especificação aberta de criptografia e segurança, criada para proteger transações envolvendo cartões de crédito pela Internet. SETv1 surgiu de um pedido de padrões de segurança pela MasterCard e Visa em A partir de 1996 ocorreram diversos testes de conceito e por volta de 1998 a primeira onda de produtos compatíveis com o SET estava disponível. SET não é, por si só, um sistema de pagamento. Em vez disso é um conjunto de protocolos e formatos de segurança que permite que os usuários empreguem a infra-estrutura de pagamento por cartão de crédito existente em uma rede, como a Internet, de modo seguro. Basicamente oferece três serviços: Um canal de comunicações seguro entre todas as partes envolvidas em uma transação Confiança no uso de certificados digitais X.509v3 Privacidade, pois as informações só estão disponíveis às partes em uma transação quando e onde forem necessárias

15 Participantes do SET Comerciante Internet Proprietário do cartão
Autoridade Certificadora A figura do Stallings indica os participantes do sistema SET, que incluem os seguintes: Proprietário do cartão: compradores interagem com comerciantes a partir de computadores pessoais pela Internet. Comerciante: uma pessoa ou organização que possui bens ou serviços para vender ao proprietário do cartão. Emissor: instituição financeira, como um banco, que oferece um cartão de pagamento. Acquirer: instituição financeira que estabelece uma conta com um comerciante e processa autorizações de cartão de pagamentos e pagamentos. Gateway de pagamento: uma função operada pelo acquirer ou por um terceiro designado que processa mensagens de pagamentos para o comerciante. Autoridade certificadora (CA): entidade confiável para emitir certificados de chave pública X.509v3 para proprietários de cartão, comerciantes e gateways de pagamento. Emissor Rede de pagamento Acquirer Gateway de pagamento

16 Transação SET O cliente abre uma conta.
O cliente recebe um certificado. Os comerciantes têm seus próprios certificados. O cliente faz um pedido. O comerciante é verificado. O pedido e o pagamento são enviados. O comerciante solicita autorização de pagamento. O comerciante confirma o pedido. O comerciante fornece os bens ou serviços. O comerciante solicita o pagamento. Agora brevemente os detalhes da seqüência de eventos que são necessários para a transação como mostrado, os detalhes no texto.

17 Assinatura Dual cliente cria duas mensagens
informação do pedido (OI) para o comerciante informação de pagamento (PI) para o banco nenhuma das partes precisa de informações da outra porém precisam ser vinculados assinatura dual é usada para isso cliente concatena os hashes de OI e PI DS=E(PRc, [H(H(PI)||H(OI))]) A finalidade da assinatura dual é vincular duas mensagens destinadas a dois destinatários diferentes, a informação do pedido (OI) para o comerciante e a informação de pagamento (PI) para o banco. O comerciante não precisa saber o número do cartão de crédito do cliente, e o banco não precisa saber os detalhes do pedido do cliente, porém os dois itens precisam ser vinculados de modo que possam ser usados pra resolver disputas, se for preciso. O cliente apanha o hash (usando SHA-1) da PI e o hash da OI, os concatena, e calcula o resultado. Finalmente, o cliente criptografa o hash final com sua chave privada para assinatura, criando uma assinatura dual. A operação pode ser resumida como: DS=E(PRc, [H(H(PI)||H(OI))])

18 Solicitação de compra SET
A transação de solicitação de compra SET consiste em quatro mensagens Inicia solicitação – solicita os certificados Inicia resposta – resposta assinada Solicitação de compra – de OI e PI Resposta de compra – confirma o pedido A transação de solicitação de compra consiste em quatro mensagens: Inicia a solicitação, Inicia a resposta, Solicitação de compra e Resposta de compra. Para enviar as mensagens SET para o comerciante, o proprietário do cartão de precisa ter uma cópia dos certificados do comerciante e do gateway de pagamento. O cliente solicita os certificados na mensagem Iniciar Solicitação (Initiate Request), enviada ao comerciante. O comerciante gera uma resposta e assina com sua chave de assinatura privada. O proprietário do cartão confirma os certificados do comerciante e do gateway por meio de respectivas assinaturas nos seus certificados feitas pela CA e depois cria a OI e a PI. Em seguida, o proprietário do cartão prepara a mensagem Solicitação de Compra (Purshase Request) com a informação relacionada com a compra e a informação relacionado com o pedido. A mensagem Resposta de Compra inclui um bloco de resposta que confirma o pedido e referencia o número da transação correspondente.

19 Solicitação de compra - Cliente
Mensagem de solicitação Passado pelo comerciante ao gateway de pagamento Assinatura Dual Recebido pelo comerciante A figura do Stallings mostra os detalhes do conteúdo da mensagem Solicitação de Compra gerada pelo cliente. A mensagem inclui o seguinte: 1 – Informações relacionadas à compra, que serão encaminhadas ao gateway de pagamento pelo comerciante que consiste em: PI, Assinatura Dual, e o resumo da mensagem de OI (OIMD). 2 – Informações relacionadas ao pedido, necessárias para o comerciante e são formadas pela: OI, Assinatura Dual, e o resumo da mensagem de PI (PIMD). 3 – Certificado do proprietário do cartão. Este contém a chave pública de assinatura do proprietário do cartão. PI OI PIMD OIMD E Ks PUb = Informações de pagamento Informações de pedido Resumo da mensagem de PI Resumo da mensagem de OI Criptografia (RSA para assimétrica; DES para simétrica) Chave simétrica temporária Chave pública de troca de chave do banco Assinatura Dual Certificado de proprietário

20 Solicitação de compra - Comerciante
Confirma o certificado do proprietário do cartão pela assinatura da CA Confirma a assinatura dual usando a chave pública de assinatura do cliente garantindo que o pedido não foi alterado em trânsito e que foi assinado usando a chave privada de assinatura do proprietário do cartão Processa o pedido e encaminha as informações do pagamento para o gateway de pagamento para autorização (descrito mais adiante) Envia uma resposta de compra ao proprietário do cartão Quando o comerciante recebe a mensagem Solicitação de Compra, a lista de ação é realizada. Detalhes da verificação de solicitação são mostradas no próximo slide; e a autorização no slide seguinte. A mensagem Solicitação de Compra inclui um bloco de resposta que confirma o pedido e referência o número da transação correspondente. Esse bloco é assinado pelo comerciante usando a chave privada de assinatura. O bloco e a assinatura são enviados ao cliente juntamente com o certificado de assinatura do comerciante.

21 Solicitação de compra - Comerciante
Mensagem de solicitação OI OIMD PIMD D H PUc = Informações de pedido Resumo da mensagem de OI Resumo da mensagem de PI Decriptografia (RSA) Função de hash (SHA-1) Chave pública de assinatura do cliente Passado pelo comerciante ao gateway de pagamento A figura do Stallings ilustra o processo de criptografia usado pelo comerciante para verificar a solicitação do pedido do cliente (etapa 2 do slide anterior). Assinatura Dual Certificado de proprietário

22 Autorização do gateway de pagamento
Verifica todos os certificados Decriptografa o envelope digital do bloco de autorização para obter a chave simétrica e depois decriptografa o bloco de autorização Verifica a assinatura do comerciante no bloco de autorização Decriptografa o envelope digital do bloco de pagamento para obter a chave simétrica e depois decriptografa o bloco de pagamento Verifica a assinatura dual no bloco de pagamento Verifica se a ID da transação recebida do comerciante combina com a da PI recebida (indiretamente) do ciente Solicita e recebe uma autorização do emissor Retorna uma Resposta de Autorização ao comerciante Durante o processo de pedido de um proprietário de cartão, o comerciante consegue a autorização da transação com o gateway de pagamento (etapa 3, previamente, com a lista do comerciante). A autorização de pagamento garante que a transação foi aprovada pelo emissor e garante que o comerciante receberá o pagamento, portanto o comerciante pode fornecer os serviços ou bens ao cliente. A troca de autorização de pagamento consiste em duas mensagens: Solicitação de Autorização (Authorization Request) e Resposta de Autorização (Authorization Response). O gateway de pagamento realiza as tarefas recebidas pela mensagem de Solicitação de Autorização.

23 Captação de Pagamento O comerciante envia um gateway de pagamento uma transação de captura de pagamento Gateway checa a solicitação Depois os fundos são transferidos para a conta do comerciante Notifica o comerciante em uma mensagem de Resposta de Captação Para obter o pagamento, o comerciante envia uma mensagem de solicitação de captura para o gateway de pagamento, para que o comerciante gere, assine e criptografe o bloco de solicitação de captura, que inclui o valor do pagamento e a ID de transação. O gateway de pagamento recebe a mensagem de solicitação de captura, decriptografa e verifica o bloco de solicitação de captura e decriptografa e verifica o bloco do token de captação. Depois, ele verifica a consistência entre a solicitação e o token de captação. Depois, cria uma solicitação de compensação que é enviada ao emissor pela rede de pagamento privada que faz com que sejam transferidos os fundos para a conta do comerciante. O gateway, então, notifica o pagamento ao comerciante em uma mensagem de Resposta de Captura (Capture Response) que inclui um bloco de resposta de captação que o gateway assina e criptografa mais o certificado de chave de assinatura do gateway. O software do comerciante armazena a resposta de captação a ser usada para reconciliação com o pagamento recebido pelo acquirer.

24 Sumário Tenha considera: Necessidade de segurança na Web
Protocolos de segurança da camada de transporte - SSL/TLS (Secure Socket Layer / Transport Layer Service) Protocolo seguro de pagamento do cartão de crédito – SET (Secure Eletronic Transaction) Sumário do capítulo 17.