Mini-Curso

Cotrole de Acesso

Rafael Coninck Teigão

teigao@ppgia.pucpr.br
Orientador: Professor Carlos Maziero
maziero@ppgia.pucpr.br

Novembro 2006
Sumário

1 Conceitos Básicos 3
1.1 Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Ameaças, Vulnerabilidades e Ataques . . . . . . . . . . . . . . 4
1.2.1 Tipos de Ameaças . . . . . . . . . . . . . . . . . . . . 4
1.3 Polı́ticas de segurança . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Mecanismos de Segurança . . . . . . . . . . . . . . . . . . . . 5
1.5 Garantia de Controle . . . . . . . . . . . . . . . . . . . . . . . 5

2 Principais Modelos e os Mecanismos que os Implementam 6

2.1 O Modelo de Matriz de Acesso . . . . . . . . . . . . . . . . . . 6
2.1.1 Controle de Acesso Discricionário . . . . . . . . . . . . 7
2.2 Modelos Bell-LaPadula e Biba . . . . . . . . . . . . . . . . . . 7
2.2.1 Controle de Acesso Mandatório . . . . . . . . . . . . . 8
2.3 Controle de Acesso Baseado em Papéis . . . . . . . . . . . . . 8
2.4 Controle de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1 Momentos de Avaliação e Atualização . . . . . . . . . . 11

3 Polı́ticas 13
3.1 Definição Formal de Polı́ticas . . . . . . . . . . . . . . . . . . 13

4 Autenticação 15
4.1 UNIX Passwords . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2 Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.1 Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2
Capı́tulo 1

Conceitos Básicos

1.1 Segurança
Quando se fala de segurança, durante esta apostila, é importante saber que
trata-se do que a palavra em inglês security, ao invés de safety, descreve.
Segurança em computação, neste contexto, é o processo que garante as ca-
racterı́sticas de confidencialidade, integridade e disponibilidade, além
de autenticidade e não-repúdio1 .

Confidencialidade Deve-se garantir que apenas sujeitos autorizados te-

nham acesso às informações protegidas.

Integridade Estes sujeitos devem poder verificar que a informação não foi
indevidamente modificada; um intruso não deve poder modificar uma
informação sem que esta alteração não seja identificável.

Disponibilidade As informações devem estar acessı́veis durante os perı́odos

e da forma que foi planejado; um ataque que leve à negação de serviço
(Denial-of-Service – DoS) afeta a disponibilidade.

Autenticidade Os sujeitos devem poder saber com certeza a origem da

informação; um intruso não pode inserir uma informação e fazer com
que ela venha de outra fonte (e.g. um sujeito autorizado).

Não-repúdio Um sujeito não pode falsamente negar ter gerado uma in-
formação.
1
Segurança no sentido de safety descreve uma proteção contra acidentes ou riscos pes-
soais.

3
1.2 Ameaças, Vulnerabilidades e Ataques
Estas definições são ainda inconsistentes nos trabalhos nesta área. Este do-
cumento utiliza as definições para estes termos que é encontrada em [Amo94].

Ameaça em um sistema computacional é definida como qualquer ocorrência

potencial que pode levar a um efeito indesejado nos recursos associados
com o sistema. É importante realçar que uma ameaça é algo ruim que
poderia acontecer.

Vulnerabilidade é uma caracterı́stica do sistema que torna possı́vel que

uma ameaça potencialmente ocorra. Ou seja, uma vulnerabilidade per-
mite que algo ruim aconteça.

Ataque é uma ação executada por um intruso que envolve o abuso de uma
vulnerabilidade para provocar a ocorrência de uma ameaça.

1.2.1 Tipos de Ameaças

Pode-se identificar três tipos básicos de ameaças, que são o foco geral das
medidas utilizadas para mitigar suas implicações:

Vazamento de Informações é uma ameaça que envolve a disseminação de

informação classificada para pessoal não-autorizado.

Violação de Integridade envolve qualquer modificação não-autorizada de

informação.

Negação de Serviço ou DoS2 é uma ameaça que impede que usuários au-
torizados utilizem algum recurso por este estar maliciosamente bloque-
ado.

1.3 Polı́ticas de segurança

Polı́ticas descrevem o que deve ser feito em um sistema para se atingir o grau
de segurança desejado. Ao contrário dos mecanismos, que descrevem como
isto é alcançado.
Esta separação entre polı́ticas e mecanismos é importante porque as
polı́ticas são mais efêmeras, e tendem à variar com o tempo. Se esta se-
paração for corretamente realizada, uma mudança na polı́tica pode ser feita
2
Denial of Service.

4
sem que se tenha que alterar o mecanismo, que normalmente está implemen-
tado no software.
Existem dois tipos de mecanismos que garantem a efetivação das polı́ticas,
que devem ser destacados: aqueles que abrangem todo o sistema, e aqueles
que são controlados pelo sujeito responsável pelo objeto. Estes mecanismos
são chamados, respectivamente, de mandatórios e discricionários.

1.4 Mecanismos de Segurança

Discricionários ou baseados em identidade Estes mecanismos contro-
lam individualmente quais sujeitos possuem direitos sobre objetos, e
quais estes direitos são.

Mandatórios Os mecanismos mandatórios categorizam sujeitos e objetos e

descrevem como as categorias interagem, e esta interação permite sem-
pre os mesmos direitos para as mesmas categorias, no sistema inteiro.

Baseado em papéis O controle de acesso baseado em papéis está forte-

mente ligado à função do sujeito dentro de uma organização; cada pa-
pel do sujeito está vinculado a um tipo de atividade, e a um conjunto
de direitos.

1.5 Garantia de Controle

Trusted Computing Base – TCB O TCB compreende o conjunto total
de mecanismos de hardware e software responsáveis por garantir que a
polı́tica de segurança de um sistema seja respeitada. Espera-se que o
TCB seja facilmente auditável, por isso deseja-se que este seja sufici-
entemente pequeno para que esta auditoria seja viável.

Monitor de referência Pode ser visto como um filtro de acesso, por onde
todas as requisições de acesso devem passar e que não pode ser desviado
ou evitado, que decide, através de avaliações, se uma requisição deve
ser autorizada ou não. É um modelo conceitual de um mediador de
acesso.

5
Capı́tulo 2

Principais Modelos e os
Mecanismos que os
Implementam

2.1 O Modelo de Matriz de Acesso

Este modelo define uma matriz de S sujeitos por O objetos, mapeados sobre
um conjunto de direitos D, tais que:

∃ s ∈ S ∧ ∃ o ∈ O/r(s, o) ∈ R

A matriz de acesso pode ser visualizada como a figura 2.1.

s1

s2

Sujeitos Direitos

sS

o1 o2 Objetos oO

Figura 2.1: Matriz de Acesso

6
 O direito que se encontra na célula indexada pelo sujeito e objeto é aquele
que será concedido durante a requisição de acesso.

2.1.1 Controle de Acesso Discricionário

O controle de acesso discricionário (DAC) [Lam74] propicia um controle que é
administrado pelo usuário. A grande vantagem deste mecanismo é sua grande
flexibilidade, mas esta vantagem pode ser também seu maior problema. Não
é incomum casos em que o usuário esquece ou falha ao proteger corretamente
um objeto.
Duas implementações deste mecanismo são as Listas de Controle de Acesso
(Access Control Lists – ACL) e Capacidades (Capabilities).
As ACL descrevem, para cada objeto, quais sujeitos tem quais direitos
sobre este objeto. Tomando-se a Matriz de Acesso como modelo, as ACL
são representadas como a coluna de cada objeto. Um modelo simples de
ACL pode ser visto nos sistemas UNIX, em que os arquivos possuem listas
de permissões de acesso (direitos) para o proprietário, o grupo e os demais
usuários.
Similarmente, as Capacidades são representadas como as linhas da matriz
de acesso. Elas descrevem quais direitos um sujeito possui sobre os objetos.
Capabilities podem ser vistas como o inverso das ACL.

2.2 Modelos Bell-LaPadula e Biba

O modelo Bell-LaPadula (BLP) foca na preservação da confidencialidade
dos dados que ele protege. Cada sujeito possui um nı́vel de segurança e cada
objeto possui uma classificação. Uma treliça relaciona todos os noiveis com
as classificações.
Quando um sujeito requisita um acesso, seu nı́vel de segurança é con-
frontado com a classificação do objeto. O BLP define três propriedades de
segurança que devem ser respeitadas:

1. A Propriedade Simples de Segurança garante que um sujeito não pode

ler uma informação classificada acima do seu nı́vel de segurança (no
read-up).

2. A Propriedade * (estrela) impede que um sujeito escreva informações

em um objeto classificado abaixo de seu nı́vel (no write-down).

3. A Propriedade de Segurança Discricionária utiliza uma matriz de acesso

para especificar um DAC.

7
 Um administrador pode, quando necessário, mover informações de uma
classificação maior para outra menor (violando a propriedade *).
O modelo Biba pode ser visto como o oposto do modelo Bell-LaPadula:
sua preocupação é com a integridade das informações. Um sujeito pode
visualizar informação classificada no seu nı́vel de acesso, ou em um nı́vel
superior (no read-down), e escrever apenas em um objeto classificado em
seu nı́vel, ou inferior (no write-up).

2.2.1 Controle de Acesso Mandatório

O controle de acesso mandatório (MAC) [BL76] é definido como mecanismos
que não são controlados à discrição do usuário, mas, sim, à de um administra-
dor central. Assim, elimina-se o problema de um usuário inadvertidamente
reduzir a segurança de acesso a um objeto, e consegue-se uma maior ga-
rantia que as polı́ticas estabelecidas serão seguidas, porém ao custo de uma
flexibilidade grandemente diminuida.

2.3 Controle de Acesso Baseado em Papéis

Role-Based Access Control, ou RBAC [SFK00], é um modelo recente que
muito se adequa às necessidades das empresas, em que o controle de acesso
está fortemente ligado à função, ou papel, do sujeito dentro da empresa.
Por exemplo, entende-se que um diretor financeiro e um gerente de ven-
das têm papéis diferentes e, logo, precisam acessar apenas as informações
que são adequadas às suas funções. Da mesma forma, todos os diretores
financeiros podem ter acesso aos mesmos dados, visto que desempenham o
mesmo papel1 .
Matematicamente, tem-se para cada sujeito um mapeamento SxP , de
S sujeitos para P papéis e para cada objeto, um mapeamento P xD, de P
papéis para D direitos sobre o objeto.
Assim, atribui-se papéis aos sujeitos e vincula-se estes papéis aos direitos
de cada objeto.
O RBAC é usualmente dividido em 4 modelos, sendo que o primeiro deles,
chamado RBAC Básico é obrigatório na implementação de qualquer outro
modelo RBAC.
Básico Também conhecido como RBAC Plano, este modelo é obrigatório
em qualquer implementação do RBAC. Consiste na atribuição muitos-
para-muitos de papéis para sujeitos, em que um sujeito pode ter vários
1
claro que podem existir casos em que diretores do mesmo “nı́vel” possuem acessos
diferentes, e o RBAC pode tratar isso.

8
 papéis e um papel pode ser atribuı́do a vários sujeitos; sujeitos de-
vem poder habilitar vários papéis simultaneamente; e deve ser possı́vel,
através de uma ação administrativa, verificar quais papéis estão dis-
ponı́veis para um dado sujeito.

Hierárquico Neste modelo, pode-se atribuir a um papel as mesmas carac-

terı́sticas de papéis que estão abaixo dele. Por exemplo, a um diretor
seriam atribuı́das as permissões de seu papel somadas às permissões
dos papéis que vêm abaixo dele, como gerente e atendente; por sua
vez às permissões do presidente seriam adicionadas as permissões do
diretor e todas as permissões abaixo dele.

Restrito O RBAC Restrito permite a implementação de separação de tare-

fas, ou SoD2 . Na separação de tarefas, deve-se evitar que dois papéis
conflitantes sejam ativados simultaneamente.
Pode-se supor, por exemplo, que para lançar um foguete seja necessária
a autorização de um engenheiro e de um matemático. Ambos possuem
papéis diferentes que, simultaneamente devem autorizar a decolagem.
Podemos cair no caso em que um engenheiro é também um matemático,
ou vice-versa. Sem separação de tarefas, este sujeito poderia ativar
ambos os papéis e lançar, sozinho, o foguete. Se estes papéis forem
marcados como conflitantes, ao menos uma pessoa com cada papel é
necessária.

Simétrico No RBAC Simétrico, deve existir uma ação administrativa que

permita descobrir todas as permissões atribuı́das a um papel em todo
o sistema.

2.4 Controle de Uso

O conceito de controle de uso (UCON) proposto por Park e Sandhu [PS03]
engloba os modelos clássicos de controle de acesso tradicional, gerência de
confiança (trust management) e gerência de direitos digitais (Digital Rights
Management - DRM). O UCONABC é um modelo matemático que introduz a
utilização de predicados de Autorização, oBrigação e Condição para tomar a
decisão de negar, permitir ou controlar o uso de um recurso ou objeto digital.
Assim, a utilização de um recurso não é mais controlada apenas por listas
de controle de acesso (ACL) ou papéis (RBAC), por exemplo, mas também
2
sigla em inglês para Separation of Duty.

9
por fatores externos como a aceitação de um contrato através de um clique
do mouse (obrigação) ou o horário do dia (condição).
Os predicados do UCONABC também podem ser verificados durante a
utilização, e não apenas na requisição inicial de acesso, possibilitando que
um usuário tenha sua permissão de uso revogada enquanto detém o controle
do recurso. Outra facilidade que é introduzida nesse modelo é a mutabilidade
dos atributos do recurso e do usuário, possibilitando polı́ticas que garantam,
por exemplo, a dedução do custo de uso de um recurso do crédito disponı́vel
a um usuário.
Usuários e objetos possuem atributos que são utilizados para a tomada
de decisão pelo monitor de referência e esses atributos podem ser atualizados
como resultado da avaliação de uma requisição de uso. Assim, um atributo
de um objeto, atualizado durante uma requisição de uso de um usuário, pode
influenciar a avaliação do uso de outro usuário.
A avaliação considera, além dos atributos, predicados para autorização,
obrigação e condição. Estes predicados podem ser compostos separadamente,
ou utilizados em conjunto, dependendo do controle de uso que se deseja
implementar.
Autorização é um conjunto de predicados funcionais que são avaliados para
decidir se um usuário pode exercer um dado direito sobre um objeto.
Estes predicados englobam os modelos clássicos de controle de acesso,
como o Controle de Acesso Discricionário (DAC), Mandatório (MAC)
e Baseado em Papéis (RBAC).
oBrigações são predicados funcionais que tratam ações que devem ser cum-
pridas antes ou durante o uso para que um usuário possa exercer seus
direitos sobre o objeto. Por exemplo, para um usuário conseguir exe-
cutar um software novo, ele tem que enviar um email para o adminis-
trador informando que um novo executável foi instalado.
Condições são fatores de decisão ambientais ou externos ao objeto e ao
sujeito. Esses fatores podem ser indicados em atributos, mas nenhum
atributo deve ser utilizado diretamente no predicado. Por exemplo, o
predicado “qualquer usuário não administrativo só pode executar um
software se a carga total do processamento do sistema for menor que
80%” é uma condição, mas “um usuário só pode executar um software
se sua utilização do sistema for menor que 80%”, não o é. O fato de a
utilização do processador por um usuário ser um atributo especı́fico do
usuário faz com que a avaliação não seja do sistema, mas de um atributo
do usuário apenas, não se enquadrando na definição de condição dada
por Park e Sandhu [PS04].

10
2.4.1 Momentos de Avaliação e Atualização
Os predicados do UCONABC podem ser avaliados para se obter direito de
uso de um objeto, ou para manter este direito. Quando o usuário ainda não
detém direito de uso, e um conjunto de predicados será avaliado, a avaliação
acontece antes do uso, então chama-se esta avaliação de pre. Assim, tem-se
preA, preB e preC, para avaliações de Autorização, oBrigações e Condições.
Da mesma forma, quando avalia-se o direito de permanecer utilizando um
recurso, a avaliação acontece durante o uso, e ela é chamada de on: onA,
onB e onC. A figura 2.2 mostra esta continuidade na tomada de decisão.
Decision
pre(ABC) on(ABC)
Continuity

before Usage After

Attribute pre-update on-update pos-update

Mutability

Figura 2.2: Momentos de Avaliação dos Predicados

Como pode ser visto na figura 2.2, assim como existem momentos dife-
rentes para a verificação, existem, também, momentos diferentes para a atu-
alização de atributos. Atributos do recurso e do sujeito podem ser imutáveis
(0, ou modificados antes (1), durante (2) ou após (3) o uso (e.g. onA0 , onA1 ,
onA2 e onA3 ). A combinação dos momentos de avaliação com os de atua-
lização gera os 16 modelos centrais do UCONABC , como mostra a tabela 2.1:
cada “S” (sim) indica a existência de uma combinação no modelo.

Tabela 2.1: Os 16 Modelos Centrais do UCONABC

0 (imutável) 1 (pre-update) 2 (on-update) 3 (pos-update)
preA S S N S
onA S S S S
preB S S N S
onB S S S S
preC S N N N
onC S N N N

Para avaliações pre, não existe atualização durante o uso. Isso ocorre
porque, como não há avaliações neste momento (on), qualquer atributo al-

11
terado somente seria utilizado na próxima avaliação, antes do próximo uso,
fazendo com que uma atualização 2 tenha o mesmo efeito de uma atualização
3 (após o uso).
Nota-se, também, que os predicados de condição não atualizam atributos,
existindo apenas preC0 e onC0 . Isso acontece porque as condições são ava-
liadas apenas um função do sistema, e não dos atributos (mas um atributo
pode informar qual condição deve ser avaliada).

12
Capı́tulo 3

Polı́ticas

Uma polı́tica de segurança descreve as regras para um sujeito poder exercer

um direito sobre um objeto. Para que as regras sejam cumpridas, devem
existir mecanismos no sistema que possibilitem e garantam que estas serão
impostas.
Idealmente, a descrição das polı́ticas deve ser feita utilizando um método
formal, pois facilita a sua compreensão futura e reduz as chances de erros de
interpretação e especificação, já que podem ser matematicamente provadas.
Mas é importante construir polı́ticas que podem ser executadas; não faz
sentido, por exemplo, criar uma polı́tica que dependa da resolução de um
problema impossı́vel de resolver (como o Problema da Parada), para que o
acesso seja analisado.
As polı́ticas devem indicar, também, o que deve ser feito caso elas sejam
violadas. Por exemplo, caso estejamos interessados em manter a integridade
de um sistema, uma polı́tica poderia definir que, caso o sistema seja violado,
os objetos protegidos que foram afetados devem ser marcados como não-
confiáveis, indicando que estes objetos não podem mais ser tratados como
ı́ntegros.

3.1 Definição Formal de Polı́ticas

Existem vários projetos para criar formas de se definir formalmente uma
polı́tica. A seguir será apresentada a forma mais simples de se criar uma
polı́tica com algum rigor matemático.
Neste contexto, as polı́ticas serão definidas relacionando-se expressões
booleanas (i.e. verdadeiro/falso) construı́das a partir de conjuntos de
diferentes direitos, sujeitos e objetos. O formato destas expressões será:

13
 regra : conjunto → booleano
Pode-se, então, construir expressões como:

dono : sujeito × objeto → booleano (3.1)

acesso : sujeito × direito × objeto → booleano (3.2)

Estas expressões podem ser vistas como funções que retornam um va-
lor booleano. Por exemplo, a função dono definida acima poderia retornar
verdadeiro para dono(pedro, /tmp/arq.txt).
Expressões mais complexas podem ser criadas, agrupando-se funções di-
ferentes:

propriedade :∀s ∈ S, o ∈ O, d ∈ D : acesso(s, o, d) ⇐⇒ dono(s, o)

Deve-se conhecer o sistema em que as polı́ticas serão utilizadas, para

que seja possı́vel estabelecer o que é possı́vel de se impor, quais informações
sobre sujeitos e objetos estarão disponı́veis e quais mecanismos poderão ser
empregados.

14
Capı́tulo 4

Autenticação

Toda proteção em controle de acesso depende da capacidade de corretamente

identificar os processos e programas e, consequentemente, o usuário que os
executa [SG98]. É preciso, portanto, garantir que esta identificação seja
autêntica.
A autenticação baseia-se geralmente na verificação de um ou mais dos
seguintes ı́tens:
1. algo que o usuário possui (um cartão, uma chave, etc);
2. algo que o usuário sabe (uma senha, um data de nascimento, etc);
3. algo que caracteriza o usuário (sua impressão digital, sua retina, seu
DNA, etc).
O mais comumente empregado destes ı́tens é aquilo que o usuário sabe,
uma senha ou palavra-chave. Mas atualmente é normal encontrar verificado-
res de impressão digital ou leitores de cartões inteligentes (smart-cards).
Senhas são armazenadas no sistema e, quando o usuário requisita um
acesso, pede-se que esta informação seja digitada. Se a informação, ao ser
comparada com aquela armazenada, for a correta, o usuário é identificado
como legı́timo, e recebe uma credencial que o permite acessar o sistema.
O principal problema das palavras-chave é a dificuldade em mantê-las em
segredo. Estas podem ser adivinhadas ou inadvertidamente disponibilizadas.
É muito comum que pessoas utilizem informações pessoais ou palavras
com que elas se relacionam para criar suas senhas. Nomes de cônjuges e
animais de estimação e palavras presentes em seu cotidiano, entre outras,
fazem parte da maioria das senhas, e podem ser facilmente adivinhadas.
Além disso, palavras comuns, encontradas em dicionários, podem ser com-
prometidas através de ataques de força-bruta, em que todas as palavras e suas
variações (como trocar a letra “i” pelo dı́gito “1” em “am1go”) são testadas.

15
 As palavras-chave podem ainda ser conseguidas ao ver o usuário as digi-
tando (“shoulder surfing”), ou em anotações em sua mesa. Em alguns casos,
usuários podem até mesmo fornecer suas senhas para qualquer pessoa que
identifique-se como profissional de informática ou para “ceder” sua conta
para um colega realizar um serviço mais facilmente.
Para evitar problemas como estes, deve-se:

1. garantir que as senhas utilizadas são de qualidade e “fortes” (executar

um ataque de dicionário contra o banco de dados das senhas, não per-
mitir que o usuário escolha palavras comuns e sem caracteres especiais
ou que sejam muito curtas, etc);

2. educar usuários para que não emprestem ou informem suas senhas e

para que não escrevam esta informação;

3. frequentemente verificar os sistemas utilizados para detectar key-loggers

e cavalos-de-tróia.

4.1 UNIX Passwords

Um erro frequentemente encontrado quando fala-se de armazenamento de
senhas é a concepção que estas senhas são armazenadas criptografadas com
uma chave, e que alguém em posse desta chave consiga visualizar todas as
senhas. Isto só é verdade em sistemas mal-planejados, e estes sistemas po-
derão sofrer grandes danos caso uma vulnerabilidade permita que um cracker
encontre esta chave e acesse todas as senhas.
Nos sistemas UNIX e na maioria dos sistemas que corretamente arma-
zenam senhas, um artifı́cio matemático é utilizado. Utiliza-se funções ma-
temáticas cujo resultado é muito fácil de calcular, mas que o inverso leva
muito tempo para ser computado.
Estas funções, chamadas de one-way (“Só de ida”) são utilizadas para
calcular um valor que é armazenado no lugar da senha. Quando o usuário
envia a sua senha, durante a autenticação, esta função é novamente utilizada
para calcular o valor resultante deste dado. Se o resultado desta função
for o mesmo para a senha digitada e para aquela armazenada, o usuário é
autenticado.
Porém, palavras-chave armazenadas desta forma ainda podem ser encon-
tradas através de um ataque de dicionário. Um cracker pode calcular o
resultado da função one-way para um dicionário com milhares de palavras e
comparar os resultados com um arquivo de senha.

16
 Para dificultar este tipo de ataque, adiciona-se à palavra-chave uma seqüência
aleatória de caracteres, chamada de salt, antes de aplicar a função one-way, e
armazena-se estes caracteres junto com o resultado no banco de dados. Se o
salt for suficientemente longo e variado, um ataque de dicionário seria prati-
camente inviabilizado devido ao tempo para se computar um dicionário com
todos os caracteres aleatórios possı́veis para cada palavra, e devido também
ao grande espaço necessário para armazenar os resultados.
Um salt de 4 caracteres entre 0-9 e a-Z (60 valores) resultaria em 12.960.000
diferentes resultados para cada palavra do dicionário. É mais fácil calcular
o dicionário utilizando-se apenas os valores aleatórios encontrados no banco
de dados, mas assim perde-se a vantagem de se poder utilizar o mesmo di-
cionário para vários ataques, e aumenta muito o tempo de cada ataque.

4.2 Single Sign-On

Single Sign-On é uma forma de autenticação que permite que o usuário
autentique-se apenas uma vez e possa usar a credencial adquirida em diversos
sistemas e serviços diferentes, sem a necessidade de reautenticar-se.
Vantagens do single sign-on:
• melhora-se o tempo de acesso aos serviços, já que o usuário não precisa
autenticar-se em cada acesso;
• tem-se um ganho de segurança, já que não há a necessidade do usuário
ficar decorando e digitando diversas senhas em vários sistemas;
• cria-se um ponto centralizado de administração de usuário, facilitando
adições e remoções de contas.
A implementação do single sign-on, que talvez seja a mais conhecida,
chama-se Kerberos. Esta implementação permite que usuários acessem serviços
em diversos sistemas operacionais diferentes, como Linux e MS-Windows,
com as mesmas credenciais, uma vez que está disponı́vel para diversos siste-
mas operacionais, em várias plataformas de hardware.

4.2.1 Kerberos
Kerberos é um protocolo que provê uma autenticação segura em rede, permi-
tindo que um usuário ou processo acesse diversos serviços realizando apenas
uma autenticação. Este protocolo é baseado em criptografia simétrica, e
compartilha uma chave secreta com cada entidade (clientes e servidores) na
rede; conhecimento desta chave secreta é prova de identidade.

17
 Figura 4.1: Passos de autenticação no Kerberos (Extraı́da de [Sch96]

O serviço Kerberos guarda um banco de dados de todos os clientes e

suas chaves secretas. Serviços que requerem autenticação, e os clientes que
desejam acessar estes serviços, registram suas chaves secretas no Kerberos.
Para um usuário, esta chave secreta poderia ser um password criptografado.
Como o Kerberos conhece a chave de todos os clientes e servidores, este
serviço pode criar mensagens que garantem a identificação de uma entidade
para outra. Pode também gerar chaves de sessão, que são entregues apenas
para as entidades envolvidas em uma comunicação, que são utilizadas para
criptografar mensagens trocadas, e que são destruı́das quando a sessão acaba.
A figura 4.1 mostra os passos envolvidos em um acesso com Kerberos. Pri-
meiramente, o cliente solicita uma credencial (ticket) para acessar o Ticket-
Granting Service (TGS). Este ticket é enviado para o cliente, criptografado
com sua chave secreta. Para acessar um servidor, o cliente solicita ao TGS
um ticket para o servidor. Se a credencial do cliente estiver correta, o TGS
envia um ticket para o cliente utilizar com o servidor. O cliente apresenta,
então, este ticket e um autenticador para o servidor, que os verifica e concede
o acesso.
Para entender as mensagens trocadas, são apresentadas na tabela 4.1 as
abreviações utilizadas na descrição matemática.

Credenciais
O Kerberos utiliza dois tipos de credenciais, tickets e autenticadores. Um
ticket é utilizado para, de maneira segura, passar a identidade de seu portador
para um servidor. É válido apenas para um cliente utilizá-lo em conjunto

18
 Tabela 4.1: Tabela de Abreviações (Extraı́da de [Sch96])
c cliente
s servidor
a endereço de rede do cliente
v inı́cio e término do tempo de validade de um ticket
t timestamp
Kx chave secreta de x
Kx,y chave de sessão para x e y
{m}Kx m criptografado com a chave secreta de x
Tx,y ticket de x para acessar y
Ax,y autenticador de x para y

com um servidor, sendo que o ticket possui informações que permitem ao

servidor assegurar que seu portador é aquele para quem o ticket foi emitido.
Um ticket Kerberos pode ser representado da seguinte forma:
Tc,s = s, {c, a, v, Kc,s}Ks
Nele estão contidos o nome e endereço do cliente, o nome do servidor, um
intervalo de validade e a chave de sessão. Várias dessas informações estão
criptografadas com a chave do servidor. Esta credencial pode ser utilizada
quantas vezes forem necessárias, dentro do prazo de validade.
Um autenticador, por sua vez, é representado por:
Ac,s = {c, t, key}Kc,s
O autenticador enviado pelo cliente contém o seu nome, um timestamp e
um segunda chave de sessão opcional. Esses dados são criptografados com
a chave de sessão Kc,s . Diferente de um ticket, um autenticador pode ser
utilizado para acessar um serviço apenas uma vez, mas o cliente pode gerar
quantos autenticadores forem necessários, dentro do prazo de validade da
chave de sessão.
Como o autenticador contém um texto conhecido (o nome do cliente),
ele garante que o cliente conhece a chave, pois se a chave fosse incorreta,
ao descriptografar os dados, o nome estaria embaralhado. Além disso, o
timestamp garante que um ataque de replay não seja possı́vel.

Mensagens trocadas no Kerberos

Como visto na figura 4.1, são cinco mensagens1 no total:
1
Apenas o Kerberos versão 5 será apresentado.

19
 1. Cliente para Kerberos: c, tgs
2. Kerberos para Cliente: {Kc,tgs }Kc , {Tc,tgs }Ktgs
3. Cliente para TGS: {Ac,s }Kc,tgs , {Tc,tgs }Ktgs
4. TGS para Cliente: {Kc,s }Kc,tgs , {Tc,s}Ks
5. Cliente para Servidor: {Ac,s }Kc,s , {Tc,s}Ks

A chave secreta do cliente Kc é o resultado de uma função one-way sobre o

seu password. Como o servidor Kerberos tem o registro de todos os usuários,
ele já possui esta informação. O password do usuário nunca é transmitido
na rede.

20
Referências Bibliográficas

[Amo94] Edward G. Amoroso. Fundamentals of computer security techno-

logy. Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1994.

[BL76] D.E. Bell and L. LaPadula. Secure computer systems: Unified

exposition and multics interpretation. Technical report, MITRE
Corporation, Massachusetts, USA, March 1976.

[Lam74] Butler W. Lampson. Protection. SIGOPS Operating System Re-

view, 8(1):18–24, 1974.

[PS03] Jaehong Park and Ravi Sandhu. Usage control: A vision for
next generation access control. In Vladimir Gorodetsky, Leo-
nard J. Popyack, and Victor A. Skormin, editors, 2nd International
Workshop on Mathematical Methods, Models, and Architectures for
Computer Network Security, volume 2776 of Lecture Notes in Com-
puter Science, pages 17–31. Springer, 2003.

[PS04] Jaehong Park and Ravi Sandhu. The U CONABC usage control
model. ACM Transactions on Information and System Security,
7(1):128–174, 2004.

[Sch96] Bruce Schneier. Applied cryptography: protocols, algorithms, and

source code in C. Wiley, Inc., New York, NY, USA, 2nd edition,
1996.

[SFK00] Ravi Sandhu, David Ferraiolo, and Richard Kuhn. The NIST model
for role-based access control: towards a unified standard. In RBAC
’00: Proceedings of the fifth ACM workshop on Role-based access
control, pages 47–63, New York, NY, USA, 2000. ACM Press.

[SG98] Abraham Silberschatz and Peter Galvin. Operating systems con-

cepts. Addison-Wesley Longman Publishing Co., Inc., Boston, MA,
USA, 5th edition, 1998.

21
Índice Remissivo

ameaça, 4 restrito, 9
negação de serviço, 3, 4 simétrico, 9
tipos de, 4 modelo
vazamento de informações, 4 Bell-LaPadula, 7
violação de integridade, 4 Biba, 8
ataque, 4 matriz de acesso, 6
autenticação, 15 monitor de referência, 5
single sign-on, 17
funções one-way, 16 não-repúdio, 3
kerberos, 17 polı́ticas, 4, 13
credenciais, 18 definição formal de, 13
mensagens do protocolo, 18, 19
problemas, 15 segurança
UNIX passwords, 16 safety, 3
autenticidade, 3 security, 3

confidencialidade, 3 TCB, 5
criptografia
salt, 17 UCON, 9
de passwords, 16 vulnerabilidade, 4
funções one-way, 16

disponibilidade, 3

integridade, 3

mecanismos de segurança, 4, 5
Capabilities, 7
ACL, 7
DAC, 5, 7
MAC, 5, 8
RBAC, 5, 8
básico, 8
hierárquico, 9

22