O documento descreve a importância da especificação formal de protocolos de segurança. Aborda técnicas como CSP e Lógica BAN que permitem modelar formalmente protocolos e verificar propriedades de segurança de forma automatizada. Também discute como protocolos complexos como Needham-Schroeder podem ser especificados nessas linguagens formais.

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. 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. 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. 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. 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. 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. 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.