Teaching material
based on Distributed
Systems: Concepts
and Design, Edition 3,
Addison-Wesley 2001.
Sistemas Distribuídos
Segurança
Copyright © George
Coulouris, Jean Dollimore,
Tim Kindberg 2001
email: [email protected]
This 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.
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
 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
Objetos and “principals”
Figure 2.13
Access rights
Object
invocation
Client
Server
result
Principal (user)
Network
Principal (server)
 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
3
O Inimigo
Figure 2.14
Copy of m
The enemy
Process p
m’
m
Process q
Communication channel
 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
Canais seguros
Figure 2.15
PrincipalA
Processp
Cryptography
The enemy
Secure channel
Principal B
Processq
Propriedade de segredos:
 Propriedades
Ocultação de informações criptográficas baseia-se
 Cada processo
deve ter certeza
sobreconvencionais
a identidade dos demais
de criptografia
privativas
em:Chaves
 Dados são privativos e protegidos contra adulteração
Par
de chaves
pública/privativa
Confusão
e difusã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
5
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
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).
7
Cenário 1: Comunicação sigilosa com uma chave
secreta compartilhada
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.
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?
9
*
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.
1.
Alice envia uma mensagem (não encriptada) para Sara informando sua
identidade e requisitando um ticket para acesso a Bob. 
2. ticket
Sara envia
resposta
para Alice,contendo:
{{Ticket}KBa, Kidentidade
é
AB}KA. A resposta
Um
é umuma
item
criptografado
do principal
em:
A e consiste
para encriptada
o qual elecom
foiKemitido,
e uma
chave compartilhada para a sessão
• um ticket (a ser enviado para Bob junto com cada requisição de acesso a
de comunicação.
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.
Esta
é uma
simplificada
do, protocolo
Needham
and decriptá-lo
Schroeder (e
5. O
ticketversão
é, na verdade,
{KAB
Alice}KB. de
Bob
usa KB para
e checar
Kerberos).
que o nome de Alice está correto; então usa K para encriptar as respostas
AB

Questões
de temporização e replay – tratadas em N-S e Kerberos.
para Alice.

Não apropriada para e-commerce porque10o serviço de autenticação não escala…
*
Cenário 3:
Comunicação autenticada com chaves públicas
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.)
 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
*
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.
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.
A função de digest deve ser segura contra o chamado “ataque do aniversário”.
12
*
Ataque do aniversário
1. Alice prepara
duas versões M and M' de um contrato para Bob. M é favorável
Paradoxo
do aniversário:
a Bob eestatístico:
M' não o é. se houver 23 pessoas em uma sala, há grande
Resultado
2. Alice cria várias versões sutilmente diferentes de ambos M and M', as quais
chance
de que 2 delas terão o mesmo dia de aniversário.
são visivelmente indistinguíveis uma da outra, através de métodos tais como a
3.
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
*
Certificados
Certificado:
umabank
afirmação
assinada por uma autoridade apropriada.
Figure 7.4 Alice’s
account certificate
Certificados requerem:
1. Certificate type:
Account number
• Um formato padrão Alice
pré-acordado entre as partes
2. Name:
• Acordo sobre a formação
de cadeias de confiança.
3. Account:
6262626
• Datas de
validade,
de
forma
que certificados possam ser revogados.
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. Public key:
KBpub
4. Certifying authority:
Fred – The Bankers Federation
{Digest(field 2 + field 3)} KFpriv
5. Signature:
14
*
Formato de Certificado X509
Figure 7.13
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
15
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
Figure 7.4 Alice’s bank account certificate
sua conta
bancária Account number
1. Certificate type:
Name:
Alice certificado de chave pública a cada
– Ela2.precisaria
adicionar seu
3. Account:
6262626
transação
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.
2.
3.
4.
5.
Certificate type:
Name:
Public key:
Certifying authority:
Signature:
Public key
Bob’s Bank
KBpub
Fred – The Bankers Federation
{Digest(field162 + field 3)} KFpriv
*
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 
drwxr-xr-x
gfc22
264de
Oct
30 16:57
User
Data
 Para
tiposstaff
de objetos e comunidades
usuários
maisAcrobat
complexos,
ACLs
-rw-r--r-- podem
gfc22
unknown
se tornar
muito complexas0 Nov 1 09:34 Eudora Folder
-rw-r--r-gfc22 staff
163945 Oct 24 00:16 Preview of xx.pdf
–
Capacidades
(capabilities)
associadas
“principals”
drwxr-xr-x gfc22 staff
264 aOct
31 13:09 iTunes
-rw-r--r-staff
325 Oct 22 22:59 list of
 Comogfc22
uma chave
broken apps.rtf
 Formato: <resource id, permitted operations, authentication code>
 Não podem ser passíveis de serem forjadas
 Problemas: espionagem, dificuldade de cancelamento
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
*
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
*
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.
20
*
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.
Figure 7.6 Cipher block chaining (CBC)
n+3
plaintext blocks
n+2
n+1
XOR
E(K, M)
n-3
ciphertext blocks
n-2
n-1
n
Figure 7.7 Stream cipher
keystream
number
generator
n+3
n+2
n+1
E(K, M)
buffer
XOR
ciphertext
stream
plaintext
stream
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
*
TEA: Função de encriptação
Figure 7.8
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]);
z += ((y << 4) + k[2]) ^ (y+sum) ^ ((y >> 5) + k[3]);
}
text[0] = y; text[1] = z;
}
Exclusive OR
key 4 x 32 bits
plaintext
and result 2 x 32
5
6
logical shift
 Linhas 5 & 6 realizam a confusão (XOR do texto deslocado)
e difusão (deslocamento e troca de valor, entre y e z)
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
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
*
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.
Uma trapdoor provê uma
Velocidade
entrepara
1 e uma
7 kbytes/s. (Processador PII 350 MHz)
entrada secreta
sala. Uma vez dentro, a
Curva elíptica:
Um método recentemente desenvolvido, usa chaves mais
saída é óbvia, mas se
curtas
e mais
rápidas.
estiver
de fora,
necessitase saber o segredo para
Algoritmos
entrar.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
*
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
*
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 último30 bloco na cadeia é H(M)
*
Assinaturas digitais com chaves públicas
Figure 7.11
M
signed doc
H(M)
Assinatura
{h}Kpri
h E(Kpri, h)
M
128 bits
{h}Kpri
Verificação
D(Kpub,{h})
h'
M
h = h'?authentic:forged
H(doc)
31
h
*
MACs: Assinaturas de baixo custo com chave privada
Figure 7.12
M
MAC: Message Authentication Code
signed doc
h
H(M+K)
Assinatura
M
K
Assinante e
verificador
compartilham a chave
privada K
M
h
H(M+K)
Verificação
h = h'?authentic:forged
h'
K
32
*
Desempenho de algoritmos de encriptação e digest seguro
Figure 7.14
Algoritmo
os dados são para um proc. Pentium II a 330 MHZ
Key size/hash size
(bits)
Extrapolated PRB optimized
speed
speed
(kbytes/sec.)
(kbytes/s)
TEA
128
700
-
DES
56
350
7746
Triple-DES
112
120
2842
IDEA
128
700
4469
Public
key
RSA
512
7
-
RSA
2048
1
-
Digest
MD5
128
1740
62425
SHA
160
750
25162
Secret
key
PRB = Preneel, Rijmen and Bosselaers [Preneel 1998]
33
*
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
*
O protocolo de autenticação com chave secreta de Needham–
Schroeder
Ponto7.15
fraco: A msg
Figure
3 pode não ser “fresca” – e KAB pode ter sido
comprometida enquanto armazenada no computador de A. Kerberos (a
Headercontempla
Message isto adicionando
Notes
seguir)
um timestamp, ou nonce, à msg 3.
A requisita que S providencie uma chave para
comunicação com B.
S returns a message encrypted in A’s secret key,
2. S->A:
{NA , B, KAB,
NA é um nonce. Nonces são
inteiros
que generated
são adicionados
containing
a newly
key KAB andaa
{K , A}KB}KA ‘ticket’ encrypted in B’s secret key. The nonce N
mensagens
paraABdemonstrar
a originalidade da transação. Eles Asão
Ticket
demonstrates that the message was sent in response
geradas pelo processo remetente
sempre
necessário,
por
to the preceding
one.que
A believes
that S sent
the
message
becauseou
only
S knows
A’s secretdo
key.
exemplo incrementando um
contador
lendo
o relógio
1. A->S:
A, B, NA
{KAB, A}
sistema
presição
3.
A->B: (com
KB
4. B->A:
{NB}KAB
5. A->B:
{NB - 1}KAB
A sends the ‘ticket’ to B.
de milissegundos).
B decrypts the ticket and uses the new key KAB to
encrypt another nonce NB.
A demonstrates to B that it was the sender of the
previous message by returning an agreed
transformation of NB.
35
*
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
*
Arquitetura de sistema de Kerberos
Figure 7.16
TGS: Ticketgranting
service
Protocolo
Needham - Schroeder
Kerberos Key Distribution Center
Step A
1. Request for
TGS ticket
Authentication
database
Authentication
service A
1. A->S: A, B, NA
2. S->A: {NA , B, KAB,
{KAB, A}KB}KA
Ticketgranting
service T
3. A->B: {KAB, A}KB
2. TGS
ticket
Login
session setup
Server
session setup
DoOperation
Step B
3. Request for
server ticket
4. Server ticket
4. B->A: {NB}KAB
5. A->B: {NB - 1}KAB
Step C
5. Service
request
Service
function
Request encrypted with session key
Step A once per login session
Reply encrypted with session key
Step B once per server session
Server
Client
37
Step C once per server transaction
*
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
*
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
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
implements the
secure channel
SSL Alert
Protocol
HTTP
Telnet
SSL Record Protocol
Transport layer (usually TCP)
Network layer (usually IP)
SSL protocols:
Other protocols:
40
*
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
ClientHello
ServerHello
Cipher suite
Componente
Certificate
Opcional: envia o certificado do servidor
e requisita o certificado do cliente
Certificate Request
ServerHelloDone
Descrição
Exemplo
Método deClient
troca o método
a ser usado
para
Certificate
Server
de chaves A
troca
da chave
B
Certificate
Verify de sessão
RSA com certificados
Envia resposta com o certificado do cliente
de chave pública
se requisitado
Cifra para transf. a cifra de bloco ou stream a ser
Change
Spec
de dados
usada Cipher
para dados
IDEA
Muda a cipher suite e finaliza
de o handshake
SHA
Fução para digest para criação de códigos
Inclui a troca da chave mestra.
de mensagens
autenticação
de msgs. (MACs)
Change
Cipher Spec
Finished
A chave mestra é usada por A e B
para gerar:
2 chaves de sessão 2 chaves MAC
KAB
MAB
KBA
MBA
Finished
41
*
SSL: opções de configuração do handshake
Figure 7.19
Componente
Descrição
Exemplo
Método de troca o método a ser usado para
de chaves
troca da chave de sessão
RSA com certificados
de chave pública
Cifra para transf. a cifra de bloco ou stream a ser
de dados
usada para dados
IDEA
Fução para digest para criação de códigos de
de mensagens
autenticação de msgs. (MACs)
SHA
42
*
SSL record protocol
Figure 7.20
abcdefghi
Application data
Fragment/combine
abc
Record protocol units
def
ghi
Compress
Compressed units
Hash
MAC
Encrypt
Encrypted
Transmit
TCP packet
43
*
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
*
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