Upload
yamal
View
28
Download
0
Embed Size (px)
DESCRIPTION
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. Objetivos. O modelo de seguran ça Tipos de ameaças - PowerPoint PPT Presentation
Citation preview
Copyright © George Coulouris, Jean Dollimore, Tim Kindberg 2001 email: [email protected] 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: [email protected] 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