Especificação formal de protocolos de Segurança

3.123 visualizações

Publicada em

Uma introdução à especificação formal de protocolos de segurança.

Publicada em: Tecnologia
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
3.123
No SlideShare
0
A partir de incorporações
0
Número de incorporações
17
Ações
Compartilhamentos
0
Downloads
61
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Especificação formal de protocolos de Segurança

  1. 1. Especificação formal de protocolos de segurança requisito para a disciplina CE-281 do programa de pós-graduação strictu sensu do Instituto de Tecnologia da Aeronáutica (ITA), Prof. Yano. 2010, Fabian Martins da Silva, fabian.martins@gmail.com Introdução O tema da especificação e verificação formal de protocolos está no escopo dos métodos formais, que é um conjunto de técnicas suportadas pela lógica matemática cujo propósito é viabilizar a especificação, desenvolvimento e verificação de software e hardware. De fato, a modelagem matemática vem sendo aplicada nas diversas áreas da engenharia como uma excelente forma de representação e validação de modelos de quaisquer tipo. Isto é muito mais eficiente e barato do que se implementar protótipos, apesar do uso de uma técnica não descartar a outra. As questões de segurança representaram um importante papel no desenvolvimento dos métodos formais nas décadas de 70 e 80, tanto que as pesquisas neste tema foram patrocinadas principalmente pela NSA (National Security Agency, USA). Estes trabalhos resultaram no desenvolvimento de modelos formais de segurança, ferramentas para suportar o raciocínio sobre este tema e a aplicação destas ferramentas para provar a segurança de sistemas [Wing,2002]. Neste artigo iremos abordar de forma objetiva a importância dos métodos formais no contexto da especificação e verificação dos protocolos de segurança e visitaremos algumas das técnicas criadas para este propósito. Especificação de protocolos de segurança Os protocolos de segurança definem regras de comunicação entre sistemas que tem por objetivo garantir a robustez do processo de comunicação destes sistemas frente a um conjunto de ameças consideradas. Uma vez que se torna inviável tratar todas as ameaças possíveis, os protocolos são projetados com base em certas conjecturas feitas com relação a estas possíveis ameaças ([Anderson, 2001], pag.13). A notação padrão de engenharia para protocolos consiste basicamente na indicação do comunicante emissor, do receptor e da lista de informações que é transmitida do primeiro para o segundo. Por exemplo, se queremos especificar um protocolo onde um crachá (C) fornece sua identificação (que também é representada por C) para um terminal (T), poderemos especificar simplesmente como: C T :C Obviamente o ideal é que o crachá transmita ao terminal sua identificação em claro e uma informação de conhecimento exclusivo do terminal. Por exemplo, a própria identificação do crachá cifrada por uma chave de conhecimento único do terminal: C T :C , { C } K T Neste caso, KT representa a chave de cifragem de conhecimento apenas do terminal e de seus sistemas de suporte. É fácil perceber que que se um falsário (F) capturar o sinal transmitido pelo crachá C e o transmitir ao terminal ele facilmente se passará pelo portador do crachá C: C  F :C , { C }K T F T :C , {C }K T Fig 1: Exemplo na notação padrão para a especificação de protocolos. Percebe-se que, uma vez entendida sua estrutura, o padrão é relativamente simples para descrever protocolos mais complexos que este, como por exemplo o protocolo de Needham-Schroeder, que descreve a comunicação entre duas entidades A e B, autenticada por um sistema S ([Anderson, 2001], pag.26):
  2. 2. Mensagem 1 AS : A, B , N A Mensagem 2 S  A : { N A , B , K AB , { K AB , A }K BS }K AS Mensagem 3 A B : { K AB , A } K BS Mensagem 4 B  A : { N B }K AB Mensagem 5 A  B : { N B−1 } K AB Fig 2: Protocolo de Needham-Schroeder em notação padrão. Fica evidente que o protocolo de Nreedham-Schroeder tem por objetivo reduzir o risco de interceptação da informação de segurança, utilizando um sistema intermediário como autenticador da comunicação entre as entidades comunicantes. No exemplo temos: • A é o requisitante da comunicação, • B é o alvo da comunicação; • S é o sistema autenticador; • NA é um “nonce” (“number used once”, um número aleatório produzido por A); • KAS é a chave de comunicação entre A e S, de conhecimento exclusivo de S; • KAB é a chave de comunicação entre A e B, produzida por S e entregue à entidade A na mensagem 2; Apesar desta notação ser relativamente simples, o processo de projeto de protocolos de segurança mais complexos é particularmente complexo e sujeito a erros, tanto que foram encontradas falhas em um significante número de protocolos de segurança mesmo anos após a publicação original. Isto indica que os métodos informais de verificação dos protocolos podem manter escondidas suas falhas e vulnerabilidades. Especificações formais Uma especificação pode ser considerada formal se for expressa em uma linguagem composta de três componentes [Lamsweerde,2000]: 1. Sintaxe, que determina se as expressões estão bem formadas gramaticalmente; 2. Semântica, que especifique as regras para a interpretação das expressões, de forma precisa e significativa dentro do domínio considerado; 3. Regras, que consiste em regras para inferência de informações úteis a partir de uma especificação determinada; Escrever uma especificação correta não é algo trivial. A especificação deve descrever apropriadamente o problema, deve ser internamente consistente (ou seja, ter valor semântico), deve ser inambigua (indicar apenas uma interpretação possível), dentre outras características importantes. Dada a complexidade, alguém pode questionar por que utilizar especificações formais. O fato é que este tipo de especificação permite validar características sistêmicas de possíveis soluções para um problema sem que a mesma precise ser implementada. Além disso, as especificações formais são importantes para que possamos suplantar os problemas semânticos da linguagem natural e que, com isso, os conceitos a serem descritos possam ter interpretação única por qualquer leitor. Por este motivo são utilizadas largamente nas várias áreas de engenharia, matemática, computação e áreas afins, para documentar, comunicar, validar e reutilizar soluções [Holloway, 1997]. Do ponto de vista dos protocolos de segurança, as especificações formais fornecem uma abordagem sistemática para a descoberta de falhas e procuram descrever estes protocolos de modo que as conjecturas com respeito às possíveis vulnerabilidades possam ser avaliadas e os requisitos de segurança e o comportamento do protocolo, sob certas condições, possam ser testados e confirmados. Abordagens comuns para a verification formal de protocolos estão baseadas na lógica modal ou em máquinas de estados. Estas técnicas viabilizam a automatização do processo de verificação, o que agiliza o processo e remove diversas fontes pontenciais de erro da verificação manual [Tian, 2006]. Nas próximas seções vamos apresentar algumas delas: CSP, BAN Logic e CAPSL
  3. 3. CSP CSP ou “Communicating Sequential Processes” é uma linguagem formal para descrever padrões de interação entre sistemas concorrentes descrito pela primeira vez em 1978 por Hoare [Hoare, 1978] e depois publicado em seu livro homônimo em 1985. A CSP descreve um sistema (ou protocolo) em termos de elementos independentes que operam por meio do envio de mensagens, oferecendo um conjunto sintático/semântico composto por operadores algebráicos que permitem que descrições de interações complexas entre processos sejam construídas a partir de poucos elementos primitivos. Apesar de eficiente, a CSP é relativamente complexa. A melhor forma de ilustrar sua aplicação é voltando ao protocolo de Needham-Schroeder conforme descrito na figura 2 e observando sua especificação em CSP na figura 3. A=□i∈USER trans.A! i ! K i !  K Ai . A rec.A.i ? K Ai n i . A (a) trans.A! i ! K i  ni−1 Stop B=rec.B ? j ? K B  y.j  trans.B! j ! y n B . y  (b) rec.B.j.y  n B−1 Stop Fig 3: Protocolo de Needham-Schroeder (parcial) em CSP. No exemplo da figura 3 temos apenas as mensagens onde A e B trocam as chaves já recebidas pelo sistema autenticador da comunicação. Em (a) podemos observar 3 passos, um em cada linha: 1. A transmite (função trans) a um usuário i, pertencente ao espaço de usuários definidos por USER, a mensagem (KAi.A) criptografada com a chave Ki (ou seja, a chave fornecida pelo sistema autenticador). Observe que a mensagem (KAi.A) possui dois elementos: A chave de comunicação entre A e i e a identificação de A. 2. Em seguida A recebe (função rec) de i um número ni (nonce de i) e a identificação de A, ambos cifrados pela chave de comunicação fornecida previamente pelo sistema. O símbolo ? Indica que há um questionamento e espera-se recerber o argumento que o segue. 3. Finalmente, A transmite à entidade i o valor ni decrementado de uma unidade. Agora certamente fica mais fácil entender a expressão em (b), onde está representada a contrapartida do lado de B, onde a entidade A é representada por j. Adicionalmente, a especificação CSP poderia determinar as regras válidas na execução dos processos: Proc :: = trans → rec | rec → trans | trans → Stop | rec → Stop | Stop A CSP define um conjunto de construções possíveis em que eventos e processos podem ser combinados, entre eles temos: Pa □ Pb ( escolha deterministica, uma entidade determina se Pa ou Pb será executado) Pa ∏ Pb ( escolha não-determinística ) if x then Pa else Pb Podemos perceber que CSP é relativamente complexa. No entanto, é bastante consistente e prática para os processos de verificação de protocolos. Mais detalhes sobre a aplicação de CSP na especificação e validação de protocolos podem ser encontrados em [Schneider,1996] e [Schneider,1997].
  4. 4. BAN Logic A então denominada “lógica BAN” obtém seu nome a partir das iniciais de seus criadores, Burrows, Abadi e Needham, tendo sido publicada em 1989 no artigo “A Logic for Authentication” e algumas vezes é descrita como a primeira a analisar formalmente os protocolos criptográficos, apesar da CSP remontar a data anterior. Conforme especificam os autores, “o objetivo da lógica é descrever a crença das partes envolvidas na autenticação e a evolução desta crença enquanto os participantes se comunicam” [BAN, 1990]. A BAN não fornece prova de segurança, somente argumenta sobre a autenticação, também não tenta fazer a distinção entre receber uma mensagem e possuí-la; ambas são tratadas do mesmo modo. Os desenvolvedores da lógica BAN tinham como meta responder as seguintes perguntas [Santos, 2002]: • Quais são os objetivos do protocolo? • O protocolo precisa de mais suposições do que um outro? • O protocolo leva em consideração passos desnecessários que poderiam ser omitidos sem prejudicá-lo? • O protocolo cifra uma mensagem que poderia ser enviada em texto em claro sem prejudicar os aspectos de segurança? A BAN possui grande aplicação na análise de protocolos, o que é feito em três passos. O primeiro deles consiste em expressar as suposições e os objetivos como afirmações numa notação simbólica para que a lógica passe de um estado conhecido para um onde possa certificar se as metas serão realmente alcançadas. O passo seguinte consiste em transformar os passos do protocolo numa notação simbólica. Finalmente, um conjunto de postulados são aplicados para atingir os objetivos de autenticação [Santos, 2002]. A BAN utiliza um conjunto de expressões lógicas. Apresentamos algumas delas na tabela 1. Expressão Leitura Significado A |≡ B A acredita em B A considera B como uma verdade. A |~ X A uma vez disse X O participante A enviou uma mensagem contendo o valor X, em algum momento. A◃ X A “vê” X A recebeu a uma mensagem contendo X. A pode ler e repetir X caso deseje. A |⇒ X A tem jurisdição sobre X A é uma autoridade sobre X. Isto geralmente significa que X é uma chave de sessão criada por A. #(X) (X) é recente K é uma chave compartilhada na K é uma chave de conhecimento A K B comunicação entre A e B. exclusivo de A e B.  V A e B compartilham um segredo V V é, por exemplo, uma senha. É A⇔B tão novo quanto seguro. K K é chave pública de B B  Tabela 1: Exemplo de notações da lógica BAN. A lógica BAN fornece também um conjunto de postulados, que são a base da lógica para que se possa fazer a análise dos protocolos [BAN,1990]. Como o foco deste artigo não é a análise dos protocolos mas sim sua representação, vamos deixar a aplicação dos postulados para um outro momento.
  5. 5. Mais uma vez vamos utilizar o protocolo de Needham-Schroeder para ilustrar como a BAN Logic pode ser utilizada para descrever protocolos. Na figura 4 descrevemos os passos do protocolo, com exceção do primeiro pois a BAN não considera, nos protocolos de segurança, as informações transmitidas em claro. Mensagem 2 SA : { N A ,  A K B , #  A K B  ,  A K B  AB AB  { AB  }} K BS K AS Mensagem 3 AB :  A { K AB  B } K BS Mensagem 4 BA : { N B , A K AB  B }K AB Mensagem 5 AB : { N B ' , A K AB  B }K AB Fig 4: Protocolo Needham-Schroeder especificado em BAN logic. Observamos que a complexidade da representação cresce um pouco e que, do ponto de vista da especificação, a semântica da lógica BAN é facilmente percebida como correspondente ao equivalente em CSP, apesar da sintaxe ser significativamente diferente. CAPSL CAPSL é o acrônimo para “Common Authentication Protocol Specification Language” e é uma linguagem formal para expressar protocolos de autenticação e trocas de chaves desenvolvida em 1997 por Millen. É sabido que apesar de sua expressividade e da posterior ampliação para a descrição de protocolos multicast, com MuCAPSL, CAPSL tem dificuldade de representar certas expressões possíveis com os métodos baseados em lógica, como BAN. Ao contrário dos modelos lógicos, a CAPSL é uma linguagem de alto-nível. Sua intenção é permitir que um protocolo possa ser especificado de uma forma que possa ser tratada por qualquer ferramenta de análise automática de protocolos, desde que exista o compilador adequado. A CAPSL possui várias características importantes: • faz a distinição entre dados recentes e de longa data associados à sessão; • é modular e extensível; • uma especificação CAPSL é composta de até três tipos de módulos: typespec, protocol e environment specifications, geralmente nesta ordem. As typespec correspondem a especificações de tipos de dados abstratos e permite a definição de novos tipos de dados e definir operadores criptográficos e outras funções. • As especificações de protocolos em CAPSL possuem três partes principais: declarações, mensagens e metas. Mais uma vez vamos usar o protocolo de Needham-Schroeder para ilustrar a técnica. Na listagem 1 temos a especificação do protocolo em CAPSL [Tian, 2006]. PROTOCOL NSPK; VARIABLES S : Principal; A, B: PKUser; Na, Nb: Nonce, CRYPTO; KAB : Skey , FRESH , CRYPTO; ASSUMPTIONS HOLDS A : S; HOLDS A : B; MESSAGES
  6. 6. 1. A -> S : A, B, Na; 2. S -> A : {Na,B,KAB,{KAB,A}pk(B)}pk(A) 3. A -> B : {KAB,A}pk(B) 4. B -> A : {Nb}KAB 5. A -> B : {Nb'}KAB GOALS SECRET Na SECRET Nb; SECRET KAB; PRECEDES A: B | Na; PRECEDES B: A | Nb; END; Vamos a algumas explicações: • HOLDS X : Y indica que X é o iniciante da comunicação e espera uma resposta de Y; • PKUser é uma especialização do tipo Principal que possui um par de chaves pública/privada. Se A é um PKUser, pk(A) é sua chave pública e sk(A) é sua chave privada; • Skey indica uma chave simétrica; • {X}Y indica que X está cifrado pela chave Y; Vemos que a descrição em CAPSL é relativamente mais simples e próxima das linguagens de programação conhecidas, principalmente aquelas que permitem o uso de assertions. Conclusão As principais críticas às especificações formais, como um todo, estão na sua inerente complexidade e nas dificuldades de sua integração suave ao processo de engenharia de software [Smith,2008]. No entanto métodos formais como CAPSL, baseado nos modelos de máquina de estados, provêem pouco ou nenhum suporte para diversos operadores lógicos fundamentais para os processos de verificação, particularmente maduros nos modelos lógicos [Tian, 2006]. Percebe-se que o tema vem sendo tratado com crescente interesse desde a década de 70 e surgem inclusive propostas de modelagem de protocolos utilizando técnicas com a UML 2 [Smith, 2008]. Neste breve passeio pelo tema percebemos um movimento de conjunção das duas linhas. Por um lado procura-se uma especificação mais clara e natural como a CAPSL, mas sem perder o poder analítico de uma lógica BAN. Mesmo esta última possui evoluções suportadas pela lógica GNY [Gong, 1990], que busca suplantar algumas de suas falhas. O aprofundamento no tema requer a avaliação destas técnicas não só na especificação mas também na análise dos protocolos de segurança. Referências [Anderson, 2001] ANDERSON, R. “Security Engineering: A Guide to Building Dependable Distributed Systems”. Wiley, 2001. [BAN, 1990] BURROWS, M., ABADI, M. e NEEDHAM, R. “A logic of authentication”. ACM Transactions on Computer Systems, vol. 8, pp. 18-36. 1990. [Gong, 1990] GONG, L., NEEDHAM, R. AND YAHALOM, R., “Reasoning about belief in cryptographic protocols”, Proceedings of IEEE Computer Society Synopsis on Research in Security and Privacy, 1990, pp.234–248. [Hoare, 1978] HOARE, C.A.R. “Communicating Sequential Processes”. Communications of the ACM, volume 21, number 8, 1978. [Holloway, 1997] HOLLOWAY, C. M. “Why Engineers Should Consider Formal Methods”. Proceedings of the 16th Digital Avionics Systems Conference, October 1997 . [Kyntaja,1995] KYNTAJA, T. “A Logic of Authentication by Burrows, Abadi and Needham”. Proceedings of Helsinki University of Technology Seminar on Network Security, 1995. [Lamsweerde, 2000] LAMSWEERDE, A.V. “Formal Specification: a Roadmap”. Proceedings of the
  7. 7. Conference on The Future of Software Engineering, Limerick, Ireland , 2000; p.147-159. [Santos, 2002] SANTOS, M.C.M.D. “Análise formal de protocolos de autenticação para redes celulares”. Dissertação de Mestrado, Instituto Militar de Engenharia, Rio de Janeiro/RJ, Brasil, 2002. [Schneider, 1996] SCHNEIDER, S. “Using CSP for protocol analysis:the Needham-Schroeder Public-Key Protocol”. Royal Holloway Technical Report CSD-TR-96-14, 1996. [Schneider, 1997] SCHNEIDER, S. “Verifying authentication protocols with CSP”. Proceedings of the 10th IEEE workshop on Computer Security Foundations, 1997. [Smith, 2008] SMITH, S., BEAULIEU, A.,PHILLIPS, W.G. “Modeling Security Protocols Using UML 2”. Modelling Security Workshop at the ACM/IEEE 11th International Conference on Model Driven Engineering Languages and Systems, Toulouse, France, 2008. [Tian, 2006] TIAN, L., DOJEN, R. AND COFFEY, T. “Extending Formal Security Protocol Specification Languages for use with New Verifications Techniques”. WSEAS Transactions on Information Science and Applications, Vol. 3, No. 2, February 2006, pp.372-378. [Wing, 2002] WING, J.M. “A Symbiotic Relationship Between Formal Methods and Security”. Computer Security, Dependability and Assurance: From Needs to Solutions, 1998; Proceedings, p.26-38, 2002.

×