Mini-Curso

Cotrole de Acesso
Rafael Coninck Teig ao teigao@ppgia.pucpr.br Orientador: Professor Carlos Maziero maziero@ppgia.pucpr.br Novembro 2006

Sum ario
1 Conceitos B asicos 1.1 Seguran ca . . . . . . . . . 1.2 Amea cas, Vulnerabilidades 1.2.1 Tipos de Amea cas 1.3 Pol ticas de seguran ca . . 1.4 Mecanismos de Seguran ca 1.5 Garantia de Controle . . . 3 3 4 4 4 5 5

. e . . . .

. . . . . Ataques . . . . . . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

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 ario . . . . . . . . . . . . 7 2.2 Modelos Bell-LaPadula e Biba . . . . . . . . . . . . . . . . . . 7 2.2.1 Controle de Acesso Mandat orio . . . . . . . . . . . . . 8 2.3 Controle de Acesso Baseado em Pap eis . . . . . . . . . . . . . 8 2.4 Controle de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4.1 Momentos de Avalia ca o e Atualiza ca o . . . . . . . . . . 11 3 Pol ticas 13 3.1 Deni ca o Formal de Pol ticas . . . . . . . . . . . . . . . . . . 13 4 Autentica c ao 15 4.1 UNIX Passwords . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2 Single Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2.1 Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Cap tulo 1 Conceitos B asicos

1.1 Seguran ca

Quando se fala de seguran ca, durante esta apostila, e importante saber que trata-se do que a palavra em ingl es security , ao inv es de safety , descreve. Seguran ca em computa ca o, neste contexto, e o processo que garante as caracter sticas de condencialidade, integridade e disponibilidade, al em 1 de autenticidade e n ao-rep udio . Condencialidade Deve-se garantir que apenas sujeitos autorizados tenham acesso a `s informa co es protegidas. Integridade Estes sujeitos devem poder vericar que a informa ca o n ao foi indevidamente modicada; um intruso n ao deve poder modicar uma informa ca o sem que esta altera ca o n ao seja identic avel. Disponibilidade As informa co es devem estar acess veis durante os per odos e da forma que foi planejado; um ataque que leve a ` nega c ao de servi co (Denial-of-Service DoS) afeta a disponibilidade. Autenticidade Os sujeitos devem poder saber com certeza a origem da informa ca o; um intruso n ao pode inserir uma informa ca o e fazer com que ela venha de outra fonte (e.g. um sujeito autorizado). N ao-rep udio Um sujeito n ao pode falsamente negar ter gerado uma informa ca o.
Seguran ca no sentido de safety descreve uma prote ca o contra acidentes ou riscos pessoais.
1

1.2

Amea cas, Vulnerabilidades e Ataques

Estas deni co es s ao ainda inconsistentes nos trabalhos nesta a rea. Este documento utiliza as deni co es para estes termos que e encontrada em [Amo94]. Amea ca em um sistema computacional e denida como qualquer ocorr encia potencial que pode levar a um efeito indesejado nos recursos associados importante real com o sistema. E car que uma amea ca e algo ruim que poderia acontecer. Vulnerabilidade e uma caracter stica do sistema que torna poss vel que uma amea ca potencialmente ocorra. Ou seja, uma vulnerabilidade permite que algo ruim aconte ca. Ataque e uma a ca o executada por um intruso que envolve o abuso de uma vulnerabilidade para provocar a ocorr encia de uma amea ca.

1.2.1

Tipos de Amea cas

Pode-se identicar tr es tipos b asicos de amea cas, que s ao o foco geral das medidas utilizadas para mitigar suas implica co es: Vazamento de Informa co es e uma amea ca que envolve a dissemina ca o de informa ca o classicada para pessoal n ao-autorizado. Viola c ao de Integridade envolve qualquer modica ca o n ao-autorizada de informa ca o. Nega c ao de Servi co ou DoS2 e uma amea ca que impede que usu arios autorizados utilizem algum recurso por este estar maliciosamente bloqueado.

1.3

Pol ticas de seguran ca

Pol ticas descrevem o que deve ser feito em um sistema para se atingir o grau de seguran ca desejado. Ao contr ario dos mecanismos, que descrevem como isto e alcan cado. Esta separa ca o entre pol ticas e mecanismos e importante porque as pol ticas s ao mais ef emeras, e tendem a ` variar com o tempo. Se esta separa ca o for corretamente realizada, uma mudan ca na pol tica pode ser feita
2

Denial of Service.

sem que se tenha que alterar o mecanismo, que normalmente est a implementado no software. Existem dois tipos de mecanismos que garantem a efetiva ca o das pol ticas, que devem ser destacados: aqueles que abrangem todo o sistema, e aqueles que s ao controlados pelo sujeito respons avel pelo objeto. Estes mecanismos s ao chamados, respectivamente, de mandat orios e discricion arios.

1.4

Mecanismos de Seguran ca

Discricion arios ou baseados em identidade Estes mecanismos controlam individualmente quais sujeitos possuem direitos sobre objetos, e quais estes direitos s ao. Mandat orios Os mecanismos mandat orios categorizam sujeitos e objetos e descrevem como as categorias interagem, e esta intera ca o permite sempre os mesmos direitos para as mesmas categorias, no sistema inteiro. Baseado em pap eis O controle de acesso baseado em pap eis est a fortemente ligado a ` fun ca o do sujeito dentro de uma organiza ca o; cada papel do sujeito est a 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 aveis por garantir que a pol tica de seguran ca de um sistema seja respeitada. Espera-se que o TCB seja facilmente audit avel, por isso deseja-se que este seja sucientemente pequeno para que esta auditoria seja vi avel. Monitor de refer encia Pode ser visto como um ltro de acesso, por onde todas as requisi co es de acesso devem passar e que n ao pode ser desviado ou evitado, que decide, atrav es de avalia co es, se uma requisi ca o deve ser autorizada ou n ao. E um modelo conceitual de um mediador de acesso.

Cap tulo 2 Principais Modelos e os Mecanismos que os Implementam

2.1 O Modelo de Matriz de Acesso

Este modelo dene 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 gura 2.1.
s1

s2

Sujeitos

Direitos

sS

o1

o2

Objetos

oO

Figura 2.1: Matriz de Acesso

O direito que se encontra na c elula indexada pelo sujeito e objeto e aquele que ser a concedido durante a requisi ca o de acesso.

2.1.1

Controle de Acesso Discricion ario

O controle de acesso discricion ario (DAC) [Lam74] propicia um controle que e administrado pelo usu ario. A grande vantagem deste mecanismo e sua grande exibilidade, mas esta vantagem pode ser tamb em seu maior problema. N ao e incomum casos em que o usu ario esquece ou falha ao proteger corretamente um objeto. Duas implementa co es deste mecanismo s ao 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 ao 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 oes de acesso (direitos) para o propriet ario, o grupo e os demais usu arios. Similarmente, as Capacidades s ao 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 ca o da condencialidade dos dados que ele protege. Cada sujeito possui um n vel de seguran ca e cada objeto possui uma classica ca o. Uma treli ca relaciona todos os noiveis com as classica co es. Quando um sujeito requisita um acesso, seu n vel de seguran ca e confrontado com a classica ca o do objeto. O BLP dene tr es propriedades de seguran ca que devem ser respeitadas: 1. A Propriedade Simples de Seguran ca garante que um sujeito n ao pode ler uma informa ca o classicada acima do seu n vel de seguran ca (no read-up ). 2. A Propriedade * (estrela) impede que um sujeito escreva informa co es em um objeto classicado abaixo de seu n vel (no write-down ). 3. A Propriedade de Seguran ca Discricion aria utiliza uma matriz de acesso para especicar um DAC. 7

Um administrador pode, quando necess ario, mover informa co es de uma classica ca o maior para outra menor (violando a propriedade *). O modelo Biba pode ser visto como o oposto do modelo Bell-LaPadula: sua preocupa ca o e com a integridade das informa co es. Um sujeito pode visualizar informa ca o classicada no seu n vel de acesso, ou em um n vel superior (no read-down ), e escrever apenas em um objeto classicado em seu n vel, ou inferior (no write-up ).

2.2.1

Controle de Acesso Mandat orio

O controle de acesso mandat orio (MAC) [BL76] e denido como mecanismos que n ao s ao controlados a ` discri ca o do usu ario, mas, sim, a ` de um administrador central. Assim, elimina-se o problema de um usu ario inadvertidamente reduzir a seguran ca de acesso a um objeto, e consegue-se uma maior garantia que as pol ticas estabelecidas ser ao seguidas, por em ao custo de uma exibilidade grandemente diminuida.

2.3

Controle de Acesso Baseado em Pap eis

Role-Based Access Control, ou RBAC [SFK00], e um modelo recente que muito se adequa a `s necessidades das empresas, em que o controle de acesso est a fortemente ligado a ` fun ca o, ou papel, do sujeito dentro da empresa. Por exemplo, entende-se que um diretor nanceiro e um gerente de vendas t em pap eis diferentes e, logo, precisam acessar apenas as informa co es que s ao adequadas a `s suas fun co es. Da mesma forma, todos os diretores nanceiros 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 eis e para cada objeto, um mapeamento P xD , de P pap eis para D direitos sobre o objeto. Assim, atribui-se pap eis aos sujeitos e vincula-se estes pap eis aos direitos de cada objeto. O RBAC e usualmente dividido em 4 modelos, sendo que o primeiro deles, chamado RBAC B asico e obrigat orio na implementa ca o de qualquer outro modelo RBAC. B asico Tamb em conhecido como RBAC Plano, este modelo e obrigat orio em qualquer implementa ca o do RBAC. Consiste na atribui ca o muitospara-muitos de pap eis para sujeitos, em que um sujeito pode ter v arios
claro que podem existir casos em que diretores do mesmo n vel possuem acessos diferentes, e o RBAC pode tratar isso.
1

pap eis e um papel pode ser atribu do a v arios sujeitos; sujeitos devem poder habilitar v arios pap eis simultaneamente; e deve ser poss vel, atrav es de uma a ca o administrativa, vericar quais pap eis est ao dispon veis para um dado sujeito. Hier arquico Neste modelo, pode-se atribuir a um papel as mesmas caracter sticas de pap eis que est ao abaixo dele. Por exemplo, a um diretor seriam atribu das as permiss oes de seu papel somadas a `s permiss oes dos pap eis que v em abaixo dele, como gerente e atendente; por sua vez a `s permiss oes do presidente seriam adicionadas as permiss oes do diretor e todas as permiss oes abaixo dele. Restrito O RBAC Restrito permite a implementa ca o de separa ca o de tarefas, ou SoD2 . Na separa ca o de tarefas, deve-se evitar que dois pap eis conitantes sejam ativados simultaneamente. Pode-se supor, por exemplo, que para lan car um foguete seja necess aria a autoriza ca o de um engenheiro e de um matem atico. Ambos possuem pap eis diferentes que, simultaneamente devem autorizar a decolagem. Podemos cair no caso em que um engenheiro e tamb em um matem atico, ou vice-versa. Sem separa ca o de tarefas, este sujeito poderia ativar ambos os pap eis e lan car, sozinho, o foguete. Se estes pap eis forem marcados como conitantes, ao menos uma pessoa com cada papel e necess aria. Sim etrico No RBAC Sim etrico, deve existir uma a ca o administrativa que permita descobrir todas as permiss oes 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 assicos de controle de acesso tradicional, ger encia de conan ca (trust management ) e ger encia de direitos digitais (Digital Rights Management - DRM). O UCONABC e um modelo matem atico que introduz a utiliza ca o de predicados de Autoriza ca o, oBriga ca o e Condi ca o para tomar a decis ao de negar, permitir ou controlar o uso de um recurso ou objeto digital. Assim, a utiliza ca o de um recurso n ao e mais controlada apenas por listas de controle de acesso (ACL) ou pap eis (RBAC), por exemplo, mas tamb em
2

sigla em ingl es para Separation of Duty.

por fatores externos como a aceita ca o de um contrato atrav es de um clique do mouse (obriga ca o) ou o hor ario do dia (condi ca o). Os predicados do UCONABC tamb em podem ser vericados durante a utiliza ca o, e n ao apenas na requisi ca o inicial de acesso, possibilitando que um usu ario tenha sua permiss ao de uso revogada enquanto det em o controle do recurso. Outra facilidade que e introduzida nesse modelo e a mutabilidade dos atributos do recurso e do usu ario, possibilitando pol ticas que garantam, por exemplo, a dedu ca o do custo de uso de um recurso do cr edito dispon vel a um usu ario. Usu arios e objetos possuem atributos que s ao utilizados para a tomada de decis ao pelo monitor de refer encia e esses atributos podem ser atualizados como resultado da avalia ca o de uma requisi ca o de uso. Assim, um atributo de um objeto, atualizado durante uma requisi ca o de uso de um usu ario, pode inuenciar a avalia ca o do uso de outro usu ario. A avalia ca o considera, al em dos atributos, predicados para autoriza ca o, obriga ca o e condi ca o. Estes predicados podem ser compostos separadamente, ou utilizados em conjunto, dependendo do controle de uso que se deseja implementar. Autoriza c ao e um conjunto de predicados funcionais que s ao avaliados para decidir se um usu ario pode exercer um dado direito sobre um objeto. Estes predicados englobam os modelos cl assicos de controle de acesso, como o Controle de Acesso Discricion ario (DAC), Mandat orio (MAC) e Baseado em Pap eis (RBAC). oBriga co es s ao predicados funcionais que tratam a co es que devem ser cumpridas antes ou durante o uso para que um usu ario possa exercer seus direitos sobre o objeto. Por exemplo, para um usu ario conseguir executar um software novo, ele tem que enviar um email para o administrador informando que um novo execut avel foi instalado. Condi co es s ao fatores de decis ao 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 ario n ao administrativo s o pode executar um software se a carga total do processamento do sistema for menor que 80% e uma condi ca o, mas um usu ario s o pode executar um software se sua utiliza ca o do sistema for menor que 80%, n ao o e. O fato de a utiliza ca o do processador por um usu ario ser um atributo espec co do usu ario faz com que a avalia ca o n ao seja do sistema, mas de um atributo do usu ario apenas, n ao se enquadrando na deni ca o de condi ca o dada por Park e Sandhu [PS04]. 10

2.4.1

Momentos de Avalia c ao e Atualiza c ao

Os predicados do UCONABC podem ser avaliados para se obter direito de uso de um objeto, ou para manter este direito. Quando o usu ario ainda n ao det em direito de uso, e um conjunto de predicados ser a avaliado, a avalia ca o acontece antes do uso, ent ao chama-se esta avalia ca o de pre. Assim, tem-se preA, preB e preC, para avalia co es de Autoriza ca o, oBriga co es e Condi co es. Da mesma forma, quando avalia-se o direito de permanecer utilizando um recurso, a avalia ca o acontece durante o uso, e ela e chamada de on: onA, onB e onC. A gura 2.2 mostra esta continuidade na tomada de decis ao.
Decision Continuity pre(ABC) on(ABC)

before

Usage

After

Attribute Mutability

pre-update

on-update

pos-update

Figura 2.2: Momentos de Avalia ca o dos Predicados Como pode ser visto na gura 2.2, assim como existem momentos diferentes para a verica ca o, existem, tamb em, momentos diferentes para a atualiza ca o de atributos. Atributos do recurso e do sujeito podem ser imut aveis (0, ou modicados antes (1), durante (2) ou ap os (3) o uso (e.g. onA0 , onA1 , onA2 e onA3 ). A combina ca o dos momentos de avalia ca o com os de atualiza ca o gera os 16 modelos centrais do UCONABC , como mostra a tabela 2.1: cada S (sim) indica a exist encia de uma combina ca o no modelo. Tabela 2.1: Os 16 Modelos Centrais do UCONABC 0 (imut avel) 1 (pre-update ) 2 (on-update ) 3 (pos-update ) S S N S S S S S S S N S S S S S S N N N S N N N

preA onA preB onB preC onC

Para avalia co es pre, n ao existe atualiza ca o durante o uso. Isso ocorre porque, como n ao h a avalia co es neste momento (on), qualquer atributo al11

terado somente seria utilizado na pr oxima avalia ca o, antes do pr oximo uso, fazendo com que uma atualiza ca o 2 tenha o mesmo efeito de uma atualiza ca o 3 (ap os o uso). Nota-se, tamb em, que os predicados de condi ca o n ao atualizam atributos, existindo apenas preC0 e onC0 . Isso acontece porque as condi co es s ao avaliadas apenas um fun ca o do sistema, e n ao dos atributos (mas um atributo pode informar qual condi ca o deve ser avaliada).

12

Cap tulo 3 Pol ticas

Uma pol tica de seguran ca 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 ao impostas. Idealmente, a descri ca o das pol ticas deve ser feita utilizando um m etodo formal, pois facilita a sua compreens ao futura e reduz as chances de erros de interpreta ca o e especica ca o, j a que podem ser matematicamente provadas. Mas e importante construir pol ticas que podem ser executadas; n ao faz sentido, por exemplo, criar uma pol tica que dependa da resolu ca 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 em, 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 denir que, caso o sistema seja violado, os objetos protegidos que foram afetados devem ser marcados como n aocon aveis, indicando que estes objetos n ao podem mais ser tratados como ntegros.

3.1

Deni c ao Formal de Pol ticas

Existem v arios projetos para criar formas de se denir formalmente uma pol tica. A seguir ser a apresentada a forma mais simples de se criar uma pol tica com algum rigor matem atico. Neste contexto, as pol ticas ser ao denidas relacionando-se express oes booleanas (i.e. verdadeiro/falso ) constru das a partir de conjuntos de diferentes direitos, sujeitos e objetos. O formato destas express oes ser a: 13

regra : conjunto booleano Pode-se, ent ao, construir express oes como: dono : sujeito objeto booleano acesso : sujeito direito objeto booleano (3.1) (3.2)

Estas express oes podem ser vistas como fun co es que retornam um valor booleano. Por exemplo, a fun ca o dono denida acima poderia retornar verdadeiro para dono(pedro, /tmp/arq.txt ). Express oes mais complexas podem ser criadas, agrupando-se fun co es diferentes: 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 ao utilizadas, para que seja poss vel estabelecer o que e poss vel de se impor, quais informa co es sobre sujeitos e objetos estar ao dispon veis e quais mecanismos poder ao ser empregados.

14

Cap tulo 4 Autentica c ao

Toda prote ca o em controle de acesso depende da capacidade de corretamente identicar os processos e programas e, consequentemente, o usu ario que os executa [SG98]. E preciso, portanto, garantir que esta identica ca o seja aut entica. A autentica ca o baseia-se geralmente na verica ca o de um ou mais dos seguintes tens: 1. algo que o usu ario possui (um cart ao, uma chave, etc); 2. algo que o usu ario sabe (uma senha, um data de nascimento, etc); 3. algo que caracteriza o usu ario (sua impress ao digital, sua retina, seu DNA, etc). O mais comumente empregado destes tens e aquilo que o usu ario sabe, uma senha ou palavra-chave. Mas atualmente e normal encontrar vericadores de impress ao digital ou leitores de cart oes inteligentes (smart-cards ). Senhas s ao armazenadas no sistema e, quando o usu ario requisita um acesso, pede-se que esta informa ca o seja digitada. Se a informa ca o, ao ser comparada com aquela armazenada, for a correta, o usu ario e identicado como leg timo, e recebe uma credencial que o permite acessar o sistema. O principal problema das palavras-chave e a diculdade em mant e-las em segredo. Estas podem ser adivinhadas ou inadvertidamente disponibilizadas. muito comum que pessoas utilizem informa E co es pessoais ou palavras com que elas se relacionam para criar suas senhas. Nomes de c onjuges e animais de estima ca o e palavras presentes em seu cotidiano, entre outras, fazem parte da maioria das senhas, e podem ser facilmente adivinhadas. Al em disso, palavras comuns, encontradas em dicion arios, podem ser comprometidas atrav es de ataques de for ca-bruta, em que todas as palavras e suas varia co es (como trocar a letra i pelo d gito 1 em am1go) s ao testadas. 15

As palavras-chave podem ainda ser conseguidas ao ver o usu ario as digitando (shoulder surng ), ou em anota co es em sua mesa. Em alguns casos, usu arios podem at e mesmo fornecer suas senhas para qualquer pessoa que identique-se como prossional de inform atica ou para ceder sua conta para um colega realizar um servi co mais facilmente. Para evitar problemas como estes, deve-se: 1. garantir que as senhas utilizadas s ao de qualidade e fortes (executar um ataque de dicion ario contra o banco de dados das senhas, n ao permitir que o usu ario escolha palavras comuns e sem caracteres especiais ou que sejam muito curtas, etc); 2. educar usu arios para que n ao emprestem ou informem suas senhas e para que n ao escrevam esta informa ca o; 3. frequentemente vericar os sistemas utilizados para detectar key-loggers e cavalos-de-tr oia.

4.1

UNIX Passwords

Um erro frequentemente encontrado quando fala-se de armazenamento de senhas e a concep ca o que estas senhas s ao armazenadas criptografadas com uma chave, e que algu em em posse desta chave consiga visualizar todas as senhas. Isto s o e verdade em sistemas mal-planejados, e estes sistemas poder ao 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 armazenam senhas, um artif cio matem atico e utilizado. Utiliza-se fun co es matem aticas cujo resultado e muito f acil de calcular, mas que o inverso leva muito tempo para ser computado. Estas fun co es, chamadas de one-way (S o de ida) s ao utilizadas para calcular um valor que e armazenado no lugar da senha. Quando o usu ario envia a sua senha, durante a autentica ca o, esta fun ca o e novamente utilizada para calcular o valor resultante deste dado. Se o resultado desta fun ca o for o mesmo para a senha digitada e para aquela armazenada, o usu ario e autenticado. Por em, palavras-chave armazenadas desta forma ainda podem ser encontradas atrav es de um ataque de dicion ario. Um cracker pode calcular o resultado da fun ca o one-way para um dicion ario com milhares de palavras e comparar os resultados com um arquivo de senha. 16

Para dicultar este tipo de ataque, adiciona-se a ` palavra-chave uma seq u encia aleat oria de caracteres, chamada de salt , antes de aplicar a fun ca o one-way, e armazena-se estes caracteres junto com o resultado no banco de dados. Se o salt for sucientemente longo e variado, um ataque de dicion ario seria praticamente inviabilizado devido ao tempo para se computar um dicion ario com todos os caracteres aleat orios poss veis para cada palavra, e devido tamb em ao grande espa co necess ario para armazenar os resultados. Um salt de 4 caracteres entre 0-9 e a-Z (60 valores) resultaria em 12.960.000 mais f diferentes resultados para cada palavra do dicion ario. E acil calcular o dicion ario utilizando-se apenas os valores aleat orios encontrados no banco de dados, mas assim perde-se a vantagem de se poder utilizar o mesmo dicion ario para v arios ataques, e aumenta muito o tempo de cada ataque.

4.2

Single Sign-On

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

4.2.1

Kerberos

Kerberos e um protocolo que prov e uma autentica ca o segura em rede, permitindo que um usu ario ou processo acesse diversos servi cos realizando apenas uma autentica ca o. Este protocolo e baseado em criptograa sim etrica, e compartilha uma chave secreta com cada entidade (clientes e servidores) na rede; conhecimento desta chave secreta e prova de identidade. 17

Figura 4.1: Passos de autentica ca o no Kerberos (Extra da de [Sch96]

O servi co Kerberos guarda um banco de dados de todos os clientes e suas chaves secretas. Servi cos que requerem autentica ca o, e os clientes que desejam acessar estes servi cos, registram suas chaves secretas no Kerberos. Para um usu ario, esta chave secreta poderia ser um password criptografado. Como o Kerberos conhece a chave de todos os clientes e servidores, este servi co pode criar mensagens que garantem a identica ca o de uma entidade para outra. Pode tamb em gerar chaves de sess ao, que s ao entregues apenas para as entidades envolvidas em uma comunica ca o, que s ao utilizadas para criptografar mensagens trocadas, e que s ao destru das quando a sess ao acaba. A gura 4.1 mostra os passos envolvidos em um acesso com Kerberos. Primeiramente, o cliente solicita uma credencial (ticket) para acessar o TicketGranting Service (TGS). Este ticket e 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 ao, este ticket e um autenticador para o servidor, que os verica e concede o acesso. Para entender as mensagens trocadas, s ao apresentadas na tabela 4.1 as abrevia co es utilizadas na descri ca o matem atica. Credenciais O Kerberos utiliza dois tipos de credenciais, tickets e autenticadores. Um ticket e utilizado para, de maneira segura, passar a identidade de seu portador v para um servidor. E alido apenas para um cliente utiliz a-lo em conjunto 18

Tabela c s a v t Kx Kx,y {m}Kx Tx,y Ax,y

4.1: Tabela de Abrevia co es (Extra da de [Sch96]) cliente servidor endere co de rede do cliente in cio e t ermino do tempo de validade de um ticket timestamp chave secreta de x chave de sess ao para x e y m criptografado com a chave secreta de x ticket de x para acessar y autenticador de x para y

com um servidor, sendo que o ticket possui informa co es que permitem ao servidor assegurar que seu portador e 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 ao contidos o nome e endere co do cliente, o nome do servidor, um intervalo de validade e a chave de sess ao. V arias dessas informa co es est ao criptografadas com a chave do servidor. Esta credencial pode ser utilizada quantas vezes forem necess arias, dentro do prazo de validade. Um autenticador, por sua vez, e representado por: Ac,s = {c, t, key}Kc,s O autenticador enviado pelo cliente cont em o seu nome, um timestamp e um segunda chave de sess ao opcional. Esses dados s ao criptografados com a chave de sess ao Kc,s . Diferente de um ticket, um autenticador pode ser utilizado para acessar um servi co apenas uma vez, mas o cliente pode gerar quantos autenticadores forem necess arios, dentro do prazo de validade da chave de sess ao. Como o autenticador cont em 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 em disso, o timestamp garante que um ataque de replay n ao seja poss vel. Mensagens trocadas no Kerberos Como visto na gura 4.1, s ao cinco mensagens1 no total:
1

Apenas o Kerberos vers ao 5 ser a apresentado.

19

1. 2. 3. 4. 5.

Cliente para Kerberos: Kerberos para Cliente: Cliente para TGS: TGS para Cliente: Cliente para Servidor:

c, tgs {Kc,tgs }Kc , {Tc,tgs }Ktgs {Ac,s }Kc,tgs , {Tc,tgs }Ktgs {Kc,s }Kc,tgs , {Tc,s}Ks {Ac,s }Kc,s , {Tc,s}Ks

A chave secreta do cliente Kc e o resultado de uma fun ca o one-way sobre o seu password. Como o servidor Kerberos tem o registro de todos os usu arios, ele j a possui esta informa ca o. O password do usu ario nunca e transmitido na rede.

20

Refer encias Bibliogr acas

[Amo94] Edward G. Amoroso. Fundamentals of computer security technology. Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1994. [BL76] D.E. Bell and L. LaPadula. Secure computer systems: Unied exposition and multics interpretation. Technical report, MITRE Corporation, Massachusetts, USA, March 1976.

[Lam74] Butler W. Lampson. Protection. SIGOPS Operating System Review, 8(1):1824, 1974. [PS03] Jaehong Park and Ravi Sandhu. Usage control: A vision for next generation access control. In Vladimir Gorodetsky, Leonard 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 Computer Science, pages 1731. Springer, 2003. Jaehong Park and Ravi Sandhu. The U CONABC usage control model. ACM Transactions on Information and System Security, 7(1):128174, 2004. Bruce Schneier. Applied cryptography: protocols, algorithms, and source code in C. Wiley, Inc., New York, NY, USA, 2nd edition, 1996.

[PS04]

[Sch96]

[SFK00] Ravi Sandhu, David Ferraiolo, and Richard Kuhn. The NIST model for role-based access control: towards a unied standard. In RBAC 00: Proceedings of the fth ACM workshop on Role-based access control, pages 4763, New York, NY, USA, 2000. ACM Press. [SG98] Abraham Silberschatz and Peter Galvin. Operating systems concepts. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 5th edition, 1998.

21

 Indice Remissivo
restrito, 9 amea ca, 4 sim etrico, 9 nega ca o de servi co, 3, 4 modelo tipos de, 4 Bell-LaPadula, 7 vazamento de informa co es, 4 Biba, 8 viola ca o de integridade, 4 matriz de acesso, 6 ataque, 4 monitor de refer encia, 5 autentica ca o, 15 single sign-on, 17 n ao-rep udio, 3 fun co es one-way, 16 kerberos, 17 pol ticas, 4, 13 credenciais, 18 deni ca o formal de, 13 mensagens do protocolo, 18, 19 problemas, 15 seguran ca UNIX passwords, 16 safety, 3 autenticidade, 3 security, 3 condencialidade, 3 criptograa salt, 17 de passwords, 16 fun co es one-way, 16 disponibilidade, 3 integridade, 3 mecanismos de seguran ca, 4, 5 Capabilities, 7 ACL, 7 DAC, 5, 7 MAC, 5, 8 RBAC, 5, 8 b asico, 8 hier arquico, 9 22 TCB, 5 UCON, 9 vulnerabilidade, 4