Copyright © George Coulouris, Jean Dollimore, Tim Kindberg 2001 email: authors@cdk2.netThis material is made available for private study and for direct use by individual teachers.It may not be included in any product or employed in any service without the written permission of the authors.

Viewing: These slides must be viewed in slide show mode.

Teaching material based on Distributed Systems: Concepts and Design, Edition 3, Addison-Wesley 2001.

Copyright © George Coulouris, Jean Dollimore, Tim Kindberg 2001 email: authors@cdk2.netThis material is made available for private study and for direct use by individual teachers.It may not be included in any product or employed in any service without the written permission of the authors.

Viewing: These slides must be viewed in slide show mode.

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

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

*

3

Principal (user) Principal (server)

Objetos and “principals”

Access rights

Network

invocation

resultClient

Server

Object

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

Figure 2.13

*

4

O Inimigo

Communication channel

Process p Process q

The enemym’

Copy of m

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

Figure 2.14

*

5

Canais seguros

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

Propriedade de segredos:

Chaves de criptografia privativas convencionais

Par de chaves pública/privativa

Figure 2.15

*

Principal A

Secure channelProcess p Process q

Principal BThe enemyCryptography

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

*

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).

*

9

Alice e Bob compartilham uma mesma chave secreta KAB.

1. 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.

2. 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.

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?

*

10

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.

1. Alice envia uma mensagem (não encriptada) para Sara informando sua identidade e requisitando um ticket para acesso a Bob.

2. 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.

3. Alice usa KA para decriptar a resposta.

4. Alice envia para Bob uma requisição R para fazer acesso a um arquivo:

• {Ticket}KB, Alice, R.

5. 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.

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…

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.

*

11

Bob tem um par de chaves pública/privada <KBpub, KBpriv>

1. Alice obtém um certificado, assinado por uma autoridade confiável, informando a chave pública de Bob, KBpub

2. 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.)

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.

*

12

Alice deseja publicar um documento M de tal forma que qualquer um possa verificar que o documento foi originado por ela.

1. Alice computa um digest de tamanho fixo do documento: Digest(M).

2. 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.

3. Bob obtém o documento assinado, extrai M computa Digest(M).

4. 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.

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”.

*

13

1. Alice prepara duas versões M and M' de um contrato para Bob. M é favorável a Bob e M' não o é.

2. 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”.)

3. 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.

Ataque do aniversário

– 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.

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.

*

14

Certificados

1. Certificate type: Account number2. Name: Alice3. Account: 62626264. Certifying authority: Bob’s Bank5. Signature: {Digest(field 2 + field 3)} KBpriv

Figure 7.4 Alice’s bank account certificate

Figure 7.5 Public-key certificate for Bob's Bank

1. Certificate type: Public key

2. Name: Bob’s Bank

3. Public key: KBpub

4. Certifying authority: Fred – The Bankers Federation

5. Signature: {Digest(field 2 + field 3)} KFpriv

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.

*

15

Formato de Certificado X509

Subject Distinguished Name, Public Key

Issuer Distinguished Name, Signature

Period of validity Not Before Date, Not After Date

Administrative information Version, Serial Number

Extended Information

Figure 7.13

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 key2. Name: Bob’s Bank3. Public key: KBpub

4. Certifying authority: Fred – The Bankers Federation5. Signature: {Digest(field 2 + field 3)} KFpriv

1. Certificate type: Account number2. Name: Alice3. Account: 62626264. Certifying authority: Bob’s Bank5. Signature: {Digest(field 2 + field 3)} KBpriv

Figure 7.4 Alice’s bank account certificate

17

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.pdfdrwxr-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

*

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

*

19

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.

*

20

Algoritmos criptográficos

Simétricos (chave secreta)E(K, M) = {M}K D(K, E(K, M)) = M

Mesma chave para E e DM 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)) = MDepende 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.

*

Mensagem M, chave K, funções de criptografia publicadas E, D

21

Blocos de cifra, encadeamento, cifras de fluxo

n

n+3 n+2 n+1 XOR

E(K, M)

n-1n-2n-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 stream

buffer

keystream

Figure 7.7 Stream cipher

A maioria dos algoritmos opera sobre blocos de 64 bit.Fraqueza de cifras de único bloco: padrões repetidos podem ser detectados.

*

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.

*

23

TEA: Função de encriptação

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]); 5z += ((y << 4) + k[2]) ^ (y+sum) ^ ((y >> 5) + k[3]); 6

}text[0] = y; text[1] = z;

}

Linhas 5 & 6 realizam a confusão (XOR do texto deslocado)e difusão (deslocamento e troca de valor, entre y e z)

*

Figure 7.8 key 4 x 32 bitsplaintextand result 2 x 32

Exclusive OR

logical shift

24

TEA: Função de decriptação

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;

}

Figure 7.9

*

O inverso da função de encriptação

25

TEA in use

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

}}

Figure 7.10

*

26

Algoritmos de criptografia assimétricos

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.

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.

Todos dependem do uso de funções do tipo trap-doorUma 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.

*

Veja a seção 7.3.2 para uma descrição e exemplo do algoritmo RSA.

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)

*

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)

*

31

Assinaturas digitais com chaves públicas

Assinatura

hH(doc)

D(Kpub,{h}) h'

h = h'?authentic:forged

Figure 7.11

Verificação

M

H(M)

128 bits

h E(Kpri, h){h}Kpri

M

signed doc

M

{h}Kpri

*

32

MACs: Assinaturas de baixo custo com chave privada

Assinatura

Verificação

M

K

Figure 7.12M

K

h = h'?authentic:forged

h

M

signed doc

H(M+K) h

h'

H(M+K)

*

Assinante e verificador compartilham a chave privada K

MAC: Message Authentication Code

33

Desempenho de algoritmos de encriptação e digest seguro

Key size/hash size(bits)

Extrapolatedspeed

(kbytes/sec.)

PRB optimized speed

(kbytes/s)

TEA 128 700 -

DES 56 350 7746

Triple-DES 112 120 2842

IDEA 128 700 4469

RSA 512 7 -

RSA 2048 1 -

MD5 128 1740 62425

SHA 160 750 25162

PRB = Preneel, Rijmen and Bosselaers [Preneel 1998]

Algoritmo

Publickey

Secret key

Digest

os dados são para um proc. Pentium II a 330 MHZFigure 7.14

*

34

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.

*

35

Header Message Notes

1. A->S: A, B, NAA requisita que S providencie uma chave paracomunicaçã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 responseto the preceding one. A believes that S sent themessage 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 toencrypt another nonce NB.

5. A->B: A demonstrates to B that it was the sender of theprevious message by returning an agreedtransformation of NB.

{KAB, A}KB

{NB}KAB

{NB - 1}KAB

Ticket

O protocolo de autenticação com chave secreta de Needham–Schroeder

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).

Figure 7.15

*

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.

36

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

*

37

ServerClient

DoOperation

Authenticationdatabase

Loginsession setup

Ticket-granting

service T

Kerberos Key Distribution Center

Serversession setup

Authen-tication

service A

Servicefunction

Arquitetura de sistema de Kerberos

3. Request forserver ticket

4. Server ticket

Step B

5. Service request

Request encrypted with session key

Reply encrypted with session key

Step C

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

ProtocoloNeedham - Schroeder

5. A->B: {NB - 1}KAB

Step B once per server session

Step C once per server transaction

*

Figure 7.16

Step A once per login session

1. Request forTGS ticket

2. TGSticket

Step A

TGS: Ticket-granting service

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

*

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

40

Pilha de protocolos SSL

SSLHandshake

protocol

SSL ChangeCipher Spec

SSL AlertProtocol

Transport layer (usually TCP)

Network layer (usually IP)

SSL Record Protocol

HTTP Telnet

SSL protocols: Other protocols:

Figure 7.17

*

negotiates cipher suite, exchanges certificates and key masters

changes thesecure channel to a new spec

implements the secure channel

41

ClientA

ServerB

ClientHello

ServerHello

SSL handshake protocol

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

Certificate

Certificate Request

ServerHelloDone

Opcional: envia o certificado do servidor e requisita o certificado do cliente

Certificate

Certificate VerifyEnvia resposta com o certificado do clientese requisitado

Change Cipher Spec

Finished

Change Cipher Spec

Finished

Muda a cipher suite e finaliza o handshake

*

Figure 7.18

Inclui a troca da chave mestra.A chave mestra é usada por A e Bpara gerar:2 chaves de sessão 2 chaves MAC

KAB MAB

KBA MBA

Componente Descrição Exemplo

Método de trocade chaves

o método a ser usado paratroca da chave de sessão

RSA com certificadosde chave pública

Cifra para transf.de dados

a cifra de bloco ou stream a serusada para dados

IDEA

Fução para digestde mensagens

para criação de códigos deautenticação de msgs. (MACs)

SHA

Cipher suite

42

SSL: opções de configuração do handshake

Figure 7.19

*

Componente Descrição Exemplo

Método de trocade chaves

o método a ser usado paratroca da chave de sessão

RSA com certificadosde chave pública

Cifra para transf.de dados

a cifra de bloco ou stream a serusada para dados

IDEA

Fução para digestde mensagens

para criação de códigos deautenticação de msgs. (MACs)

SHA

43

SSL record protocol

Application data abcdefghi

abc def ghiRecord protocol units

Fragment/combine

Compressed units

Compress

MAC

Hash

Encrypted

Encrypt

Figure 7.20

TCP packet

Transmit

*

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.

*

45

[p. 260]

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