Sistemas Distribuídos Segurança

1. Sistemas DistribuídosSegurança Capítulo 2 (seção 2.3.3): O Modelo de Segurança Capítulo 7: Visão geral de técnicas de segurança Algoritmos criptográficos Assinaturas digitais Aspectos práticos do uso de criptografia Estudos de caso

2. Objetivos • O modelo de segurança • Tipos de ameaças • Técnicas básicas • Técnicas de criptografia • Sigilo e privacidade • Autenticação • Certificados e credenciais • Controle de acesso • Logs de auditoria • Algoritmos de criptografia simétricos e assimétricos • Assinaturas digitais • Abordagens para o projeto de sistemas seguros • Pragmática e casos de estudo 2 *

3. Access rights Principal (user) Principal (server) Objetos and “principals” Figure 2.13 • Objeto (ou recurso) • Mailbox, arquivo do sistema, parte de um sítio web comercial • “Principal” (entidade que realiza uma requisição) • Usuário ou processo que tem autoridade (direito) para realizar ações • A identidade de um principal é importante Object invocation Client Server result Network 3 *

4. m Copy of The enemy m’ p m Process q Process Communication channel O Inimigo Figure 2.14 • Ataques • A aplicações que lidam com informações financeiras ou outros tipos de informação para os quais sigilo e integridade são essenciais • Inimigo (adversário): autor dos ataques • Ameaças • A processos, canais de comunicação, negação de serviço 4 *

5. Cryptography B Principal A Principal The enemy p Process Process q Secure channel Canais seguros Figure 2.15 • Propriedades • Cada processo deve ter certeza sobre a identidade dos demais • Dados são privativos e protegidos contra adulteração • Proteção contra repetição (replay) ou re-ordenação dos dados • Emprego de criptografia • Privacidade baseada em ocultação criptográfica • Autenticação baseada na prova de propriedade de segredos • Propriedade de segredos: • Chaves de criptografia privativas convencionais • Par de chaves pública/privativa • Ocultação de informações criptográficas baseia-se em: • Confusão e difusão 5 *

6. Ameaças e formas de ataque • Espionagem (eavesdropping) • obtenção de informação privativa ou sigilosa • Mascaramento • alguém assume a identidade de um outro usuário / “principal” • Adulteração de mensagens • alteração do conteúdo de mensagens em trânsito • ataque tipo “man in the middle” (corrompe o mecanismo de canal seguro) • Repetição (Replay) • armazenamento de mensagens seguras e posterior re-envio das mesmas • Negação de serviço (“denial of service”) • inundar um canal ou outro recurso, negando acesso a outros usuários 6 *

7. Ataques imunes a canais segurosou outras técnicas criptográficas • Ataques de negação de serviço • Uso excessivo e deliberado de recursos, a ponto de os tornar inacessíveis a usuários legítimos • “Cavalos de Tróia” e vírus • Um vírus apenas pode entrar em um computador quando código é importado. • Mas usuários freqüentemente necessitam novos programas, Ex.: • Instalação de novo software • Código móvel “baixado” dinamicamente por software existente (ex.: applets Java) • Execução acidental de programas suspeitos • Defesas: autenticação de código (código assinado), validação de código (checagem de tipos, prova), “caixa de areia” (sandboxing). 7 *

8. Cenário 1: Comunicação sigilosa com uma chave secreta compartilhada Questões importantes: Distribuição de chaves: Como Alice pode enviar uma chave compartilhada KAB para Bob de maneira segura? “Freshness” da comunicação: Como Bob saberia que {Mi} não é uma cópia de uma mensagem anterior de Alice que foi capturada por Mallory e repetida (replayed) posteriormente? Alice e Bob compartilham uma mesma chave secreta KAB. Alice usa KAB e uma função de encriptação pré-acordada E(KAB, M) para encriptar e enviar quaisquer mensagens {Mi}KAB para Bob. Bob lê as mensagens encriptadas usando a função de decriptação correspondente D(KAB, M). Alice e Bob podem continuar usando KAB enquanto for seguro assumir que KAB não foi comprometida. 9 *

9. Cenário 2: Comunicação autenticada com um servidore chaves privadas • Esta é uma versão simplificada do protocolo de Needham and Schroeder (e Kerberos). • Questões de temporização e replay – tratadas em N-S e Kerberos. • Não apropriada para e-commerce porque o serviço de autenticação não escala… • Suponha que Bob é um servidor de arquivos; Sara é um serviço de autenticação. Sara compartilha chave secreta KA com Alice e chave secreta KB com Bob. • Alice envia uma mensagem (não encriptada) para Sara informando sua identidade e requisitando um ticket para acesso a Bob. • Sara envia uma resposta para Alice, {{Ticket}KB, KAB}KA. A resposta é encriptada com KA e consiste em: • um ticket (a ser enviado para Bob junto com cada requisição de acesso a arquivo) encriptado com KB, e uma nova chave secreta KAB. • Alice usa KA para decriptar a resposta. • Alice envia para Bob uma requisição R para fazer acesso a um arquivo: • {Ticket}KB, Alice, R. • O ticket é, na verdade, {KAB, Alice}KB. Bob usa KB para decriptá-lo e checar que o nome de Alice está correto; então usa KAB para encriptar as respostas para Alice. Um ticket é um item criptografado contendo: a identidade do principal para o qual ele foi emitido, e uma chave compartilhada para a sessão de comunicação. 10 *

10. Cenário 3: Comunicação autenticada com chaves públicas • Mallory poderia interceptar a requisição inicial de Alice ao serviço de distribuição de chaves pedindo o certificado de chave pública de Bob e enviar uma resposta contendo sua própria chave pública. Ela pode então interceptar todas as mensagens. Bob tem um par de chaves pública/privada <KBpub,KBpriv> Alice obtém um certificado, assinado por uma autoridade confiável, informando a chave pública de Bob, KBpub Alice cria uma nova chave compartilhada KAB , encripta-a com KBpub usando um algoritmo de chave pública e envia o resultado para Bob. 3. Bob usa sua chave privada, KBpriv, para decriptar a mens. de Alice. (Se eles quiserem ter certeza de que a mensagem não foi adulterada, Alice pode adicionar um valor pré-acordade à mensagem, de forma que Bob possa checá-lo.) 11 *

11. Cenário 4: Assinaturas digitais com uma função de “digest” segura A função de digest deve ser segura contra o chamado “ataque do aniversário”. Alice deseja publicar um documento M de tal forma que qualquer um possa verificar que o documento foi originado por ela. Alice computa um digest de tamanho fixo do documento: Digest(M). Alice encripta o digest com sua chave privativa, acrescenta-o a M produz o seguinte documento assinado: (M, {Digest(M)}KApriv), o qual fica disponível para os usuários. Bob obtém o documento assinado, extrai M computa Digest(M). Bob usa a chave pública de Alice para decriptar {Digest(M)}KApriv e compara o resultado com o digest que ele calculou. Se iguais, a assinatura de Alice foi verificada com sucesso. 12 *

12. Ataque do aniversário Paradoxo do aniversário: Resultado estatístico: se houver 23 pessoas em uma sala, há grande chance de que 2 delas terão o mesmo dia de aniversário. 1. Alice prepara duas versões M and M' de um contrato para Bob. M é favorável a Bob e M' não o é. Alice cria várias versões sutilmente diferentes de ambos M and M', as quais são visivelmente indistinguíveis uma da outra, através de métodos tais como a adição de espaços em branco ao final das linhas. Ela compara os hashes de todas as versões de M com todas as versões de M'. (É provável que ela encontrará duas iguais, devido ao “Paradoxo do Aniversário”.) Quando ela tem um par de documentos M and M' que tenham o mesmo valor como hash, ela entrega o documento favorável M para Bob para ele assinar com uma assinatura digital usando sua chave privativa. Quando ele retorna o documento, ela o substitui pela versão desfavorável com mesmo hash, M', retendo a assinatura dada para M. • Se os valores de hash são de 64 bits, são necessárias apenas 232 versões of M and M’ na média. • Isto é insuficiente para se ter um certo conforto. É necessário usar valores de hash de pelo menos 128 bits para se proteger deste ataque. 13 *

13. 1. Certificate type : Account number 2. Name : Alice 3. Account : 6262626 Figure 7.5 Public-key certificate for Bob's Bank 4. Certifying authority : Bob’s Bank 5. Signature : {Digest(field 2 + field 3)} {Digest(field 2 + field 3)} KFpriv KBpriv 1. Certificate type : Public key 2. Name : Bob’s Bank 3. Public key : KBpub 4. Certifying authority : Fred – The Bankers Federation 5. Signature : Certificados Figure 7.4 Alice’s bank account certificate • Certificado: uma afirmação assinada por uma autoridade apropriada. • Certificados requerem: • Um formato padrão pré-acordado entre as partes • Acordo sobre a formação de cadeias de confiança. • Datas de validade, de forma que certificados possam ser revogados. 14 *

14. S u b jec t D i s t i n g u is he d N a m e, Pu b l ic K e y Iss ue r D i s t i n g u is he d N a m e, Si g n at u r e Pe ri o d o f v a li d i t y N o t Be f o r e Da t e, No t A f t e r D ate A d m i ni str a t ive i n fo rma ti o n V er si o n , S e r i a l N u mb e r Ex t en d e d I n f or m a t i o n Formato de Certificado X509 Figure 7.13 15

15. Figure 7.4 Alice’s bank account certificate 1. Certificate type : Account number 2. Name : Alice 3. Account : 6262626 Figure 7.5 Public-key certificate for Bob's Bank 4. Certifying authority : Bob’s Bank {Digest(field 2 + field 3)} 5. Signature : {Digest(field 2 + field 3)} KFpriv KBpriv Public key 1. Certificate type : 2. Name : Bob’s Bank 3. Public key : KBpub 4. Certifying authority : Fred – The Bankers Federation 5. Signature : Certificados como credenciais • Certificados podem atuar como credenciais • Evidência sobre os direitos de um “principal” de acesso a um recurso • Os dois certificados mostrados no slide anterior poderiam atuar como credenciais para Alice operar sua conta bancária • Ela precisaria adicionar seu certificado de chave pública a cada transação * 16

16. Controle de acesso • Domínio de proteção • Um conjunto de pares <recurso, direitos> • Duas abordagens principais de implementação: • Listas de controle de acesso (ACL) associadas a cada objeto • Ex.: Permissões de acesso a arquivos no Unix  • Para tipos de objetos e comunidades de usuários mais complexos, ACLs podem se tornar muito complexas • Capacidades (capabilities) associadas a “principals” • Como uma chave • Formato: <resource id, permitted operations, authentication code> • Não podem ser passíveis de serem forjadas • Problemas: espionagem, dificuldade de cancelamento drwxr-xr-x gfc22 staff 264 Oct 30 16:57 Acrobat User Data -rw-r--r-- gfc22 unknown 0 Nov 1 09:34 Eudora Folder -rw-r--r-- gfc22 staff 163945 Oct 24 00:16 Preview of xx.pdf drwxr-xr-x gfc22 staff 264 Oct 31 13:09 iTunes -rw-r--r-- gfc22 staff 325 Oct 22 22:59 list of broken apps.rtf 17 *

17. Credenciais • Requisições para acesso a recursos devem vir acompanhadas de credenciais: • Evidência do direito do “principal” requisitante de acesso ao recurso • Caso mais simples: um certificado de identidade do “principal”, assinado pelo “principal”. • Credenciais podem ser usadas em combinação. Ex.: para enviar um e-mail autenticado como um membro da UFG, eu precisaria apresentar um certificado provando que sou membro da UFG, bem como um certificado do meu endereço de e-mail. • A idéia de que a credencial “fala” pelo principal • Indesejável que usuários forneçam sua senha toda vez que seus PCs fazem acesso a um server que mantém recursos protegidos. • Ao invés disso, a noção de que uma credencial “fala” pelo principal é introduzida. Ex.: o certificado de chave pública de um usuário fala por ele. • Um servidor que receba uma requisição acompanhada do certificado de um usuário pode assumir que a requisição foi gerada por ele • mesmo que tenha recebido a requisição através de terceiros 18 *

18. Delegação • Considere um servidor que imprime arquivos: • seria um desperdício copiar os arquivos: deveria acessá-los in situ • ao servidor deve ser dado acesso restrito e temporário aos arquivos do usuário • Pode usar um certificado de delegação ou uma capability • um certificado de delegação é uma requisição assinada autorizando um outro principal a acessar um recurso designado, de acordo com certas restrições. • CORBA Security Service suporta certificados de delegação. • uma capability é uma chave que permite ao seu possuidor o acesso a uma ou mais das operações suportadas por um recurso. • A restrição temporal pode ser obtida adicionando prazos de validade. 19 *

19. Algoritmos criptográficos Mensagem M, chave K, funções de criptografia publicadas E, D • Simétricos (chave secreta) E(K, M) = {M}KD(K, E(K, M)) = M Mesma chave para E e D M deve ser difícil (não factível) de se computar se K não for conhecida. A forma usual de ataque é por força bruta: tentar todos os valores de chave possíveis para um dado par M, {M}K. Pode-se resistir a este ataque tornando K suficientemente grande ~ 128 bits • Assimétricos (chave pública) Chaves separadas para encriptação e decriptação: Ke, Kd D(Kd. E(Ke, M)) = M Depende do uso de uma função trap-door para se criar chaves. E tem alto custo computacional. Usa chaves muito grandes > 512 bits • Protocolos Híbridos – usado em SSL (atualmente conhecido como TLS) Usa criptografia assimétrica para transmitir a chave simétrica que é então usada para encriptar os dados transmitidos em uma sessão. 20 *

20. Figure 7.6 Cipher block chaining (CBC) XOR n+3 n+2 n+1 plaintext blocks E(K, M) n-3 n-2 n-1 n ciphertext blocks Figure 7.7 Stream cipher keystream number E(K, M) buffer n+3 n+2 n+1 generator XOR ciphertext plaintext stream stream Blocos de cifra, encadeamento, cifras de fluxo A maioria dos algoritmos opera sobre blocos de 64 bit. Fraqueza de cifras de único bloco: padrões repetidos podem ser detectados. 21 *

21. Algoritmos de criptografia simétricos Todos estes são programas que realizam operações de confusão e difusão sobre blocos de dados binários TEA: um algoritmo simples mas efetivo desenvolvido na U. Cambridge (1994) com finalidade de ensino e explanação de conceitos. Chave de 128 bits, 700 kbytes/s. DES: Data Encryption Standard (EUA, 1977). Atualmente, não é seguro em sua forma original. Chave de 56 bits, 350 kbytes/s. Triple-DES: aplica DES três vezes, com duas chaves diferentes. Chaves de 112 bits, 120 Kbytes/s. IDEA: International Data Encryption Algorithm (1990). Parecido com TEA. Chave de 128 bits, 700 kbytes/s. AES: Advanced Encryption Standard (proposto nos EUA, 1997). Chaves de 128/256 bits. Há muitos outros algoritmos efetivos. Veja Schneier [1996]. As taxas de dados acima foram medidas em um processador Pentium II com clock de 330 MHZ. PCs de hoje (janeiro de 2002) deveriam obter uma melhora de 5x. 22 *

22. key 4 x 32 bits plaintext and result 2 x 32 Exclusive OR logical shift TEA: Função de encriptação Figure 7.8 • Linhas 5 & 6 realizam a confusão (XOR do texto deslocado)e difusão (deslocamento e troca de valor, entre y e z) void encrypt(unsigned long k[], unsigned long text[]) { unsigned long y = text[0], z = text[1]; unsigned long delta = 0x9e3779b9, sum = 0; int n; for (n= 0; n < 32; n++) { sum += delta; y += ((z << 4) + k[0]) ^ (z+sum) ^ ((z >> 5) + k[1]); 5 z += ((y << 4) + k[2]) ^ (y+sum) ^ ((y >> 5) + k[3]); 6 } text[0] = y; text[1] = z; } 23 *

23. TEA: Função de decriptação Figure 7.9 void decrypt(unsigned long k[], unsigned long text[]) { unsigned long y = text[0], z = text[1]; unsigned long delta = 0x9e3779b9, sum = delta << 5; int n; for (n= 0; n < 32; n++) { z -= ((y << 4) + k[2]) ^ (y + sum) ^ ((y >> 5) + k[3]); y -= ((z << 4) + k[0]) ^ (z + sum) ^ ((z >> 5) + k[1]); sum -= delta; } text[0] = y; text[1] = z; } • O inverso da função de encriptação 24 *

24. TEA in use Figure 7.10 void tea(char mode, FILE *infile, FILE *outfile, unsigned long k[]) { /* mode is ’e’ for encrypt, ’d’ for decrypt, k[] is the key.*/ char ch, Text[8]; int i; while(!feof(infile)) { i = fread(Text, 1, 8, infile); /* read 8 bytes from infile into Text */ if (i <= 0) break; while (i < 8) { Text[i++] = ' ';} /* pad last block with spaces */ switch (mode) { case 'e': encrypt(k, (unsigned long*) Text); break; case 'd': decrypt(k, (unsigned long*) Text); break; } fwrite(Text, 1, 8, outfile); /* write 8 bytes from Text to outfile */ } } 25 *

25. Uma trapdoor provê uma entrada secreta para uma sala. Uma vez dentro, a saída é óbvia, mas se estiver de fora, necessita-se saber o segredo para entrar. Algoritmos de criptografia assimétricos Todos dependem do uso de funções do tipo trap-door • Uma função trap-door é uma função apenas de entrada (oneway), com uma saída secreta – ex.: produto de dois números grandes; fácil de multiplicar, muito difícil (não factível) de se fatorar. RSA: O primeiro algoritmo prático (Rivest, Shamir and Adelman 1978) e até hoje o de uso mais freqüente. Tamanho de chave variável: 512-2048 bits. Velocidade entre 1 e 7 kbytes/s. (Processador PII 350 MHz) Curva elíptica: Um método recentemente desenvolvido, usa chaves mais curtas e mais rápidas. Algoritmos assimétricos são cerca de 1000 x mais lentos e, portanto, não são práticos para encriptação de grandes quantidades de dados, mas suas outras propriedades os tornam ideais para distribuição de chaves e para autenticação. Veja a seção 7.3.2 para uma descrição e exemplo do algoritmo RSA. 26 *

26. Assinaturas digitais Requisito: • Autenticação de documentos armazenados e mensagens • Proteção contra assinaturas forjadas • Prevenir que o assinante repudie um documento por ele assinado (negando sua responsabilidade) A encriptação de um documento com uma chave constitui uma assinatura • impossível para outros realizarem sem conhecimento da chave • autenticação forte de documentos • proteção forte contra falsificações • fraca contra repúdio (assinante pode dizer que a chave foi comprometida) 29 *

27. Funções de digest seguro • O documento inteiro encriptado é uma chave impraticavelmente longa • sendo assim, encripta-se apenas um digest (resumo) do documento • Uma função de digest seguro computa um hash de tamanho fixo H(M) que caracteriza o documento M • H(M) deve ser: • rápido de se computar • difícil de inverter - difícil de computar M dado H(M) • difícil de derrotar em quaisquer variantes do Birthday Attack • MD5: Desenvolvido por Rivest (1992). Computa um digest de 128 bit. Taxa de 1740 kbytes/s. • SHA: (1995) baseado em no MD4 de Rivestmas tornado mais seguro através da produção de um digest de 160 bits. Taxa? 750 kbytes/s. • Qualquer algoritmo de criptografia assimétrico pode ser usado em nidi CBC (cipher block chaining). O último bloco na cadeia é H(M) 30 *

28. signed doc M {h} h Kpri E(K , h) H(M) pri M 128 bits {h} D(K ,{h}) h' Kpri pub M h = h'?authentic:forged h H(doc) Assinaturas digitais com chaves públicas Figure 7.11 Assinatura Verificação 31 *

29. M signed doc h H(M+K) M K M h H(M+K) h = h'?authentic:forged h' K MACs: Assinaturas de baixo custo com chave privada MAC: Message Authentication Code Figure 7.12 Assinatura Assinante e verificador compartilham a chave privada K Verificação 32 *

30. Key size/hash size Extrapolated PRB optimized speed (bits) speed (kbytes/sec.) (kbytes/s) TEA 128 700 - DES 56 350 7746 112 120 2842 Triple-DES IDEA 128 700 4469 512 7 - RSA RSA 2048 1 - MD5 128 1740 62425 160 750 25162 SHA Desempenho de algoritmos de encriptação e digest seguro Figure 7.14 os dados são para um proc. Pentium II a 330 MHZ Algoritmo Secret key Publickey Digest PRB = Preneel, Rijmen and Bosselaers [Preneel 1998] 33 *

31. Estudo de caso: O protocolo Needham - Schroeder Nos primeiros sistemas distribuídos (1974-84) era difícil proteger os servidores • Ex.: contra ataques de mascaramento sobre um servidor de arquivos • porque não havia mecanismos para autenticar a origem das requisições • criptografia de chave pública ainda não era disponível ou prática • computadores eram muito lentos para calcular funções trap-door • o Algoritmo RSA não estava disponível até 1978 Needham e Schroeder portanto desenvolveram um protocolo de autenticação e distribuição de chaves para uso em uma rede local • Um primeiro exemplo do tipo de cuidado necessário para se projetar um algoritmo efetivamente seguro • Introduziu várias idéias de projeto, incluindo o uso de nonces. * 34

32. Header Message Notes A requisita que S providencie uma chave para 1. A->S: A, B, NA comunicação com B. S returns a message encrypted in A’s secret key, 2. S->A: {NA , B, KAB, containing a newly generated key KAB and a {KAB, A}KB}KA Ticket ‘ticket’ encrypted in B’s secret key. The nonce NA demonstrates that the message was sent in response to the preceding one. A believes that S sent the message because only S knows A’s secret key. A sends the ‘ticket’ to B. {KAB, A}KB 3. A->B: B decrypts the ticket and uses the new key KAB to {NB}KAB 4. B->A: encrypt another nonce NB. A demonstrates to B that it was the sender of the {NB - 1}KAB 5. A->B: previous message by returning an agreed transformation of NB. O protocolo de autenticação com chave secreta de Needham–Schroeder Ponto fraco: A msg 3 pode não ser “fresca” – e KABpode ter sido comprometida enquanto armazenada no computador de A. Kerberos (a seguir) contempla isto adicionando um timestamp, ou nonce, à msg 3. Figure 7.15 NA é um nonce. Nonces são inteiros que são adicionados a mensagens para demonstrar a originalidade da transação. Eles são geradas pelo processo remetente sempre que necessário, por exemplo incrementando um contador ou lendo o relógio do sistema (com presição de milissegundos). 35 *

33. Estudo de caso: Kerberos – serviço de autenticação e distribuição de chaves • Torna segura a comunicação com servidores em uma LAN • Desenvolvido no MIT nos anos 1980para prover segurança em uma rede de campus com mais de 5000 usuários • baseado no protocolo de Needham - Schroeder • Padronizado e agora incluído em sistemas operacionais • Internet RFC 1510, OSF DCE • BSD UNIX, Linux, Windows 2000, NT, XP, etc. • Disponível no sítio do MIT • O servidor Kerberos cria uma chave secreta compartilhada para cada servidor que necessite e a envia (encriptada) para o computador do usuário • A senha do usuário é o segredo original compartilhado com Kerberos 36 *

34. Protocolo Needham - Schroeder Kerberos Key Distribution Center TGS: Ticket-granting service 1. A->S: A, B, NA Authentication database Step A 2. S->A: {NA , B, KAB, Ticket- Authen- granting tication 1. Request for {KAB, A}KB}KA service T service A TGS ticket {KAB, A}KB 3. A->B: 2. TGS ticket {NB}KAB 4. B->A: Step B 3. Request for {NB - 1}KAB 5. A->B: server ticket Login Step C 4. Server ticket session setup 5. Service Server request Service session setup function Request encrypted with session key DoOperation Reply encrypted with session key Server Client Arquitetura de sistema de Kerberos Figure 7.16 Step A once per login session Step B once per server session Step C once per server transaction 37 *

35. Kerberized NFS • O protocolo Kerberos é muito caro para ser aplicado a cada operação do NFS • Kerberos é usado no serviço de montagem (mount): • para autenticar a identidade do usuário • O UserID e GroupID do usuário são armazenados no servidor com o endereço IP do cliente • Para cada requisição de arquivo: • O UserID e GroupID são enviados encriptados na chave de sessão compartilhada • O UserID e GroupID devem ser iguais àqueles armazenados no servidor • Os endereços IP também devem ser idênticos • Esta abordagem tem alguns problemas • não consegue acomodar múltiplos usuários compartilhando o mesmo computador cliente • todos os sistemas de arquivos remotos devem ser montados a cada login do usuário 38 *

36. Estuto de caso: Secure Socket Layer (SSL) • Distribuição de chaves e canais seguros para comércio na Internet • Protocolo híbrido; depende de criptografia de chave pública • Originalmente desenvolvido pela Netscape Corporation (1994) • Extendido e adotado como um padrão da Internet com o nome de Transport Level Security (TLS) • Provê segurança em em todos os servidores web e browsers e em versões seguras de Telnet, FTP e outras aplicações de rede • Requisitos de projeto • Comunicação segura sem negociação de chaves ou ajuda de terceiros • Escolha livre dos algoritmos de criptografia por clientes e servidores • comunicação em cada direção pode ser autenticada e/ou encriptada 39

37. SSL SSL Change SSL Alert Handshake HTTP Telnet Cipher Spec Protocol protocol SSL Record Protocol Transport layer (usually TCP) Network layer (usually IP) SSL protocols: Other protocols: Pilha de protocolos SSL Figure 7.17 changes thesecure channel to a new spec negotiates cipher suite, exchanges certificates and key masters implements the secure channel 40 *

38. ClientHello ServerHello Componente Descrição Exemplo Certificate Cipher suite Opcional: envia o certificado do servidor Método de troca o método a ser usado para RSA com certificados Certificate Request e requisita o certificado do cliente de chaves troca da chave de sessão de chave pública ServerHelloDone Cifra para transf. a cifra de bloco ou stream a ser IDEA Certificate ClientA ServerB Envia resposta com o certificado do cliente de dados usada para dados Certificate Verify se requisitado Fução para digest para criação de códigos de SHA de mensagens autenticação de msgs. (MACs) Change Cipher Spec Muda a cipher suite e finaliza Finished o handshake Change Cipher Spec Finished SSL handshake protocol Figure 7.18 Estabelece a versão do protocolo, o ID da sessão, cipher suite, método de compressão, troca de valores de inicialização aleatórios Inclui a troca da chave mestra. A chave mestra é usada por A e B para gerar: 2 chaves de sessão 2 chaves MAC KAB MAB KBA MBA 41 *

39. Componente Descrição Exemplo Método de troca o método a ser usado para RSA com certificados de chaves troca da chave de sessão de chave pública Cifra para transf. a cifra de bloco ou stream a ser IDEA de dados usada para dados Fução para digest para criação de códigos de SHA de mensagens autenticação de msgs. (MACs) SSL: opções de configuração do handshake Figure 7.19 42 *

40. abcdefghi Application data Fragment/combine abc def ghi Record protocol units Compress Compressed units Hash MAC Encrypt Encrypted Transmit TCP packet SSL record protocol Figure 7.20 43 *

41. Sumário • É essencial proteger contra ataques os recursos, canais de comunicação e as interfaces de sistemas e aplicações distribuídos. • Isto é obtido com o uso de mecanismos de controle de acesso e canais seguros. • Criptografia de chave pública e secreta provê a base para autenticação e comunicação segura. • Kerberos e SSL são componentes de sistema largamente utilizados que suportam comunicação segura e autenticada. 44 *

42. Suposições de pior caso linhas mestras de projeto [p. 260] • As interfaces são expostas • As redes são inseguras • Limitar o tempo de vida e o escopo de cada segredo • Os algoritmos e código de programa são disponíveis aos intrusos • Os intrusos podem ter acesso a vastos recursos • Minimizar a base de confiança 45