Este texto será um dos capítulos reescritos do manual sobre proteção de informações do Departamento de Engenharia de Rádio e Sistemas de Controle, bem como, a partir deste código de treinamento, o Departamento de Proteção de Informações do MIPT (GU). O tutorial completo está disponível no github (veja também versões preliminares ). Pretendo fazer upload de novas peças "grandes" no hub, primeiro, para coletar comentários e observações úteis e, segundo, para fornecer à comunidade mais material de visão geral sobre tópicos úteis e interessantes.Conceitos básicos
Para o cumprimento bem-sucedido de quaisquer objetivos de proteção de informações, é necessário participar do processo de proteção de várias entidades que, de acordo com certas regras, executam ações técnicas ou organizacionais, operações criptográficas, interagem entre si, por exemplo, transmitindo mensagens ou verificando as identidades umas das outras.
A formalização de tais ações é feita através de uma descrição do protocolo.
Protocolo - uma descrição de um algoritmo distribuído no processo em que dois ou mais participantes executam sequencialmente determinadas ações e trocam mensagens (a seguir, nesta seção, as definições são fornecidas com base em
[Cheremushkin: 2009] ).
Por um participante (sujeito, parte) do protocolo entende-se não apenas pessoas, mas também aplicativos, grupos de pessoas ou organizações inteiras. Formalmente, os participantes são considerados apenas aqueles que desempenham um papel ativo dentro do protocolo. Embora ao criar e descrever os protocolos, você também não deve esquecer os lados passivos. Por exemplo, um criptoanalista passivo não é formalmente um participante dos protocolos, mas muitos protocolos são desenvolvidos levando em consideração a proteção contra esses "não participantes".
O protocolo consiste em
ciclos (
rodada em inglês) ou
passes (
passe em inglês). Um ciclo é um intervalo de tempo de atividade de apenas um participante. Com exceção do primeiro ciclo do protocolo, geralmente começa com o recebimento de uma mensagem e termina com o envio.
Um ciclo (ou passagem) consiste em
etapas (ações,
etapa em inglês
, ação ) - ações concluídas específicas executadas por um participante do protocolo. Por exemplo:
- geração de um novo valor (aleatório);
- cálculo de valores de função;
- verificação de certificados, chaves, assinaturas, etc;
- recebendo e enviando mensagens.
Uma implementação passada ou apenas descrita teoricamente do protocolo para participantes específicos é chamada de
sessão . Cada participante da sessão executa uma ou mais
funções . Em outra sessão de protocolo, os participantes podem trocar de função e executar funções completamente diferentes.
Podemos dizer que o protocolo descreve prescritivamente as regras para o comportamento de cada função no protocolo. Uma sessão é uma descrição descritiva (possivelmente teoricamente) de uma implementação de protocolo que ocorreu no passado.
Um exemplo de descrição de protocolo.
- Um participante com a função Remetente deve enviar uma mensagem a um participante com a função Destinatário.
- Um participante com a função Destinatário deve receber uma mensagem de um participante com a função Remetente.
Um exemplo de uma descrição da sessão do protocolo.
- Em 1º de abril, às 13:00, Alice enviou uma mensagem a Bob.
- Em 1º de abril, às 13:05, Bob recebeu uma mensagem de Alice.
Um protocolo protegido ou
um protocolo de segurança será chamado de protocolo que fornece pelo menos uma função de proteção
[ISO: 7498-2: 1989] :
- autenticação de partes e fonte de dados,
- controle de acesso
- confidencialidade
- integridade
- incapacidade de recusar o fato de enviar ou receber.
Se um protocolo seguro for projetado para executar as funções de segurança de um sistema criptográfico, ou se algoritmos criptográficos forem utilizados durante sua execução, esse protocolo será chamado de
criptográfico .
Gravação de protocolo
Para registrar protocolos relacionados à implementação de funções de proteção de informações, não use expressões como "participante com a função de" Remetente ", mas substitua-as por notações curtas como" remetente "ou use
exemplos geralmente aceitos: Alice, Bob, Clara, Eva etc. e) Os seguintes acordos são usados.
- Alice, Bob (do inglês A, B ) - remetente e destinatário.
- Karl, Clara, Charlie (do inglês C ) - um terceiro igual.
- Eve (do bisbilhoteiro inglês) é um criptoanalista passivo.
- Mellory (do inglês malicioso ) é um criptoanalista ativo.
- Trent (da confiança inglesa) é uma parte confiável.
Não existe um formato de gravação de protocolo universalmente aceito; eles podem diferir tanto na aparência quanto na integridade da descrição. Por exemplo, aqui está o formato de gravação de protocolo Diffie-Hellman mais abrangente.
- Fase preliminar.
- Todas as partes escolheram comum g e p .
- Passe 1.
- Alice gera aleatoriamente a .
- Alice calcula A = g a b m o d p .
- Alice envia Bob Um .
- Passe 2.
- Bob tira de Alice Um .
- Bob gera aleatoriamente b .
- Bob está calculando B = g b b m o d p .
- Bob envia Alice B .
- Bob está calculando s = A b b m o d p .
- Passe 2.
- Alice tira Bob B .
- Alice calcula s = B a b m o d p .
- O resultado do protocolo.
- As partes calcularam uma chave de sessão compartilhada s .
Agora compare com um pequeno registro do mesmo protocolo.
- A p a r a B : A = g a b m o d p
- B paraA:B=gb bmodp
Em um breve registro, inicialização e pré-requisitos, cálculos de dados não transmitidos (neste exemplo, uma chave de sessão comum são omitidos)
s ), bem como quaisquer verificações.
Neste tutorial, manteremos um formato de gravação intermediário.
- Alice gera a .
Alice \ à \ esquerda \ {A = g ^ a \ bmod p \ right \} \ para BobAlice \ à \ esquerda \ {A = g ^ a \ bmod p \ right \} \ para Bob . - Bob gera b .
Bob está calculando s=Ab bmodp .
Bob \ à \ esquerda \ {B = g ^ b \ mod p \ direita \} \ para AliceBob \ à \ esquerda \ {B = g ^ b \ mod p \ direita \} \ para Alice . - Alice calcula s=Ba bmodp .
Também concordamos com as regras para registrar o caso quando um criptoanalista ativo (Mellory) se apresenta como um usuário legal.
\ begin {array} {llllc} (1) & A & \ para M \ left (B \ right) &: & A = g ^ a \ bmod p, \\ (2) & M \ left (A \ right ) & \ para B &: & A ^ * = g ^ {a ^ *} \ bmod p, \\ (3) & B & \ para M \ esquerda (A \ direita) &: & B = g ^ b \ bmod p, \\ (4) & M \ esquerda (B \ direita) & \ para A &: & B ^ * = g ^ {b ^ *} \ bmod p. \\ \ end {array}
\ begin {array} {llllc} (1) & A & \ para M \ left (B \ right) &: & A = g ^ a \ bmod p, \\ (2) & M \ left (A \ right ) & \ para B &: & A ^ * = g ^ {a ^ *} \ bmod p, \\ (3) & B & \ para M \ esquerda (A \ direita) &: & B = g ^ b \ bmod p, \\ (4) & M \ esquerda (B \ direita) & \ para A &: & B ^ * = g ^ {b ^ *} \ bmod p. \\ \ end {array}
Ou atribuindo uma coluna separada para cada participante.
\ begin {array} {lllclllc} (1) & A & \ to & M \ left (B \ right) & {} & {} &:} &: & A = g ^ a \ bmod p, \\ (2) e {} & {} & M \ esquerda (A \ direita) & \ para & B &: & A ^ * = g ^ {a ^ *} \ bmod p, \\ (3) & {} & {} & M \ left (A \ right) & \ gets & B &: & B = g ^ b \ bmod p, \\ (4) & A & \ gets & M \ left (B \ right) & {} & {} & : & B ^ * = g ^ {b ^ *} \ bmod p. \\ \ end {array}
\ begin {array} {lllclllc} (1) & A & \ to & M \ left (B \ right) & {} & {} &:} &: & A = g ^ a \ bmod p, \\ (2) e {} & {} & M \ esquerda (A \ direita) & \ para & B &: & A ^ * = g ^ {a ^ *} \ bmod p, \\ (3) & {} & {} & M \ left (A \ right) & \ gets & B &: & B = g ^ b \ bmod p, \\ (4) & A & \ gets & M \ left (B \ right) & {} & {} & : & B ^ * = g ^ {b ^ *} \ bmod p. \\ \ end {array}
Para reduzir a descrição e simplificar a comparação de diferentes protocolos, use as seguintes convenções para a designação dos dados transmitidos.
- A , B , C etc. - identificadores dos participantes do protocolo: Alice, Bob e Clara, respectivamente.
- M (da mensagem em inglês) - uma mensagem em sua forma original, em texto sem formatação, independentemente da codificação. Ou seja, sob M o texto de origem pode ser entendido como texto ou, por exemplo, som, ou já um determinado número ou uma matriz de bits que corresponde exclusivamente a esta mensagem.
- K (da tecla em inglês) - alguma tecla. Sem mais elaboração, geralmente indica uma chave de sessão secreta.
- KA - uma chave secreta compartilhada entre Alice e Trent (para sistemas de criptografia simétricos).
- KA - Chave pública de Alice (para sistemas de criptografia assimétricos).
- EK esquerda( pontos direita) (do inglês encrypt ) - dados criptografados na chave K .
- EA esquerda( dots right) , EB esquerda( pontos direita) - dados criptografados nas chaves de Alice e Bob, respectivamente.
- L (desde a vida útil em inglês) - a vida útil, por exemplo, de um certificado.
- SK esquerda( dots right) (do sinal em inglês) - dados e a assinatura digital correspondente na chave pública K .
- TA , TB (do registro de data e hora em inglês) - registros de data e hora dos respectivos participantes.
- RA , RB (do inglês aleatório ) - números aleatórios selecionados pelos respectivos participantes.
Exemplos de uso de notação.
- EKB(M) ou apenas EB(M) - mensagem M criptografado com a chave de Bob KB .
- SA(RA) - número aleatório RA gerado por Alice e assinado por ela. Ou seja, a mensagem conterá um número aleatório (em texto sem formatação) e uma assinatura eletrônica desse número.
- ST(A,KA,TT,L) - O identificador e a chave de Alice, carimbo de data e hora e duração desse registro, todos assinados juntos pela chave pública do centro confiável (Trent). Na verdade, esse é o certificado de chave de Alice.
Propriedades de segurança do protocolo
Um sistema seguro e, consequentemente, um protocolo seguro podem executar várias funções de segurança. Muitas dessas funções ou objetivos (objetivos em inglês) podem ser formuladas como resistência a uma classe específica de ataques. O mais completo e relevante é considerado a listagem e interpretação desses objetivos no documento do projeto AVISPA (
Validação automatizada em inglês
de protocolos e aplicativos de segurança da Internet )
[AVISPA] , resumindo as descrições de vários documentos da IETF (
Internet Engineering Task Force ). Esses objetivos são considerados
formalizados - ou seja, de modo que, para protocolos individuais, haja uma oportunidade de provar ou refutar formalmente a consecução desses objetivos.
- Autenticação (unidirecional).
Inglês Autenticação (unicast) .
- (G1) Autenticação de assunto.
Inglês Autenticação de entidade (Autenticação de entidade ponto a ponto) .
Uma garantia para um lado do protocolo através do envio de evidências e / ou credenciais da segunda parte participante do protocolo e de que a segunda parte realmente participou da sessão atual do protocolo. Geralmente, isso é feito através da apresentação de dados que podem ser gerados apenas pelo outro lado. A autenticação do sujeito implica que os dados recebidos possam ser rastreados de maneira inequívoca até o sujeito do protocolo, o que implica autenticação da fonte de dados. - (G2) Autenticação de mensagem.
Inglês Autenticação de mensagem (autenticação de origem de dados) .
Garantia de que a mensagem recebida ou parte dos dados foi criada por um determinado assunto em algum momento (geralmente não especificado) no passado e que esses dados não foram danificados ou violados. Mas sem fornecer exclusividade ou pontualidade. A autenticação de mensagens implica sua integridade. - (G3) Repita a proteção.
Inglês Proteção de reprodução
Proteção contra a situação em que alguma parte gravará alguma mensagem e a reproduzirá mais tarde (possivelmente em outra sessão de protocolo), o que levará à interpretação incorreta desse lado como autenticado.
- Autenticação ao enviar para muitos endereços ou ao conectar-se a um serviço de assinatura / notificação.
Inglês Autenticação em multicast ou por meio de um serviço de inscrição / notificação .
- (G4) Autenticação explícita do destinatário.
Inglês Autenticação implícita de destino .
O protocolo deve garantir que a mensagem enviada seja legível apenas para destinatários legítimos. Ou seja, apenas participantes legais autorizados terão acesso a informações relevantes, uma mensagem multicast ou uma sessão de comunicação em grupo. Inclui grupos de distribuição com associações muito dinâmicas. - (G5) Autenticação de origem.
Inglês Autenticação de origem .
Os destinatários legais poderão autenticar a fonte e o conteúdo das informações ou da comunicação do grupo. Inclui casos em que os membros do grupo não confiam um no outro.
- (G6) Autorização (por uma terceira parte confiável).
Inglês Autorização (por um terceiro confiável) .
A garantia da capacidade de autorizar (em termos do protocolo) de um sujeito a acessar o recurso de outro usando uma terceira parte confiável. Isso implica que o proprietário do recurso pode não ter suas próprias listas de acesso (Eng. Access Control List, ACL ) e depende daquelas do lado confiável. - Geração de chaves conjuntas.
Inglês Propriedades do Contrato Chave .
- (G7) Autenticação de chave.
Inglês Autenticação de chave .
Uma garantia para uma das entidades de que apenas usuários legais podem acessar uma chave secreta específica. - (G8) Comprovante de propriedade da chave.
Inglês Confirmação de chave (Prova de posse de chave) .
Uma garantia para uma das entidades de que a outra entidade realmente possui uma chave secreta específica (ou as informações necessárias para obter essa chave). - (G9) Perfeito sigilo direto.
Inglês Perfect Forward Secrecy (PFS) .
Garantir que o comprometimento futuro das chaves mestras não comprometa as chaves de sessão das sessões de protocolo anteriores. - (G10) Geração de novas chaves.
Inglês Derivação de Chave Fresca .
Garantido para criar novas chaves de sessão para cada sessão de protocolo. - (G11) Uma oportunidade segura de concordar com as configurações de segurança.
Inglês Negociação de recursos seguros (resistência a ataques de rebaixamento e negociação) .
A garantia não é apenas que as partes legais tenham a oportunidade de concordar com os parâmetros de segurança, mas também que o lado ilegal não interveio no protocolo e não levou à seleção de seus parâmetros de segurança preferidos (possivelmente os mais fracos).
- (G12) Confidencialidade.
Inglês Confidencialidade (Sigilo) .
A garantia de que um elemento de dados específico (parte da mensagem sendo transmitida) permanece desconhecido do invasor. Para esse fim, não são considerados o sigilo da chave da sessão, a autenticação da chave ou a confiabilidade das chaves mestras de longo prazo. - Anonimato.
Inglês Anonimato .
- (G13) Proteção de identificadores contra escuta (não conectividade).
Inglês Proteção de identidade contra bisbilhoteiros .
A garantia de que o atacante (o bisbilhoteiro) não é capaz de conectar as mensagens do sujeito com sua identidade real. - (G14) Proteção de identificadores de outras partes.
Inglês Proteção de identidade contra pares .
Garantia de que o participante da correspondência não consiga conectar as mensagens do sujeito a uma pessoa real, mas apenas com um certo pseudônimo.
- (G15) Proteção limitada contra ataques de negação de serviço.
Inglês Resistência (limitada) à negação de serviço (DoS) .
Garantir que o protocolo siga certos princípios que reduzam a probabilidade (complicando o uso) de certas classes de ataques de negação de serviço. - (G16) Invariância do remetente.
Inglês Invariância do remetente .
Uma garantia para uma das partes de que a fonte da mensagem permanece a mesma que iniciou a comunicação, embora a identificação real da fonte não seja importante para o destinatário. - Irrefutabilidade.
Inglês Não repúdio .
- (G17) Responsabilidade.
Inglês Responsabilização .
Capacidade garantida de rastrear as ações dos sujeitos nos objetos. - (G18) Prova de origem.
Inglês Prova de origem .
Garantia de evidência irrefutável da fonte da mensagem. - (G19) Comprovante de entrega.
Inglês Prova de Entrega .
Garantia de evidência irrefutável do fato de receber a mensagem.
- (G20) Propriedade temporária protegida.
Inglês Propriedade Temporal de Segurança .
A garantia da capacidade de provar que o fato de o sistema estar em um dos estados significa que, uma vez no passado, o sistema estava pelo menos uma vez em algum outro estado. Por exemplo, que obter um acesso de assunto a um recurso significa que uma vez no passado o sujeito pagou com êxito por esse acesso.
Exemplos de propriedades de segurança implementadas por vários protocolos são fornecidos na tabela.

Classificação de protocolo
Não existe uma classificação universalmente aceita de protocolos de segurança. No entanto, é possível distinguir um conjunto de recursos
objetivos e inequívocos que classificam os protocolos.
- Classificação pelo número de participantes do protocolo:
- bilateral
- tripartido etc.,
- multilateral.
- Classificação pelo número de mensagens transmitidas:
- interativo (com presença de mensagens mútuas);
- não interativo (com mensagens únicas), geralmente chamadas de esquemas . A definição não está totalmente completa. Qualquer esquema envolve pelo menos dois estágios. No primeiro estágio preliminar, o centro confiável distribui algumas informações entre os participantes. No segundo estágio (sessões de protocolo específicas), os participantes trocam essas informações, recebendo o segredo original ou uma nova chave de sessão secreta. Além disso, a troca de informações pode variar entre mais de dois participantes. No entanto, após a troca mútua de informações, não são necessários passes adicionais para atingir os objetivos do esquema.
- Classificação pelo número de passes (rodadas):
- Classificação por sistemas criptográficos utilizados:
- baseado apenas em sistemas criptográficos simétricos;
- com base na inclusão de sistemas criptográficos assimétricos.
- Classificação por propriedades de protocolo protegidas:
- (G1) fornece ou não autenticação do primeiro, segundo lado do protocolo, etc;
- (G2) fornece ou não autenticação de mensagem;
- (G3) fornece ou não proteção contra repetição;
- etc.
- Classificação por tipo de participantes:
- Ponto a ponto, quando todos os participantes podem desempenhar qualquer função dentro do protocolo;
- com um intermediário confiável quando uma terceira parte confiável sempre estiver envolvida no protocolo;
- com um árbitro confiável, quando uma terceira parte confiável puder participar do protocolo, se os outros participantes não tiverem concordado.
Uma classificação menos objetiva e inequívoca também pode ser introduzida com base em uma avaliação subjetiva dos protocolos.
- Classificação de acordo com a finalidade do protocolo:
- ... garantindo integridade
- ... assinado digitalmente
- ... identificação
- ... privacidade
- ... distribuição de chaves,
- ... etc.
- Classificação da "completude" das funções desempenhadas:
- primitivo, são usados como um componente básico na construção de protocolos de aplicação;
- intermediário;
- aplicado, projetado para resolver problemas práticos.
A classificação por objetivo também pode ser reformulada como uma classificação pelas propriedades protegidas do protocolo para o qual foi desenvolvido. Nesse caso, será necessário destacar as “propriedades básicas” (por exemplo, G10 - a formação de novas chaves) e a maior parte do restante atribuída a mais (por exemplo, G7 - autenticação de chave e G8 - confirmação de propriedade da chave). Determinar quais das propriedades são "básicas" e quais são "adicionais" criará uma ambiguidade na classificação de acordo com a finalidade do protocolo. Se todas as propriedades do protocolo forem chamadas de “básicas”, essa classificação se tornará muito detalhada.
A classificação por "integralidade" das funções desempenhadas é problemática devido ao fato de que nem um único protocolo pode ser chamado de "aplicado" completamente. Qualquer protocolo em si é apenas parte de um determinado sistema de informação (ou organizacional), que apenas executa a função exigida pelos usuários. No entanto, podemos dizer que protocolos individuais (por exemplo, TLS) são protocolos de um nível mais alto que os protocolos, por exemplo, Diffie-Hellman, já que este último costuma atuar como parte integrante do mesmo protocolo TLS.
Ataques de protocolo
As propriedades protegidas dos protocolos podem ser declaradas quando os próprios autores do protocolo as declaram (e, geralmente, apresentam vários argumentos a favor do desempenho dessas funções) e implícitas quando os autores de um sistema dependem da implementação de propriedades protegidas por um determinado protocolo.Um ataque a um protocolo seguro é uma tentativa de analisar mensagens de protocolo e / ou executar ações não previstas no protocolo para violar as propriedades declaradas ou implícitas do protocolo. ( É usada uma definição modificada de [Cheremushkin: 2009] . A diferença é que Cheryomushkin em sua definição não descreve o que é “mau funcionamento do protocolo” e deixa casos ambíguos de violação, por exemplo, as propriedades G9 / PFS e G20 / STP.)Um ataque é considerado bem-sucedido se pelo menos uma das propriedades declaradas ou implícitas do protocolo for violada.No caso de um ataque bem-sucedido às propriedades implícitas, esclareceremos que o ataque ao uso do protocolo em algum sistema é bem - sucedido . Isso falará, é claro, não sobre as falhas do protocolo em si, mas sobre a escolha errada do protocolo (ou de suas configurações) pelos autores do sistema.Existem muitos tipos de ataques de protocolo. Muitos ataques têm alguns princípios gerais, o que possibilita distinguir classes de ataque para simplificar a análise e o desenvolvimento de protocolos resistentes a classes de ataque inteiras.- MitM « »
. man-in-the-middle attack
, , , , , , , . , ( G1). —. - Replay
. replay attack
, , , , . , , - . - TF
. type flaw attack
, , () ( ). , , Wide-Mouth Frog, —, Yahalom —. - PS
. parallel-session attack
, . , , —. - STS
. short-term secret attack - KN
. known-key attack
, , (, ), , , . - UKS
. unknown key-share attack
, ( , , ), . , , -.
É importante notar que, salvo indicação em contrário, na análise de protocolos criptográficos (sistemas não específicos), é usada a suposição da força de todas as primitivas criptográficas usadas. Por exemplo, supõe-se que, embora exista uma troca segura de informações usando uma chave de sessão gerada em uma sessão de algum protocolo criptográfico, o invasor não terá recursos e tempo suficientes para obter essa chave de sessão através de um ataque às cifras usadas ou funções de hash resistentes a criptografia.Por outro lado, deve-se supor que as chaves da sessão obtidas dentro da estrutura das sessões de protocolo, após algum tempo (no entanto, sejam muito mais longas que a própria sessão de comunicação), sejam obtidas pelo invasor (classes de ataque STS e KN). E depois de muito mais tempo, o invasor poderá obter acesso às chaves "mestras" - chaves de uso a longo prazo; portanto, protocolos com a geração de chaves de sessão devem ser desenvolvidos, incluindo a propriedade G9 / PFS.(As seções a seguir descrevem os protocolos específicos.)Referências
Posfácio
O autor será grato por comentários factuais e outros sobre o texto.
A apresentação e o texto foram preparados em grande parte na excelente palestra de Cheryomushkin (link acima).