( PDF ) Modelo de gerência para o SPKI através do XKMS

Download PDF

ads:

JOSIANE MILANEZ

MODELO DE GER

ENCIA PARA O SPKI ATRAV

DO XKMS

FLORIAN

OPOLIS

2005

ads:

Livros Grátis

http://www.livrosgratis.com.br

Milhares de livros grátis para download.

UNIVERSIDADE FEDERAL DE SANTA CATARINA

CURSO DE P

OS-GRADUAC¸

AO EM ENGENHARIA EL

ETRICA

MODELO DE GER

ENCIA PARA O SPKI ATRAV

DO XKMS

Dissertac¸

ao submetida

Universidade Federal de Santa Catarina

como parte dos requisitos para a

obtenc¸

ao do grau de Mestre em Engenharia El

etrica.

JOSIANE MILANEZ

Florian

opolis, Outubro de 2005.

ads:

MODELO DE GER

ENCIA PARA O SPKI ATRAV

ES DO

XKMS

Josiane Milanez

‘Esta Dissertac¸

ao foi julgada adequada para a obtenc¸

ao do t

ıtulo de Mestre em Engenharia

etrica,

Area de Concentrac¸

ao em Controle, Automac¸

ao e Inform

atica Industrial, e

aprovada em sua forma ﬁnal pelo Programa de P

os-Graduac¸

ao em Engenharia El

etrica da

Universidade Federal de Santa Catarina.’

Joni da Silva Fraga, Dr.

Orientador

Nelson Sadowski, Dr.

Coordenador do Programa de P

os-Graduac¸

ao em Engenharia El

etrica

Banca Examinadora:

Joni da Silva Fraga, Dr.

Presidente

Michelle Silva Wangham, Dr.

Altair Olivo Santin, Dr.

Carla Merkle Westphal, Dr.

Ricardo Jos

e Rabelo, Dr.

Para Odete Steiner Milanez, minha m

ae.... . .

iii

AGRADECIMENTOS

Agradec¸o

a Deus, meus pais, pela vida.

Agradec¸o meu orientador Joni e minha co-orientadora Michelle, pela enorme ajuda.

Agradec¸o ao Emerson Mello a ajuda na deﬁnic¸

ao do algoritmo de buscas de certiﬁcados.

Agradec¸o tamb

em aos bolsistas Laura Carrijo e Rafael Deitos e a todos que tornaram poss

ıvel a

realizac¸

ao deste mestrado.

Agradec¸o principalmente aos familiares, meus amigos e amigas pela paci

encia comigo durante

este per

ıodo.

Resumo da Dissertac¸

ao apresentada

a UFSC como parte dos requisitos necess

arios para obtenc¸

ao do

grau de Mestre em Engenharia El

etrica.

MODELO DE GER

ENCIA PARA O SPKI ATRAV

ES DO

XKMS

Josiane Milanez

Outubro/2005

Orientador: Joni da Silva Fraga, Dr.

Area de Concentrac¸

ao: Controle, Automac¸

ao e Inform

atica Industrial

Palavras-chave: Federac¸

oes SPKI, XKMS, Seguranc¸a Computacional, Sistemas Distribu

ıdos

umero de P

aginas: xi + 67

O prop

osito do XML Key Management Speciﬁcation (XKMS)

e facilitar o gerenciamento da

PKI, transferindo a complexidade da mesma para um servic¸o web de conﬁanc¸a. Os servic¸os

web formam uma tecnologia emergente e promissora para a automatizac¸

ao de interac¸

oes

inter-organizacionais. Estes servic¸os, fornecem um n

ıvel de abstrac¸

ao para diferentes pla-

taformas e linguagens de programac¸

ao, permitindo que sistemas de organizac¸

oes diferentes

se comuniquem de forma aberta, atrav

es de padr

oes de facto como o XML e o HTTP. En-

tretanto, o XKMS est

a fortemente focado na PKI X.509 que deﬁne um modelo hier

arquico

de conﬁanc¸a baseado na nomenclatura do X.500. Estes modelos apresentam efeitos nega-

tivos devido a esta centralizac¸

ao como a escalabilidade limitada e a falta de ﬂexibilidade,

indispens

aveis em ambientes distribu

ıdos de larga escala. O SPKI, se mostra mais adequado

a estes sistemas comparado ao X.509. Esta PKI est

a baseada em uma estrutura de nomes

locais e um modelo simples de autorizac¸

ao, baseado em redes de conﬁanc¸a. Este trabalho

prop

oe um modelo de ger

encia para o SPKI atrav

es do XKMS. S

ao apresentadas as princi-

pais facilidades providas pelo modelo proposto, como auxiliar na localizac¸

ao de certiﬁcados

de autorizac¸

ao para construir os caminhos ligando o cliente ao servidor. Um algoritmo

proposto para a localizac¸

ao destes certiﬁcados e um prot

otipo

e implementado e integrado a

uma aplicac¸

ao de forma a validar o modelo proposto.

Sum

ario

1 Introduc¸

ao 1

1.1 Motivac¸

ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Organizac¸

ao do Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Seguranc¸a em Sistemas Distribu

ıdos 4

2.1 Introduc¸

ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Seguranc¸a Computacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Ameac¸as, Ataques e Vulnerabilidades a Sistemas Distribu

ıdos . . . . . . . . . . . . 5

2.4 Pol

ıticas de Seguranc¸a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.5 Mecanismos de Seguranc¸a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.5.1 Autenticac¸

ao e autorizac¸

ao . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.5.2 Controles criptogr

aﬁcos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.5.3 Controles de acesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.6 Autenticac¸

ao e Autorizac¸

ao em Sistemas Distribu

ıdos . . . . . . . . . . . . . . . . . 9

2.6.1 Abordagem Centralizada da Autenticac¸

ao e da Autorizac¸

ao . . . . . . . . . 9

2.6.2 Abordagem de Autenticac¸

ao Centralizada e de Autorizac¸

ao Descentralizada . 9

2.6.3 Controle Descentralizado da Autenticac¸

ao e da Autorizac¸

ao . . . . . . . . . 10

2.7 Estudo de Casos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.7.1 Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.7.2 X.509 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.7.3 SPKI/SDSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.7.4 Federac¸

oes SPKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.8 Conclus

ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Seguranc¸a atrav

es do XML e Servic¸os Web 19

3.1 Introduc¸

ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 XML Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3 XML Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3.1 Cen

arios de Cifragem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4 XACML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.4.1 Regras em XACML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.4.2 Pol

ıticas em XACML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.4.3 Fluxo de dados no modelo e XACML . . . . . . . . . . . . . . . . . . . . . 25

3.5 SAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.5.1 Arquitetura SAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.5.2 A SAML e outros padr

oes e iniciativas . . . . . . . . . . . . . . . . . . . . 28

3.6 XKMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.6.1 Especiﬁcac¸

ao XML do Servic¸o de Informac¸

ao de Chaves (X-KISS) . . . . . 30

3.6.2 Especiﬁcac¸

ao XML do servic¸o de Registro de Chaves (X-KRSS) . . . . . . 31

3.6.3 Protocolos de Trocas de Mensagens . . . . . . . . . . . . . . . . . . . . . . 31

3.7 Servic¸os Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.7.1 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.7.2 WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.7.3 UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.7.4 WS Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.8 Conclus

ao do Cap

ıtulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

vii

4 Modelo de ger

encia para o SPKI atrav

es do XKMS 40

4.1 Introduc¸

ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2 Gerenciamento Federado do SPKI atrav

es do XKMS . . . . . . . . . . . . . . . . . 41

4.3 Processo de Filiac¸

ao e de Registro de certiﬁcados no reposit

orio da Federac¸

ao . . . . 43

4.4 Provendo suporte as Teias de Federac¸

oes SPKI . . . . . . . . . . . . . . . . . . . . 44

4.5 Algoritmo de Busca de Certiﬁcados nas Teias de Federac¸

oes . . . . . . . . . . . . . 47

4.6 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.7 Conclus

ao do Cap

ıtulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5 Implementac¸

ao 54

5.1 Introduc¸

ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.2 Arquitetura do Prot

otipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.2.1 Camada de transporte, mensagens e descric¸

ao . . . . . . . . . . . . . . . . . 55

5.2.2 Infra-estrutura SPKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.2.3 Qualidade de Servic¸o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.2.4 XKMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.3 Integrac¸

ao do Prot

otipo a uma Aplicac¸

ao Distribu

ıda . . . . . . . . . . . . . . . . . 61

5.4 Considerac¸

oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.5 Conclus

ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6 Conclus

oes 65

viii

Lista de Figuras

2.1 Ataques de seguranc¸a (Stallings, 2000) . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Certiﬁcado X.509 vers

ao 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 Modelo de conﬁanc¸a estendido do SPKI/SDSI . . . . . . . . . . . . . . . . . . . . . 16

2.5 Teias de federac¸

oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Enveloped XML Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Enveloping XML Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3 Detached Signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4 Exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.5 Cifragem de um elemento XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.6 Cifragem do conte

udo de um elemento XML . . . . . . . . . . . . . . . . . . . . . 23

3.7 Cifragem de um dado qualquer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.8 Modelo de Fluxo de dados (Moses, 2005) . . . . . . . . . . . . . . . . . . . . . . . 26

3.9 Cen

ario SSO - Identidade Federada . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.10 Ligac¸

ao entre contas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.11 Componentes SAML (Hughes e Maler, 2004) . . . . . . . . . . . . . . . . . . . . . 29

3.12 Interface ao PKI (O’Neill, 2003) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.13 Processamento S

ıncrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.14 Processamento Ass

ıncrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.15 Protocolo de Duas Fases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.16 Mensagem SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.17 Descric¸

ao abstrata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.18 Descric¸

ao concreta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.19 Estrutura de dados de um registro UDDI (Clement et al., 2004) . . . . . . . . . . . . 36

4.1 Elementos da Federac¸

ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2 Gerenciamento Federado do SPKI atrav

es do XKMS . . . . . . . . . . . . . . . . . 43

4.3 Teias de Federac¸

oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.4 Cen

ario de busca de certiﬁcados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.5 Operac¸

oes do Servic¸o XKMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.6 Algoritmo de busca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.1 Arquitetura do Prot

otipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.2 Extens

ao do XML Signature Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.3 Diagrama de Seq

encia de Localizac¸

ao . . . . . . . . . . . . . . . . . . . . . . . . 59

5.4 Diagrama de Seq

encia de Validac¸

ao . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.5 Cen

ario de Registro 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.6 Din

amica da aplicac¸

ao (de Melo et al., 2004) . . . . . . . . . . . . . . . . . . . . . 61

5.7 Retorno da busca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.8 Opc¸

ao de localizac¸

ao no reposit

orio da Federac¸

ao SPKI . . . . . . . . . . . . . . . . 62

Lista de Tabelas

3.1 Modelo de Fluxo de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1 Subelementos do ds:SPKISexp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Cap

ıtulo 1

Introduc¸

A Internet prov

e uma poderosa infra-estrutura de comunicac¸

ao, que com seu crescimento t

impulsionado a demanda por aplicac¸

oes distribu

ıdas. Entretanto, a interac¸

ao entre estas aplicac¸

oes

advindas de organizac¸

oes diferentes torna-se uma tarefa dif

ıcil, j

a que cada organizac¸

ao utiliza os mais

diferentes tipos de hardware bem como s

ao usadas as mais diversas linguagens de desenvolvimento.

A arquitetura orientada a servic¸os (AOS) concentra-se no fraco acoplamento e ligac¸

ao din

amica

entre servic¸os, onde estes podem ser: aplicativos, informac¸

oes e outros recursos de TI (Weerawa-

rana et al., 2005). Atrav

es deste fraco acoplamento e ligac¸

ao din

amica de servic¸os, a AOS permite

uma r

apida integrac¸

ao entre servic¸os podendo mistur

a-los e combin

a-los de diferentes formas, cri-

ando assim ﬂex

ıveis processos de neg

ocios. Como benef

ıcios desta arquitetura destacam-se: (1) uma

diminuic¸

ao de tempos de ciclo de desenvolvimento e implementac¸

ao utilizando servic¸os reutiliz

aveis,

(2) facilidades de integrac¸

ao entre estes servic¸os, (3) automatizac¸

ao de transac¸

oes usuais (como

localizac¸

ao de servic¸os, por exemplo), al

em de (4) facilidades nas interac¸

oes inter-organizacionais.

Os servic¸os Web, uma tecnologia emergente e promissora para a automatizac¸

ao destas interac¸

oes

inter-organizacionais baseada na AOS, fornece um n

ıvel de abstrac¸

ao para diferentes plataformas e

linguagens de programac¸

ao. Estes servic¸os tamb

em permitem que sistemas de organizac¸

oes diferen-

tes se comuniquem de forma aberta, atrav

es de padr

oes de facto como o XML e o HTTP.

arios padr

oes de seguranc¸a como XML Signature(Bartel, 2002), XML Encryption(Imamura,

2002), SAML(Cantor et al., 2005), entre outros, s

ao utilizados para prover seguranc¸a ao XML e

aos servic¸os Web. Estes padr

oes est

ao fundamentados em PKIs na manipulac¸

ao de chaves p

ublicas e

emiss

ao de certiﬁcados. Dentre estas PKIs podem ser citadas: X.509, PGP e SPKI.

1.1 Motivac¸

O prop

osito do XML Key Management Speciﬁcation (XKMS)

e facilitar o gerenciamento de PKIs,

abstraindo a sua complexidade dos usu

arios. Para isso, a especiﬁcac¸

ao XKMS deﬁne um servic¸o

Web de conﬁanc¸a, respons

avel pelo gerenciamento da PKI. Sendo assim, a complexidade da PKI

1. Introduc¸

ao 2

transferida da aplicac¸

ao para um servic¸o Web, poupando a mesma da necessidade de gerenciamento

da PKI utilizada. As informac¸

oes e operac¸

oes envolvendo a PKI ﬁcam acess

ıveis atrav

es de um

protocolo padr

ao, independendo da tecnologia de seguranc¸a usada.

O XKMS est

a fortemente focado na PKI X.509 que deﬁne um modelo hier

arquico e centrali-

zado de conﬁanc¸a baseado na nomenclatura do X.500. Entretanto, estes modelos apresentam efeitos

negativos devidos a esta centralizac¸

ao. As diﬁculdades nestes modelos, normalmente citadas, s

ao a

escalabilidade limitada e a falta de ﬂexibilidade, indispens

aveis em ambientes distribu

ıdos de larga

escala.

a os modelos de autenticac¸

ao e autorizac¸

ao distribu

ıda n

ao apresentam este problema. A

SPKI/SDSI (Simple Public Key Infrastructure/Simple Distributed Security Infrastructure) (Rivest e

Lampson, 1996) (Ellison et al., 1999)

e uma infra-estrutura de seguranc¸a baseada em chaves p

ublicas

que segue esta abordagem e teve seu desenvolvimento motivado devido a complexidade e imperfeic¸

das infra-estruturas de chaves p

ublicas baseadas em uma hierarquia de nomes globais, como o X.509.

O SPKI/SDSI tem um modelo igualit

ario, no qual, os principais s

ao chaves p

ublicas e cada chave

ublica pode divulgar e assinar certiﬁcados (Clarke, 2001). Como o SPKI trabalha com uma estru-

tura de nomes locais, sua implementac¸

ao torna-se mais simples, quando comparado ao X.509. Entre-

tanto, o esquema de autorizac¸

ao do SPKI imp

oe restric¸

oes

a localizac¸

ao de um determinado direito

porque n

ao oferece nenhum mecanismo atrav

es do qual seja poss

ıvel buscar principais detentores de

certiﬁcados com o direito de acesso desejado (Santin, 2004).

Em (Santin, 2004) foi proposta uma extens

ao do modelo de conﬁanc¸a do SPKI/SDSI chamada

Federac¸

ao SPKI, que

e uma entidade que re

une principais com interesses aﬁns e atua como um agente

facilitador na localizac¸

ao de certiﬁcados e principais, pois permite o compartilhamento do acesso

ao seu reposit

orio de certiﬁcados. Atrav

es deste compartilhamento, os clientes passam a ter uma

alternativa a recorrer quando da falta de cadeias apropriadas para o acesso desejado.

Por

em, este modelo de ger

encia ao preservar a ﬁlosoﬁa adotada no modelo SPKI/SDSI, no qual o

principal que deseja obter acesso a algum recurso

e inteiramente respons

avel pela busca das cadeias

de certiﬁcados que lhe fornec¸am o direito de acesso, sobrecarrega o cliente. Al

em disso, este modelo

ao prov

e um protocolo padr

ao de acesso as func¸

oes de gerenciamento e estabelecimento de conﬁanc¸a

providos pelo mesmo.

1.2 Objetivos

O objetivo deste trabalho

e propor uma extens

ao ao modelo de Federac¸

oes SPKI proposta em

(Santin, 2004) atrav

es de servic¸os XKMS. O modelo aqui proposto oferece um esquema alternativo

para a criac¸

ao de cadeias de autorizac¸

ao ligando um cliente a um servidor de forma padronizada.

Neste modelo, a responsabilidade pela localizac¸

ao de cadeias de autorizac¸

e transferida para o

servic¸o XKMS, que tamb

e o respons

avel pelo gerenciamento de conﬁanc¸a entre os membros e

associados da Federac¸

ao.

1. Introduc¸

ao 3

Para que este objetivo seja atingido

e necess

aria uma integrac¸

ao do SPKI com o XKMS, o que

e uma tarefa f

acil, j

a que o XKMS

e fortemente focado no X.509. Tamb

e necess

aria a criac¸

de um novo algoritmo para a localizac¸

ao de cadeias de autorizac¸

ao que liga um cliente a um servidor.

Pretende-se tamb

em comprovar a aplicabilidade deste modelo em ambientes distribu

ıdos de larga

escala. A partir das perspectivas citadas, o projeto de pesquisa perseguiu os seguintes objetivos es-

pec

ıﬁcos:

• Deﬁnir um modelo de gerenciamento federado para o SPKI.

• Propor um algoritmo ﬂex

ıvel para a localizac¸

ao de cadeias de autorizac¸

ao.

• Deﬁnir e implementar um prot

otipo que inclui o modelo de gerenciamento federado e o algo-

ritmo de localizac¸

ao.

• De forma a comprovar a aplicabilidade deste modelo, integrar o prot

otipo a uma aplicac¸

distribu

ıda.

1.3 Organizac¸

ao do Texto

Este cap

ıtulo descreveu o contexto geral, a motivac¸

ao e os objetivos da dissertac¸

ao, sendo que os

oximos cap

ıtulos encontram-se assim divididos:

O cap

ıtulo 2 apresenta os fundamentos sobre seguranc¸a computacional, dentre estes est

ao as

pol

ıticas e os mecanismos de seguranc¸a. Por ﬁm, os modelos apresentados s

ao comparados.

O cap

ıtulo 3 descreve as especiﬁcac¸

oes de seguranc¸a para a Extensible Markup Language (XML),

tais como: XML Signature, XML Encryption, SAML, XACML e XKMS. Al

em das especiﬁcac¸

oes de

seguranc¸a em XML, ser

ao descritos os conceitos de servic¸os Web e as especiﬁcac¸

oes para seguranc¸a

destes servic¸os, tais como: WS-Security, WS-Policy, WS-Trust, WS-SecureConversation e WS-Federation.

O cap

ıtulo 4 apresenta um modelo proposto de gerenciamento para o SPKI atrav

es do XKMS.

Este modelo

e uma extens

ao das Federac¸

ao SPKI. Tamb

em ser

a apresentado como a Teia de Federac¸

oes

e formada e o algoritmo de localizac¸

ao de certiﬁcados pelas Teias de Federac¸

oes atrav

es do XKMS.

O Cap

ıtulo 5 apresenta uma descric¸

ao detalhada do prot

otipo implementado, descrevendo as fer-

ramentas utilizadas, os cen

arios de aplicac¸

ao e as considerac¸

oes sobre os resultados encontrados.

No cap

ıtulo 6 s

ao feitas conclus

ao sobre o texto e tamb

em ser

ao expostos os trabalhos futuros.

Cap

ıtulo 2

Seguranc¸a em Sistemas Distribu

ıdos

2.1 Introduc¸

A evoluc¸

ao da inform

atica e das redes de computadores tem aumentado o uso de sistemas compu-

tacionais nas organizac¸

oes e, em geral na vida das pessoas. O barateamento de alguns recursos como

hardware e meios de comunicac¸

ao t

em contribu

ıdo para expandir o desenvolvimento e utilizac¸

ao de

sistemas distribu

ıdos.

Juntamente com este aumento, surge a preocupac¸

ao com a seguranc¸a destes sistemas para garantir,

por exemplo, que n

ao haja interfer

encia indevida entre o envio e o recebimento das mensagens, ou

mesmo reservando recursos apenas

a entidades autorizadas. Uma entidade, tamb

em chamada de

principal, pode ser um usu

ario, um processo ou ainda uma m

aquina em uma rede de computadores.

Neste cap

ıtulo ser

ao discutidos alguns aspectos da seguranc¸a computacional em sistemas dis-

tribu

ıdos. Ser

ao revisados os conceitos fundamentais, as pol

ıticas de seguranc¸a, as t

ecnicas nas quais

os mecanismos de seguranc¸a est

ao baseados e as abordagens de implementac¸

ao dos mecanismos de

autenticac¸

ao e de autorizac¸

ao.

2.2 Seguranc¸a Computacional

Um sistema computacional

e seguro se atende

as propriedades b

asicas de seguranc¸a. Conforme a

literatura, estas propriedades de seguranc¸a s

ao (Landwehr, 2001):

• Conﬁdencialidade: assegura que as informac¸

oes n

ao ser

ao reveladas a pessoas que n

ao tenham

acesso autorizado.

• Integridade: assegura que as informac¸

oes n

ao ser

ao modiﬁcadas por pessoas sem acesso au-

torizado.

• Disponibilidade: assegura que as informac¸

oes estar

ao sempre dispon

ıveis

a usu

arios leg

ıtimos.

2. Seguranc¸a em Sistemas Distribu

ıdos 5

A violac¸

ao das propriedades de conﬁdencialidade, integridade e disponibilidade s

ao chamadas

de revelac¸

ao n

ao-autorizada ou vazamento de informac¸

ao, modiﬁcac¸

ao n

ao autorizada e negac¸

ao de

servic¸o, respectivamente.

Outras propriedades podem ser adicionadas a estas citadas (Landwehr, 2001):

• Autenticidade: assegura que cada principal

e realmente quem diz ser.

• N

ao repudiac¸

ao: assegura que um emissor ou receptor de uma comunicac¸

ao n

ao possa neg

a-la

posteriormente.

2.3 Ameac¸as, Ataques e Vulnerabilidades a Sistemas Distribu

ıdos

Uma vulnerabilidade

e um erro em um sistema de computadores (Landwehr, 2001), sendo este um

erro de programac¸

ao, conﬁgurac¸

ao ou ainda de operac¸

ao. Uma ameac¸a pode ser deﬁnida como um

conjunto de ac¸

oes que fornec¸am potencial violac¸

ao das propriedades de seguranc¸a (Bishop, 2003). Ou

seja,

e uma intenc¸

ao de causar danos em um sistema, que podem comprometer a conﬁdencialidade,

integridade e disponibilidade.

Quando uma violac¸

ao da seguranc¸a ocorre atrav

es de uma ac¸

ao, esta ac¸

e chamada de ataque.

O ataque consiste na explorac¸

ao de alguma vulnerabilidade do sistema, que se bem sucedido, causa

danos ao mesmo.

Ataques de seguranc¸a em uma rede ou sistema de computadores podem ser caracterizados anali-

sando o ﬂuxo de informac¸

ao de uma fonte, como um arquivo ou uma regi

ao de mem

oria principal,

de uma m

aquina para um destino, que pode ser um outro arquivo ou usu

ario. Conforme pode ser

veriﬁcado na Figura 2.1, existem quatro categorias gerais de ataques (Stallings, 2000):

• Interrupc¸

ao: Um bem (asset) do sistema

e destru

ıdo ou se torna indispon

ıvel ou inutiliz

avel.

Este

e um ataque contra a disponibilidade. Este bem pode ser uma parte do hardware, o corte

na linha de comunicac¸

ao ou a desabilitac¸

ao do gerenciamento do sistema.

• Interceptac¸

ao: Um principal n

ao autorizado obt

em acesso a informac¸

ao. Este

e um ataque

contra a conﬁdencialidade.

• Modiﬁcac¸

ao: Um principal n

ao autorizado ganha acesso a um bem e o modiﬁca. Este

e um

ataque contra a integridade. Exemplos incluem trocas de valores em um arquivo, alterac¸

ao de

um programa que passa a executar de forma diferente, modiﬁcando o conte

udo de mensagens

transmitidas na rede.

• Personiﬁcac¸

ao: Um principal n

ao autorizado insere objetos falsiﬁcados no sistema. Este

e um

ataque contra a autenticidade.

Para um sistema ser denominado seguro

e necess

ario corrigir os pontos vulner

aveis, diminuindo

assim, o risco de ataques. Entretanto, esta correc¸

ao n

e f

acil, principalmente em sistemas mais

complexos que tendem a apresentar maior n

umero de vulnerabilidades.

2. Seguranc¸a em Sistemas Distribu

ıdos 6

origem destino

Interceptação

origem destino

Interrupção

origem destino

Modificação

origem destino

Personificação

origem destino

Fluxo Normal

Figura 2.1: Ataques de seguranc¸a (Stallings, 2000)

2.4 Pol

ıticas de Seguranc¸a

Uma pol

ıtica

e um simples conjunto de regras deﬁnidas para ir ao encontro de um objetivo princi-

pal, neste caso, a seguranc¸a de um computador ou da informac¸

ao que este processa (Landwehr, 2001).

Estas regras s

ao espec

ıﬁcas para cada sistema. As pol

ıticas de seguranc¸a de sistemas diferem em tr

ramos: seguranc¸a f

ısica, seguranc¸a administrativa e seguranc¸a l

ogica (Nicomette, 1996).

• Pol

ıtica F

ısica: ocupa-se em proteger o meio f

ısico em que opera o sistema. Nestas pol

ıticas

ao deﬁnidas medidas contra desastres, como por exemplo: inc

endios, alagamentos, terremotos,

entre outros. Tamb

em s

ao deﬁnidas medidas para proteger o acesso f

ısico ao provedor do

sistema, fornecendo meios de proibir o acesso de pessoas n

ao autorizadas. No caso de sistemas

distribu

ıdos, as pol

ıticas f

ısicas n

ao s

ao muito eﬁcazes, j

a que existem muitos pontos de acesso

ao sistema.

• Pol

ıtica Administrativa: ocupa-se em proteger o sistema sob o ponto de vista organizacional.

Deﬁne o modo atrav

es do qual, os respons

aveis pela seguranc¸a dos sistemas informatizados s

selecionados e os modos de como criar e manter as pol

ıticas de seguranc¸a.

• Pol

ıtica L

ogica: ocupa-se em proteger os controles de acesso l

ogico ao sistema. Estes controles

de acesso deﬁnem ”quem”tem acesso a ”que”e em ”quais”circunst

ancias. Esta pol

ıtica pode ser

decomposta em pol

ıticas de autenticac¸

ao, em que o usu

ario necessita se identiﬁcar para obter

o acesso ao recurso e pol

ıticas de autorizac¸

ao em que o usu

ario precisa provar que possui

direitos sobre o recurso o qual ele deseja acessar.

2. Seguranc¸a em Sistemas Distribu

ıdos 7

2.5 Mecanismos de Seguranc¸a

Mecanismos de seguranc¸a s

ao as implementac¸

oes das pol

ıticas expressas pelos modelos de segu-

ranc¸a. Para isso, os mecanismos fazem uso dos controles de acesso e controles criptogr

aﬁcos.

Em 1985, foi deﬁnido pelo Departamento de Defesa dos EUA (DoD) o conceito de Base Compu-

tacional de Seguranc¸a ou TCB (Trust Computing Base) como um conjunto que cont

em os elementos

do sistema respons

aveis pelo suporte

as pol

ıticas de seguranc¸a (Department of Defense, 1985). Este

conjunto inclui hardware, software e ﬁrmware

ıticos. Um TCB

e composto por um n

ucleo de

seguranc¸a, que implementa o conceito de monitor de refer

encia (respons

avel por aplicar o controle

de acesso) e tamb

em pelos controles adicionais, como os controles criptogr

aﬁcos entre outros.

2.5.1 Autenticac¸

ao e autorizac¸

A autenticac¸

ao consiste em um conjunto de procedimentos e mecanismos que permitem a um

sistema computacional assegurar que a identiﬁcac¸

ao de um principal esteja correta. Um exemplo de

autenticac¸

e a identiﬁcac¸

ao de um principal atrav

es de um nome de usu

ario (login) e uma senha.

Existem tamb

em outras maneiras de provar a identiﬁcac¸

ao de um principal, como cart

oes magn

eticos

(smartcards), ou atrav

es do reconhecimento de caracter

ısticas f

ısicas, por exemplo: impress

ao digital

ıris.

Nos sistemas distribu

ıdos, o servic¸o de autenticac¸

ao preocupa-se tamb

em em assegurar a autenticac¸

utua dos parceiros da comunicac¸

ao. Esta preocupac¸

ao se faz necess

aria para que os indiv

ıduos se

assegurem da identidade dos envolvidos no processo da troca de informac¸

oes. Al

em da autenticac¸

utua tamb

em existe a necessidade da autenticac¸

ao dos dados, tornando poss

ıvel provar a identidade

da origem da mensagem.

A autorizac¸

e o processo que controla quais recursos e operac¸

oes o principal autenticado ter

permiss

ao de acesso. Esses recursos incluem arquivos, bancos de dados, tabelas, entre outros. No

caso de um sistema multi-usu

ario, o administrador do sistema deﬁne quais usu

arios ter

ao permiss

para acessar algum recurso do sistema. Sendo assim, somente os usu

arios com os devidos direitos

especiﬁcados poder

ao acessar os recursos protegidos.

O monitor de refer

encia consulta uma base de dados com as informac¸

oes de pol

ıticas de autorizac¸

para determinar se a demanda de um principal est

a autorizada ou n

ao no sistema. As pol

ıticas nesta

base de dados s

ao deﬁnidas e mantidas por um administrador de seguranc¸a. (Sandhu e Samarati,

1994).

2.5.2 Controles criptogr

aﬁcos

Os controles criptogr

aﬁcos s

ao usados em v

arios n

ıveis de um sistema distribu

ıdo, envolvendo

a conﬁdencialidade, a integridade, a autenticidade e o n

ao rep

udio nestes sistemas. Os algoritmos

Programac¸

ao em hardware; programa ou dados de computador que s

ao armazenados permanentemente em um chip de

mem

oria de hardware, como uma ROM ou EPROM.

2. Seguranc¸a em Sistemas Distribu

ıdos 8

criptogr

aﬁcos usados podem ser sim

etricos ou assim

etricos. Um algoritmo sim

etrico utiliza a mesma

chave para cifrar e decifrar mensagens. J

a o assim

etrico utiliza uma chave p

ublica e uma privada para

cifrar e decifrar um mensagem, respectivamente.

A criptograﬁa baseada em chave p

ublica tamb

em pode ser usada no processo de assinatura digital,

que permite garantir a autenticidade de quem envia a mensagem, associada

a integridade do seu

conte

udo. A assinatura digital

e executada em duas etapas. Como primeiro passo, o emissor, atrav

de um algoritmo gera um hash dos dados da mensagem que quer enviar. O hash

e ent

ao cifrado com a

chave privada do emissor, resultando a assinatura digital. Em seguida, o emissor envia a mensagem ao

destinat

ario, com a assinatura digital e este, por meio da chave p

ublica faz a decifragem e recalcula o

hash da mensagem. Se os hashes forem iguais, a assinatura ser

a aut

entica. A n

ao repudiac¸

ao tamb

e garantida pois o emissor da mensagem

e o

unico com acesso

a chave privada.

Com um sistema de chave p

ublica, existe a necessidade de garantir a entrega da chave p

ublica de

forma segura. Por esta raz

ao, um sistema de gerenciamento de chaves visa amenizar as preocupac¸

oes

de armazenamento e distribuic¸

ao de chaves criptogr

aﬁcas. A forma de distribuic¸

ao de chaves crip-

togr

aﬁcas mais empregada na atualidade s

ao os certiﬁcados digitais, que vinculam chaves p

ublicas a

principais. Para garantir que a chave p

ublica contida no certiﬁcado realmente pertence ao sujeito,

comum que o mesmo seja assinado por uma terceira parte conﬁ

avel, chamada de autoridade certiﬁ-

cadora (CA).

2.5.3 Controles de acesso

Os mecanismos de controle de acesso s

ao usados para garantir que o acesso a um recurso seja

limitado aos usu

arios devidamente autorizados. Formam a base para a implementac¸

ao dos mecanis-

mos de autorizac¸

ao. Os modelos de controle de acesso s

ao geralmente classiﬁcados como (Sandhu e

Samarati, 1994):

• Controle de Acesso Discricion

ario (Discretionary Access Control - DAC): O respons

avel

pela informac¸

ao, geralmente o propriet

ario,

e quem manipula o direito de acesso a informac¸

conforme a sua discric¸

ao.

• Controle de Acesso Obrigat

orio (Mandatory Access Control - MAC): A cada usu

ario e a

cada objeto

e atribu

ıdo um r

otulo (Security label). Este r

otulo associado com um objeto re-

ﬂete a sensibilidade da informac¸

ao contida no objeto, enquanto aos usu

arios reﬂetem n

ıveis de

habilitac¸

ao. Um controle obrigat

orio administra o acesso com base na habilitac¸

ao dos sujeitos

e na classiﬁcac¸

ao dos objetos do sistema.

• Controle de Acesso Baseado em Pap

eis (Role-Based Access Control - RBAC): O acesso dos

usu

arios

a informac¸

e regulamentado tendo como base os pap

eis. Estes pap

eis s

ao atribu

ıdos

aos usu

arios conforme as atividades que estes executam no sistema. Os pap

eis podem ser

deﬁnidos como um conjunto de ac¸

oes e responsabilidades associadas com uma atividade de

trabalho em particular (Sandhu e Samarati, 1994). Sendo assim, a autorizac¸

e dada aos

2. Seguranc¸a em Sistemas Distribu

ıdos 9

pap

eis, ao inv

es de especiﬁcar o que cada principal est

a autorizado a fazer, o que facilita o

remanejamento de pap

eis.

2.6 Autenticac¸

ao e Autorizac¸

ao em Sistemas Distribu

ıdos

Em sistemas distribu

ıdos, os recursos computacionais est

ao distribu

ıdos em computadores ligados

de forma din

amica atrav

es de uma rede. Conforme a escala do sistema aumenta, maior

e a diﬁculdade

de implementar os mecanismos de autenticac¸

ao e autorizac¸

ao. Um sistema

e dito escal

avel se este

puder tratar a adic¸

ao de usu

arios e recursos sem sofrer uma perda not

avel de desempenho ou um

aumento na complexidade de administrac¸

ao (Neuman, 1994).

A seguir ser

ao apresentadas abordagens para implementac¸

ao dos mecanismos de autenticac¸

ao e

autorizac¸

ao de forma escal

avel em sistemas distribu

ıdos. Tamb

em ser

ao apresentados alguns estudos

de caso.

2.6.1 Abordagem Centralizada da Autenticac¸

ao e da Autorizac¸

Nesta abordagem, os servic¸os de autenticac¸

ao e autorizac¸

ao s

ao implementados de forma centra-

lizada por uma

unica m

aquina no sistema distribu

ıdo, a Base Computacional de Seguranc¸a (TCB -

Trust Computing Base).

A vantagem desta abordagem

e a facilidade para a implantac¸

ao da pol

ıtica de autorizac¸

ao. Por

em,

a centralizac¸

ao dos controles em um sistema distribu

ıdo provoca uma perda de desempenho j

a que

todos os usu

arios que desejam utilizar os servic¸os de autenticac¸

ao e autorizac¸

ao ter

ao uma

unica

aquina que executar

a este servic¸o.

Um outro problema

e que esta m

aquina torna-se um ponto central de falhas, ou seja, caso uma fa-

lha ocorra, a seguranc¸a de todo o sistema

e comprometida. Devido a estes problemas, esta abordagem

ao se torna atrativa para sistemas distribu

ıdos e escal

aveis.

2.6.2 Abordagem de Autenticac¸

ao Centralizada e de Autorizac¸

ao Descentralizada

Diferindo da abordagem anterior, o sistema de autorizac¸

ao e de autenticac¸

ao s

ao separados, n

sendo mais realizados na mesma m

aquina. Os controles de autenticac¸

ao continuam centralizados,

por

em a autorizac¸

e realizada de forma local. Esta abordagem deixa o sistema menos vulner

avel

pois, apesar da autenticac¸

ao ainda ser feita em uma

unica m

aquina, tornando-se um ponto central de

falhas, a autorizac¸

e feita em m

aquinas diferentes. Entretanto observa-se que a descentralizac¸

ao da

autorizac¸

ao pode provocar problemas de coer

encia na pol

ıtica de autorizac¸

ao.

A escalabilidade dos sistemas que seguem esta abordagem

e obtida atrav

es do conceito de dom

ınios:

os v

arios dom

ınios em sistemas de larga escala devem impor suas pol

ıticas de autenticac¸

ao e de

autorizac¸

ao aos seus respectivos membros.

2. Seguranc¸a em Sistemas Distribu

ıdos 10

Um servidor de um sistema de autenticac¸

ao pode possuir relac¸

oes de conﬁanc¸a com outros servi-

dores, sendo que estas relac¸

oes permitem a troca entre dom

ınios nas certiﬁcac¸

oes de autenticac¸

ao e

no controle de autorizac¸

ao. O modelo X.509 (ITU-T, 1993) e o Kerberos (Kohl e Neuman, 1993) s

modelos baseados nesta abordagem.

2.6.3 Controle Descentralizado da Autenticac¸

ao e da Autorizac¸

Nesta abordagem, a autenticac¸

ao e a autorizac¸

ao s

ao descentralizadas. Ou seja, os principais se

encarregam da implantac¸

ao das pol

ıticas de autenticac¸

ao e de autorizac¸

ao, sem que haja a necessidade

de uma entidade conﬁ

avel central, podendo criar relac¸

oes de conﬁanc¸a sucessivas, formando redes de

conﬁanc¸a (de Melo, 2003).

Apesar da diﬁculdade em se manter a coer

encia das pol

ıticas de autorizac¸

ao, n

ao h

a mais o ponto

central de falhas. Duas propostas, o TCSEC (Department of Defense, 1985) e o SPKI (Simple Public

Key Infrastructure) (Ellison et al., 1999) baseiam-se nesta abordagem.

2.7 Estudo de Casos

2.7.1 Kerberos

Kerberos (Kohl e Neuman, 1993)

e um servic¸o de autenticac¸

ao centralizado, que prov

e autenticac¸

entre aplicac¸

oes clientes e servidoras. Este servic¸o teve seu modelo de autenticac¸

ao baseado no pro-

tocolo de distribuic¸

ao de chaves de Needham e Schroeder (Needham e Schroeder, 1978) e est

a en-

quadrado na abordagem de controle de autenticac¸

ao centralizada e de autorizac¸

ao descentralizada.

Serviço de

autenticação

Ticket−Granting

Server

KERBEROS

Cliente

Servidor

CiscoSystems

Cisco 7500

SERIES

CiscoSystems

Cisco 7500

SERIES

Figura 2.2: Kerberos

A Figura 2.2 ilustra, de forma simpliﬁcada, as trocas de mensagens no processo de autenticac¸

ao.

No passo 1, o cliente envia seu nome e o nome do servidor com o qual este deseja se comunicar e

2. Seguranc¸a em Sistemas Distribu

ıdos 11

solicita ao servidor de autenticac¸

ao (AS) o ticket do servidor de tickets (TGS). O cliente de posse do

ticket, fornece o mesmo ao TGS, que cria uma chave de sess

ao que ser

a utilizada na comunicac¸

entre o cliente e o servidor desejado (passo 2). No passo 3, o cliente envia ao servidor o ticket

concedido pelo TGS.

O servidor Kerberos possui depend

encia no compartilhamento de chaves secretas com cada cli-

ente pertencente ao dom

ınio e com cada servidor de dom

ınio com quem possui relacionamento de

conﬁanc¸a.

A escalabilidade do Kerberos

e obtida atrav

es do uso de dom

ınios separados de autenticac¸

chamado de realms. Cada dom

ınio possui o seu pr

oprio servidor Kerberos, e todos os clientes deste

dom

ınio conﬁam neste servidor. Estabelecendo relac¸

oes de conﬁanc¸a entre servidores, atrav

es de

compartilhamento de uma chave secreta, um cliente autenticado em um dom

ınio pode utilizar esta

autenticac¸

ao em dom

ınios diferentes. Para a unicidade de nomes, nomes locais s

ao concatenados a

nomes de dom

ınio.

2.7.2 X.509

A recomendac¸

ao ITU-T X.509 (ITU-T, 1993) deﬁne uma estrutura para certiﬁcados de chave

ublica e descreve dois n

ıveis de autenticac¸

ao. Um modo chamado de fraco, que usa conta e senha e

outro chamado de forte, que envolve credenciais consolidadas por t

ecnicas criptogr

aﬁcas.

O n

ıvel forte de autenticac¸

ao deﬁne uma estrutura para o fornecimento de servic¸os de autenticac¸

controlado de forma centralizada representado por um servic¸o de diret

orio X.500. O X.500, atrav

de uma hierarquia de nomes, permite uma nomeac¸

ao global e geograﬁcamente distribu

ıda.

Como no modelo Kerberos, o X.509 deﬁne uma autorizac¸

ao descentralizada, ou seja, ap

os a

autenticac¸

ao o cliente ﬁca sujeito ao controle de acesso do servidor de aplicac¸

ao. Al

em disso, tem

como base uma infra-estrutura de chave p

ublica ou PKI (Public Key Infrastructure). Cada cliente

possui, em particular, um par de chaves: uma chave privada que ﬁca em seu poder, e outra, chave

ublica, que ﬁca armazenada em diret

orios X.500 na forma de certiﬁcados emitidos pela CA do

dom

ınio.

O modelo de conﬁanc¸a X.509

e hier

arquico e as comunidades X.509 s

ao constru

ıdas de forma

top-down com base na conﬁanc¸a das chaves privadas das CAs. Este modelo baseia-se em certiﬁcados

providos com a cadeia de autenticac¸

ao, partindo da chave privada de uma CA conﬁ

avel at

e a chave

ublica do usu

ario (Clarke, 2001). Atrav

es destes certiﬁcados

e poss

ıvel vincular nomes globais a

chaves p

ublicas.

Os certiﬁcados permitem uma associac¸

ao entre um nome chamado identiﬁcador de nome

unico,

ou DN para um usu

ario e a sua chave p

ublica.

E interessante notar, entretanto, que um mesmo usu

ario

pode ter diferentes DNs em diferentes CAs, ou usar o mesmo DN em diferentes CAs, mesmo se este

e o primeiro a utiliz

a-lo. Desta forma, diferentes DNs em diferentes CAs n

ao necessariamente

signiﬁcam diferentes usu

arios (Gerck, 2000). A Figura 2.3 apresenta o conjunto padr

ao de campos

2. Seguranc¸a em Sistemas Distribu

ıdos 12

de um certiﬁcado X.509. No

ultimo campo encontra-se a assinatura dos campos anteriores utilizando

a chave privada da CA. Na seq

encia segue a descric¸

ao de cada campo:

Subject Public Key Information

Subject Name

Validity

Issuer Name

Version

Serial Number

Issuer’s Signature

Extension

Issuer Unique Idendifier

Subject Issuer Unique Idendifier

Gera a assinatura com

a chave privada da CA

Signature

Figura 2.3: Certiﬁcado X.509 vers

ao 3

• Vers

ao (Version): identiﬁca qual a vers

ao do X.509 usada no certiﬁcado em quest

ao, o que

afeta qual informac¸

ao pode ser especiﬁcada neste.

• N

umero de S

erie do Certiﬁcado (Serial Number): valor inteiro

unico atribu

ıdo pela CA a

cada certiﬁcado.

• Assinatura (Signature): identiﬁcador do algoritmo usado para assinatura.

• Nome do Emissor (Issuer Name): o nome

unico da entidade que assinou o certiﬁcado.

• Validade (Validity): per

ıodo de validade do certiﬁcado.

• Nome do Sujeito do Certiﬁcado (Subject Name): Identiﬁcac¸

ao do principal associado

a chave

ublica.

• Informac¸

ao da Chave P

ublica do Sujeito do Certiﬁcado (Subject Public Key Information):

a chave p

ublica do principal, par

ametros opcionais e o identiﬁcador do algortimo.

• Identiﬁcador

unico do Emissor do Certiﬁcado (Issuer Unique Identiﬁer): o nome da CA

que publicou o certiﬁcado.

• Identiﬁcador

Unico do Sujeito do Certiﬁcado (Subject Unique Identiﬁer): campo ideali-

zado para ser

unico em toda a Interntet; este

e composto de v

arias partes, como por exemplo:

DN=JosianeM CN=Josiane, OU=DAS, O=UFSC, Inc., C=BR.

• Extens

ao (Extension): Proporciona um meio para associar dados adicionais para informac¸

oes

pessoais, chaves p

ublicas e ger

encia de chaves, entre outras.

• Assinatura do Emissor (Issuer’s Signature): a assinatura usando a chave privada da CA.

2. Seguranc¸a em Sistemas Distribu

ıdos 13

O modelo X.509 tamb

em permite construir relac¸

oes de conﬁanc¸a atrav

es de certiﬁcac¸

ao cruzada

entre duas CAs, dispensando assim a necessidade de percorrer toda a estrutura hier

arquica para ir

de uma CA at

e outra. Esta alternativa s

o pode ser adotada entre CAs, o que evidentemente n

descaracteriza a CA como entidade centralizadora da certiﬁcac¸

ao.

O conceito de Listas de Revogac¸

ao de Certiﬁcados (CLR - Certiﬁcate Revocation Lists), que in-

validam certiﬁcados antes de sua data de expirac¸

ao, tamb

em s

ao descritas no padr

ao X.509. Esta

caracter

ıstica pode ser interessante em caso de comprometimento da chave, ou em casos em que a

informac¸

ao sobre o sujeito do certiﬁcado

e invalidada. Um certiﬁcado X.509 s

o pode ser revogado

por uma CA. As CLRs, constantemente emitidas, datadas e assinadas digitalmente, informam quando

a pr

oxima CRL ser

a emitida. Infelizmente CRLs n

ao resolvem os problemas que lhes foram designa-

das, pois pode haver um atraso consider

avel e vari

avel entre a CA que deseja notiﬁcar a revogac¸

ao de

algum certiﬁcado e a a reﬂex

ao desta necessidade nos clientes e nos servidores. Al

em disso, a maior

aplicac¸

ao de seguranc¸a X.509 atual, SSL/TLS (Freier et al., 1996a) n

ao veriﬁca as CRLs (Gerck,

2000).

Um dos maiores problemas com o X.509

e seu n

ıvel de diﬁculdade para ser entendido e adotado.

Os formatos dos dados n

ao s

ao humanamente leg

ıveis e s

ao expressos em uma notac¸

ao de sintaxe

abstrata (ASN.1). Esta notac¸

ao, que

e um padr

ao de interconex

ao de sistemas abertos (OSI),

e muito

poderosa, por

em muito complexa para ser usada (Clarke, 2001).

2.7.3 SPKI/SDSI

O SPKI/SDSI, conforme citado anteriormente, segue a abordagem descentralizada. Teve seu de-

senvolvimento motivado devido a complexidade e imperfeic¸

ao das infra-estruturas de chaves p

ublicas

baseadas em uma hierarquia de nomes globais, como o X.509. O SPKI/SDSI surgiu da uni

ao das pro-

postas SDSI (Simple Distributed Security Infrastructure) (Rivest e Lampson, 1996) e SPKI (Simple

Public Key Infrastructure) (Ellison et al., 1999).

O SDSI, projetado no MIT por Rivest e Butler Lampson (Rivest e Lampson, 1996),

e uma infra-

estrutura de seguranc¸a com o objetivo principal de facilitar a construc¸

ao de sistemas distribu

ıdos

seguros e escal

aveis. A proposta SPKI, criada por Carl Ellison e outros (Ellison et al., 1999)

e um

padr

ao IETF que surgiu com o intuito de ser um modelo de autorizac¸

ao ﬂex

ıvel, simples e de f

acil

implementac¸

ao.

O SPKI/SDSI est

a baseado em um modelo igualit

ario. Os principais s

ao chaves p

ublicas e cada

chave p

ublica pode funcionar similarmente a uma entidade certiﬁcadora (Clarke, 2001). N

ao h

a uma

entidade centralizadora para o registro de chaves p

ublicas e emiss

ao de certiﬁcados como a autoridade

certiﬁcadora do X.509. N

ao existe uma infra-estrutura global hier

arquica, ou seja, as comunidades

podem ser constru

ıdas de forma distribu

ıda sem a necessidade de uma entidade ra

ız (na qual todos

conﬁam).

O SPKI/SDSI foi projetado para ser simples de entender, adotar e usar (Clarke, 2001). Por estes

motivos foi concebido tendo como base uma adaptac¸

ao da linguagem S-expressions (sintaxe abstrata

2. Seguranc¸a em Sistemas Distribu

ıdos 14

utilizada para representar dados) proposta em (Rivest e Lampson, 1996). Estas S-expressions s

como estruturas LISP que encapsulam elementos com par

enteses, cujos elementos podem ser cadeias

de caracteres ou outras S-expressions. Ou seja, listas vazias n

ao s

ao permitidas e o primeiro elemento

deve ser uma string.

Existem dois tipos de certiﬁcados no SDSI/SPKI: certiﬁcados de nomes e certiﬁcados de autorizac¸

(Clarke, 2001). Um certiﬁcado de nome deﬁne um nome local no espac¸o de nomes do emissor do

certiﬁcado e

e formado pelos seguintes campos:

• Emissor (Issuer): chave p

ublica que assina o certiﬁcado.

• Identiﬁcador (identiﬁer): identiﬁcador que determina o nome local que est

a sendo deﬁnido.

• Sujeito (subject): uma chave p

ublica ou um nome, que identiﬁque uma entidade deﬁnida em

outro espac¸o de nomes e que est

a sendo redeﬁnida no espac¸o de nomes do emissor.

• Data de validade (Validity Speciﬁcation): per

ıodo de tempo em que o certiﬁcado

e v

alido.

Um certiﬁcado de nomes deﬁne um nome local e pode ser expresso da seguinte forma:

K ”nome”−→ S.

Onde K

e a chave do emissor, ”nome”

e o nome dado a chave no espac¸o de nomes local e S

representa o sujeito que est

a sendo ligado ao ”nome”. Por exemplo, B

arbara detentora da chave K

quer emitir um certiﬁcado de nomes para sua m

ae Carmen, detentora da chave K

. Ent

ao B

arbara cria

no seu espac¸o de nomes um nome local (m

ae), ou seja, emite um certiﬁcado de nome para a chave

ublica de Carmem:

”m

ae”−→ K

ebora, detentora da chave K

deseja deﬁnir um nome para a chave p

ublica da m

ae de B

arbara.

Para isso, D

ebora associa um nome (B

arbaraM

ae) ao certiﬁcado emitido por B

arbara:

”B

arbaraM

ae”−→ K

”m

ae”,

formando assim uma cadeia de certiﬁcados de nome. Se uma cadeia de certiﬁcados de nome for

reduzida chega-se a uma chave p

ublica, neste caso, a chave p

ublica de Carmen.

No SPKI/SDSI

e poss

ıvel deﬁnir grupos de principais, no qual cada grupo possui um nome que

e identiﬁcado com um conjunto de membros. O nome

e local ao emissor de certiﬁcados de nome

de grupo, que

e o respons

avel pelas alterac¸

oes nas deﬁnic¸

oes do mesmo. Para deﬁnir um grupo, o

emissor emite um certiﬁcado de nomes deﬁnindo o nome local do grupo no seu espac¸o de nomes. O

sujeito deste certiﬁcado pode ser a chave de um membro ou um nome (Clarke, 2001).

Um certiﬁcado de autorizac¸

ao no SPKI/SDSI concede uma autorizac¸

ao espec

ıﬁca dada pelo emis-

sor ao sujeito do certiﬁcado e

e formado pelos seguintes campos:

2. Seguranc¸a em Sistemas Distribu

ıdos 15

• Emissor (Issuer): chave p

ublica que assina o certiﬁcado; ou seja, o principal que garante a

autorizac¸

ao.

• Sujeito (subject): uma chave ou um grupo que recebe a autorizac¸

ao.

• Bit de delegac¸

ao (Delegation bit): Valor l

ogico que indica se o certiﬁcado pode ou n

ao ser

delegado.

• Autorizac¸

ao (tag): especiﬁca a autorizac¸

ao que ser

a concedida ao sujeito pelo emissor.

• Data de validade (Validity Speciﬁcation): per

ıodo de tempo em que o certiﬁcado

e v

alido.

O emissor destes certiﬁcados corresponde a um principal que, atrav

es dos mesmos, concede per-

miss

oes de acesso a outros principais no sistema. O emissor de um certiﬁcado pode permitir que

o sujeito (principal receptor) delegue as permiss

oes recebidas a outros principais, atrav

es do bit de

delegac¸

ao.

Este sujeito, no papel de emissor, pode delegar estes direitos recebidos a outros principais, cons-

truindo assim, uma cadeia de autorizac¸

ao. Esta cadeia

e enviada ao sujeito deste novo certiﬁcado.

Como a autorizac¸

ao baseada em redes de conﬁanc¸a exige que sempre haja caminhos ou cadeia de

certiﬁcados entre cliente e servidores que garantam ao cliente o direito sobre o recurso (provido pelo

servidor) desejado, o sujeito do novo certiﬁcado dever

a sempre apresentar a cadeia recebida quando

quiser acessar o servic¸o.

Uma Lista de Controle de Acesso ou ACL SPKI/SDSI consiste de uma lista de entradas, onde cada

entrada

e considerada um certiﬁcado de autorizac¸

ao com o emissor sendo o propriet

ario da mesma.

Os campos requeridos para cada entrada na ACL s

ao: um sujeito, que pode ser um nome ou uma

chave; uma tag; e o bit de delegac¸

ao, que s

ao os mesmos campos de um certiﬁcado de autorizac¸

(Clarke, 2001).

O SPKI/SDSI prov

e um mecanismo de toler

ancia a falhas atrav

es dos threshold subjects (Aura,

1998), que podem ser usados somente como certiﬁcados de autorizac¸

ao. S

ao utilizados para especiﬁ-

car K de n sujeitos (sendo estes uma chave p

ublica, um nome ou ainda um grupo), que devem assinar

uma requisic¸

ao ou uma delegac¸

ao para que esta seja honrada.

O modelo SPKI/SDSI apresenta, como diﬁculdade, a identiﬁcac¸

ao das cadeias de certiﬁcados

que levem um cliente a obter autorizac¸

ao necess

aria para acessar os recursos do servidor desejado,

podendo haver casos em que o cliente n

ao possua caminho de conﬁanc¸a que o autorize diante do

servidor. Para solucionar este problema, existem diversos trabalhos que tratam da procura de cadeias

de certiﬁcados que viabilizem acessos aos recursos desejados, dentre estes destacam-se a abordagem

de Federac¸

oes SPKI, proposta em (Santin, 2004).

2.7.4 Federac¸

oes SPKI

Em (Santin, 2004) foi proposta uma extens

ao do modelo de conﬁanc¸a do SDSI/SPKI (que imp

restric¸

oes

a localizac¸

ao de determinado direito) atrav

es da introduc¸

ao da noc¸

ao de Federac¸

ao. A

2. Seguranc¸a em Sistemas Distribu

ıdos 16

federac¸

e uma entidade que re

une principais com interesses aﬁns e atua como um agente facilitador

na localizac¸

ao de certiﬁcados e principais, pois permite o compartilhamento do acesso ao seu repo-

sit

orio de certiﬁcados. Atrav

es deste compartilhamento, os clientes passam a ter uma alternativa a

recorrer quando da falta de cadeias apropriadas para o acesso desejado.

As principais func¸

oes de uma federac¸

ao est

ao centradas em um gerente que prov

e mecanismos

de armazenamento, recuperac¸

ao e criac¸

ao de cadeias de certiﬁcados de autorizac¸

ao, necess

arios para

que os clientes consigam efetivar o acesso nos servidores, sem no entanto caracterizar-se como uma

chave intermedi

aria. Um principal, sendo um cliente ou um servidor, ao ingressar em uma federac¸

fornece os certiﬁcados de nomes e de autorizac¸

ao deleg

aveis que julgar

uteis para a federac¸

ao.

Um principal qualquer pode ﬁliar-se a quantas federac¸

oes este queira. Sendo que para se regis-

trar ter

a que fornecer um threshold certicate, assinado por k-de-n membros j

a ﬁliados

a Federac¸

em quest

ao, acompanhado do certiﬁcado de nome deste principal que est

a solicitando a admiss

ao.

Quando registrado, um certiﬁcado de nome

e inclu

ıdo no reposit

orio da federac¸

ao e ser

a mantido

pelo gerente de certiﬁcados para auxiliar no processo de identiﬁcac¸

ao deste principal. Para cada novo

membro inclu

ıdo na federac¸

e tamb

em emitido um ”certiﬁcado de grupo”(certiﬁcado de nome ex-

pressando participac¸

ao no grupo SDSI) para ﬁns de comprovac¸

ao da ﬁliac¸

ao (membership).

A partir da integrac¸

ao da federac¸

ao ao modelo de conﬁanc¸a do SDSI/SPKI, os clientes passam a

ter uma alternativa a recorrer na falta de cadeias apropriadas para o acesso desejado (Santin, 2004).

Na Figura 2.4 pode ser observado um cen

ario em que um cliente A recebe de um servidor de aplicac¸

um certiﬁcado de autorizac¸

ao delegando um direito ao mesmo (passo 1). O cliente A armazena este

certiﬁcado no seu reposit

orio local e no reposit

orio de certiﬁcados da Federac¸

ao que pertence (passo

2). Desta forma, um cliente B, que n

ao possui o direito de acesso, ao fazer a busca deste certiﬁcado

na Federac¸

ao, recebe o certiﬁcado emitido pelo servidor ao cliente A (passo 3). De posse deste

certiﬁcado, o cliente B pode negociar o direito com o cliente A (passo 4). Obtido o direito atrav

es do

certiﬁcado negociado, o cliente B pode fazer requisic¸

oes de acesso ao Servidor de Aplicac¸

ao (passo

5).

Certificados

Gerente de

Rep A

Federação A

Rep Local

Cliente A

Rep Local

Cliente B

Servidor de

Aplicação

Rep ACL

Figura 2.4: Modelo de conﬁanc¸a estendido do SPKI/SDSI

Apesar de facilitar a localizac¸

ao de certiﬁcados de autorizac¸

ao, uma federac¸

ao geralmente tem

2. Seguranc¸a em Sistemas Distribu

ıdos 17

a sua abrang

encia limitada ao ﬁm a que se presta. Para evitar que membros de uma federac¸

ao ne-

cessitem ﬁliar-se a v

arias outras federac¸

oes para atingir um certo n

ıvel de presenc¸a na rede, surgiu a

proposta que os gerentes de certiﬁcados das federac¸

oes se associem formando teias de federac¸

oes.

A teia de federac¸

oes

e formada arbitrariamente e cria caminhos de conﬁanc¸a entre as federac¸

oes

associadas de tal modo que um cliente pode fazer consultas a federac¸

oes as quais n

e ﬁliado. Para

poder realizar uma busca em uma outra federac¸

ao, o gerente de certiﬁcados da federac¸

ao de origem

deve ser associado a federac¸

ao onde ser

a realizada a busca. Ao realizar uma busca em uma outra

federac¸

ao, o cliente deve apresentar

a federac¸

ao associada o certiﬁcado de membro da sua federac¸

de origem e o certiﬁcado de associac¸

ao entre as duas federac¸

oes. Desta forma, a criac¸

ao de novas

cadeias de certiﬁcados pode ser realizada atrav

es da busca de certiﬁcados em uma teia de federac¸

oes

e da negociac¸

ao da concess

ao do privil

egio com o possuidor do mesmo.

Conforme pode ser visto na Figura 2.5, um principal da Federac¸

ao A pode realizar a busca na

Federac¸

ao B, j

a que os gerentes das duas Federac¸

oes s

ao associados, ou seja, possuem uma relac¸

de conﬁanc¸a. Desta forma, para que esta busca se realize, basta que o principal da Federac¸

ao A

apresente ao gerente da Federac¸

ao B, o seu certiﬁcado de membro da Federac¸

ao A.

Certificados

Gerente de

Certificados

Gerente de

Servidor de

Aplicação Y

Rep Y

Rep A Rep B

Federação A Federação B

Relação de

Confiança

Rep X

Servidor de

Aplicação X

Teias de Federações

Rep W

Agente

Principal W

Agente

Principal V

Rep V

Principal Z

Agente

Rep Z

Figura 2.5: Teias de federac¸

oes

A extens

ao do modelo de conﬁanc¸a do SDSI/SPKI proposta em (Santin, 2004), visa preservar

a ﬁlosoﬁa adotada no modelo SPKI/SDSI vers

ao 2.0, na qual o principal que deseja obter acesso a

algum recurso

e inteiramente respons

avel pela busca das cadeias de certiﬁcados que lhe fornec¸am

o direito de acesso ao recurso. Entretanto, esta ﬁlosoﬁa sobrecarrega o cliente, j

a que

e este quem

realiza a busca por certiﬁcados na teia de federac¸

oes.

2. Seguranc¸a em Sistemas Distribu

ıdos 18

2.8 Conclus

Neste cap

ıtulo foram apresentados os conceitos fundamentais de seguranc¸a, juntamente com os

conceitos de pol

ıticas e de mecanismos de seguranc¸a. Foram vistas as principais abordagens cl

assicas

para a autenticac¸

ao e a autorizac¸

ao em sistemas distribu

ıdos.

Conforme pode ser observado no texto, modelos onde a relac¸

ao de conﬁanc¸a pode ser estabelecida

de maneira distribu

ıda, como no SPKI/SDSI, a escalabilidade e a ﬂexibilidade s

ao favorecidas. Foi

tamb

em apresentado o trabalho proposto em (Santin, 2004) que introduz o conceito de Federac¸

ao que

visa auxiliar o modelo de conﬁanc¸a do SPKI/SDSI, que apresenta como diﬁculdade a identiﬁcac¸

das cadeias de certiﬁcados.

No cap

ıtulo 4, ser

a apresentado um modelo tamb

em baseado em federac¸

oes que possui um servic¸o

que encapsula o gerente de certiﬁcados, al

em de realizar buscas para o cliente. Al

em desta facilidade

para o cliente, o novo modelo tamb

em est

a baseado em servic¸os Web.

Cap

ıtulo 3

Seguranc¸a atrav

es do XML e Servic¸os

Web

3.1 Introduc¸

No cap

ıtulo anterior foram expostas diferentes abordagens de seguranc¸a utilizadas em sistemas

distribu

ıdos, tendo como enfoque as caracter

ısticas de autenticac¸

ao e de autorizac¸

ao. Foi exposta uma

alternativa para recorrer quando h

a a falta de cadeias apropriadas para o acesso desejado, constru

ıda

sobre a infra-estrutura de chaves p

ublicas chamada SPKI/SDSI proposta em (Santin, 2004).

Neste cap

ıtulo ser

ao apresentadas as especiﬁcac¸

oes de seguranc¸a para a Extensible Markup Lan-

guage (XML) (Bray et al., 2004) ou, linguagem de marcac¸

ao de dados, que prov

e um formato para

descrever diversos tipos de dados. Estas especiﬁcac¸

oes deﬁnem vocabul

arios em XML para represen-

tar informac¸

oes seguras permitindo a aplicac¸

ao de seguranc¸a em documentos XML, em elementos do

documento, bem como no seu conte

udo total. Por serem interoper

aveis e ﬂex

ıveis, as especiﬁcac¸

oes

de seguranc¸a XML tamb

em facilitam o gerenciamento de direitos digitais e o controle de acesso

distribu

ıdo. As especiﬁcac¸

oes a serem descritas s

ao: XML Signature (Bartel, 2002), XML Encryp-

tion (Imamura, 2002), Security Assertion Markup Language (SAML)(Cantor et al., 2005), Extensible

Access Control Markup Language (XACML)(Moses, 2005) e XML Key Management Speciﬁcation

(XKMS)(Hallam-Baker, 2004).

em das especiﬁcac¸

oes de seguranc¸a em XML, ser

ao apresentados os conceitos de servic¸os Web

e as especiﬁcac¸

oes para seguranc¸a destes servic¸os, tais como: WS-Security (Nadalin et al., 2004),

WS-Policy (Anderson et al., 2005b), WS-Trust, WS-SecureConversation (Anderson et al., 2005a) e

WS-Federation (Bajaj, 2003).

A XML, desenvolvida por um grupo de trabalho formado atrav

es do World Wide Web Consortium

(W3C) em 1996,

e um subconjunto do Standard Generalized Markup Language (SGML)

otimizado,

O SGML

e um padr

ao internacional (ISO 8879), port

avel, publicado em 1986, que descreve um padr

ao para o uso de

marcac¸

oes descritivas mescladas ao documento, permitindo a criac¸

ao de documentos independentes do tipo de m

aquina e

dos programas usados.

3. Seguranc¸a atrav

es do XML e Servic¸os Web 20

principalmente para a distribuic¸

ao de dados atrav

es da Web.

Dentre os principais objetivos de projeto do padr

ao XML (Bray et al., 2004) est

ao o suporte a

um grande n

umero de aplicac¸

oes e a usabilidade de documentos XML em diversos contextos (Bray

et al., 2004). Para descrever os dados em um documento XML, um documento de deﬁnic¸

ao de

tipos (Document Type Deﬁnition - DTD) pode ser adotado. O DTD

e um documento que especiﬁca

exatamente o contexto e a estrutura dos elementos permitidos em um documento XML. Como uma

alternativa ao DTD, pode ser utilizado um esquema XML (XML Schema) (David C. Fallside, 2004),

que

e uma evoluc¸

ao do DTD. Uma das grandes vantagens do esquema XML sobre o DTD

e o suporte

a tipos de dados, que facilita a descric¸

ao do conte

udo de documentos XML permitindo assim a sua

validac¸

ao e a sua convers

ao, al

em da deﬁnic¸

ao de restric¸

oes dos dados. Por ser deﬁnido atrav

es da

opria linguagem XML, um esquema XML pode ser facilmente estendido, reutilizado, transformado

atrav

es das ferramentas j

a deﬁnidas e implementadas para o XML.

3.2 XML Signature

A especiﬁcac¸

ao XML Signature (XMLSig) (Bartel, 2002)

e um padr

ao desenvolvido em conjunto

pela W3C e IETF (RFC 2807 e 3275), que deﬁne regras para gerar e validar assinaturas digitais

expressas em XML. As assinaturas digitais servem como prova persistente da integridade e da auten-

ticidade de dados de um documento, assim como evidencia a origem de quem a criou (garante a n

repudiac¸

ao).

As assinaturas digitais somente funcionam se os c

alculos de veriﬁcac¸

ao s

ao executados nos mes-

mos bits que os usados para o c

alculo da assinatura. A especiﬁcac¸

ao XML Signature utiliza meca-

nismos para representar documentos XML na forma can

onica

(Boyer, 2001). A forma can

onica

assegura que duas inst

ancias de um mesmo texto produzam o mesmo resumo e a mesma assinatura,

mesmo que as inst

ancias sejam um pouco diferentes. Por exemplo, uma destas inst

ancias possui

um espac¸o em branco a mais que a outra, ainda assim, o resumo ser

a o mesmo (Naedele, 2003). A

forma can

onica de um documento XML

e uma representac¸

ao f

ısica e invariante em respeito a todas

as poss

ıveis diferenc¸as sint

aticas que um mesmo documento pode sofrer, por exemplo, um espac¸o em

branco, a ordem dos atributos, entre outros (O’Neill, 2003).

ao somente documentos XML podem ser assinados, como tamb

em outros tipos de dados. Os

dados assinados podem estar dentro ou fora do documento XML que cont

em uma assinatura (ar-

quivos bin

arios ou textos). A especiﬁcac¸

ao prev

e ainda a possibilidade de assinar somente porc¸

oes

espec

ıﬁcas da

arvore XML, ao inv

es do documento completo. Isto

e importante quando um

unico

documento XML deve ser assinado m

ultiplas vezes por uma

unica ou m

ultiplas partes. Esta ﬂexibili-

dade pode assegurar a integridade de certas porc¸

oes de um documento XML, enquanto deixa aberta

a possibilidade para que outras porc¸

oes do documento possam ser modiﬁcadas.

Segundo a especiﬁcac¸

ao, existem tr

es tipos de assinatura XML (Bartel, 2002):

Forma can

onica

e aquela que

e geral e que as outras formas podem ser geradas da mesma por processos de reduc¸

ao. Do-

cumentos XML que sejam sintaticamente diferentes, por

em logicamente equivalentes, podem ser assumidos como reduc¸

oes

de uma forma can

onica e representados por esta

ultima

3. Seguranc¸a atrav

es do XML e Servic¸os Web 21

• Enveloped

Quando a assinatura est

a contida no pr

oprio documento assinado, esta

e chamada de Envelo-

ped XML Signature. Obviamente, com assinaturas enveloped, deve-se tomar cuidado para que

ao seja inclu

ıdo o seu valor no c

alculo do SignatureValue. Uma representac¸

ao deste tipo de

assinatura pode ser visto na Figura 3.1.

</SignedInfo>

</Signature>

</document>

Figura 3.1: Enveloped XML Signature

• Enveloping XML Signature

Quando o dado assinado (em XML ou n

ao) est

a contido na pr

opria estrutura da assinatura

XML, a assinatura

e chamada de Enveloping XML Signature. Este dado

e identiﬁcado via um

elemento Reference, conforme ilustrado na Figura 3.2.

</SignedInfo>

Id="Res0">

<dsig:Object xmlns:dsig="http://www.w3c.org/2000/09/xmldsig#"

</dsig:Object>

</Signature>

Figura 3.2: Enveloping XML Signature

• Detached Signature

Quando uma assinatura est

a separada dos dados que foram assinados, esta

e chamada de De-

tached Signature, conforme apresentado na Figura 3.3. Este tipo de assinatura

e geralmente

aplicada em objetos, ou arquivos de dados separados de sua assinatura. Mas tamb

em podem

incluir casos em que a assinatura e o dado assinado est

ao no mesmo documento XML, por

3. Seguranc¸a atrav

es do XML e Servic¸os Web 22

em elementos separados. O dado assinado pode ser referenciado atrav

es de uma URI, podendo

ser localizado na Web e n

ao limitado aos dados dispon

ıveis em arquivos locais.

</SignedInfo>

</Signature>

Figura 3.3: Detached Signature

3.3 XML Encryption

A especiﬁcac¸

ao XML Encryption (Imamura, 2002), desenvolvida pela W3C,

e um padr

ao que des-

creve o processo de cifragem e representac¸

ao de dados cifrados em documentos XML. O conte

udo

cifrado e o processamento adicional da informac¸

ao s

ao representados em XML, de modo que o resul-

tado possa ser processado por outras ferramentas XML. A XML Encryption n

ao pretende substituir

os protocolos SSL/TLS (Freier et al., 1996b) (Dierks e Allen, 1999), mas sim prover um mecanismo

de seguranc¸a ﬁm-a-ﬁm que oferece algumas caracter

ısticas n

ao cobertas pelo SSL/TLS, tais como:

cifrar somente parte dos dados.

A especiﬁcac¸

ao XML Encryption deﬁne uma sintaxe (deﬁnida atrav

es de um esquema XML)

e regras de processamento para protec¸

ao da conﬁdencialidade de dados. Estes dados podem ser,

documentos XML como um todo, partes de um documento XML, ou ainda um dado qualquer. O

resultado da cifragem

e um elemento EncryptedData, que cont

em o dado cifrado.

3.3.1 Cen

arios de Cifragem

Cifragem XML pode ser aplicada em tr

es casos amplos: cifragem de um elemento XML, cifragem

do conte

udo de um elemento XML e cifragem de um dado qualquer (que pode ser XML) (O’Neill,

2003). Estes casos s

ao exempliﬁcados nos cen

arios descritos em http://www.w3.org/TR/xmlenc-core,

que ser

ao aqui analisados conforme apresentado na Figura 3.4. Nesta Figura, podem ser observados

dados de uma pessoa representados em elementos XML. Dentre estes elementos est

ao o nome da

pessoa e os dados de seu cart

ao de cr

edito.

3.3.1.1 Cifragem de um elemento XML

O n

umero do cart

ao de cr

edito de Smith

e uma informac¸

ao sens

ıvel. Se a aplicac¸

ao deseja con-

servar a conﬁdencialidade da informac¸

ao, esta pode cifrar o elemento CreditCard que pode ser visu-

3. Seguranc¸a atrav

es do XML e Servic¸os Web 23

<?xml version=’1.0’?>

<Name>John Smith</Name>

<Issuer>Example Bank</Issuer>

</CreditCard>

</PaymentInfo>

Figura 3.4: Exemplo

alizado na Figura 3.4(Imamura, 2002) (Figura 3.5).

<?xml version=’1.0’?>

<Name>John Smith</Name>

<EncryptedData Type=’http://www.w3.org/2001/04/xmlenc#Element’

xmlns=’http://www.w3.org/2001/04/xmlenc#’>

</CipherData>

</EncryptedData>

</PaymentInfo>

Figura 3.5: Cifragem de um elemento XML

O elemento CreditCard, desde o seu in

ıcio at

e seu ﬁm, foi escondido no elemento CipherData

que cont

em a cifragem do mesmo.

3.3.1.2 Cifragem do conte

udo de um elemento XML

Pode-se ainda considerar o cen

ario no qual toda informac¸

ao exceto o n

umero do cart

ao de cr

edito

real deve estar dispon

ıvel. Neste caso, somente o conte

udo do elemento Number

e cifrado (Figura

3.6).

<?xml version=’1.0’?>

<Name>John Smith</Name>

<EncryptedData xmlns=’http://www.w3.org/2001/04/xmlenc#’

Type=’http://www.w3.org/2001/04/xmlenc#Content’>

</CipherData>

</EncryptedData>

</Number>

<Issuer>Example Bank</Issuer>

</CreditCard>

</PaymentInfo>

Figura 3.6: Cifragem do conte

udo de um elemento XML

3. Seguranc¸a atrav

es do XML e Servic¸os Web 24

3.3.1.3 Cifragem de um dado qualquer

Se o cen

ario da aplicac¸

ao requer que toda informac¸

ao seja cifrada, todo documento

e cifrado

como uma seq

uencia de octetos. Isto aplica-se a dados arbitr

arios, ou seja, qualquer tipo de dado,

podendo ser ou n

ao um documento XML (Figura 3.7).

<?xml version=’1.0’?>

<EncryptedData xmlns=’http://www.w3.org/2001/04/xmlenc#’

MimeType=’text/xml’>

</CipherData>

</EncryptedData>

Figura 3.7: Cifragem de um dado qualquer

3.4 XACML

Devido ao alto custo de gerenciamento de pol

ıticas em grandes empresas (que deﬁnem estas

pol

ıticas em diferentes pontos de efetivac¸

ao e de forma n

ao padronizada) surge a necessidade de

uma linguagem comum para expressar as pol

ıticas de seguranc¸a. A Extensible Access Control Mar-

kup Language (XACML) (Moses, 2005)

e uma linguagem que especiﬁca esquemas para pol

ıticas

de controle de acesso, al

em de um formato para requisic¸

oes e respostas de decis

oes de autorizac¸

ao,

garantindo assim, a interoperabilidade destas pol

ıticas. Atrav

es da XACML, uma empresa pode ge-

renciar a efetivac¸

ao de todos os elementos de suas pol

ıticas de seguranc¸a em todos os componentes

dos seus sistemas de informac¸

ao (Moses, 2005). A XACML

e usada para deﬁnir se o acesso ao re-

curso requisitado

e permitido baseado em conjuntos de regras ou pol

ıticas (Damiani et al., 2002). A

XACML deﬁne tr

es componentes principais (Moses, 2005):

• Regras (Rule): cont

em express

oes booleanas que podem ser acessadas atrav

es de um Ponto de

Decis

ao de Pol

ıtica (PDP).

• Pol

ıtica (Policy): cont

em um conjunto de elementos de regras.

• Conjunto de Pol

ıticas (PolicySet): cont

em um conjunto de pol

ıticas (policies) ou conjuntos de

pol

ıticas e um procedimento especiﬁcado pela combinac¸

ao dos resultados de suas avaliac¸

oes.

3.4.1 Regras em XACML

Uma regra

e a unidade mais elementar de uma pol

ıtica. Possui tr

es principais componentes: um

target, um efeito (effect) e um conjunto de condic¸

oes (conditions) (Moses, 2005). Um target

e deﬁ-

nido como o espac¸o de pedidos de decis

ao que referenciam ac¸

oes em recursos (documentos, servic¸os

ou sistemas) por sujeitos (pessoas ou computadores). Efeito

e permitir ou negar. Para a efetivac¸

3. Seguranc¸a atrav

es do XML e Servic¸os Web 25

de uma regra, condic¸

oes devem avaliadas para a aplicac¸

ao do efeito a regra. Estas condic¸

oes podem

envolver c

alculo de atributos de um sujeito, de um recurso de uma ac¸

ao ou de um ambiente (O’Neill,

2003).

3.4.2 Pol

ıticas em XACML

Uma pol

ıtica compreende quatro principais componentes: targets, algoritmo de combinac¸

ao de

regras (Rule-combining algorithm), regras (rules) e obrigac¸

oes (obligations) (Moses, 2005). Um

target especiﬁca um sujeito (subject), recursos e ac¸

oes e ambientes aos quais a mesma se aplica.

O algoritmo de combinac¸

ao de regras especiﬁca o procedimento atrav

es do qual os resultados das

avaliac¸

oes dos componentes das regras s

ao combinados quando se avalia a pol

ıtica. Ou seja, o valor

de decis

ao dado como resposta pelo Ponto de decis

ao de pol

ıticas (PDP)

e o valor da pol

ıtica conforme

deﬁnido no algoritmo de combinac¸

ao de regras. Uma obrigac¸

e deﬁnida como uma ac¸

ao para ser

executada uma vez que a decis

ao de autorizac¸

ao est

a completa. Quando um PDP avalia uma pol

ıtica

que cont

em obrigac¸

oes, este retorna estas obrigac¸

oes ao Ponto de Efetivac¸

ao de Pol

ıticas (PEP).

3.4.3 Fluxo de dados no modelo e XACML

Para deﬁnir se o acesso ao recurso requisitado

e permitido, a XACML utiliza um contexto que

facilmente mapeado em requisic¸

oes SAML (Damiani et al., 2002) (sec¸

ao 3.5). O contexto XACML

e deﬁnido em um esquema XML que descreve a representac¸

ao para entradas e sa

ıdas do pondo de

decis

ao de pol

ıticas (PDP). Na Figura 3.8, onde

e mostrado o modelo de ﬂuxo de dados do XACML,

pode ser observado o tratador do contexto (handler) . O modelo realiza passos que podem ser obser-

vados na tabela 3.1 (Moses, 2005). Ao ﬁm, se o acesso

e permitido, o PEP libera o acesso ao recurso,

caso contr

ario o acesso

e negado.

3.5 SAML

A Security Assertion Markup Language (SAML) (Cantor et al., 2005), desenvolvida pelo comit

ecnico de servic¸os de seguranc¸a da OASIS (Organization for the Advancement of Structured Infor-

mation Standards),

e um conjunto de especiﬁcac¸

oes e esquemas XML para expressar informac¸

oes de

autenticac¸

ao, direitos e atributos de usu

arios (Madsen, 2004). Visando garantir a interoperabilidade,

o SAML prov

e uma plataforma neutra, abstraindo o framework de seguranc¸a de uma implementac¸

ou arquitetura em particular.

A SAML 2 introduz um novo suporte ao mundo m

ovel al

em de mecanismos de privacidade (Mad-

sen, 2004). Al

em disso, deﬁne como pseud

onimos podem ser utilizados, estabelecidos e gerenciados

entre provedores para representar principais (gerenciamento federado). Outra caracter

ıstica

e o ge-

renciamento de sess

ao provido pelo protocolo SAML 2, atrav

es do qual as sess

oes providas por uma

autoridade de sess

ao podem ser simultaneamente terminadas. O SAML tamb

em n

ao exige que a

3. Seguranc¸a atrav

es do XML e Servic¸os Web 26

sujeitos

recurso

ambiente

3 requisição

4 contexto

5 atributos ??

10 atributosPDP

1 política

PAP

PEP

requisitor

de acesso

contexto

Tratador de

11 contexto

PIP

6 requisita

atributo

8 atributo

7 atributos do

sujeito

9 recurso

7 atributos do

recurso

7 atributos do

ambiente

12 resposta

13 obrigações

Serviço de

obrigações

2 requisição

de acesso

Figura 3.8: Modelo de Fluxo de dados (Moses, 2005)

informac¸

ao do usu

ario seja gerenciada ou sincronizada em todos os diret

orios das entidades partici-

pantes (acoplamento entre diret

orios).

A maioria dos produtos atuais que prov

eem a propriedade Single Sign On

, evitando a necessidade

de uma nova autenticac¸

ao, s

ao normalmente implementados em formas propriet

arias. Al

em disso,

estes produtos utilizam cookies para armazenar informac¸

oes do usu

ario, que n

ao s

ao transferidas

entre diferentes dom

ınios DNS.

1.Auntentica

2.Acessa o recurso

Usuário Web

Provedor de Indentidade

Provedor de serviço

transportesaerios.com

locadoracarros.com

Figura 3.9: Cen

ario SSO - Identidade Federada

Um usu

ario autentica-se uma

unica vez em um mesmo dom

ınio e mesmo usando servic¸os ou servidores diferentes n

necessita se autenticar novamente.

3. Seguranc¸a atrav

es do XML e Servic¸os Web 27

1 O Ponto de Administrac¸

ao de Pol

ıticas (PAP) deﬁne as pol

ıticas e as deixa dispon

ıveis no Ponto

de Decis

ao de Pol

ıticas (PDP).

2 O requisitor de acesso envia a requisic¸

ao de acesso ao Ponto de Efetivac¸

ao de Pol

ıticas (PEP).

3 O PEP envia a requisic¸

ao de acesso ao tratador de contexto no seu formato de requisic¸

ao nativo,

opcionalmente incluindo os atributos do sujeito, do recurso, da ac¸

ao e do ambiente.

4 O tratador de contexto constr

oi o contexto de uma requisic¸

ao XACML e o envia ao PDP.

5 O PDP requisita os atributos adicionais necess

arios ao tratador de contexto.

6 O tratador de contexto requisita ao Ponto de Informac¸

oes de Pol

ıticas (PIP) os atributos necess

arios.

7 O PIP obt

em estes atributos requisitados.

8 O PIP retorna estes atributos ao tratador de contexto.

9 Opcionalmente o tratador de contexto adiciona o recurso ao contexto.

10 De posse dos atributos, o tratador de contexto os envia ao PDP.

11 O PDP retorna ao tratador de contexto o contexto de resposta que cont

em a decis

ao de autorizac¸

ao.

12 O tratador de contexto traduz o contexto de resposta para o formato de resposta nativo e envia o

resultado desta traduc¸

ao para o PEP.

13 O PEP cumpre as obrigac¸

oes.

Tabela 3.1: Modelo de Fluxo de dados

As asserc¸

oes de autenticac¸

ao SAML possibilitam o Single Sign On atrav

es de uma autenticac¸

em um provedor de identidade de forma que o acesso a servic¸os e recursos nos provedores de servic¸o,

dispersos em v

arios dom

ınios administrativos, sejam realizados sem que uma autenticac¸

ao adicio-

nal seja necess

aria. Ou seja, a responsabilidade de gerenciamento de identidades

e repassada para

o provedor de identidade, j

a que este gerenciamento

e mais compat

ıvel com o mesmo do que com

o provedor de servic¸o, permitindo assim que usu

arios consolidem muitas identidades locais em uma

unica (ou pelo menos um conjunto reduzido de) identidade federada que atravesse dom

ınios adminis-

trativos.

Provedor de Indentidade

transportesaerios.com

Provedor de serviço

locadoracarros.com

Provedor de serviço

hotel.com

Usuário Web

Figura 3.10: Ligac¸

ao entre contas

O caso de uso original suportado pela SAML 1.0, ilustrado na Figura 3.9,

e o caso de uso sin-

3. Seguranc¸a atrav

es do XML e Servic¸os Web 28

gle sign on

, em que um usu

ario possui uma sess

ao de logon (um contexto de seguranc¸a) em um

determinado web site e esta sess

e repassada de forma transparente ou expl

ıcita para outro web

site em um dom

ınio diferente (Madsen, 2004). Para isso o web site original ou provedor de identi-

dade declara ao provedor de servic¸o que o usu

ario

e conhecido e prov

e o nome ou os atributos de

sess

ao do usu

ario. O provedor de servic¸o (locadoracarros.com) que conﬁa no provedor de identidade

(transportesaereos.com) cria uma sess

ao para o usu

ario com base no nome ou nos atributos de sess

repassados.

Um outro de caso de uso

e a ligac¸

ao entre contas, ilustrado na Figura 3.10. Neste caso de uso,

o usu

ario

e registrado em dois provedores de servic¸os diferentes (locadoracarros.com e hotel.com),

por

em com nomes diferentes. No locadoracarros.com, o usu

ario est

a registrado como deveria e no

hotel.com como daniellav.

3.5.1 Arquitetura SAML

A SAML consiste de um conjunto de componentes que permitem a transfer

encia e troca de

informac¸

oes de identidade, autenticac¸

ao e autorizac¸

ao entre organizac¸

oes aut

onomas. A especiﬁcac¸

SAML deﬁne a estrutura e o conte

udo de asserc¸

oes SAML, que transportam declarac¸

oes sobre um

principal. Estas asserc¸

oes s

ao um conjunto de declarac¸

oes sobre caracter

ısticas e atributos de uma en-

tidade, dadas por uma autoridade SAML. S

ao deﬁnidos tr

es tipos de asserc¸

oes SAML (Cantor et al.,

2005):

• Autenticac¸

ao: O emissor da asserc¸

ao declara que o sujeito foi autenticado.

• Atributo: Declara informac¸

oes espec

ıﬁcas do sujeito (como por exemplo, limite de cr

edito

para com

ercio eletr

onico entre outros) e credenciais do mesmo.

• Autorizac¸

ao: Declarar se o sujeito pode ou est

a autorizado a acessar um determinado recurso,

com base nas asserc¸

oes de autenticac¸

ao e de atributos.

Como estas asserc¸

oes SAML s

ao transportadas

e deﬁnido nos protocolos SAML, que deﬁnem

os pares de requisic¸

ao e resposta para a obtenc¸

ao das asserc¸

oes SAML e o gerenciamento federado

(Hughes e Maler, 2004). Os bindings deﬁnem como estes protocolos SAML s

ao transportados sobre

os protocolos de mensagens (HTTP ou SOAP) e a combinac¸

ao entre os protocolos SAML juntamente

com os bindings e as estruturas de asserc¸

oes criam os perﬁs SAML que suportam os casos de uso. A

Figura 3.11 ilustra como os componentes SAML se relacionam.

3.5.2 A SAML e outros padr

oes e iniciativas

A Liberty Alliance (www.projectliberty.org/)

e um cons

orcio industrial de deﬁnic¸

oes de padr

oes

para identidade federada. O ID-Web Services Framework, uma plataforma de seguranc¸a para servic¸os

Atravessam dom

ınios administrativos diferentes atrav

es da autenticac¸

unica (SSO)

3. Seguranc¸a atrav

es do XML e Servic¸os Web 29

Asserções

Informações de atributos, autorização e autenticação

e gerenciamento federado

Pares de requisição e resposta para obtenção de asserções

Protocolos

Como protocolos SAML são mapeados para protocoloes de mensagens

Bindings

Como as asserções, bindings e protocolos SAML são combinados

Perfis

para suportar um caso de uso em particular

Figura 3.11: Componentes SAML (Hughes e Maler, 2004)

Web deﬁnido pela Liberty Alliance, usa asserc¸

oes SAML como formatos de tokens de seguranc¸a

atrav

es dos quais as informac¸

oes de autenticac¸

ao e autorizac¸

ao associadas a atores de servic¸os Web

ao comunicadas entre estes.

Shibboleth (shibboleth.internet2.edu)

e uma iniciativa da Internet2 para compartilhamento de re-

cursos entre pesquisadores e estudantes de instituic¸

oes de ensino. O Shibboleth trac¸a o perﬁl de seus

requisitos inserindo a ger

encia de privacidade em asserc¸

oes SAML.

A XACML (Moses, 2005) (sec¸

ao 3.5)

e uma linguagem baseada em XML para controle de acesso

padronizada pela OASIS que descreve uma linguagem de controle de acesso e uma linguagem de

requisic¸

oes de respostas. A linguagem de pol

ıtica

e usada para expressar pol

ıticas de controle de

acesso e a linguagem de requisic¸

ao resposta expressam consultas sobre um acesso em particular e as

respostas para estas consultas. A XACML e a SAML s

ao complementares. Uma pol

ıtica XACML

pode especiﬁcar o que um provedor deve fazer para receber uma asserc¸

ao SAML.

WS-Security (Nadalin et al., 2004) (sec¸

ao 3.7.4)

e um padr

ao OASIS que especiﬁca extens

oes

de seguranc¸a SOAP provendo integridade e conﬁdencialidade de dados. WS-Security deﬁne um fra-

mework que torna segura estas mensagens SOAP. Existem diferentes perﬁs do WS-Security para dife-

rentes formatos de tokens de seguranc¸a, por exemplo: certiﬁcados X.509, tickets Kerberos e asserc¸

oes

SAML.

3.6 XKMS

Aplicac¸

oes que fazem uso da cifragem e assinaturas XML utilizam uma soluc¸

ao PKI baseada em

X.509, PGP, ou SPKI. Estas infra-estruturas de chaves p

ublicas (PKIs) permitem ligar um nome a uma

chave p

ublica. Entretanto, quando uma aplicac¸

ao necessita interagir com uma outra aplicac¸

ao que

use uma PKI diferente da sua, as duas aplicac¸

oes ter

ao que entender as duas soluc¸

oes PKI adotadas

3. Seguranc¸a atrav

es do XML e Servic¸os Web 30

(Verma, 2004). Por estes motivos,

e desej

avel que a complexidade da PKI seja transferida de um

lugar onde

e dif

ıcil a ger

encia (a aplicac¸

ao cliente) para o servic¸o especializado em ger

encia da PKI.

A XML Key Management Speciﬁcation (XKMS) (Hallam-Baker, 2004) deﬁne protocolos para o

registro, localizac¸

ao e validac¸

ao de informac¸

oes de chaves p

ublicas, al

em da possibilidade de gerac¸

de pares de chaves. O prop

osito do XKMS

e facilitar o gerenciamento da PKI, abstraindo a sua

complexidade. Para alcanc¸ar este objetivo o XKMS deﬁne uma interface baseadas em servic¸os Web

para uma PKI (Naedele, 2003), conforme pode ser observado na Figura 3.12:

Aplicação Serviço Web XKMS PKI

Figura 3.12: Interface ao PKI (O’Neill, 2003)

Esta interface elimina a necessidade da aplicac¸

ao de entender a sintaxe e a sem

antica complexa da

PKI, podendo assim utilizar diferentes soluc¸

oes de PKI sem a necessidade de modiﬁcar a aplicac¸

ao.

A especiﬁcac¸

ao XKMS se divide em duas partes: especiﬁcac¸

ao XML do servic¸o de informac¸

ao de

chaves (XML Key Information Service Speciﬁcation X-KISS) e a especiﬁcac¸

ao XML do servic¸o de

registro de chaves (XML Key Registration Service Speciﬁcation X-KRSS).

3.6.1 Especiﬁcac¸

ao XML do Servic¸o de Informac¸

ao de Chaves (X-KISS)

O X-KISS prov

e um mecanismo de processamento de informac¸

oes de chaves p

ublicas associ-

adas

as assinaturas e cifragens XML ou qualquer outro uso do elemento ds:Keyinfo (Hallam-Baker,

2004). O elemento ds:KeyInfo

e deﬁnido na especiﬁcac¸

ao de assinatura XML (Bartel, 2002) como um

elemento opcional que cont

em informac¸

oes sobre a chave p

ublica que assinou o documento XML.

Esta informac¸

ao pode ser a chave em si, um nome de chave, um certiﬁcado X.509, um identiﬁca-

dor de chave PGP entre outras informac¸

oes de gerenciamento. Atrav

es do conte

udo deste elemento

o receptor do documento XML assinado ou cifrado pode obter os dados necess

arios para validar a

assinatura.

Ao processar a informac¸

ao contida em um elemento ds:KeyInfo para a aplicac¸

ao cliente, um

servic¸o XKMS libera a mesma da sintaxe e complexidade das subcamadas PKI usadas para esta-

belecer relacionamentos de conﬁanc¸a (Hallam-Baker, 2004). Para isso, a aplicac¸

ao cliente repassa

ao servic¸o XKMS a informac¸

ao da chave que assinou ou cifrou estes dados e o mesmo processa a

informac¸

ao ou responde se a chave

e v

alida ou n

ao. O X-KISS suporta duas operac¸

oes (Verma, 2004):

• Localizar: esta operac¸

ao localiza informac¸

oes relacionadas ao elemento ds:KeyInfo, por

esta informac¸

ao n

e validada. Para obter estas informac¸

oes, o servic¸o XKMS pode usar

dados locais ou pode fazer uso de outros servic¸os XKMS.

• Validar: esta operac¸

ao al

em de localizar as informac¸

oes relacionadas a um elemento ds:KeyInfo,

tamb

em valida estas informac¸

oes. O servic¸o XKMS pode fornecer ao cliente uma declarac¸

especiﬁcando o estado da ligac¸

ao da chave p

ublica a outros dados, por exemplo, um nome ou

um conjunto de atributos estendidos (Hallam-Baker, 2004).

3. Seguranc¸a atrav

es do XML e Servic¸os Web 31

3.6.2 Especiﬁcac¸

ao XML do servic¸o de Registro de Chaves (X-KRSS)

O X-KRSS prov

e operac¸

oes para o registro e gerenciamento de uma chave p

ublica. Ou seja, uma

aplicac¸

ao cliente pode requisitar a um servic¸o XKMS que registre uma chave p

ublica associando uma

informac¸

ao, sendo esta um nome, um identiﬁcador ou atributos estendidos,

a mesma. O gerencia-

mento desta informac¸

ao associada a chave p

ublica

e tamb

em realizado atrav

es deste mecanismo. O

X-KRSS suporta quatro operac¸

oes (Hallam-Baker, 2004):

• Registrar: esta operac¸

ao associa uma informac¸

ao a uma chave p

ublica. A chave pode ser

gerada pela aplicac¸

ao cliente ou pelo servic¸o XKMS. Caso a chave tenha sido gerada pela

aplicac¸

ao cliente, a mesma deve provar a posse da chave. Se a chave for gerada pelo servic¸o, o

mesmo envia a chave privada para o usu

ario. O servic¸o XKMS tamb

em permite que uma chave

privada seja registrada, caso o par de chaves tenha sido gerado pelo mesmo.

• Recuperar: esta operac¸

ao recupera chaves privadas que tenham sido registradas previamente.

E semelhante a operac¸

ao de registro e s

o pode ser executada quando a chave privada tiver sido

registrada previamente e gerada pelo XKRSS.

• Reemitir: esta operac¸

ao reemite associac¸

oes de informac¸

oes a chaves p

ublicas, realizadas

previamente na operac¸

ao de registro. A reemiss

ao permite a gerac¸

ao de novas credenciais na

PKI subjacente.

• Revogar: esta operac¸

ao revoga uma chave previamente registrada e qualquer credencial cifrada

associada a esta. Revogar esta associac¸

ao signiﬁca que esta n

e mais conﬁ

avel para nenhum

uso da aplicac¸

ao.

3.6.3 Protocolos de Trocas de Mensagens

O protocolo de trocas de mensagens XKMS consiste de pares de requisic¸

ao e resposta. Os mo-

dos de processamento destas mensagens podem ser s

ıncronos ou ass

ıncronos. No processamento

ıncrono, conforme pode ser visto na Figura 3.13, o servic¸o XKMS responde ao pedido sem emitir

mais respostas com respeito a esta requisic¸

ao.

Cliente Serviço XKMS

requisição

resposta

Tempo

Figura 3.13: Processamento S

ıncrono

a no processamento ass

ıncrono (Figura 3.14), o servic¸o XKMS n

ao completa a requisic¸

ao ime-

diatamente, notiﬁca a aplicac¸

ao cliente de que o pedido ainda n

ao foi satisfeito e que respostas

3. Seguranc¸a atrav

es do XML e Servic¸os Web 32

subseq

uentes ser

ao enviadas. O processamento ass

ıncrono pode ser usado para permitir ao servic¸o

XKMS intervir durante o processamento do pedido.

requisição

resposta pendente

Tempo

notificação

resposta

requisição pedente

Cliente Serviço XKMS

Figura 3.14: Processamento Ass

ıncrono

Por exemplo, pode ser solicitado ao mesmo a veriﬁcac¸

ao e aprovac¸

ao de todos os pedidos de

registro X-KRSS antes que sejam processados. Uma aplicac¸

ao cliente pode notiﬁcar a um servic¸o

XKMS de que esta aceita processamento ass

ıncrono de um pedido na mensagem de requisic¸

ao.

O servic¸o XKMS que recebe este pedido pode responder imediatamente ou n

ao. Caso n

ao res-

ponda imediatamente, este avisa a aplicac¸

ao cliente na mensagem de resposta. O modo atrav

es do

qual a aplicac¸

ao cliente toma conhecimento de que o servic¸o completou o processamento n

e espe-

ciﬁcado pelo XKMS. Uma forma seria atrav

es de uma mensagem de notiﬁcac¸

ao. Ap

os a aplicac¸

cliente receber a notiﬁcac¸

ao esta envia a requisic¸

ao pendente ao servic¸o XKMS, que retorna a res-

posta da mesma. Um servic¸o XKMS s

o deve retornar uma mensagem pendente quando especiﬁcado

no pedido correspondente. Ou seja, se o servic¸o receber um pedido que n

ao pode ser processado

imediatamente este deve notiﬁcar o cliente na mensagem de resposta.

O servic¸o XKMS pode utilizar um protocolo de requisic¸

ao de duas fases para se proteger contra

negac¸

ao de servic¸o. Este protocolo permite ao servic¸o XKMS executar uma autenticac¸

ao fraca da

fonte de requisic¸

oes XKMS (aplicac¸

ao cliente). O Protocolo de duas fases consiste nas seguintes

trocas, que podem ser observadas na Figura 3.15:

• Na primeira fase a aplicac¸

ao cliente envia a requisic¸

ao e o servic¸o XKMS responde a esta com

o nonce

• Na segunda fase a aplicac¸

ao reapresenta a requisic¸

ao original juntamente com o nonce emitido

previamente pelo servic¸o XKMS.

Uma aplicac¸

ao cliente pode avisar ao servic¸o XKMS que suporta o protocolo de requisic¸

ao de

duas fases de forma semelhante ao processamento ass

ıncrono. Um servic¸o XKMS s

o deve retornar o

nonce para a aplicac¸

ao cliente quando especiﬁcado no pedido correspondente. Ou seja, se o servic¸o

Valor aleat

orio que

e enviado de um servidor ou aplicativo, solicitando autorizac¸

ao do usu

ario.

3. Seguranc¸a atrav

es do XML e Servic¸os Web 33

Serviço XKMS

requisição

Tempo

resposta

requisição + nonce

resposta + nonce

Cliente

2ª fase

1ª fase

Figura 3.15: Protocolo de Duas Fases

XKMS receber um pedido que exija o protocolo de duas fases e a aplicac¸

ao cliente n

ao especiﬁcou

que aceita o mesmo, o servic¸o XKMS deve enviar uma mensagem de resposta notiﬁcando a aplicac¸

cliente que este protocolo

e necess

ario. O servic¸o tamb

em deve veriﬁcar se o valor do Nonce especi-

ﬁcado na segunda fase da requisic¸

ao foi gerado recentemente pelo servic¸o XKMS, ou se este j

a n

foi enviado anteriormente.

Um servic¸o XKMS tamb

em suporta requisic¸

oes compostas, permitindo que m

ultiplas requisic¸

oes

sejam feitas ao mesmo tempo. Estas consistem de uma requisic¸

ao externa e uma ou mais requisic¸

oes

internas. N

ao h

a uma ordem impl

ıcita entre as requisic¸

oes internas. A sem

antica de um conjunto de

requisic¸

oes enviadas em separado ou a de uma

unica requisic¸

ao composta

e a mesma. O retorno de

uma requisic¸

ao composta

e uma resposta composta que consiste de uma resposta externa e zero ou

mais respostas internas.

3.7 Servic¸os Web

Conforme deﬁnido em (Booth, 2004), um servic¸o Web

e um sistema de software desenvolvido

para suportar interoperabilidade de interac¸

ao entre m

aquinas sobre a rede. Os servic¸os Web deﬁ-

nem pontos de entrada para os sistemas internos das organizac¸

oes, al

em de empacotar componentes

intra-organizacionais provendo conectividade entre aplicac¸

oes inter-organizacionais aut

onomas e he-

terog

eneas (Medjahed et al., 2003).

Para isso, estes servic¸os, prov

eem um sistem

atico e extens

ıvel framework para interac¸

ao entre

aplicac¸

oes, constru

ıdo sobre os protocolos web e baseado nos padr

oes XML. O framework de servic¸os

Web

e dividido em tr

areas (Curbera, 2002): protocolos de comunicac¸

ao (SOAP), descric¸

oes de

servic¸os (WSDL) e descoberta de servic¸os (UDDI).

3. Seguranc¸a atrav

es do XML e Servic¸os Web 34

3.7.1 SOAP

O SOAP (Simple Object Access Protocol) prov

e um mecanismo simples e leve para troca de

informac¸

ao estruturada e tipada em um ambiente distribu

ıdo (Gudgin et al., 2003). Este protocolo

utiliza tecnologias XML como suporte para a construc¸

ao de mensagens, fazendo uso de uma vari-

edade de protocolos subjacentes para transporte das mesmas. Este suporte

e desenvolvido para ser

independente de qualquer modelo de programac¸

ao em particular, ou de qualquer outra sem

antica

espec

ıﬁca de implementac¸

ao (Gudgin et al., 2003).

A princ

ıpio, o SOAP

e um paradigma de troca de mensagens de um s

o sentido, por

em aplicac¸

oes

podem criar padr

oes de interac¸

oes mais complexas, como por exemplo requisic¸

ao/resposta, requisic¸

ao/

ultiplas respostas, entre outras. Estes padr

oes podem ser obtidos atrav

es da combinac¸

ao de trocas

one-way, adicionando ainda as caracter

ısticas providas pelo protocolo subjacente ou informac¸

oes

espec

ıﬁcas de cada aplicac¸

ao. Conforme pode ser visualizado na Figura 3.16, o formato de uma men-

sagem SOAP cont

em um elemento chamado envelope SOAP que por sua vez cont

em dois subele-

mentos: cabec¸alho (elemento opcional) e corpo (elemento obrigat

orio). Dentro destes dois elementos

ainda podem haver outros subelementos chamados blocos de cabec¸alho e subelementos do corpo,

respectivamente.

Envelope SOAP

Corpo

Cabeçalho

Sublemento do corpo

Bloco de cabeçalho

Figura 3.16: Mensagem SOAP

No elemento cabec¸alho est

ao contidas informac¸

oes de controle que incluem a passagem de di-

retivas ou informac¸

oes contextuais relacionadas ao processamento da mensagem. Isto permite que

uma mensagem SOAP possa ser estendida para atender requisitos de uma aplicac¸

ao espec

ıﬁca (Mi-

tra, 2003). O elemento corpo deﬁne a troca de informac¸

ao entre o emissor inicial e o receptor ﬁnal,

ou seja,

e nos subelementos do corpo onde est

ao contidas as informac¸

oes trocadas entre as partes

emissora e receptora. Estes subelementos do corpo tamb

em podem ser utilizados para transportar um

erro, ou informac¸

oes obrigat

orias esperadas pelo receptor ﬁnal da mensagem. O SOAP 1.2 tamb

comporta funcionalidades para a chamada remota de procedimento usando a extensibilidade e ﬂexi-

bilidade do XML (Gudgin et al., 2003).

3. Seguranc¸a atrav

es do XML e Servic¸os Web 35

3.7.2 WSDL

A Web Services Description Language (WSDL) (Chinnici, 2005) prov

e um modelo e um formato

XML para descric¸

ao de servic¸os Web. Esta linguagem permite separar a descric¸

ao das funcionali-

dades oferecidas por um servic¸o das representac¸

oes concretas que descrevem, por exemplo ”como”e

”onde”tal funcionalidade

e oferecida. Esta separac¸

e realizada para promover a reusabilidade de

descric¸

oes e separar interesses de projetos independentes.

WSDL deﬁne uma descric¸

ao abstrata em termos de mensagens trocadas na interac¸

ao de um

servic¸o. H

a tr

es principais componentes nesta descric¸

ao (Curbera, 2002): vocabul

ario, a mensagem

e a interac¸

ao. No vocabul

ario encontram-se as deﬁnic¸

oes de tipo usadas na WSDL. As mensagens

(message) s

ao descritas em um formato independente, usando um sistemas de tipos, como os esque-

mas XML. Um exemplo de uma descric¸

ao abstrata pode ser observada na Figura 3.17. Um tipo de

porta (portType)

e uma colec¸

ao de operac¸

oes que s

ao suportadas por um ponto de acesso, onde cada

operac¸

ao (operation) representa o padr

ao de trocas de mensagens que o servic¸o Web suporta. As

mensagens (message) s

ao combinadas nos elementos operac¸

ao (operation) e tipo de porta (portType)

para deﬁnir interac¸

oes.

output name = "TesteResponse"

input name = "TesteRequest"

operation name="Teste"

portType name = "TestePortType"

message name = "TesteResponse"

message name = "TesteRequest"

Figura 3.17: Descric¸

ao abstrata

As informac¸

oes concretas de ligac¸

ao deﬁnem quais protocolos de comunicac¸

ao utilizar na trans-

fer

encia de mensagens (SOAP sobre HTTP, por exemplo), como concretizar interac¸

oes com o servic¸o

sobre este protocolo e os enderec¸os de rede onde o mesmo est

a dispon

ıvel. Na descric¸

ao concreta,

conforme pode ser visto na Figura 3.18, um elemento ligac¸

ao (binding) especiﬁca o transporte e o

formato detalhado para uma ou mais mensagens, um ponto de acesso (port) associa um enderec¸o de

rede a uma ligac¸

ao (binding) e um servic¸o (service) agrupa os pontos de acesso que implementam

uma interface comum.

3.7.3 UDDI

Para que um servic¸o Web seja utilizado,

e necess

ario que os potenciais usu

arios tenham conheci-

mento de sua interface, da sua sem

antica, da sua chamada e a sua localizac¸

ao. O objetivo da Universal

Description Discovery and Integration (UDDI) (Clement et al., 2004) ou Servic¸o para a Localizac¸

e Publicac¸

ao de Servic¸os

e a deﬁnic¸

ao dos conjuntos de servic¸os que suporta a descric¸

ao do neg

ocio,

3. Seguranc¸a atrav

es do XML e Servic¸os Web 36

soap:binding transport = "www.teste.com"

operation name = "Teste"

binding name = "TesteSoapBinding" type = "TestePortType"

service name = "TesteService"

port name = "TestePort" binding = "TesteSoapBinding"

Figura 3.18: Descric¸

ao concreta

a descric¸

ao de como o servic¸o est

a dispon

ıvel e as interfaces t

ecnicas utilizadas para acesso a estes

servic¸os. O Servic¸o para a Localizac¸

ao e Publicac¸

ao de Servic¸os est

a baseado em um conjunto de

padr

oes (HTTP, XML, esquema XML e SOAP) e prov

e uma infra-estrutura fundamental e intero-

per

avel para ambientes de software baseados em servic¸os Web dispon

ıveis ao p

ublico ou expostos

internamente nas organizac¸

oes.

Um registro UDDI oferece um mecanismo para classiﬁcar, catalogar e gerenciar servic¸os Web

para que os mesmos possam ser descobertos e utilizados. Esta classiﬁcac¸

ao dos servic¸os Web

feita atrav

es do esquema XML do UDDI. Este esquema deﬁne quatro estruturas para a classiﬁcac¸

de informac¸

oes t

ecnicas que uma pessoa necessita saber a ﬁm de usar servic¸os Web parceiros. Na

Figura 3.19 encontra-se a hierarquia da informac¸

ao e os nomes dos elementos XML chaves que s

utilizados:

ponteiros URL para especificações

nome, descriçãonome, contato, descrição

identificadores, categorias

informação técnica

informação técnica

Figura 3.19: Estrutura de dados de um registro UDDI (Clement et al., 2004)

• businessEntity: Elemento XML que suporta publicac¸

ao e descoberta de informac¸

ao sobre os

registros de neg

ocio UDDI. Estas informac¸

oes permitem que pesquisas possam ser realizadas

para localizar neg

ocios que servem a uma ind

ustria em particular, categoria de produto, ou

quais est

ao localizado dentro de uma regi

ao geogr

aﬁca espec

ıﬁca.

• businessService: Elemento XML que

e utilizado para agrupar servic¸os Web relacionados a

processos de neg

ocio ou categorias de servic¸os. Exemplos de processos de neg

ocio que podem

3. Seguranc¸a atrav

es do XML e Servic¸os Web 37

ser agrupados, s

ao os servic¸os de compra e os servic¸os de transporte.

• bindingTemplate: Elemento XML que cont

em informac¸

ao relevante aos aplicativos que s

conectados e se comunicam com servic¸os Web remotos. Esta informac¸

ao inclui enderec¸o de

contato, assim como suporte a opc¸

oes de informac¸

ao que podem ser utilizados para descrever

servic¸os hospedados e servic¸os que requerem valores adicionais para serem descobertos an-

tes da invocac¸

ao do servic¸o. Caracter

ısticas adicionais s

ao deﬁnidas para permitir opc¸

oes de

roteamento complexo como balanc¸o de carga.

• tModel: Elemento cont

em dados sobre a especiﬁcac¸

ao, incluindo seu nome, organizac¸

ao que

o publicou e ponteiros URL para sua especiﬁcac¸

ao real. O conjunto destes elementos formam

uma impress

ao digital que pode ser utilizada para reconhecer um servic¸o Web que implementa

um comportamento em particular e uma interface de programac¸

ao.

3.7.4 WS Security

O projeto de servic¸os Web prov

e um n

ıvel de abstrac¸

ao para diferentes plataformas e linguagens

de programac¸

ao, permitindo que sistemas de organizac¸

oes diferentes se comuniquem de forma aberta.

em de utilizar plataformas e linguagens de programac¸

ao diferentes, estas organizac¸

oes podem uti-

lizar diferentes tecnologias de seguranc¸a. Para prover um n

ıvel de abstrac¸

as organizac¸

oes que

utilizam diferentes tecnologias surgiu a especiﬁcac¸

ao Web Services Security (WS Security) (O’Neill,

2003).

Uma mensagem SOAP pode sofrer v

arios tipos de ataques, entre estes: modiﬁcac¸

ao (uma men-

sagem modiﬁcada), interceptac¸

ao (leitura da mensagem por uma pessoa n

ao autorizada) ou ainda,

personiﬁcac¸

ao (uma pessoa n

ao autorizada envia mensagens falsas a um servic¸o Web). Para proteger-

se destes ataques e autenticar as mensagens SOAP, a WS Security especiﬁca um modelo de seguranc¸a

de mensagens abstratas unindo tokens de seguranc¸a

em conjunto com assinaturas digitais.

O padr

ao WS Security prop

oe extens

oes

as mensagens SOAP que podem ser usadas na construc¸

de servic¸os Web seguros implementando integridade e conﬁdencialidade de mensagens (Nadalin et al.,

2004). A especiﬁcac¸

ao prov

e tr

es principais mecanismos: a propagac¸

ao de tokens de seguranc¸a

como parte de uma mensagem, a integridade e a conﬁdencialidade de mensagens. A integridade e a

conﬁdencialidade das mensagens s

ao garantidas pelas assinatura e cifragem XML (XML Signature

e XML Encryption sec¸

ao 3.2 e 3.3) (Bartel, 2002) (Imamura, 2002) respectivamente. Estes servic¸os

podem ser usados em conjunto com outras extens

oes de servic¸os Web e protocolos de alto n

ıvel

espec

ıﬁcos da aplicac¸

ao para acomodar uma larga variedade de modelos e tecnologias de seguranc¸a,

entretanto, n

ao garantem uma soluc¸

ao completa para a seguranc¸a de servic¸os Web. A seguir ser

apresentadas outras especiﬁcac¸

oes sobre o protocolo SOAP para garantir a seguranc¸a de servic¸os

Web.

Um Token de seguranc¸a representa uma colec¸

ao de um ou mais direitos. (Nadalin et al., 2004)

3. Seguranc¸a atrav

es do XML e Servic¸os Web 38

3.7.4.1 WS-Policy

O WS-Policy (Bajaj, 2004) permite que organizac¸

oes especiﬁquem requisitos de seguranc¸a em

seus servic¸os Web. Estes requisitos de seguranc¸a incluem os algoritmos de suporte a cifragem e

assinatura digital, atributos de privacidade (como quais par

ametros devem ser cifrados) e como esta

informac¸

ao pode ser ligada a um servic¸o Web. O objetivo principal da WS-Policy

e prover mecanismos

necess

arios para permitir que aplicac¸

oes web especiﬁquem informac¸

ao de pol

ıtica. A WS-Policy

tamb

em deﬁne uma pol

ıtica como uma colec¸

ao de pol

ıticas alternativas, onde cada pol

ıtica alternativa

e uma colec¸

ao de asserc¸

oes.

3.7.4.2 WS-Trust

A especiﬁcac¸

ao WS-Trust (Anderson et al., 2005b) deﬁne mecanismos gerais para trocas de men-

sagens durante a aquisic¸

ao ou comunicac¸

ao de tokens dentre diferentes dom

ınios de conﬁanc¸a. Esta

especiﬁcac¸

ao usa os mecanismos b

asicos de mensagens seguras deﬁnidos no WS-Security e deﬁne pri-

mitivas adicionais e extens

oes para troca de token de seguranc¸a permitindo a emiss

ao e disseminac¸

de credenciais dentro de diferentes dom

ınios de conﬁanc¸a. Entretanto, cada uma das partes precisa

determinar se pode conﬁar nas credenciais declaradas pela outra parte.

A WS-Trust descreve um modelo para que se obtenha um relacionamento de conﬁanc¸a, tanto

direto, quanto por meio de agentes (incluindo terceiros e intermedi

arios). Este modelo

e baseado em

um processo no qual um servic¸o Web indica ao cliente um conjunto de direitos, descritos atrav

es do

WS-Policy. Se a mensagem enviada por este cliente n

ao provar o conjunto de direitos, a mesma

ignorada pelo servic¸o. Caso o cliente n

ao possua os tokens necess

arios para provar a um servic¸o os

direitos exigidos, este pode entrar em contato com o servic¸o de tokens de seguranc¸a e requisit

a-los.

O servic¸o de tokens tamb

em pode exigir seu pr

oprio conjunto de direitos para autenticar e autorizar a

requisic¸

ao destes tokens.

em disso, o servic¸o de tokens pode formar a base de conﬁanc¸a para emiss

ao e alcance dos

tokens que podem ser usados para suportar relacionamentos de conﬁanc¸a entre diferentes dom

ınios.

Ou seja, o servic¸o n

ao necessita conﬁar na autoridade que emitiu o token original, desde que conﬁe

no servic¸o que est

a comprometido na troca do novo token.

3.7.4.3 WS-SecureConversation

A WS-Secure Conversation (Anderson et al., 2005a) deﬁne extens

oes da WS-Security e da WS-

Trust para prover comunicac¸

ao segura, al

em de mecanismos para estabelecer e compartilhar contextos

de seguranc¸a

, assim como estabelecer e compartilhar as chaves derivadas do estabelecimento destes

contextos. Al

em disso, a WS-Secure Conversation tamb

em descreve como um servic¸o pode trocar de

contexto de uma forma segura.

colec¸

oes de direitos sobre atributos de seguranc¸a e dados relacionados

3. Seguranc¸a atrav

es do XML e Servic¸os Web 39

Ao estabelecer um contexto, um servic¸o pode suportar al

em de tokens de seguranc¸a usando tec-

nologia de chaves assim

etricas, tokens de seguranc¸a utilizando chaves sim

etricas. Ou seja, inicia-se

o processo com o uso de uma chave assim

etrica para negociar uma chave sim

etrica, que pode ser

utilizada por uma s

erie de mensagens SOAP. Isto signiﬁca que cada mensagem SOAP n

ao tem que

passar por um processo longo e intenso de autenticac¸

ao em n

ıvel de mensagens (O’Neill, 2003).

3.7.4.4 WS-Federation

A especiﬁcac¸

ao WS-Federation (Bajaj, 2003) deﬁne mecanismos para permitir que diferentes

dom

ınios de seguranc¸a sejam unidos usando mecanismos diferentes ou semelhantes permitindo conﬁanc¸a

intermediada de identidades, atributos e autenticac¸

ao entre servic¸os Web participantes nestes dom

ınios.

A WS-Federation age uma camada acima das especiﬁcac¸

oes WS-Policy, WS-Trust e

WS-SecureConversation, que s

ao usadas para determinar quais tokens s

ao consumidos e como re-

quisit

a-los de um servic¸o de emiss

ao de tokens de seguranc¸a, indicando como relacionamentos de

conﬁanc¸a s

ao gerenciados.

3.8 Conclus

ao do Cap

ıtulo

Neste cap

ıtulo foram apresentados os padr

oes de seguranc¸a para o XML. Foram vistas as especiﬁ-

cac¸

oes para garantir a integridade, conﬁdencialidade de documentos XML, al

em da especiﬁcac¸

ao de

um servic¸o que funciona como uma interface para PKIs. Esquemas XML para a troca de informac¸

oes

de autenticac¸

ao e autorizac¸

ao e para a deﬁnic¸

ao de pol

ıticas de autorizac¸

ao tamb

em foram apresen-

tados. Al

em disso, foram expostos os padr

oes de seguranc¸a para servic¸os Web deﬁnidos sobre o

protocolo SOAP.

Cap

ıtulo 4

Modelo de ger

encia para o SPKI atrav

do XKMS

4.1 Introduc¸

O modelo de conﬁanc¸a, fundamentado na formac¸

ao de cadeias de autorizac¸

ao do SPKI/SDSI,

deﬁne pol

ıticas de autorizac¸

ao distribu

ıdas atrav

es da cadeia de conﬁanc¸a formada pela delegac¸

de direitos, propagada atrav

es dos certiﬁcados de autorizac¸

ao de um servidor at

e um cliente. Este

modelo

e fortemente focado no principal que deseja acessar a um recurso (Santin, 2004).

No cap

ıtulo 2, uma extens

ao do modelo de conﬁanc¸a SDSI/SPKI chamada de Federac¸

ao SPKI

(Santin, 2004) foi apresentada. A Federac¸

ao SPKI

e uma entidade que re

une principais com interesses

aﬁns e atua como um agente facilitador na localizac¸

ao de certiﬁcados e principais, pois permite o com-

partilhamento do acesso ao seu reposit

orio de certiﬁcados. Neste modelo foi introduzido o gerente

de certiﬁcados (GC), que

e principalmente um reposit

orio de cadeias de certiﬁcados de autorizac¸

SPKI/SDSI, que serve apenas ao grupo de principais de sua Federac¸

ao e n

ao participa ativamente de

nenhuma cadeia de autorizac¸

ao (Santin et al., 2003).

Ao integrar a noc¸

ao de Federac¸

ao SPKI a infra-estrutura do SPKI/SDSI, os clientes passam a ter

uma alternativa para a busca de cadeias apropriadas de modo a obter o acesso desejado. Este modelo

de ger

encia visa preservar a ﬁlosoﬁa adotada no modelo SPKI/SDSI no qual o principal que deseja

obter acesso a algum recurso,

e inteiramente respons

avel pela busca das cadeias de certiﬁcados que

lhe fornec¸am o direito de acesso. No entanto, esta ﬁlosoﬁa sobrecarrega o cliente, j

a que este necessita

entender a complexidade da PKI, al

em de ser o respons

avel pela busca de certiﬁcados.

Por outro lado, a especiﬁcac¸

ao XKMS deﬁne um servic¸o Web de conﬁanc¸a para a ger

encia de

PKIs. O XKMS atrav

es de protocolos padr

oes independentes da tecnologia de seguranc¸a usada, via-

biliza aplicativos com um foco maior nas atividades de neg

ocios. A complexidade do gerenciamento

da PKI

e ent

ao deixado para um servic¸o Web de conﬁanc¸a.

O modelo de ger

encia proposto nesta dissertac¸

e uma extens

ao do modelo de Federac¸

ao SPKI

4. Modelo de ger

encia para o SPKI atrav

es do XKMS 41

apresentado em (Santin, 2004), que tamb

em prov

e suporte

a ger

encia de certiﬁcados. Neste modelo,

as func¸

oes de gerenciamento e estabelecimento de conﬁanc¸a entre os elementos da Federac¸

ao SPKI,

assim como a busca de certiﬁcados, antes atribu

ıdas ao gerente de certiﬁcados, s

ao repassados a

um servic¸o XKMS. O servic¸o XKMS, em outras palavras, deve encapsular muitas das func¸

oes de

gerenciamento introduzidas em (Santin, 2004) para o SPKI/SDSI.

Ao livrar o cliente destas necessidades, o servic¸o torna as aplicac¸

oes menores e mais facilmente

implementadas. Al

em disso, estas aplicac¸

oes tornam-se independentes da tecnologia de seguranc¸a

subjacente, j

a que, a responsabilidade pela localizac¸

ao das cadeias de certiﬁcados passa tamb

em a ser

responsabilidade do servic¸o XKMS.

Apesar das facilidades citadas, a integrac¸

ao do XKMS ao SPKI n

e simples, pois o XKMS

est

a fortemente focado na PKI X.509 e esta infra-estrutura difere do SPKI. A PKI X.509 segue uma

abordagem centralizada de autenticac¸

ao e deﬁne um modelo hier

arquico de conﬁanc¸a baseado na

nomenclatura X.500. J

a o SPKI trabalha com uma estrutura de nomes locais e deﬁne um modelo

igualit

ario, onde cada chave p

ublica torna-se uma entidade certiﬁcadora, que pode divulgar e assinar

certiﬁcados.

Neste cap

ıtulo, o nosso modelo de ger

encia que faz uso do XKMS nas buscas de cadeias de

certiﬁcados SPKI nas Teias de Federac¸

oes,

e apresentado como um Servic¸o XKMS provendo as

func¸

oes de gerenciamento para uma Federac¸

ao SPKI.

4.2 Gerenciamento Federado do SPKI atrav

es do XKMS

No modelo proposto neste trabalho, as tarefas de localizac¸

ao e validac¸

ao de certiﬁcados de cadeias

de autorizac¸

ao da PKI usada s

ao repassadas para um servic¸o XKMS. Desta forma, o servic¸o XKMS

facilita a interac¸

ao entre o cliente e o servidor de aplicac¸

ao, tornando dispon

ıvel o suporte de uma

Federac¸

ao SPKI. Al

em disso, o servic¸o XKMS prov

e operac¸

oes de armazenamento, e de recuperac¸

ao,

necess

arios para que os clientes consigam efetivar o acesso nos servidores.

Serviço XKMS

XKISS XKRSS

Federação X

Repositório da

biblioteca

SDSI

Rep Local

Cliente A

Guardião

Servidor de

Aplicação

Rep ACL

Federação X

membro membro

Request

Response

Figura 4.1: Elementos da Federac¸

4. Modelo de ger

encia para o SPKI atrav

es do XKMS 42

Conforme pode ser observado na Figura 4.1, o servic¸o XKMS prov

e dois servic¸os: XKISS e

XKRSS. Neste modelo, o XKISS

e respons

avel pelo gerenciamento das informac¸

oes SPKI e prev

e as

operac¸

oes de localizac¸

ao e validac¸

ao. J

a o XKRSS

e respons

avel pelo gerenciamento das Federac¸

oes

SPKI e prev

e a operac¸

ao de registro.

A especiﬁcac¸

ao do XKMS prev

e para o XKRSS al

em da operac¸

ao de registro, as operac¸

oes de

reemiss

ao, recuperac¸

ao e revogac¸

ao. As operac¸

oes de reemiss

ao e recuperac¸

ao n

ao s

ao utilizadas

neste modelo, pois estas s

ao espec

ıﬁcas para o gerenciamento de chaves privadas e na ﬁlosoﬁa SPKI

ningu

em al

em do detentor da chave privada pode emitir certiﬁcados. Tamb

em n

ao foi utilizada a

operac¸

ao de revogac¸

ao, j

a que o SPKI/SDSI

e caracterizado por certiﬁcados com per

ıodos de validade

bem deﬁnidos, o que descaracteriza de certa forma a necessidade de CRLs descrevendo pol

ıticas

negativas como nos outros modelos de controle de acesso (Santin, 2004).

Cada servic¸o XKMS serve apenas aos grupos de principais de sua Federac¸

ao SPKI (as chaves

ublicas de seus integrantes formam um grupo SDSI), n

ao participando ativamente de nenhuma ca-

deia de autorizac¸

ao.

A forma como o modelo de ger

encia, suportado atrav

es das Federac¸

oes SPKI,

e integrado ao

servic¸o XKMS est

a representado no cen

ario da Figura 4.2. Quando ativada uma operac¸

ao de localizac¸

de certiﬁcados no reposit

orio da Federac¸

ao, o servic¸o XKMS retorna a identiﬁcac¸

ao do principal, de-

tentor do acesso, atrav

es de uma URI

(Uniform Resource Identiﬁer) (BERNERS-LEE et al., 1998).

De posse desta URI, o principal que deseja obter o acesso pode negociar a delegac¸

ao da permiss

com o principal detentor do direito. A negociac¸

ao de permiss

oes pode ser realizada de maneira sim-

ples (atrav

es de uma delegac¸

ao), j

a que os principais s

ao membros de uma mesma Federac¸

ao SPKI.

Entretanto, dependendo da aplicac¸

ao pode haver a necessidade de uma negociac¸

ao mais complexa.

No cen

ario da Figura 4.2, podem ser observados os clientes A e B, que s

ao membros da Federac¸

X. No passo 1, o servidor de aplicac¸

ao emite e envia um certiﬁcado de autorizac¸

ao deleg

avel ao cliente

A. Este cliente ent

ao passa a ter o direito de acesso ao recurso protegido pelo guardi

ao, al

em de poder

delegar este direito. No passo 2, o cliente A armazena este certiﬁcado no reposit

orio da Federac¸

ao,

para que ﬁque dispon

ıvel aos demais membros da mesma. No passo 3, o cliente B tenta acessar o

recurso, por

em o guardi

ao do servidor de aplicac¸

ao veriﬁca que este cliente B n

ao possui o direito de

acesso e responde com um desaﬁo (passo 4). O cliente B realiza uma busca no seu reposit

orio local

e n

ao encontra a cadeia de certiﬁcados necess

aria. Entretanto, o cliente B, atrav

es das Federac¸

oes

SPKI, tem uma alternativa para localizar o certiﬁcado desejado. No passo 5, o cliente B faz uma

requisic¸

ao de localizac¸

ao para o servic¸o XKMS que procura no reposit

orio da Federac¸

ao X e encontra

o certiﬁcado que o cliente A armazenou no passo 2. No passo 6, o servic¸o XKMS retorna a URI do

cliente A de forma que o cliente B possa localiz

a-lo e negociar com o mesmo a delegac¸

ao do direito

de acesso (passo 7). Ap

os a negociac¸

ao, o cliente A emite um certiﬁcado de autorizac¸

ao ao cliente B

(passo 8). Finalmente o cliente B, de posse de uma cadeia de certiﬁcados de autorizac¸

ao que o liga

ao servic¸o desejado, assina esta cadeia junto a uma requisic¸

ao e envia ao servidor de aplicac¸

ao (passo

9), que por sua vez libera o acesso ao recurso (passo 10).

A URI fornece basicamente as seguintes informac¸

oes: o mecanismo de acesso, a m

aquina hospedeira e o nome do

recurso sendo acessado.

4. Modelo de ger

encia para o SPKI atrav

es do XKMS 43

Rep Local

Guardião

Servidor de

Aplicação

Rep ACL

Serviço XKMS X

Cliente A

Cliente B

5. Busca no repositório

4. Envia um desafio

3. Tenta acessar o recurso

7. Negociação

8. Negociação

repositório da Federação

2. Armazena o certificado no

1. Emite e envia o certificado

9. Envia cadeia

10. Libera o acesso

6. URI do Cliente A

Federação X

Repositório da

Domínio da Federação X

Figura 4.2: Gerenciamento Federado do SPKI atrav

es do XKMS

4.3 Processo de Filiac¸

ao e de Registro de certiﬁcados no reposit

orio da

Federac¸

Um principal pode ﬁliar-se a quantas Federac¸

oes SPKI ele for aceito. Para isso, conforme deﬁ-

nido em (Santin, 2004), o mesmo deve fornecer um endosso efetivado atrav

es da apresentac¸

ao de um

threshold certiﬁcate, assinado por k-dentre-n membros deﬁnidos pela Federac¸

ao em quest

ao,

junta-

mente com seu o certiﬁcado de nome, que ser

a inclu

ıdo no reposit

orio da mesma. Este certiﬁcado de

nomes

e utilizado na identiﬁcac¸

ao de principais. A cada novo membro da Federac¸

ao SPKI

e emitido

um novo certiﬁcado de grupo, expressando a participac¸

ao no grupo SDSI, para ﬁns de comprovac¸

da ﬁliac¸

ao (membership).

Neste trabalho, o processo de ﬁliac¸

ao se d

a atrav

es da operac¸

ao de Registro do XKRSS. Esta

operac¸

ao pode ser utilizada tanto para a aﬁliac¸

ao de membros quanto para envio de certiﬁcados de-

leg

aveis para o reposit

orio da Federac¸

ao SPKI. Desta forma, quando um servic¸o XKMS recebe uma

requisic¸

ao de registro, o mesmo veriﬁca se no conte

udo da mensagem encontra-se um threshold cer-

tiﬁcate ou uma cadeia de certiﬁcados de autorizac¸

ao. Se no conte

udo da mensagem encontra-se uma

cadeia de certiﬁcados de autorizac¸

ao deleg

avel, o servic¸o XKMS veriﬁca se o principal que enviou

a requisic¸

e membro da Federac¸

ao SPKI. Se este n

ao for membro, o servic¸o XKMS simplesmente

ignora a requisic¸

ao, caso contr

ario o servic¸o armazena este certiﬁcado no reposit

orio da Federac¸

SPKI, que serve como base de consulta para futuras requisic¸

oes de localizac¸

ao. Caso no conte

udo da

mensagem encontra-se um threshold certiﬁcate, o servic¸o XKMS da Federac¸

ao SPKI em quest

ao ve-

Esta estrat

egia facilita o processo de ﬁliac¸

ao no sentido de permitir que um subconjunto (k) de principais do conjunto

(n) possa atuar no papel do administrador da federac¸

ao.

4. Modelo de ger

encia para o SPKI atrav

es do XKMS 44

riﬁca se o endosso, al

em de v

alido,

e para aﬁliac¸

ao. Em caso aﬁrmativo

e emitido um novo certiﬁcado

de grupo de ﬁliados para o principal que fez a solicitac¸

ao.

4.4 Provendo suporte as Teias de Federac¸

oes SPKI

Um principal, ao ﬁliar-se a uma Federac¸

ao SPKI pode fazer uso do reposit

orio da mesma como

aux

ılio na localizac¸

ao de cadeias e/ou certiﬁcados de autorizac¸

ao. Por

em uma Federac¸

ao SPKI tem

sua abrang

encia limitada, havendo a necessidade de que os membros de uma Federac¸

ao se ﬁliem a

arias outras Federac¸

oes para alcanc¸ar um certo n

ıvel de presenc¸a na rede. Para solucionar este pro-

blema,

e proposto em (Santin, 2004) que a Federac¸

ao SPKI atrav

es de seus Gerentes de Certiﬁcados

se associem a outras Federac¸

oes SPKI criando relacionamentos m

utuos de conﬁanc¸a que permitam

ampliar o modelo de conﬁanc¸a administrativo, formando Teias de Federac¸

oes SPKI.

De forma semelhante ao proposto em (Santin, 2004), neste modelo, uma Federac¸

ao SPKI pode se

associar a outras Federac¸

oes formando Teias de Federac¸

oes SPKI, por

em esta associac¸

e realizada

atrav

es dos Servic¸os XKMS e n

ao mais pelos Gerentes de Certiﬁcados.

Uma Teia de Federac¸

oes SPKI

e formada arbitrariamente e cria caminhos de conﬁanc¸a entre as

Federac¸

oes SPKI associadas de tal modo que um membro pode fazer consultas ao Servic¸o XKMS

de sua Federac¸

ao original e este, por sua vez, realiza em nome de seu membro a busca nos Servic¸os

XKMS aos quais est

a associado.

No cen

ario da Figura 4.3 pode ser observado um cliente A, pertencente a Federac¸

ao X, que deseja

acessar um servidor de aplicac¸

ao pertencente a Federac¸

ao Y. O servic¸o XKMS de X

e associado aos

servic¸os XKMS das Federac¸

oes W e Z, e o servic¸o XKMS de Z, por sua vez

e associado ao servic¸o

XKMS da Federac¸

ao Y. Neste caso, o cliente A pode recorrer ao Servic¸o XKMS da Federac¸

ao X a

qual pertence, para que este realize a localizac¸

ao atrav

es das Teias de Federac¸

oes SPKI. Quando uma

cadeia de certiﬁcados de autorizac¸

e localizada, o membro pode negociar a concess

ao do privil

egio

com o detentor do mesmo.

Um Servic¸o XKMS

e associado com os Servic¸os XKMS aos quais tenha uma relac¸

ao de conﬁanc¸a.

Esta relac¸

ao de conﬁanc¸a pode ser de dois tipos: ligac¸

ao fraca de conﬁanc¸a ou ligac¸

ao forte de

conﬁanc¸a. O tipo da ligac¸

ao de conﬁanc¸a

e deﬁnido atrav

es da regra do neg

ocio. Por exemplo, uma

ligac¸

ao forte de conﬁanc¸a pode ocorrer entre uma Federac¸

ao de companhias de transportes a

ereos e

uma Federac¸

ao de Hot

eis. Estas Federac¸

oes podem apresentar fortes ligac¸

oes de conﬁanc¸a por terem

interesses comuns, como por exemplo uma venda casada de passagens a

ereas com estadias em hot

eis.

Caso as Federac¸

oes n

ao apresentem esta relac¸

ao forte de neg

ocios, a ligac¸

ao de conﬁanc¸a entre estas

e fraca. Por exemplo, uma Federac¸

ao de companhia de transportes a

ereos com uma Federac¸

ao de pet

shops.

As relac¸

oes podem ser estabelecidas por quest

oes de escala e de abrang

encia nas procuras de

certiﬁcados; o que deve diferenciar as v

arias associac¸

oes de uma federac¸

ao s

ao os diferentes graus de

conﬁanc¸a que s

ao quantiﬁcados como fracos e fortes.

4. Modelo de ger

encia para o SPKI atrav

es do XKMS 45

Rep Local

Cliente A Serviço XKMS X

Guardião

Servidor de

Aplicação

Rep ACL

Repositório da

Serviço XKMS

Repositório da

Serviço XKMS

Serviço XKMS Y

Repositório da

Federação W Federação Z

Federação Y

Federação X

membro

Relação deRelação de

Relação de

confiança fraca

confiança forte

confiança fraca

Relação de

Requisição

Federação X

Federação ZFederação W

Federação Y

Figura 4.3: Teias de Federac¸

oes

Associac¸

oes entre Federac¸

oes SPKI tamb

em s

ao interpretadas como membros pela ger

encia de

uma Federac¸

ao. Neste caso, o servic¸o XKMS que se associa a uma outra Federac¸

ao SPKI, torna-se

membro da mesma. Esta associac¸

e materializada pela emiss

ao de um certiﬁcado de grupo SDSI

de associados.

Ao servic¸o XKMS cabe ent

ao, a manutenc¸

ao das informac¸

oes referentes aos membros e as-

sociados de sua Federac¸

ao SPKI, removendo ou adicionando membros e associac¸

oes com outras

Federac¸

oes SPKI, sem promover conﬂito de interesses.

As federac¸

oes e suas teias formam o suporte para a gerac¸

ao de novas cadeias de certiﬁcados

de autorizac¸

ao SPKI. Para ilustrar este processo de formac¸

ao de novas cadeias, pode-se observar o

cen

ario da Figura 4.4, que mostra a troca de mensagens entre o Cliente, o Servidor de Aplicac¸

ao, o

Servic¸o XKMS e o detentor do privil

egio. No passo 1, o Cliente envia uma requisic¸

ao ao Servidor

de Aplicac¸

ao. Como o Cliente n

ao possui a autorizac¸

ao de acesso, o Servidor envia ao mesmo um

desaﬁo (passo 2). Este desaﬁo, neste caso

e a ACL SPKI/SDSI que protege o recurso.

De posse da ACL, o Cliente chama o seu agente para que o mesmo fac¸a uma busca no seu re-

posit

orio local por uma cadeia e/ou certiﬁcado de autorizac¸

ao que o ligue ao servidor de aplicac¸

e permita o acesso desejado. Se a busca local n

ao for bem sucedida, o Cliente ent

ao recorre ao

Servic¸o XKMS (passo 3) da Federac¸

ao SPKI a qual

e membro. Este Servic¸o XKMS tenta localizar

esta cadeia e/ou certiﬁcado no reposit

orio da Federac¸

ao SPKI, se novamente n

ao houver sucesso na

4. Modelo de ger

encia para o SPKI atrav

es do XKMS 46

Cliente

Teia de

Federações

Detentor do Direito

Servidor de Aplicação

1: requisita o acesso

2: desafio

3: busca cadeia

4: busca cadeia

10: acesso liberado

9: direito

8: direito

7: negociação

6: URI

5: URI

Serviço XKMS

Figura 4.4: Cen

ario de busca de certiﬁcados

busca, o Servic¸o XKMS inicia a localizac¸

ao nos seus Servic¸os XKMS associados (passo 4), ou seja,

a localizac¸

e feita na Teia de Federac¸

oes. Ap

os o t

ermino da busca realizada pelo servic¸o, o mesmo

retorna a identiﬁcac¸

ao do detentor do direito, contida no certiﬁcado de autorizac¸

ao (passo 5). De

posse da identiﬁcac¸

ao do detentor, a Federac¸

ao SPKI de origem repassa a mesma ao seu membro

(Cliente), (passo 6), que parte para a negociac¸

ao da delegac¸

ao do direito requerido (mensagem 7 e 8).

Conforme citado anteriormente a negociac¸

ao da delegac¸

ao pode ser realizada de forma simples ou

complexa, entretanto neste cen

ario a negociac¸

ao foi realizada com uma simples delegac¸

ao do direito

desejado. Com o certiﬁcado que delega o direito ao Cliente, o mesmo responde ao desaﬁo proposto

pelo Servidor (passo 2) e por ﬁm, (passo 9) o Servidor de Aplicac¸

ao libera o acesso ao Cliente (passo

10).

A associac¸

ao entre servic¸os, conforme deﬁnida na sec¸

ao 4.3, se d

a atrav

es da operac¸

ao de registro

do XKMS, assim como a ﬁliac¸

ao e o registro de certiﬁcados, conforme pode ser visualizado na Figura

4.5. Um grupo inicial de Federac¸

oes com interesses comuns se associam atrav

es de seus Servic¸os

XKMS.

Estas associac¸

oes formam teias que assumem topologias arbitr

arias, uma vez que as mesmas s

estabelecidas e removidas de forma din

amica e aleat

oria. Um servic¸o XKMS, se torna um associado

de outro ao fornecer o endosso assinado por k-dentre-n associados, juntamente com seu certiﬁcado

de nome. Um Servic¸o XKMS tamb

em pode se associar a quantos servic¸os XKMS quiser.

Em uma requisic¸

ao de associac¸

ao, o Servic¸o XKMS da Federac¸

ao SPKI em quest

ao veriﬁca se

na mensagem recebida existe um threshold certiﬁcates e se este endossa uma associac¸

ao. Neste caso

o servic¸o XKMS emite um certiﬁcado de grupo de associados e o envia para o requisitor da operac¸

ao.

Da mesma forma, se o endosso

e para a aﬁliac¸

ao,

e emitido um certiﬁcado de grupo de membros que

e posteriormente enviado ao requisitante.

A operac¸

ao de localizac¸

ao de um servic¸o XKMS

e utilizada pelos membros da Federac¸

ao e pelos

4. Modelo de ger

encia para o SPKI atrav

es do XKMS 47

Principal

Membro da

Federação

Localizar

Validar

XKISS

Repositório

da Federação

XRSS

Serviço XKMS

Localizar

Validar

XKISSXRSS

Registrar

Repositório

da Federação

Serviço XKMS

Requisição de filiação

Requisição de associação

Requisição de armazenamento de cadeia e/ou

certificado no repositório da Federação

Federação

Registrar

Serviço XKMS

Figura 4.5: Operac¸

oes do Servic¸o XKMS

servic¸os XKMS associados para requisitar uma busca de cadeias de certiﬁcados de autorizac¸

ao na

sua Federac¸

ao. Um membro tamb

em pode requisitar a um Servic¸o XKMS que valide uma cadeia

de certiﬁcados, por exemplo, de autorizac¸

ao, atrav

es da operac¸

ao de ”Validar”livrando o membro da

Federac¸

ao da necessidade de implementar esta operac¸

ao.

4.5 Algoritmo de Busca de Certiﬁcados nas Teias de Federac¸

oes

O uso dos servic¸os XKMS facilita a localizac¸

ao de certiﬁcados de autorizac¸

ao atrav

es de buscas

realizadas nas teias de Federac¸

oes SPKI. Nesta sec¸

ao ser

a apresentada a forma como a localizac¸

ao de

novas cadeias de certiﬁcados de autorizac¸

ao nas Teias de Federac¸

oes SPKI acontece.

Conforme observado anteriormente, uma ligac¸

ao de conﬁanc¸a entre servic¸os XKMS pode ser de

dois tipos: fraca e forte. Quando a relac¸

ao de conﬁanc¸a

e fraca, o funcionamento do algoritmo de

busca de certiﬁcados

e realizado de forma interativa. Ou seja, quando um membro faz uma requisic¸

de localizac¸

ao de cadeias de certiﬁcados de autorizac¸

ao ao Servic¸o XKMS na Federac¸

ao SPKI, este

Servic¸o, caso o certiﬁcado desejado n

ao se encontra no reposit

orio da Federac¸

ao SPKI em quest

ao,

faz uma requisic¸

ao aos Servic¸os XKMS associados. Se o Servic¸o XKMS que recebeu a requisic¸

veriﬁca que a sua Federac¸

ao tamb

em n

ao possui o certiﬁcado, este retorna as URIs dos Servic¸os

XKMS associados ao Servic¸o XKMS requisitante para que este possa continuar a busca na Teia de

Federac¸

oes.

No ﬁm da busca, o Servic¸o XKMS da Federac¸

ao de origem retorna uma lista de zero ou mais

URIs, onde cada URI cont

em a identiﬁcac¸

ao de um principal que possui o direito de acesso ao recurso

desejado ao cliente. Se a lista de URIs n

ao for vazia, o cliente parte para a negociac¸

ao da concess

com os principais que possuem este direito.

4. Modelo de ger

encia para o SPKI atrav

es do XKMS 48

Algoritmo 1 locate (recurso, sign, ttl)

Require: T = {Conjuto de servic¸os com associac¸

ao forte.}

Require: U = {Conjuto de servic¸os com associac¸

ao fraca.}

1: if (ttl > 0 ) and (signature.getPublicKey() ∈ (T ∪ U)) then {A requisic¸

ao deve ser proveniente de um servic¸o com associac¸

ao forte ou

fraca e ttl tem que ser maior que zero.}

2: ttl ← ttl-1

3: uris ← buscaRepositorio(recurso)

4: if (uris = ) then {Algum membro possui o recurso}

5: locateHit(uris, ”members”)

6: else if (signature.getPublicKey() ∈ U) then {A requisic¸

e de um servic¸o de associac¸

ao fraca}

7: uris = associatedsURIs(T ∪ U)[URIs dos associados]

8: locateHit(uris, ”associateds”)

9: else if (ttl > 0 ) then {Busca nos assoiados de relac¸

ao forte e fraca.}

10: N ← T ∪ U

11: while (N = ) do

12: X ← ﬁrstElement(N)

13: X.locate(recurso, sign(), ttl)

14: N ← N \ X Remove o elemento X do conjunto N

15: end while

16: end if

17: else

18: locateHit(, ””)

19: end if

Se a relac¸

ao de conﬁanc¸a entre os servic¸os associados

e forte, a busca

e feita de forma recursiva.

Neste caso, quando um membro faz um requisic¸

ao ao Servic¸o XKMS da sua Federac¸

ao SPKI e este

ao possuindo a permiss

ao, deve repassar a procura a seus associados diretos. A busca em quest

ao s

e repassada para um Servic¸o XKMS associado se a relac¸

ao entre ambos for forte. Ou seja, o Servic¸o

XKMS que recebeu a requisic¸

ao de busca veriﬁca se a requisic¸

ao veio de um servic¸o com quem este

tenha uma relac¸

ao de conﬁanc¸a forte. Em caso aﬁrmativo, a busca

e assumida por este. Desta forma,

a busca

e realizada como se um dos membros da Federac¸

ao ao qual pertence a tivesse requisitado. Na

localizac¸

ao recursiva, o servic¸o XKMS ao delegar a tarefa de busca de cadeias de certiﬁcados a um

servic¸o associado, diminuem a sua sobrecarga no processamento desta localizac¸

ao.

Visualizando a Teia de Federac¸

oes SPKI como um grafo, a busca de certiﬁcados pode ser de

duas formas: a busca por amplitude e a busca por profundidade. Neste modelo, assim como em

(Santin, 2004), optou-se pela busca em amplitude, pois quanto mais distante o membro e o principal

detentor do direito, maior a diﬁculdade de negociac¸

ao, pois estes pertencem a Federac¸

oes distantes,

por conseq

encia a probabilidade de os membros possu

ırem interesses aﬁns

e menor. Para que a

busca n

ao seja inﬁnita foi inserido tamb

em um controle de saltos. Este controle de saltos

e passado

na requisic¸

ao de busca do certiﬁcado (valor ttl). O cliente tamb

em apresenta um timeout para que

este n

ao ﬁque esperando indeﬁnidamente por uma resposta do servic¸o XKMS.

O protocolo que segue este modelo possui duas mensagens: locate, usada para efetuar a localizac¸

da cadeia e/ou certiﬁcado; e a locateHit, informando que a cadeia e/ou certiﬁcado procurado(o) foi

encontrado(a). A mensagem locate

e composta por tr

es elementos principais, sendo estes: o recurso,

a assinatura e o ttl. O valor ttl, conforme citado anteriormente

e usado para o controle de saltos, o re-

curso

e quem identiﬁca a cadeia de certiﬁcado que est

a sendo buscada, e atrav

es da assinatura

e obtida

a chave p

ublica para a identiﬁcac¸

ao do requisitor (se

e membro, ou se

e Federac¸

ao com associac¸

forte ou fraco).

O Algoritmo 1 descreve como esta localizac¸

e realizada. Primeiramente o Servic¸o XKMS

veriﬁca atrav

es da chave p

ublica contida na assinatura se o cliente que fez a requisic¸

e um Servic¸o

4. Modelo de ger

encia para o SPKI atrav

es do XKMS 49

XKMS associado ou se

e um membro da Federac¸

ao e se o valor de ttl

e maior que zero(linha 1). Se

e nem membro nem associado e o valor de ttl n

e maior que 0, o servic¸o XKMS n

ao responde

a requisic¸

ao. Caso contr

ario, o valor de ttl

e diminu

ıdo de 1 e a busca

e realizada normalmente.

Se o servic¸o XKMS encontrar algum membro que detenha o recurso, sua(s) identiﬁcac¸

ao(s) atrav

da(s) URI(s)

e(s

ao) enviada(s) na mensagem locateHit, juntamente com um valor identiﬁcando que

as mesma(s) s

ao URI(s) de membros que det

em o recurso (”members”, linha 5).

Caso n

ao seja encontrado nenhuma cadeia de certiﬁcados no reposit

orio da Federac¸

ao,

e ent

veriﬁcado se a chave p

ubica do requisitor pertence a uma Federac¸

ao associada de relac¸

ao fraca de

conﬁanc¸a (linha 6). Em caso aﬁrmativo, o servic¸o XKMS retorna na mensagem locateHit, contendo

as URIs dos seus Servic¸os XKMS associados (de associac¸

ao forte e fraca), juntamente com um valor

identiﬁcando que as mesma(s) s

ao URI(s) de associados (”associateds”) para que o servic¸o que fez a

requisic¸

ao possa continuar a busca (linha 8).

Caso a chave p

ublica pertenc¸a a algum Servic¸o XKMS com relac¸

ao de conﬁanc¸a forte ou a um

membro da Federac¸

ao, o servic¸o XKMS assume a localizac¸

ao. Como os Servic¸os XKMS de relac¸

oes

de conﬁanc¸a forte assumem a busca, o servic¸o XKMS em quest

ao somente armazena os resultados

da busca para posteriormente enviar a quem lhe fez a requisic¸

ao. Quando o valor de ttl for igual

a 0, o servic¸o XKMS respons

avel p

ara a localizac¸

ao e envia uma mensagem locateHit contendo os

resultados obtidos at

e ent

ao (linha 18).

Membro

Serviço

XKMS A

Serviço

XKMS C

Federação C

Serviço

XKMS B

Federação B

Serviço

XKMS D

Federação D

Serviço

XKMS E

Federação E

Serviço

Federação G

XKMS G

Serviço

Federação F

XKMS F

Serviço

XKMS H

Federação H

Serviço

XKMS I

Federação I

relação de

confiança forte

confiança fraca

Federação A

Figura 4.6: Algoritmo de busca

4. Modelo de ger

encia para o SPKI atrav

es do XKMS 50

Um cen

ario de exemplo de uma busca de uma cadeia de certiﬁcados

e ilustrado na Figura 4.6.

Um membro da Federac¸

ao A faz uma requisic¸

ao ao servic¸o XKMS A, que por sua vez, veriﬁca no

reposit

orio da Federac¸

ao e n

ao encontra a cadeia requisitada. Neste exemplo, os dois servic¸os XKMS

B e C, com os quais este possui uma relac¸

ao de conﬁanc¸a fraca, a cadeia tamb

em n

e encontrada.

Desta forma, o servic¸o XKMS C retorna a URI contendo a localizac¸

ao do servic¸o XKMS E (passos 1

e 2), para que o servic¸o XMKS A realize a busca.

Se a relac¸

ao de conﬁanc¸a entre os servic¸os XKMS for forte, a busca

e realizada de forma recursiva.

Neste caso, o servic¸o D, que possui uma relac¸

ao de conﬁanc¸a forte com o servic¸o A, assume a busca

e procura a cadeia em seus associados (passos 2a e 2b). No passo 3b, o servic¸o XKMS G associado ao

servic¸o XKMS D que assumiu a busca, n

ao encontra a cadeia e repassa as URIs dos servic¸os XKMS H e

I de seus associados. Atrav

es destas URIs, conforme passos 4b e 5b, o servic¸o XKMS D de associac¸

forte envia uma requisic¸

ao de localizac¸

ao de certiﬁcados ao servic¸o XKMS I, que ﬁnalmente retorna

uma mensagem indicando que a cadeia foi encontrada e informa a URI do membro da sua federac¸

que det

em o recurso. Ao delegar a tarefa de busca de cadeias de certiﬁcados aos servic¸os associados

de conﬁanc¸a forte, o servic¸o XKMS diminui a carga de processamento para realizar a operac¸

ao de

localizac¸

4.6 Trabalhos Relacionados

Existem alguns trabalhos na literatura fazem uso de um servic¸o XKMS. No entanto, estes tra-

balhos utilizam somente a infra-estrutura de chaves p

ublica (PKI) X.509, herdando os problemas de

uma abordagem de autenticac¸

ao centralizada.

Um servic¸o de validac¸

ao de certiﬁcados usando XKMS para grids computacionais

e apresentado

em (Park et al., 2003). Este servic¸o introduz um m

odulo de validac¸

ao de certiﬁcados (CVM), que

e um

componente que valida certiﬁcados para o cliente. V

arios protocolos s

ao utilizados para a validac¸

de certiﬁcados, tais como, OSCP

, SCVP

e LDAP

. O ﬂuxo de validac¸

ao de certiﬁcados funciona

da seguinte maneira: o cliente gera uma requisic¸

ao para a validac¸

ao de um caminho de certiﬁcados

e envia esta ao servidor. O servidor reconstr

oi o caminho usando a sua tabela de certiﬁcados. Se o

caminho j

a se encontra na tabela local, o servidor responde ao cliente que o caminho

e v

alido. Caso o

caminho n

ao seja encontrado na tabela local, o servic¸o faz a validac¸

ao usando a tabela da CA em que

est

a registrado. Se o caminho do certiﬁcado

e v

alido, o servic¸o armazena este caminho na sua tabela

local e responde ao cliente que o caminho

e v

alido. Caso contr

ario, retorna uma resposta ao cliente

indicando que o caminho de certiﬁcado

e inv

alido. Nos testes de validac¸

ao de certiﬁcados devem

ocorrer tamb

em as veriﬁcac¸

oes das CRLs com as pol

ıticas negativas.

O modelo proposto no nosso trabalho tamb

em apresenta a operac¸

ao de validac¸

ao de cadeias de

certiﬁcados onde o servic¸o XKMS responde ao cliente o resultado da validac¸

ao do mesmo. Por

em,

Protocolo que veriﬁca a validade de um certiﬁcado em tempo real

Protocolo de validac¸

ao de certiﬁcados simples, que pode prover mais informac¸

oes que somente o status de um certiﬁ-

cado

Lightweight Directory Access Protocol. Como o nome sugere,

e um protocolo leve para acessar servic¸os de diret

orio.

O LDAP roda em cima do protocolo TCP/IP ou outras conex

oes de transfer

encia de servic¸os.

4. Modelo de ger

encia para o SPKI atrav

es do XKMS 51

conforme citado no texto, o SPKI/SDSI

e caracterizado por certiﬁcados com per

ıodos de validade

bem deﬁnidos, o que descaracteriza de certa forma a necessidade de CRLs descrevendo pol

ıticas

negativas, facilitando assim a implementac¸

ao desta operac¸

ao.

Em (Kraft, 2002)

e apresentando um modelo geral de um processador de controle de acesso

para servic¸os Web. Neste trabalho o XKMS, juntamente com as extens

oes XML de assinatura e de

cifragem, s

ao citados como exemplo de ferramentas a serem usados para garantir a integridade, n

repudiac¸

ao e a conﬁdencialidade das mensagens SOAP.

Um framework para implementac¸

ao de seguranc¸a em servic¸os Web atrav

es de extens

oes do WSDL

e UDDI

e proposto em (Adams e Boeyen, 2002). Nestas extens

oes um elemento chamado security-

Parameters e seus subelementos s

ao inclu

ıdos no esquema do UDDI e do WSDL para prover um

modo de estabelecer uma infraestrutura de pol

ıtica de conﬁanc¸a. Atrav

es destes elemento um servic¸o

consumidor obt

em os certiﬁcados e as chaves, necess

arios para acessar o servic¸o provedor, que por

sua vez, pode utilizar um servic¸o XKMS para determinar se as chaves ou certiﬁcados recebidos s

alidos.

Em (Bilykh et al., 2003)

e apresentado um grid de informac¸

oes de sa

ude chamado HealthInfoGrid

que possui um componente chamado Medical Exchange Agency (MEA). Este componente, usa PKI

X.509 e assume o papel de CA para os demais componentes do GRID. Para cada um destes compo-

nentes, o MEA emite um certiﬁcado de rede usado para a identiﬁcac¸

ao e assinatura digital e imple-

menta a interface XKMS para o gerenciamento destes certiﬁcados.

Entretanto, nestes modelos citados acima ((Kraft, 2002), (Adams e Boeyen, 2002) e (Bilykh et al.,

2003)) o XKMS prov

e somente suporte para a PKI X.509.

a em (Daniel J. Polivy, 2002)

e apresentado uma arquitetura para autenticac¸

ao de respostas assi-

nadas de requisic¸

oes feitas a r

eplicas de dicion

arios autenticados usando servic¸os Web e assinaturas

XML. Se a informac¸

ao da chave p

ublica contida na assinatura necess

aria para a validac¸

ao da mesma

ao estiver no documento XML, esta arquitetura cita, como exemplo de um meio de busca desta

informac¸

ao, um servic¸o XKMS. Novamente o sistema obriga a utilizac¸

ao da PKI X.509 nas r

eplicas

de dicion

arios.

Um modelo, proposto em (Kim e Moon, 2005), deﬁne uma extens

ao ao XKMS para que este

gerencie n

ao somente informac¸

oes de chaves p

ublicas, mas tamb

em outras informac¸

oes de seguranc¸a,

tais como: chave privada, chave secreta, informac¸

oes biom

etricas, tokens de seguranc¸a para servic¸os

Web, entre outros. Este tipo de extens

ao n

e interessante para o nosso modelo devido a ﬁlosoﬁa

do SPKI onde o detentor da chave

e o respons

avel por sua chave privada, e pelos seus certiﬁcados

deleg

aveis.

O SPKI necessita de um modelo de ger

encia para que principais possam localizar uma cadeia e ou

certiﬁcado com direito de acesso necess

ario para o acesso a determinado recurso. Em (Santin, 2004),

foi proposto um modelo de ger

encia, por

em neste modelo h

a uma sobrecarga no cliente que al

em de

ter que entender a complexidade da PKI, tamb

e o respons

avel pela tarefa de localizac¸

ao de cadeias

de certiﬁcados. Al

em disso, o acesso

as funcionalidades providas pelo mesmo n

ao apresentam uma

4. Modelo de ger

encia para o SPKI atrav

es do XKMS 52

forma padronizada. Desta forma, neste trabalho, optou-se pelo uso de um servic¸o XKMS de forma

que a localizac¸

ao seja realizada pelo mesmo, al

em de apresentar uma padronizac¸

ao de acesso as

funcionalidades providas.

Na literatura n

ao existe nenhum esforc¸o do uso do XKMS com o SPKI. Nisto o nosso trabalho

original. A explicac¸

ao para a aus

encia de abordagens concorrentes com a nossa

e que a especiﬁcac¸

do XKMS embora, possua elementos nos quais

e poss

ıvel a extens

ao dos mesmos, tornando-a ade-

quada para o uso com o SPKI, na pr

atica, esta integrac¸

e dif

ıcil porque a especiﬁcac¸

ao do XKMS

foi toda deﬁnida visando uma PKI hier

arquica como o X.509. No nosso trabalho de integrac¸

ao do

XKMS com o SPKI n

ao houve nenhuma alterac¸

ao ou extens

ao que alterasse os padr

oes XKMS ou

comprometesse a conformidade da nossa proposta.

Para o desenvolvimento do algoritmo de localizac¸

ao foram observados na literatura alguns pro-

tocolos peer-to-peer. O Gnutella (Services, 2001)

e um protocolo de compartilhamento de arquivos

peer-to-peer que usa inundac¸

ao para rotear suas mensagens atrav

es dos nodos de forma a implementar

as funcionalidade de busca e procura de pares. Para reduzir o overhead da rede causado pelo proto-

colo Gnutella foi introduzido o conceito de ultrapeer e n

os folhas (leaf nodes). Um n

o Ultra peer

mant

em conex

ao com n

os folhas, evitando assim que estes n

os folhas recebam muitas mensagens de

afego introduzidas pelo protocolo Gnutella. Ou seja, o ultranode

e quem responde as requisic¸

oes de

busca no lugar dos n

os folha conectados a este.

Fast Track (FastTrack, 2001)

e um protocolo peer-to-peer propriet

ario usado no Kazaa, Kazaa

Lite, Grokster, iMesh. Sua vers

ao aberta

e chamada de OpenFT. A arquitetura do OpenFT

e um pouco

diferenciada da arquitetura proposta no Fast Track e introduz tr

es tipos de n

os:

• N

os indexados (Index nodes): S

ao os hosts mais conﬁ

aveis. Mant

ındices dispon

ıveis para

os de busca, coleta de estat

ısticas e monitorac¸

ao da estrutura da rede.

• N

os de busca (Search nodes): S

ao os servidores da rede que mant

em os

ındices dos arquivos

compartilhados pelos n

os usu

arios. A conﬁgurac¸

ao padr

ao permite a um n

o de busca gerenciar

informac¸

ao de arquivos armazenados em 500 n

os usu

arios.

• N

os usu

arios (User nodes): n

os clientes que mant

em conex

oes com um grande n

umero de n

de busca.

Quando uma mensagem de busca chega a um n

o de busca esta n

e mais propagada. Os n

os clientes

enviam mensagens de busca a todos os n

os de busca com os quais mant

em conex

ao. Pode-se econo-

mizar largura de banda atrav

es de crit

erios para a escolha dos n

os de busca para os quais a mensagem

ser

a enviada.

Estes algoritmos apesar das modiﬁcac¸

oes para a diminuic¸

ao de mensagens enviados pela rede,

ainda apresentam um grande consumo de banda nos n

os intermedi

arios. Por este motivo, optou-se por

um algoritmo no qual o servic¸o XKMS, ao qual foi requisitado a localizac¸

ao do recurso,

e quem rea-

liza a busca em cada servic¸o XKMS associado. Caso exista um servic¸o XKMS com uma associac¸

forte, ao qual pode ser repassada a busca, o algoritmo de busca funciona de forma semelhante ao

Gnutella, de forma que o servic¸o XKMS de associac¸

ao forte assume a tarefa de localizac¸

ao.

4. Modelo de ger

encia para o SPKI atrav

es do XKMS 53

4.7 Conclus

ao do Cap

ıtulo

Neste cap

ıtulo foi apresentado um modelo que estende o modelo de ger

encia baseado nas teias

de federac¸

oes proposto em (Santin, 2004). Nesta proposta, o Servic¸o XKMS

e o respons

avel pela

localizac¸

ao distribu

ıda e pela validac¸

ao de cadeias e/ou certiﬁcados de autorizac¸

ao atrav

es de teias

de federac¸

oes, poupando assim o cliente desta tarefa. Al

em disso, o Servic¸o XKMS tamb

em assume

as func¸

oes administrativas da Federac¸

ao SPKI. Quando a cadeia de autorizac¸

ao n

ao existe

e poss

ıvel

criar novas cadeias atrav

es do processo de negociac¸

ao.

Cap

ıtulo 5

Implementac¸

5.1 Introduc¸

No cap

ıtulo anterior foi apresentado um modelo de gerenciamento federado para o SPKI atrav

de servic¸os XKMS. Para veriﬁcar a aplicabilidade do modelo, neste cap

ıtulo ser

ao apresentados al-

guns aspectos da implementac¸

ao de um prot

otipo deste servic¸o e as ferramentas utilizadas no desen-

volvimento do mesmo.

O prot

otipo desenvolvido

e integrado a uma aplicac¸

ao que localiza publicac¸

oes cient

ıﬁcas em um

Servic¸o Web ﬁct

ıcio. Esta aplicac¸

ao foi desenvolvida com o prop

osito de evidenciar as vantagens da

integrac¸

ao do XKMS ao SPKI. Outros aspectos envolvendo a an

alise dos resultados e a comparac¸

dos mesmos com a literatura relacionada tamb

em ser

ao objeto de considerac¸

oes neste cap

ıtulo.

5.2 Arquitetura do Prot

otipo

De modo a avaliar o modelo de ger

encia proposto para o SPKI atrav

es do uso do XKMS, uma

arquitetura que atende

as especiﬁcac¸

oes do modelo e aos requisitos espec

ıﬁcos de um sistema de

larga escala, foi deﬁnida como se pode ver a partir da Figura 5.1. Nesta arquitetura encontram-se os

servic¸os de Transporte e Mensagens, onde se d

a a comunicac¸

ao entre o cliente e o servic¸o XKMS.

A camada de servic¸os de Transporte prov

e o fundamento para a comunicac¸

ao entre servic¸os Web, j

a camada dos servic¸os de Mensagens forma a base interoper

avel dos mesmos (Weerawarana et al.,

2005).

Tamb

em podem ser observados, nesta arquitetura, os servic¸os de descric¸

ao que deﬁnem metada-

dos para a descric¸

ao das caracter

ısticas dos servic¸os Web em funcionamento na rede (Weerawarana

et al., 2005) e, na camada de qualidade de servic¸o as especiﬁcac¸

oes associadas com a qualidade des-

tas interac¸

oes (Weerawarana et al., 2005). As escolhas tecnol

ogicas que comp

oem cada camada desta

arquitetura ser

ao expostas na seq

encia.

5. Implementac¸

ao 55

Xml EncXKMS Xml Dsig

WSDL

SOAP

HTTP

TCP/IP

SPKI

WS Security

Xml EncXKMS Xml Dsig

WSDL

SOAP

HTTP

TCP/IP

SPKI

WS Security

Requisição

Resposta

Cliente Serviço XKMS

Qualidade de

Serviço

Transporte

Mensagem

Descrição

Figura 5.1: Arquitetura do Prot

otipo

5.2.1 Camada de transporte, mensagens e descric¸

O apache Tomcat (http://jakarta.apache.org/tomcat/ )

e um servlet container como Implementac¸

de Refer

encia oﬁcial para as tecnologias Java Servlet e JavaServer Pages (JSP), que s

ao especiﬁcac¸

oes

desenvolvidas pela Sun. O Tomcat

e tamb

em um servidor de aplicac¸

oes Java para Web, robusto e eﬁ-

ciente o suﬁciente para ser utilizado mesmo em um ambiente de produc¸

ao. Sua escolha deve-se ao

fato deste ser software livre e de c

odigo aberto desenvolvido dentro do conceituado projeto Jakarta da

Fundac¸

ao Apache, dispon

ıvel, seja para ﬁns comerciais ou n

ao.

O Apache Axis

e um framework atrav

es do qual

e poss

ıvel criar servic¸os Web e os clientes desses

servic¸os.

E implementado nas linguagens Java e C++. Para a vers

ao 1.2, o Apache vem focando o

suporte ao WS-I Basic Proﬁle 1.0

a especiﬁcac¸

ao JAX-RPC 1.1

. Por ter seu desenvolvimento

orientado a componentes, possibilita a reutilizac¸

ao de Handlers. A tecnologia de Handlers age como

um Firewall XML, geralmente utilizado para a gerac¸

ao e validac¸

ao de extens

oes XML de assinaturas

e de cifragens (XML Signature e XML Encryption) da mensagem SOAP no cliente e no servidor. Esta

tecnologia foi escolhida para a implementac¸

ao desta aplicac¸

ao devido a sua facilidade de integrac¸

com aplicac¸

oes Web, independente do container (Tomcat, JBoss, outros) e por ser um framework

de c

odigo aberto. O framework de mensagens possui uma abstrac¸

ao simples e clara para desenvol-

vimento de mensagens (SOAP senders and listeners). O n

ucleo

e completamente independente da

camada de transporte. As requisic¸

oes s

ao passadas em documentos XML, empacotados em envelo-

pes SOAP (compat

ıvel com o SOAP 1.1/1.2). Estas mensagens, ao chegar ao seu destino, tem seus

envelopes SOAP processados pelo Axis que entrega para as aplicac¸

oes apenas o seu conte

udo. O

Axis tamb

em prov

e suporte aos tipos de dados b

asicos e a serializac¸

ao/desserializac¸

ao autom

atica e

tamb

em realiza a convers

ao autom

atica entre Java Collections e SOAP Arrays.

Dentre suas funcionalidades, o Axis possui um extenso suporte a Web Service Description Lan-

guange (WSDL 1.1) atrav

es do qual as interfaces Java dos servic¸os podem ser geradas automatica-

mente. Da mesma forma podem ser gerados, os documentos WSDL com as descric¸

oes das interfaces,

http://ws.apache.org/axis/

O WS-I Basic Proﬁle 1.0 consiste em um conjunto de especiﬁcac¸

oes para servic¸os Web juntamente com emendas

especiﬁcac¸

oes que promovem interoperabilidade.

JAX-RPC 1.1

e uma API JAVA para RPC baseado em XML que permite aos desenvolvedores Java construir servic¸os

Web utilizando a funcionalidade RPC de acordo com a especiﬁcac¸

ao SOAP.

5. Implementac¸

ao 56

uma vez criadas as interfaces Java dos servic¸os. Juntamente com este framework, existe uma ferra-

menta chamada SOAPMonitor, que intercepta mensagens SOAP e as torna vis

ıveis aos usu

arios.

Por

em a vers

ao utilizada do Axis apresenta alguns problemas na gerac¸

ao de classes atrav

es de

WSDL que utilizam o elemento de grupo choice usado para deﬁnir esquemas XML, que permite que

somente um dos seus subelementos esteja no documento XML deﬁnido por este esquema

5.2.2 Infra-estrutura SPKI

O suporte a infra-estrutura SPKI/SDSI

e obtida atrav

es da biblioteca JSDSI2.0, implementada por

(Morcos, 1998). Esta biblioteca JSDSI2.0, uma implementac¸

ao na linguagem Java do SPKI/SDSI,

cont

em classes que fornecem meios de converter e criar S-expressions e implementar os objetos fun-

damentais do SPKI/SDSI, como certiﬁcados e chaves. Esta biblioteca foi escolhida por se tratar de

uma implementac¸

ao mais completa, j

a que existe a possibilidade de criac¸

ao de pares de chaves sem

a necessidade de utilizar outras ferramentas, e principalmente por esta ter sido desenvolvida em Java.

em da criac¸

ao dos pares de chaves, a biblioteca tamb

em apresenta uma ferramenta gr

aﬁca que per-

mite o gerenciamento de certiﬁcados, a criac¸

ao de assinaturas, como tamb

em a veriﬁcac¸

ao de cadeias

de certiﬁcados.

Para que a infra-estrutura SPKI/SDSI se tornasse mais ﬂex

ıvel e eﬁciente para ser usada pelo

servic¸o XKMS de forma a agilizar a busca de cadeias de certiﬁcados SPKI e a validac¸

ao das mesmas,

esta biblioteca foi acrescida de algumas extens

oes. Toda a habilidade de se trabalhar com objetos

SPKI/SDSI no prot

otipo

e garantida atrav

es da classe SPKIResolver e esta foi desenvolvida dentro

do projeto Cadeias de Conﬁanc¸a (Conte

udos Digitais - CNPq/PROTEM)

Para o suporte criptogr

aﬁco, a biblioteca utiliza o Cryptix32, que

e uma implementac¸

ao das ex-

tens

oes de criptograﬁa do Java (JCE - Java Cryptography Extensions). Por

em, o JSDSI s

o trabalha

com chaves RSA, embora a especiﬁcac¸

ao do SPKI/SDSI prev

e o uso de outras chaves, como chaves

DSA (Digital Signature Algorithm).

Como os objetos SPKI/SDSI s

ao descritos em S-expressions (Rivest, 1997), estes podem ser ar-

mazenados no formato ASCII, podendo estar em um arquivo texto ou at

e mesmo em um banco de

dados relacional. A ferramenta presente na biblioteca JSDSI2.0 utiliza como reposit

orio um simples

arquivo texto. Para facilitar o gerenciamento dos objetos SPKI/SDSI e agilizar a busca de certiﬁ-

cados a biblioteca parserSxxS, desenvolvida no projeto Cadeias de Conﬁanc¸a, foi implementada de

maneira que todos os objetos suportados pela biblioteca JSDSI pudessem ser convertidos para docu-

mentos XML e vice-versa. Para isso,

e seguido o DTD (Document Type Deﬁnition) especiﬁcado em

(Apparao et al., 1998) e pode ser utilizada como ferramenta para construir aplicac¸

oes que trabalhem

com a infra-estrutura SPKI/SDSI. Assim, a biblioteca permite a completa adoc¸

ao de documentos

XML como uma forma para armazenar objetos SDSI ao inv

es de S-expressions, tornando mais

agil a

manipulac¸

ao destes documentos e ainda permite que aplicac¸

oes SPKI/SDSI que utilizam documentos

Para contornar este problema foi feita uma modiﬁcac¸

ao na vers

ao contida no CVS do projeto AXIS.

www.das.ufsc.br/seguranca

5. Implementac¸

ao 57

XML trabalhem perfeitamente com aplicac¸

oes SPKI/SDSI que s

o conhec¸am S-expressions (de Melo,

2003).

No contexto das Federac¸

oes SPKI/SDSI, implementadas no projeto Cadeias de Conﬁanc¸a, h

a dois

tipos de reposit

orios: os reposit

orios locais e os reposit

orios globais (pacotes repository.local e

pacote repository.global) (de Melo, 2003). O pacote repository.local, desenvolvidos em

Java, situam-se junto de cada membro da federac¸

ao. S

ao implementados em uma estrutura de ar-

quivos, a qual representa os documentos XML armazenados no reposit

orio e ainda mecanismos para

manutenc¸

ao desta base de dados como a inclus

ao, modiﬁcac¸

ao, exclus

ao de arquivos bem como a

busca por alguma informac¸

ao dentro destes arquivos, tendo para isto utilizado o parser SAX (Simple

API for XML) (Megginson, 1998), presente no J2SE 1.5.

a para o reposit

orio global, que situa-se junto aos servic¸os XKMS, foi utilizado o Apache Xin-

dice (Staken, 2002). O Xindice

e um banco de dados que armazena documentos XML de forma

nativa e utiliza o XPath (Clark e DeRose, 1999) como linguagem para recuperac¸

ao de documentos.

Assim o pacote repository.global consiste basicamente da implementac¸

ao de mecanismos que

propiciem fazer consultas, inclus

oes, remoc¸

oes e modiﬁcac¸

oes r

apidas e simples na base de dados,

implementada pelo Xindice.

Tamb

em foi desenvolvida uma classe chamada RepositorioResolver para auxiliar na ger

encia

de certiﬁcados membros e associados da Federac¸

ao. Esta classe prov

e funcionalidades que encapsu-

lam o acesso ao reposit

orio facilitando assim as operac¸

oes executadas no mesmo.

5.2.3 Qualidade de Servic¸o

A seguranc¸a das interac¸

oes entre servic¸os est

a inclu

ıda na camada de qualidade de servic¸o. Para

prover suporte a esta camada, foi escolhido o Apache WSS4J (http://ws.apache.org/wss4j/) que prov

uma implementac¸

ao em Java de c

odigo da WS-Security (Nadalin et al., 2004).

O WSS4J prov

e recursos para a construc¸

ao de servic¸os Web de forma interoper

avel usando o

padr

ao WS-Security. O WSS4J utiliza a engine do Axis e invoca uma s

eries de handlers na entrada

e sa

ıda de mensagens SOAP, permitindo assim, uma clara separac¸

ao da l

ogica de neg

ocio da l

ogica

do processamento da seguranc¸a. Os handlers permitem o desenvolvimento e a adic¸

ao de novas carac-

ter

ısticas de seguranc¸a com o m

ınimo de impacto no c

odigo e conﬁgurac¸

oes existentes.

Para prover o suporte a assinaturas XML (XML Signature), utilizadas nestes handlers,

e utili-

zada a biblioteca implementada no projeto Apache XML Security. Este projeto foi escolhido por ser

um projeto de c

odigo aberto, que implementa a especiﬁcac¸

ao W3C de assinatura XML e permite a

implementac¸

ao de extens

oes da especiﬁcac¸

ao de assinatura XML.

Este projeto requisita a biblioteca Java Cryptography Extensions (JCE), que n

ao est

a inclu

ıda

com a distribuic¸

ao padr

ao. Tamb

e necess

aria uma vers

ao est

avel do Xalan, que

e um processador

usado com a XSLT para transformar documentos XML criado pelo Apache XML Project. Por ser uma

implementac¸

ao desenvolvida pela apache foundation, a conﬁabilidade e prosseguimento na correc¸

de eventuais bugs

e garantida.

5. Implementac¸

ao 58

A especiﬁcac¸

ao W3C de assinatura XML prev

e que o elemento ds:KeyInfo contenha um subele-

mento chamado ds:SPKIData. Este subelemento

e usado para transmitir pares de chave, certiﬁcados

ou outro dado SPKI. Entretanto a especiﬁcac¸

ao n

ao deﬁne como estes dados SPKI s

ao inseridos no

ds:SPKIData. Por este motivo, neste trabalho, foi deﬁnida uma extens

ao ao esquema XKMS de

modo a restringir quais elementos da infra-estrutura SPKI/SDSI podem ser inseridos em uma assina-

tura XML (Figura 5.2).

</sequence>

</complexType>

</sequence>

</complexType>

Figura 5.2: Extens

ao do XML Signature Schema

O elemento ds:SPKIData cont

em o elemento ds:SPKISexp que, por sua vez cont

em os subele-

mentos, indicados na Tabela 5.1.

KeyValue Valor de uma chave p

ublica

tag Express

ao real que pode transmitir autorizac¸

oes.

uris Lista de URI.

authorization-cert Certiﬁcado de autorizac¸

ao SPKI.

name-cert Certiﬁcados de nome SPKI

sequence Seq

encia SPKI.

Tabela 5.1: Subelementos do ds:SPKISexp

5.2.4 XKMS

A especiﬁcac¸

ao do XKMS prev

e diferentes modos de trocas de mensagens entre os servic¸os

XKMS e seus clientes. Neste trabalho, para a troca de mensagens entre o servic¸o XKMS e os seus

servic¸os XKMS associados, o protocolo ass

ıncrono a duas fases

e usado (sec¸

ao 3.6.3). Este protocolo

foi escolhido para que o servic¸o n

ao ﬁque bloqueado toda vez que recebe uma requisic¸

ao de um outro

servic¸o XKMS associado e para a protec¸

ao contra negac¸

ao de servic¸o, respectivamente.

a para as trocas de mensagens entre os servic¸os XKMS e seus membros foi usado o protocolo

ıncrono a duas fases. Novamente o protocolo a duas fases foi escolhido para prover a protec¸

ao contra

5. Implementac¸

ao 59

negac¸

ao de servic¸o e a escolha do modo s

ıncrono deve-se a limitac¸

ao da vers

ao utilizada do Axis que

o prov

e processamento s

ıncrono.

Foi desenvolvida uma classe chamada RepositorioResolver, que traz como facilidades: a

busca por URIs de detentores de direitos no reposit

orio e as URIs de associados. Tamb

em fazem parte

de suas funcionalidades o teste, determinar atrav

es de uma chave p

ublica se o detentor da mesma

um membro, um associado forte, ou um associado fraco. Estas funcionalidades s

ao necess

arias para

a implementac¸

ao do algoritmo implementado na operac¸

ao de localizac¸

ao. Al

em destas facilidades,

esta classe tamb

em prov

e as func¸

oes de gerenciamento de membros, associados e certiﬁcados, sendo

respons

avel pelo registro dos mesmos no reposit

orio da Federac¸

ao.

No cap

ıtulo 4, para o servic¸o XKMS foram introduzidas as operac¸

oes de localizac¸

ao e de validac¸

e registro. Estas operac¸

oes foram implementadas no prot

otipo e, abaixo encontram-se os diagramas

de seq

encia e alguns detalhes da implementac¸

ao de cada uma destas operac¸

oes.

5.2.4.1 Cen

arios que fazem uso da operac¸

ao de Localizac¸

O primeiro cen

ario ocorre quando um cliente requisita ao servic¸o XKMS a localizac¸

ao do prin-

cipal que det

em a cadeia de certiﬁcados necess

aria para o acesso ao recurso. Neste caso, o cliente

envia uma requisic¸

ao ao servic¸o XKMS contendo as informac¸

oes necess

arias para a localizac¸

ao e

o servic¸o responde com os valores das uris dos sujeitos aos quais foram delegados os direitos. No

segundo cen

ario, o cliente tenta acessar um recurso e recebe um desaﬁo, contendo uma ACL, para

que o mesmo prov

e a posse do direito de acesso a este recurso. Entretanto, este cliente n

ao sabe

como process

a-la. Nesta circunst

ancia, o mesmo deve enviar esta ACL ao servic¸o XKMS. O servic¸o

processa a ACL e a partir de cada entrada, executa a localizac¸

ao da cadeia desejada do mesmo modo

que no cen

ario anterior.

Figura 5.3: Diagrama de Seq

encia de Localizac¸

Os detalhes da implementac¸

ao desta operac¸

ao podem ser observados no diagrama de seq

encia

da Figura 5.3. Primeiramente

e feita uma veriﬁcac¸

ao do dado recebido, caso seja uma ACL esta

tratada atrav

es de uma chamada a classe SPKIResolver antes do in

ıcio da localizac¸

ao do certiﬁcado.

5. Implementac¸

ao 60

5.2.4.2 Cen

arios que fazem uso da operac¸

ao de Validac¸

Este cen

ario trata da validac¸

ao de certiﬁcados SPKI. Um cliente faz uma requisic¸

ao ao servic¸o

XKMS enviando uma seq

encia contendo uma cadeia de certiﬁcados, a chave do sujeito e o direito

delegado. Como resposta o servic¸o XKMS envia o resultado da validac¸

ao. Na Figura 5.4, encontra-

se o diagrama de seq

encia desta operac¸

ao, onde tamb

em faz-se o uso do SPKIResolver para a

validac¸

ao da cadeia.

Figura 5.4: Diagrama de Seq

encia de Validac¸

5.2.4.3 Cen

arios que fazem uso da operac¸

ao de Registro

Conforme citado no cap

ıtulo 4, a operac¸

ao de Registro pode ser utilizada em tr

es cen

arios dife-

rentes: ﬁliac¸

ao de membros, associac¸

ao de servic¸os XKMS ou ainda, envio de certiﬁcados deleg

aveis

para serem armazenados no reposit

orio da Federac¸

ao SPKI.

Quando um cliente deseja se ﬁliar a Federac¸

ao SPKI, o mesmo envia uma requisic¸

ao de registro

contendo o endosso efetivado atrav

es do threshold certiﬁcate assinado por k-dentre-n membros da

Federac¸

ao em quest

ao. Ao veriﬁcar que o conte

udo da mensagem

e um endosso para ﬁliac¸

ao, o

servic¸o XKMS veriﬁca a validade do mesmo. Caso o endosso seja v

alido, o servic¸o XKMS emite um

certiﬁcado de grupo de ﬁliados para o cliente e os demais membros e armazena a chave p

ublica deste

novo membro.

Se o endosso

e para uma associac¸

ao, o servic¸o XKMS veriﬁca a validade do mesmo. Caso o

endosso seja v

alido, o servic¸o XKMS emite um certiﬁcado de grupo de associados para o servic¸o

XKMS solicitante.

Por

em se um cliente faz uma requisic¸

ao ao servic¸o XKMS enviando uma seq

encia contendo

uma cadeia de certiﬁcados, o servic¸o XKMS veriﬁca se este

e membro da Federac¸

ao SPKI e, em caso

aﬁrmativo, armazena a cadeia no reposit

orio da Federac¸

ao. A Figura 5.5 mostra aspectos de como

esta implementac¸

ao foi realizada.

5. Implementac¸

ao 61

Figura 5.5: Cen

ario de Registro 2

5.3 Integrac¸

ao do Prot

otipo a uma Aplicac¸

ao Distribu

ıda

A id

eia da aplicac¸

ao exemplo foi proposta em (de Melo et al., 2004) e surgiu da atual necessidade

em possuir um reposit

orio distribu

ıdo de artigos onde se pudesse realizar consultas a textos cient

ıﬁcos,

informando nome do autor, t

ıtulo do trabalho, etc. e que fosse retornado a maior quantidade de

indicac¸

oes de artigos poss

ıveis sobre um determinado assunto.

O usu

ario de um aplicativo stand-alone pode se autenticar somente uma

unica vez nesta base

distribu

ıda, realizando consultas e, assim, recebendo uma resposta

unica de informac¸

oes provenientes

de diversos servic¸os que comp

oem esta base de informac¸

oes distribu

ıda. Uma vez autenticado, o

usu

ario

e poupado da necessidade de se autenticar ou conhecer os mecanismos de busca nas v

arias

organizac¸

oes que cooperam neste sistema de informac¸

oes distribu

ıdas.

Serviço Web A

Cliente

Serviço Web B

Serviço Web C

Serviço Web D

Figura 5.6: Din

amica da aplicac¸

ao (de Melo et al., 2004)

Para que isso seja poss

ıvel

e necess

ario que os servic¸os Web envolvidos possuam alguma relac¸

de conﬁanc¸a, ou seja, que um usu

ario autenticado em algum destes servic¸os esteja autorizado a aces-

sar os recursos providos pelos demais, desde que possua os direitos necess

arios. Essa relac¸

ao de

5. Implementac¸

ao 62

conﬁanc¸a pode ser simples, estabelecida em algum momento do passado entre os administradores dos

sistemas envolvidos, atrav

es do cadastro dos servic¸os associados, ou poderiam adotar modelos com

pol

ıticas de neg

ocios complexas as quais poderiam deﬁnir taxas para o uso de seus servic¸os(de Melo

et al., 2004).

Figura 5.7: Retorno da busca

O servic¸o Web montado para pesquisas de artigos consiste basicamente de uma interface, a qual

interage com o usu

ario, e um motor de buscas, respons

avel por realizar consultas em bases locais,

remotas ou ainda invocando outros servic¸os Web. A din

amica da aplicac¸

ao pode ser vista na Figura

5.6. O cliente realiza a busca atrav

es da interface do servic¸o Web A e este efetua a consulta em seu

reposit

orio local e propaga a consulta para os demais servic¸os Web. Por ﬁm retorna ao aplicativo do

usu

ario uma

unica lista de ponteiros para todos os artigos encontrados (Figura 5.7).

Quando o usu

ario selecionar um destes ponteiros retornados, o aplicativo envia uma mensagem de

requisic¸

ao ao servic¸o Web que possui em seu reposit

orio o artigo desejado. Ao receber esta mensagem

o servic¸o Web lanc¸a um desaﬁo para este usu

ario para que este prove a posse do direito de acesso a

este artigo.

Figura 5.8: Opc¸

ao de localizac¸

ao no reposit

orio da Federac¸

ao SPKI

Se a aplicac¸

ao n

ao encontrar em seu reposit

orio local o direito necess

ario para o acesso, esta d

5. Implementac¸

ao 63

a opc¸

ao de localizac¸

ao no reposit

orio da Federac¸

ao o qual o usu

ario

e ﬁliado (Figura 5.8). Caso o

usu

ario aceite esta opc¸

ao a aplicac¸

ao envia uma requisic¸

ao de localizac¸

ao ao servic¸o XKMS para que

este realize a busca da cadeia de certiﬁcados que ligue a aplicac¸

ao cliente ao servidor. O servic¸o

retorna esta cadeia e o usu

ario pode enﬁm visualizar o conte

udo do ponteiro retornado pelo servic¸o

Web de pesquisa de artigos.

5.4 Considerac¸

oes

Os resultados observados a partir de textos desenvolvidos e da integrac¸

ao com a aplicac¸

ao citada

comprovou a validade do modelo proposto em aspectos que foram levantados neste texto, como o

isolamento das aplicac¸

oes em relac¸

ao a ger

encia de chaves e o uso de padr

oes.

As operac¸

oes deﬁnidas no cap

ıtulo 4 foram implementadas e seguem o comportamento desejado,

conforme descrito na sec¸

ao anterior. Na operac¸

ao de localizac¸

ao, foi implementado o algoritmo

apresentado na sec¸

ao 4.5. Para auxiliar o servic¸o XKMS no acesso ao reposit

orio da Federac¸

ao, foi

desenvolvida uma classe RepositorioResolver que encapsula o acesso ao mesmo. Tamb

em foi

utilizada a SPKIResolver, para a implementac¸

ao do cen

ario 2 da operac¸

ao de localizac¸

ao, como

aux

ılio no processamento da ACL.

A operac¸

ao de validac¸

ao foi implementada de forma que ao receber as seq

encias assinadas,

e ent

ao realizada a validac¸

ao das mesmas. Novamente foi utilizada a classe SPKIResolver como

aux

ılio para a validac¸

ao. A implementac¸

ao da operac¸

ao de registro tamb

em faz uso da classe SPKIResolver

e de funcionalidades da classe que encapsula reposit

orio. Esta classe proveu o auxilio no registro de

cadeias de certiﬁcados, membros e associados no reposit

orio da Federac¸

ao.

Existem servic¸os XKMS, tais como o SQLData XKMS Server v2.0 (SQLData XKMS Server

v2.0, 2005), que implementa a especiﬁcac¸

ao XKMS 1.0 e foi desenvolvida em C++. O servidor

desta implementac¸

e empacotado juntamente com uma autoridade certiﬁcadora e

e capaz de emitir,

validar e revogar certiﬁcados de forma s

ıncrona e ass

ıncrona.

Richard Salz (Richard Salz, 2003) tamb

em mostra como implementar um servic¸o XKRSS da

especiﬁcac¸

ao do XKMS 1.0 com as operac¸

oes register e revoke na linguagem Python. Nesta proposta

que n

ao tem uma CA integrada, para o suporte da PKI

e necess

ario um certiﬁcado SSL ou uma chave

privada, que sirva de mestre nas emiss

oes de certiﬁcados a partir deste servic¸o. Estas implementac¸

oes

citadas acima, al

em de suportarem apenas a PKI X.509, seguem a vers

ao 1.0 da especiﬁcac¸

ao XKMS.

O projeto Markup Security Project implementa um servic¸o XKMS que prov

e suporte para as PKIs

X.509 e PGP. Este projeto tamb

em incorpora suporte para hardware criptogr

aﬁco, permitindo assim

o uso de smartcards que prov

eem a interface PKCS 11

tanto no lado cliente como no lado servidor.

Uma outra proposta de servic¸o XKMS pode ser encontrado em (XKMS Prototype Server, 2005).

Este prot

otipo suporta somente as operac¸

oes XKISS (locate e validade) sobre os protocolos s

ıncrono,

Padr

ao de criptograﬁa de chaves p

ublicas que controla dispositivos de seguranc¸a, como cart

oes inteligentes.

5. Implementac¸

ao 64

ass

ıncrono, de 2 fases e requisic¸

oes compostas. Existe tamb

em uma outra implementac¸

ao que envolve

a operac¸

ao Validate do XKMS, dirigida

a testes de interoperabilidade apresentada em (XKMS 2

Interop Test Site, 2005). Estes prot

otipos do servic¸o somente geram o XML das mensagens XKMS,

a que o objetivo dos mesmos

e apenas um servic¸o para testes de interoperabilidade.

A ferramenta PHAOS XKMS (http://www.phaos.com/products/xkms/xkms.html) implementa a

especiﬁcac¸

ao XKMS 2.O e prov

e suporte para as operac¸

oes XKISS e XKRSS. Nesta implementac¸

a localizac¸

ao e validac¸

ao de certiﬁcados utiliza entre outras ferramentas como o LDAP e o OSCP

respectivamente. Por

em esta ferramenta, que d

a suporte ao X.509, foi comprada pela ORACLE, que

ao o apresentou ainda como produto comercial.

Existe tamb

em o Trust Service Integration Kit (Trust Service Integration Kit, 2005), que

e um kit

de integrac¸

ao de conﬁanc¸a que prov

e uma API Java para minimizar a complexidade no desenvolvi-

mento de aplicac¸

oes de conﬁanc¸a. Este kit prov

e uma API para a construc¸

ao de um cliente XKMS

que faz requisic¸

oes de registro, localizac¸

ao e validac¸

ao de certiﬁcados e chaves. Este kit tamb

baseado na PKI X.509.

Conforme pode ser observado, todas estas implementac¸

oes encontradas n

ao integram o SPKI ao

XKMS, sendo que o prot

otipo desenvolvido

e a primeira implementac¸

ao a realizar esta integrac¸

ao.

Este prot

otipo traz como benef

ıcio al

em de uma extens

a especiﬁcac¸

ao do XKMS para integrac¸

com o SPKI, o suporte

a localizac¸

ao de certiﬁcados SPKI de forma padronizada.

E importante salientar que nenhuma das experi

encias, envolvendo o XKMS, citadas acima est

dispon

ıvel em c

odigo aberto. Para desenvolver o XKMS foi utilizada a especiﬁcac¸

ao XKMS 2.0

(Hallam-Baker, 2004), por

em este n

ao contempla requisic¸

oes compostas, al

em das operac¸

oes revogar,

reemitir e de recuperar informac¸

oes associadas a chaves p

ublicas.

Estas omiss

oes na nossa implementac¸

ao, como j

a foi explicado (sec¸

ao 4.2), se deve ao fato de que

ao s

ao aplic

aveis no manuseio de certiﬁcados SPKI.

5.5 Conclus

Este cap

ıtulo descreve a implementac¸

ao do prot

otipo e da sua integrac¸

ao a uma aplicac¸

ao. O

objetivo do prot

otipo era validar a aplicabilidade do modelo de seguranc¸a proposto nesta dissertac¸

ao.

Foram apresentados os cen

arios de uso do prot

otipo bem como apresentadas implementac¸

oes

existes na literatura e a comparac¸

ao entre estas com a implementac¸

ao do prot

otipo.

Cap

ıtulo 6

Conclus

oes

Com a crescente evoluc¸

ao da Internet impulsionando a demanda por aplicac¸

oes distribu

ıdas,

criou-se a necessidade de uma arquitetura que fornecesse um meio de integrar diferentes tecnolo-

gias e linguagens de programac¸

ao. Atrav

es de servic¸os Web, que seguem a arquitetura AOS, esta

integrac¸

ao tornou-se poss

ıvel, j

a que estes n

ao imp

oem restric¸

oes de algum tipo de implementac¸

e as trocas de mensagens entre aplicac¸

oes de corporac¸

oes que utilizam tecnologias diferentes s

realizadas atrav

es de protocolos padr

oes.

Nesta dissertac¸

ao foram discutidos alguns aspectos da seguranc¸a computacional em sistemas dis-

tribu

ıdos. Foram tamb

em revisados os conceitos fundamentais, as pol

ıticas de seguranc¸a, as t

ecnicas

nas quais os mecanismos de seguranc¸a est

ao baseados e as abordagens de implementac¸

ao dos meca-

nismos de autenticac¸

ao e de autorizac¸

ao.

Foi observado que a escalabilidade limitada e a falta de ﬂexibilidade, indispens

aveis em ambientes

distribu

ıdos de larga escala s

ao as principais diﬁculdades encontradas nos modelos que seguem uma

abordagem de autenticac¸

ao centralizada. A habilidade de deﬁnir grupos e de delegar autorizac¸

oes,

bem como as facilidades para o desenvolvimento de sistemas computacionais distribu

ıdos escal

aveis

e seguros, fazem do SPKI/SDSI uma boa opc¸

ao de suporte para o desenvolvimento de aplicac¸

oes dis-

tribu

ıdas baseadas em redes de conﬁanc¸a. Por

em foi observado que o modelo SPKI/SDSI apresenta,

como diﬁculdade, a localizac¸

ao de cadeias de certiﬁcados que levem um cliente a obter a autorizac¸

necess

aria para acessar os recursos de um servidor desejado, podendo haver casos em que o cliente

ao possua o caminho de conﬁanc¸a necess

ario que o autorize diante do servidor do recurso alvo de

acesso.

Para solucionar este problema foi proposta em (Santin, 2004) uma extens

ao do modelo de conﬁanc¸a

do SPKI/SDSI chamada Federac¸

ao SPKI, que

e uma entidade que re

une principais com interesses

aﬁns e atua como um agente facilitador na localizac¸

ao de certiﬁcados e principais, pois permite o

compartilhamento do acesso ao seu reposit

orio de certiﬁcados. Atrav

es deste compartilhamento, os

clientes passam a ter uma alternativa a recorrer quando da falta de cadeias apropriadas para o acesso

desejado. Entretanto p

ode ser conclu

ıdo que este modelo de ger

encia ao preservar a ﬁlosoﬁa adotada

no modelo SPKI/SDSI no qual o principal que deseja obter acesso a algum recurso

e inteiramente

6. Conclus

oes 66

respons

avel pela busca das cadeias de certiﬁcados que lhe fornec¸am o direito de acesso, sobrecar-

rega o cliente. Al

em disso, este modelo n

ao prov

e um protocolo padr

ao de acesso as func¸

oes de

gerenciamento e estabelecimento de conﬁanc¸a providos pelo mesmo.

Neste trabalho foi apresentada uma abordagem para integrar o conceito de Federac¸

ao SPKI/SDSI

aos padr

oes de servic¸os Web e de extens

oes XML. Os estudos apresentados sobre servic¸os Web e XML

e das extens

oes de seguranc¸a mostraram a necessidade de extens

oes principalmente nas especiﬁcac¸

oes

de assinaturas XML para a adequac¸

ao destas tecnologias ao SPKI.

Os esforc¸os realizados levaram ao resultado de oferecer a partir do modelo de Federac¸

oes SPKI/SDSI,

func¸

oes de gerenciamento aos certiﬁcados SPKIs atrav

es da tecnologia orientada a servic¸os, via

XKMS. A localizac¸

ao de certiﬁcados atribu

ıda ao servic¸o XKMS poupa o cliente desta tarefa. Este

modelo, por se tratar de um servic¸o XKMS, apresenta um protocolo padr

ao de acesso as func¸

oes de

gerenciamento e estabelecimento de conﬁanc¸a providos pelo mesmo.

O prot

otipo implementado, baseado em uma aplicac¸

ao que faz uma busca de textos cient

ıﬁcos em

um servic¸o de publicac¸

ao Web ﬁct

ıcio, enfatiza a viabilidade e a adequac¸

ao do modelo proposto com

a tecnologia de servic¸os Web.

Concluindo ent

ao, acredita-se que os objetivos apresentados na sec¸

ao 1.2 que nortearam este

trabalho tenham sido alcanc¸ados e que este tenha contribu

ıdo de forma simples para o avanc¸o do uso

de t

ecnicas e padr

oes em aplicac¸

oes programados segundo a

otica de orientac¸

ao a servic¸o.

Refer

encias Bibliogr

aﬁcas

Adams, C. e Boeyen, S. (2002). Uddi and wsdl extensions for web service: a security framework.

Em Proceedings of the 2002 ACM workshop on XML security, p

aginas 80–89.

Anderson, S. et al. (2005a). Web Services Secure Conversation Language (WS-

SecureConversation). Dispon

ıvel na Internet,

ultima visita em julho de 2005.

ftp://www6.software.ibm.com/software/developer/library/ws-secureconversation.pdf.

Anderson, S. et al. (2005b). Web Services Trust Language (WS-Trust). Dispon

ıvel na Internet,

ultima

visita em julho de 2005. ftp://www6.software.ibm.com/software/developer/library/ws-trust.pdf.

Apparao, V., Byrne, S., Champion, M., Isaacs, S., Jacobs, I., Hors, A. L., Nicol, G., Robie, J.,

Sutor, R., Wilson, C., e Wood, L. (1998). Document Object Model Level 1 Speciﬁcation ver-

sion 1.0 - W3C recommendation. Dispon

ıvel na Internet,

ultima visita em agosto de 2005.

http://www.w3.org/TR/RECDOM-Level-1.

Aura, T. (1998). On the structure of delegation networks. Em 11th IEEEE Computer Security Foun-

dations Workshop, Rockport, MA USA.

Bajaj, S. (2003). Web Services Federation Language (WSFederation). Dispon

ıvel na Internet,

ultima

visita em julho de 2005. www-106.ibm.com/developerworks/ webservices/library/ws-fed.

Bajaj, S. (2004). Web Services Policy Framework (WSPolicy). Dispon

ıvel na Internet,

ultima visita

em setembro de 2004. ftp://www6.software.ibm.com/software/developer/library/ws-policy.pdf.

Bartel, M. (2002). XML-Signature Syntax and Processing. Dispon

ıvel na Internet,

ultima visita em

julho de 2004. http://www.w3.org/TR/xmldsig-core/.

BERNERS-LEE, T., FIELDING, R. E., e MASINTER, L. (1998). Uniform Resource Identiﬁers

(URI): Generic Syntax. Internet Engineering Task Force RFC 1396.

Bilykh, I., Bychkov, Y., Dahlem, D., Jahnke, J. H., McCallum, G., C. Obry, A. O., e Kuziemsky,

C. (2003). Can grid services provide answers to the challenges of national health information

sharing? Em Proceedings of the 2003 conference of the Centre for Advanced Studies on Colla-

borative research, p

aginas 01–15.

Bishop, M. (2003). Computer Security. Addison-Wesley. ISBN 0-201-44099-7.

Refer

encias Bibliogr

aﬁcas 68

Booth, D. (2004). Web Services Architecture. Dispon

ıvel na Internet,

ultima visita em junho de 2004.

http://www.w3.org/TR/ws-arch/.

Boyer, J. (2001). Canonical XML. Dispon

ıvel na Internet,

ultima visita em julho de 2004.

http://www.w3.org/TR/xml-c14n.

Bray, T. et al. (2004). Extensible Markup Language (XML) 1.0 (Third Edition). Dispon

ıvel na

Internet,

ultima visita em julho de 2005. http://www.w3.org/TR/REC-xml/.

Cantor, S. et al. (2005). Assertions and Protocol for the OASIS Security Assertion Markup Lan-

guage (SAML) V2.0. Dispon

ıvel na Internet,

ultima visita em julho de 2005. http://docs.oasis-

open.org/security/saml/v2.0/saml-core-2.0-os.pdf.

Chinnici, R. (2005). Web Services Description Language (WSDL) Version 2.0. Dispon

ıvel na Inter-

net,

ultima visita em julho de 2005. http://www.w3.org/TR/wsdl20.

Clark, J. e DeRose, S. (1999). XML Path Language (XPath). Dispon

ıvel na Internet,

ultima visita em

julho de 2005. http://www.w3.org/TR/xpath.

Clarke, D. E. (2001). SPKI/SDSI HTTP Server / Certiﬁcate Chain Discovery in SPKI/SDSI. Tese de

Doutorado, MIT.

Clement, L. et al. (2004). UDDI Version 3.0.2. Dispon

ıvel na Internet,

ultima visita em julho de

2005. http://uddi.org/pubs/uddiv3.htm.

Curbera, F. (2002). Unraveling the web services web: An introduction to soap, wsdl, and uddi. Em

IEEE Internet Computing, p

aginas 86–93. IEEE Educational Activities Department.

Damiani, E., di Vimercati, S. D. C., e Samarati, P. (2002). Towards securing xml web services. Em

Proceedings of the 2002 ACM workshop on XML security, p

aginas 90 – 96, New York, USA.

Daniel J. Polivy, R. T. (2002). Authenticating distributed data using web services and xml signatures.

Em Proceedings of the 2002 ACM workshop on XML security, p

aginas 80–89.

David C. Fallside, P. W. (2004). XML Schema Part 0: Primer Second Edition. Dispon

ıvel na Internet,

ultima visita em julho de 2005. http://www.w3.org/TR/xmlschema-0/.

de Melo, E. R. (2003). Redes de conﬁanc¸a em sistemas de objetos CORBA. Tese de Doutorado,

UFSC.

de Melo, E. R., Acajima, G., e Fraga, J. (2004). Integrac¸

ao da arquitetura de seguranc¸a dos servic¸os

web com modelos de conﬁanc¸a igualit

aria. SSI 2004 - 6

◦

Simposio Seguranca em Informatica.

Department of Defense (1985). Trusted computer system evaluation criteria. DOD 5200.28-STD.

Dierks, T. e Allen, C. (1999). The TLS Protocol. Internet Draft.

Ellison, C. M., Frantz, B., Lampson, B., Rivest, R., Thomas, B. M., e Ylonen, T. (1999). SPKI

Certiﬁcate Theory. Internet Engineering Task Force RFC 2693.

Refer

encias Bibliogr

aﬁcas 69

FastTrack (2001). FastTrack Peer-to-Peer technology company. Dispon

ıvel na Internet,

ultima visita

em agosto de 2005. http://www.fasttrack.nu.

Freier, A. O., Karlton, P., e Kocher, P. C. (1996a). The SSL protocol - version 3. Internet Draft.

Freier, A. O., Karlton, P., e Kocher, P. C. (1996b). The SSL protocol - version 3. Internet Draft.

Gerck, E. (2000). Overview of certiﬁcation systems: X.509, CA, PGP and SKIP. Visitado em

03/02/2003.

Gudgin, M. et al. (2003). SOAP Version 1.2 Part 1: Messaging Framework. Dispon

ıvel na Internet,

ultima visita em julho de 2005. http://www.w3.org/TR/soap12-part1/.

Hallam-Baker, P. (2004). XML Key Management Speciﬁcation (XKMS 2.0). Dispon

ıvel na Internet,

ultima visita em julho de 2005. http://www.w3.org/TR/xkms2.

Hughes, J. e Maler, E. (2004). Security Assertion Markup Language (SAML) 2.0 Technical Over-

view. Dispon

ıvel na Internet,

ultima visita em julho de 2005. http://xml.coverpages.org/SAML-

TechOverviewV20-Draft7874.pdf.

Imamura, T. (2002). XML Encryption Syntax and Processing. Dispon

ıvel na Internet,

ultima visita

em agosto de 2004. http://www.w3.org/TR/xmlenc-core/.

ITU-T (1993). ITU-T recommendation x.509. http://www.mcg.org.br/mirrors/97x509ﬁnal.doc. Visi-

tado em 22/08/2005.

Kim, J. e Moon, K. (2005). Design of uniﬁed key management model using xkms. Em Advanced

Communication Technology, 2005, ICACT 2005, p

aginas 77–80.

Kohl, J. e Neuman, C. (1993). The Kerberos Network Authentication Service (v5). Internet Enginee-

ring Task Force RFC 1510.

Kraft, R. (2002). Designing a distributed access control processor for network services on the web.

ACM Transactions on Information and System Security (TISSEC), 7(1):36–52.

Landwehr, C. E. (2001). Computer Security. Em International Journal of Information Security,

volume 1, p

aginas 3–13. Springer-Verlag Heidelberg.

Madsen, P. (2004). Assertions and Protocol for the OASIS Security Assertion Markup Lan-

guage (SAML) V2.0. Dispon

ıvel na Internet,

ultima visita em agosto de 2005. www.oasis-

open.org/committees/download.php/9886/sstc-saml-exec-overview-2.0-draft-02.pdf.

Medjahed, B., Benatallah, B., Bouguettaya, A., Ngu, A. H. H., e Elmagarmid, A. K. (2003). Business-

to-business interactions: issues and enabling technologies. The International Journal on Very

Large Data Bases, 12(1):59–85.

Megginson, D. (1998). The Simple API for XML. Dispon

ıvel na Internet. Dispon

ıvel na Internet,

ultima visita em agosto de 2005. http://www.saxproject.org/.

Refer

encias Bibliogr

aﬁcas 70

Mitra, N. (2003). SOAP Version 1.2 Part 0: Primer. Dispon

ıvel na Internet,

ultima visita em julho de

2005. http:http://www.w3.org/TR/2003/REC-soap12-part0-20030624/.

Morcos, A. (1998). A Java implementation of Simple Distributed Security Infrastructure. Dissertac¸

de mestrado, MIT.

Moses, T. (2005). eXtensible Access Control Markup Language (XACML) Version 2.0. Dispon

ıvel

na Internet,

ultima visita em julho de 2005. http://docs.oasis-open.org/security/saml/v2.0/saml-

core-2.0-os.pdf.

Nadalin, A. et al. (2004). Web Services Security: SOAP Message Security 1.0 (WS-Security 2004).

Dispon

ıvel na Internet,

ultima visita em julho de 2005. docs.oasis-open.org/wss/2004/01/oasis-

200401-wss-soap-message-security-1.0.pdf.

Naedele, M. (2003). Standards for xml and web services security. Em Computer, p

aginas 96 – 98.

IEEE Educational Activities Department.

Needham, R. M. e Schroeder, M. D. (1978). Using encryption for authentication in large networks of

computers. Em Communications of the ACM 21(12), p

aginas 993–999.

Neuman, B. C. (1994). Readings in Distributed Computing Systems, chapter Scale in distributed

systems, p

aginas 463–489. IEEE Computer Society, Los Alamitos, CA.

Nicomette, V. (1996). La Protection dans les Syst

emes

a Objets R

epartis. Tese de Doutorado, Institut

National Polytechnique de Toulouse.

O’Neill, M. (2003). Web Services Security. Brando A. Nordin. ISBN 0-07-222471-1.

Park, N., Moon, K., e Sohn, S. (2003). Xml security: Certiﬁcate validation service using xkms for

computational grid. Em Proceedings of the 2003 ACM workshop on XML security, p

aginas

112–120.

Richard Salz (2003). Developing a X-KRSS Web Service. Dispon

ıvel na Internet,

ultima visita em

setembro de 2005. http://webservices.xml.com/pub/a/ws/2003/11/25/salz.html.

Rivest, R. (1997). SEXP (S-expressions). Internet Engineering Task Force - Internet Draft.

Rivest, R. L. e Lampson, B. (1996). SDSI – A simple distributed security infrastructure. Presented at

CRYPTO’96 Rumpsession. http://citeseer.nj.nec.com/rivest96sdsi.html.

Sandhu, R. S. e Samarati, P. (1994). Access control: Principles and practice. IEEE Communications

Magazine, 32(9):40–48.

Santin, A. (2004). Teias de Federac¸

oes: uma Abordagem baseada em Cadeias de Conﬁanc¸a para

Autenticac¸

ao, Autorizac¸

ao e Navegac¸

ao em Sistemas de Larga Escala. Tese de Doutorado,

UFSC.

Santin, A., Fraga, J., Mello, E., e Siqueira, F. (2003). Federation web: A scheme to compound

authorization chains. The 22nd Symposium on Reliable Distributed Systems.

Refer

encias Bibliogr

aﬁcas 71

Services, C. D. S. (2001). The Gnutella Protocol Speciﬁcation v0.4. Dispon

ıvel na Internet,

ultima

visita em agosto de 2005. http://dss.clip2.com.

SQLData XKMS Server v2.0 (2005). Dispon

ıvel na Internet,

ultima visita em junho de 2005.

http://www.sqldata.com/xkms.htm.

Staken, K. (2002). Developers Guide 1.1. Dispon

ıvel na Internet,

ultima visita em agosto de 2005.

http://xml.apache.org/xindice/guide-developer.html.

Stallings, W. (2000). Network Security Essentials - Applications and Standards. Prentice Hall.

Trust Service Integration Kit (2005). Dispon

ıvel na Internet,

ultima visita em junho de 2005.

http://www.verisign.com/developer/xml/.

Verma, M. (2004). XML Security: The XML Key Management Speciﬁcation. Dispon

ıvel na In-

ternet,

ultima visita em julho de 2005. http://www-128.ibm.com/developerworks/xml/library/x-

seclay3/.

Weerawarana, A., Curbera, F., Leymann, F., Storey, T., e Ferguson, D. (2005). Web Services Platform

Architecture. Prentice Hall. ISBN 0-13-148874-0.

XKMS 2 Interop Test Site (2005). Dispon

ıvel na Internet,

ultima visita em junho de 2005.

http://vsinterop.entrust.com:7001/veriﬁcationserver/index.html.

XKMS Prototype Server (2005). Dispon

ıvel na Internet,

ultima visita em junho de 2005.

http://www.wingso fhermes.org/xkms.html.

Livros Grátis
( http://www.livrosgratis.com.br )
 
Milhares de Livros para Download:
 
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas

Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo
 
 