Sistemas Distribuídos Segurança

Apresentação em tema: "Sistemas Distribuídos Segurança"— Transcrição da apresentação:

1 Sistemas Distribuídos Seguranç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 George took about 4 hours to present this material.

2 Objetivos O modelo de segurança Técnicas básicas
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 Objetos and “principals”
Figure 2.13 Access rights Object Principal (user) Principal (server) invocation Client Server result Network 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 Objects such as mailboxes, shared web pages, etc. Introduces concept of a Principal - a user or a process with authority (rights) 3 *

4 Inimigo (adversário): autor dos ataques Ameaças
O Inimigo Figure 2.14 Copy of m The enemy Communication channel Process p q m’ 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 Open distributed systems have exposed communication channels and ports. The enemy can attempt to eavesdrop, impersonate principals, tamper with messages, flood ports with messages 4 *

5 Emprego de criptografia
Canais seguros Figure 2.15 Principal A Secure channel Process p q B The enemy Cryptography Propriedade de segredos: Chaves de criptografia privativas convencionais Par de chaves pública/privativa 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 Ocultação de informações criptográficas baseia-se em: Confusão e difusão Popup 1 identifies crypto principles of diffusion and confusion Popup 2 expands on shared secrets Cryptographic concealment is based on: Confusion and diffusion Shared secrets: Conventional crypto keys (not algorithms) Public/private pair --( illustration - a sheet of paper torn in half) 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 seguros ou 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). DoS: a form of attack in which the enemy interferes with the activities of authorized users by making excessive and pointless invocations on services or message transmissions in a network, resulting in overloading of physical resources (network bandwidth, server processing capacity). Such attacks are usually made with the intention of delaying or preventing actions by other users. For example, the operation of electronic door locks in a building might be disabled by an attack that saturates the computer controlling the electronic locks with invalid requests. Mobile code may easily play a Trojan horse role, purporting to fulfil an innocent purpose but in fact including code that accesses or modifies resources that are legitimately available to the host process but not to the originator of the code. The methods by which such attacks might be carried out are many and varied, and the host environment must be very carefully constructed in order to avoid them. Many of these issues have been addressed in Java and other mobile code systems, but the recent history of this topic has included the exposure of some embarrassing weaknesses. This illustrates well the need for rigorous analysis in the design of all secure systems. 7 *

8 The February 2000 IP Spoofing DDoS attack
Internet Campus intranets Firewall amazon.com yahoo.com IP = x.x.x.x IP = y.y.y.y IP = n.n.n.i hidden Echo request | source = x.x.x.x | destination = n.n.n.i Echo reply | source = n.n.n.i | destination = x.x.x.x Untrue! Compromised host on each local network sends repeatedly (for all i): resulting in: 8 *

9 Cenário 1: Comunicação sigilosa com uma chave secreta compartilhada
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. 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? Popup: Bullet points 9 *

10 Cenário 2: Comunicação autenticada com um servidor e chaves privadas
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. Popup 1 defines ticket Popup 2 bullet points 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… 10 *

11 Cenário 3: Comunicação autenticada com chaves públicas
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.) Popup bullet point 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. 11 *

12 Cenário 4: Assinaturas digitais com uma função de “digest” segura
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. Popup 2 bullet points A função de digest deve ser segura contra o chamado “ataque do aniversário”. 12 *

13 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. Popup 1 shows an example of birthday attack Popup 2 bullet points 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 *

14 Figure 7.4 Alice’s bank account certificate
Certificados 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. Figure 7.4 Alice’s bank account certificate 1. Certificate type : Account number 2. Name Alice 3. Account 4. Certifying authority Bob’s Bank 5. Signature {Digest(field 2 + field 3)} KBpriv Figure 7.5 Public-key certificate for Bob's Bank 1. Certificate type : Public key 2. Name Bob’s Bank 3. KBpub 4. Certifying authority Fred – The Bankers Federation 5. Signature {Digest(field 2 + field 3)} KFpriv Popup shows Alice's bank account certificate 14 *

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

16 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 Figure 7.5 Public-key certificate for Bob's Bank 1. Certificate type : Public key 2. Name Bob’s Bank 3. KBpub 4. Certifying authority Fred – The Bankers Federation 5. Signature {Digest(field 2 + field 3)} KFpriv Account number Alice Account KBpriv Figure 7.4 Alice’s bank account certificate Further details on the implementation of access control in distributed systems and the uses of credentials are in Sections and 16 *

17 Duas abordagens principais de implementação:
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 Oct 30 16:57 Acrobat User Data -rw-r--r gfc22 unknown Nov 1 09:34 Eudora Folder -rw-r--r gfc22 staff Oct 24 00:16 Preview of xx.pdf drwxr-xr-x gfc22 staff Oct 31 13:09 iTunes -rw-r--r gfc22 staff Oct 22 22:59 list of broken apps.rtf Popup shows Unix file access control list 17 *

18 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 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 . 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 *

19 Considere um servidor que imprime arquivos:
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. Consider the example of a print server that accepts requests to print files. It would be wasteful of resources to copy the file, so the name of the file is passed to the print server and it is accessed by the print server on behalf of the user making the request. If the file is read-protected, this does not work unless the print server can acquire temporary rights to read the file. Delegation is a mechanism designed to solve problems such as this. Delegation can be achieved using a delegation certificate or a capability. The certificate is signed by the requesting principal and it authorizes another principal (the print server in our example) to access a named resource (the file to be printed). In systems that support them, capabilities can achieve the same result without the need to identify the principals – a capability to access a resource can be passed in a request to a server. The capability is an unforgeable, encoded set of rights to access the resource. When rights are delegated, it is common to restrict them to a subset of the rights held by the issuing principal, so that the delegated principal cannot misuse them. In our example, the certificate could be time-limited to reduce the risk that the print server’s code is subsequently compromised and the file disclosed to third parties. The CORBA Security Service includes a mechanism for the delegation of rights based on certificates, with support for the restriction of the rights carried. 19 *

20 Algoritmos criptográficos
Mensagem M, chave K, funções de criptografia publicadas E, D Simétricos (chave secreta) E(K, M) = {M}K D(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. Popup bullet points defining symmetric and asymmetric algorithms 20 *

21 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. n n+3 n+2 n+1 XOR E(K, M) n-1 n-2 n-3 plaintext blocks ciphertext blocks Figure 7.6 Cipher block chaining (CBC) XOR E(K, M) number generator n+3 n+2 n+1 plaintext stream ciphertext buffer keystream Figure 7.7 Stream cipher Popups show cipher block chaining snd stream cipher illustrations Compare use of keystream with the use of a white noise generator to enable secret conversation to be recorded in an exposed place. Playbeack substracts the original white noise from the recorded sound. Can combine CBC with key stream generator for extra security. 21 *

22 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 *

23 TEA: Função de encriptação
Figure 7.8 key 4 x 32 bits plaintext and result 2 x 32 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; Exclusive OR logical shift The TEA algorithm uses rounds of integer addition, XOR (the ^ operator) and bitwise logical shifts (<< and >>) to achieve diffusion and confusion of the bit patterns in the plaintext. The plaintext is a 64-bit block represented as two 32-bit integers in the vector text[]. The key is 128 bits long, represented as four 32-bit integers. On each of the 32 rounds, the two halves of the text are repeatedly combined with shifted portions of the key and each other in lines 5 and 6. The use of XOR and shifted portions of the text provides confusion, and the shifting and swapping of the two portions of the text provides diffusion. The non-repeating constant delta is combined with each portion of the text on each cycle to obscure the key in case it might be revealed by a section of text that does not vary. The decryption function is the inverse of that for encryption and is given in Figure 7.9. Linhas 5 & 6 realizam a confusão (XOR do texto deslocado) e difusão (deslocamento e troca de valor, entre y e z) 23 *

24 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 *

25 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 *

26 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. 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. 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: 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. A trapdoor provides a secret way into a room. If you're inside, the way out is obvious, if you're outside, you need to know a secret to get in. Veja a seção para uma descrição e exemplo do algoritmo RSA. 26 *

27 Encriptação com RSA - 1 Para encontrar um par de chaves e, d:
1. Escolha dois números primos grandes, P e Q (cada um maior que 10100), e forme: N = P * Q Z = (P–1) * (Q–1) 2. Para d escolha qualquer número que seja primo relativo com Z (isto é, tal que d não tenha fatores comuns com Z). Ilustramos as computações envolvidas usando valores pequenos para P e Q: P = 13, Q = 17 –> N = 221, Z = 192 d = 5 3. Para encontrar e resolva a equação: e * d = 1 mod Z Isto é, e x d é o menor elemento divisível por d na série Z+1, 2Z+1, 3Z+1, ... . e x d = 1 mod = 1, 193, 385, ... 385 é divisível por d e = 385/5 = 77 Hidden 27

28 Encriptação com RSA - 2 Para encriptar texto usando o método RSA, o plaintext é dividido em blocos iguais de tamanho k bits, onde 2k < N (isto é, tal que o valor numérico de um bloco é sempre menor que N; em aplicações práticas, k está usualmente na faixa de 512 a 1024). k = 7, uma vez que 27 = 128 A função para encriptar um único bloco de plaintext M é: E'(e,N,M) = Me mod N para uma mensagem M, o texto cifrado é M77 mod 221 A função para decriptar um bloco de texto cifrado c para produzir o bloco de plaintext original é: D'(d,N,c) = cd mod N Rivest, Shamir e Adelman provaram que E' e D' são mutuamente inversas (isto é, E'(D'(x)) = D'(E'(x)) = x) para todos os valores de P na faixa 0 ≤ P ≤ N. Os dois parâmetros e,N podem ser considerados como uma chave para a função de encriptação; similarmente d,N representam uma chave para a função de decriptação. Desta forma, podemos escrever Ke = <e,N> e Kd = <d,N>, podendo obter a função de encriptação: E(Ke, M) ={M}K (a notação indica que a mensagem encriptada pode ser decriptada apenas pelo detentor da chave privada Kd) e D(Kd, ={M}K ) = M. Hidden 28

29 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 *

30 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 *

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

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

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

34 Estudo de caso: O protocolo Needham - Schroeder
Nos primeiros sistemas distribuídos ( ) 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 *

35 O protocolo de autenticação com chave secreta de Needham–Schroeder
Ponto fraco: A msg 3 pode não ser “fresca” – e KAB pode ter sido comprometida enquanto armazenada no computador de A. Kerberos (a seguir) contempla isto adicionando um timestamp, ou nonce, à msg 3. Figure 7.15 Header Message Notes 1. A->S: A, B, NA A requisita que S providencie uma chave para comunicação com B. 2. S->A: {NA , B, KAB, {KAB, A}KB}KA S returns a message encrypted in A’s secret key, containing a newly generated key KAB and a ‘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. 3. A->B: A sends the ‘ticket’ to B. 4. B->A: B decrypts the ticket and uses the new key KAB to encrypt another nonce NB. 5. A->B: A demonstrates to B that it was the sender of the previous message by returning an agreed transformation of NB. {KAB, A}KB {NB}KAB {NB - 1}KAB 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). Ticket 35 *

36 Torna segura a comunicação com servidores em uma LAN
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 1980 para 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 *

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

38 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 *

39 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

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

41 SSL handshake protocol
Figure 7.18 Client A Server B ClientHello ServerHello 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 Componente Descrição Exemplo Método de troca de chaves o método a ser usado para troca da chave de sessão RSA com certificados de chave pública Cifra para transf. de dados a cifra de bloco ou stream a ser usada para dados IDEA Fução para digest de mensagens para criação de códigos de autenticação de msgs. (MACs) SHA Cipher suite Certificate Certificate Request ServerHelloDone Opcional: envia o certificado do servidor e requisita o certificado do cliente Certificate Certificate Verify Envia resposta com o certificado do cliente se requisitado Change Cipher Spec Finished Muda a cipher suite e finaliza o handshake 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 *

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

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

44 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 *

45 Suposições de pior caso linhas mestras de projeto
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 Interfaces are exposed Distributed systems are composed of processes that offer services or share information. Their communication interfaces are necessarily open (to allow new clients to access them) – an attacker can send a message to any interface. Networks are insecure For example, message sources can be falsified – messages can be made to look as though they came from Alice when they were actually sent by Mallory. Host addresses can be ‘spoofed’ – Mallory can connect to the network with the same address as Alice and receive copies of messages intended for her. Limit the lifetime and scope of each secret When a secret key is first generated we can be confident that it has not been compromised. The longer we use it and the more widely it is known, the greater the risk. The use of secrets such as passwords and shared secret keys should be time-limited, and sharing should be restricted. Algorithms and program code are available to attackers The bigger and the more widely distributed a secret is, the greater the risk of its disclosure. Secret encryption algorithms are totally inadequate for today’s large-scale network environments. Best practice is to publish the algorithms used for encryption and authentication, relying only on the secrecy of cryptographic keys. This helps to ensure that the algorithms are strong by throwing them open to scrutiny by third parties. Attackers may have access to large resources The cost of computing power is rapidly decreasing. We should assume that attackers will have access to the largest and most powerful computers projected in the lifetime of a system, then add a few orders of magnitude to allow for unexpected developments. Minimize the trusted base The portions of a system that are responsible for the implementation of its security, and all the hardware and software components upon which they rely, have to be trusted – this is often referred to as the trusted computing base. Any defect or programming error in this trusted base can produce security weaknesses, so we should aim to minimize its size. For example, application programs should not be trusted to protect data from their users. 45

46 Notações de segurança KA Chave secreta de Alice KB
Chave secreta de Bob KAB Chave secreta compartilhada entre Alice e Bob KApriv Chave privada de Alice (conhecida apenas por Alice) KApub Chave pública de Alice (publicada por Alice para todos lerem) { M } K Msg. encript. com chave [ ]K ass. com chave Alice Primeiro participante Bob Segundo participante Carol Participante em protocolos envolvendo 3 ou 4 partes Dave Participante em protocolos envolvendo 4 partes Eve Espião (Eavesdropper) Mallory Atacante (intruso) malicioso Sara Um servidor Optional slide 46