Protocolos de distribuição de chaves criptográficas assimétricas: Denning - Sacco, DASS, Wu Lama

Protocolos assimétricos, ou protocolos baseados em sistemas de criptografia com chaves públicas, podem enfraquecer os requisitos para o estágio preliminar dos protocolos. Em vez de uma chave secreta compartilhada que duas partes devem ter (cada uma das partes e um centro confiável), nos protocolos considerados abaixo, as partes devem primeiro trocar chaves públicas (entre si ou com um centro confiável). Essa troca preliminar pode ocorrer através de um canal de comunicação aberto, sob a suposição de que o criptoanalista não pode influenciar o conteúdo do canal de comunicação nesse estágio.

Protocolo Denning - Sacco

O protocolo foi proposto por Dorothy Denning e Giovanni Sacco em 1981 (inglês Dorothy E. Denning, Giovanni Maria Sacco ). Nesse protocolo, o iniciador (Alice) recorre ao centro confiável (Trent) para obter certificados de ambos os participantes ao mesmo tempo. O mesmo participante também é responsável pela formação de uma nova chave de sessão. $$$K$ .

1. $$$Alice \ à \ esquerda \ {A, B \ direita \} \ para Trent$
2. $$$Trent \ à \ esquerda \ {S_T (A, K_A, T_T), S_T (B, K_B, T_T) \ right \} \ para Alice$
3. Alice gera uma nova chave de sessão $$$K$
   $$$\ begin {array} {lll} Alice \ to \ {& E_B (S_A (K, T_A)), & \\ & S_T (A, K_A, T_T), & \\ & S_T (B, K_B, T_T) & \} \ para Bob \ end {array}$
4. Bob verifica a assinatura do centro de confiança no certificado $$$S_T (A, K_A, T_T)$ descriptografa a chave da sessão $$$K$ e verifica a assinatura de Alice.

Mensagem em falta $$$E_B (S_A (K, T_A))$ qualquer identificador torna o protocolo vulnerável a um ataque com uma chave de sessão conhecida e permite que o segundo lado (Bob) represente o iniciador (Alice) em uma sessão com um terceiro (Clara).

1. Alice e Bob tiveram uma sessão de protocolo, gerando uma nova chave de sessão $$$K$ .
2. $$$Bob \ à \ esquerda \ {B, C \ direita \} \ em Trent$
3. $$$Trent \ à \ esquerda \ {S_T (B, K_B, T_T), S_T (C, K_C, T_T) \ right \} \ para Bob$
4. Bob reproduz mensagens $$$S_A (K, T_A)$ e $$$S_T (A, K_A, T_T)$ de Alice em uma sessão com Clara:
   $$$\ begin {array} {lll} Bob ~ (Alice) \ to \ {& E_C (S_A (K, T_A)), & \\ & S_T (A, K_A, T_T) e \\ & S_T (C, K_C, T_T) e \} \ para Clara \ end {array}$
5. Clara verifica com êxito a assinatura do centro confiável no certificado $$$S_T (A, K_A, T_T)$ descriptografa a chave da sessão $$$K$ e verifica a assinatura de Alice.

Como resultado, Clara tem certeza de que recebeu uma nova chave de sessão de Alice. $$$K$ .

Protocolo DASS

O protocolo DASS era parte integrante do Serviço de Segurança de Autenticação Distribuída (DASS), desenvolvido pela DEC e descrito na RFC 1507 em setembro de 1993.

No protocolo DASS, por analogia com os protocolos Wide-Mouth Frog e Denning - Sacco, o iniciador (Alice) gera uma nova chave de sessão e, para cada sessão de protocolo, um novo par de chaves públicas e privadas do remetente. O Trusted Center (Trent) é usado como um repositório de certificados de chave pública dos participantes. Mas, diferentemente de Denning-Sacco, os dois participantes recorrem ao centro confiável.

1. $$$Alice \ à \ esquerda \ {B \ right \} \ em Trent$
2. $$$Trent \ à \ esquerda \ {S_T \ left (B, K_B \ right) \ right \} \ para Alice$
3. $$$Alice \ à \ esquerda \ {E_K \ esquerda (T_A \ direita), S_A \ esquerda (L, A, K_P \ direita), S_ {K_P} \ esquerda (E_B \ esquerda (K \ direita) \ direita) \ direita \} \ para Bob$
4. $$$Bob \ à \ esquerda \ {A \ right \} \ em Trent$
5. $$$Trent \ à \ esquerda \ {S_T \ left (A, K_A \ right) \ right \} \ para Bob$
6. $$$Bob \ à \ esquerda \ {E_K \ left \ {T_B \ right \} \ right \} \ para Alice$

Usando certificados de chave pública $$$\ left \ {S_T \ left (B, K_B \ right) \ right \}$ e $$$\ left \ {S_T \ left (A, K_A \ right) \ right \}$ que Trent envia e, após confirmação da propriedade das chaves correspondentes, os participantes podem se autenticar. Descriptografando com êxito os registros de data e hora das mensagens $$$E_K \ esquerda (T_A \ direita)$ e $$$E_K \ left \ {T_B \ right \}$ fornece prova de propriedade da chave da sessão.

O protocolo usa uma vida útil ( $$$L$ ) chave da sessão $$$K_P$ mas o registro de data e hora não está incluído na mensagem. Como resultado, o protocolo permanece vulnerável a um ataque com uma chave de sessão conhecida. Suponha que Mellory tenha conseguido gravar uma sessão de comunicação completamente passada entre Alice e Bob e, em seguida, tenha conseguido acessar a chave da sessão $$$K$ . Isso permite que Mellory se autentique como Alice na frente de Bob.

1. $$$Mellory ~ (Alice) \ à \ esquerda \ {E_K \ esquerda (T_M \ direita), S_A \ esquerda (L, A, K_P \ direita), S_ {K_P} \ esquerda (E_B \ esquerda (K \ direita) \ right) \ right \} \ para Bob$
2. $$$Bob \ à \ esquerda \ {A \ right \} \ em Trent$
3. $$$Trent \ à \ esquerda \ {S_T \ left (A, K_A \ right) \ right \} \ para Bob$
4. $$$Bob \ à \ esquerda \ {E_K \ left \ {T_B \ right \} \ right \} \ para Alice$

Na primeira passagem, Mellory altera apenas a primeira mensagem que contém um carimbo de data / hora. $$$E_K \ esquerda (T_M \ direita)$ . Mellory copia o restante da sessão gravada. Se Bob não gravar as teclas usadas, ele não notará a falsificação. A correção mais simples para esta vulnerabilidade é incluir um carimbo de data / hora na mensagem. $$$S_A \ esquerda (T_A, L, A, K_P \ direita)$ .

Como a chave da sessão está no protocolo $$$K$ criptografado pela chave "master" Bob $$$K_B$ , um comprometimento deste último levará a um comprometimento de todas as chaves de sessão usadas anteriormente. Ou seja, o protocolo não fornece sigilo direto perfeito (objetivo G9).

Trent e Bob não estão envolvidos na formação de novas chaves de sessão. Portanto, Alice pode forçar Bob a usar a chave de sessão antiga, como nos protocolos Wide-Mouth Frog e Yahalom.

Protocolo Wu Lama

O protocolo Wu-Lama, proposto em 1992 ( Thomas YC Woo, Simon S. Lam ), adiciona números aleatórios de participantes às mensagens, o que protege o protocolo, inclusive contra ataques repetidos, e também fornece confirmação da propriedade da chave. Também é o único protocolo considerado nesta seção em que uma nova chave é gerada por uma parte confiável (Trent).

1. $$$Alice \ à \ esquerda \ {A, B \ direita \} \ para Trent$
2. $$$Trent \ à \ esquerda \ {S_T (K_B) \ right \} \ para Alice$
3. $$$Alice \ à \ esquerda \ {E_B (A, R_A) \ direita \} \ para Bob$
4. $$$Bob \ à \ esquerda \ {A, B, E_T (R_A) \ right \} \ em Trent$
5. $$$Trent \ à \ esquerda \ {S_T (K_A), E_B (S_T (R_A, K, A, B)) \ right \} \ para Bob$
6. $$$Bob \ à \ esquerda \ {E_A (S_T (R_A, K, A, B), R_B) \ direita \} \ para Alice$
7. $$$Alice \ à \ esquerda \ {E_K (R_B) \ direita \} \ para Bob$

Como no certificado da chave da sessão $$$S_T (R_A, K, A, B)$ O número aleatório de Alice está presente $$$R_A$ , o invasor não poderá usar o certificado antigo em uma nova sessão em nome de Bob. Portanto, a sexta passagem do protocolo permite que Alice verifique se Bob conhece a nova chave de sessão $$$K$ e, portanto, possui sua chave "mestre" $$$K_B$ (já que essa é a única maneira de obter o certificado da mensagem $$$E_B (S_T (R_A, K, A, B)))$ )

Mensagem $$$E_K (R_B)$ de Alice a Bob na sétima passagem nos permite garantir ao mesmo tempo que Alice conhece sua chave "mestre" $$$K_A$ (como foi capaz de descriptografar $$$E_A (\ pontos, R_B)$ ) e uma nova chave de sessão $$$K$ porque ele foi capaz de criptografar corretamente $$$R_B$ essa chave.