Padroes de Segurança Aplicados A Linguagem XML

UNIVERSIDADE FEDERAL DE SANTA CATARINA DEPARTAMENTO DE INFORMTICA E ESTATSTICA CURSO DE GRADUAO EM SISTEMAS DE INFORMAO
PROJETO II Sistemas de Informao
Padres de Segurana Aplicados Linguagem XML
Florianpolis, 2005 Luiz Henrique Wiggers Kato Marcos Hideki Watanebe de Moraes
PADRES DE SEGURANA APLICADOS LINGUAGEM XML
Trabalho de Concluso de Curso apresentado Universidade Federal de Santa Catarina como um dos prrequisitos para obteno do grau de bacharel em Sistemas de Informao.
Florianpolis, 2005
Luiz Henrique Wiggers Kato Marcos Hideki Watanabe de Moraes

1
PADRES DE SEGURANA APLICADOS LINGUAGEM XML
Trabalho de concluso de curso apresentado como parte dos requisitos para obteno do grau de Bacharel em Sistemas de Informao.
Orientador: Prof. Joo Bosco Mangueira Sobral
Banca examinadora:
_____________________________
Profa. Kathia Regina Lemos Juc _________________________ Profa. Mirela Sechi Moretti Anonni Notare
KATO, Luiz Henrique Wiggers; MORAES, Marcos Hideki Watanabe de. PADRES DE SEGURANA APLICADOS LINGUAGEM XML. 2005. 118 f. Trabalho de Concluso de Curso, Curso de Bacharelado em Sistemas de Informao, Universidade Federal de Santa Catarina, Florianpolis (SC), 2005.
Sumrio
Lista de Figuras..............................................................................................................5 Lista de Siglas ................................................................................................................6 Lista de Siglas ................................................................................................................6 Resumo ..........................................................................................................................7 Abstract ..........................................................................................................................8 Captulo 1 Introduo .................................................................................................9 1.1 Justificativa .........................................................................................................9 1.2 Objetivos .............................................................................................................9 1.2.1 Objetivo Geral...............................................................................................9 1.2.2 Objetivo Especfico.......................................................................................9 1.3 Contexto e Tecnologia ......................................................................................10 1.3.1 Contexto do trabalho...................................................................................10 1.3.2 Tecnologias .................................................................................................10 Captulo 2 Conceitos de Criptografia .......................................................................11 2.1 Introduo .........................................................................................................11 2.1.1 Fluxo de informaes..................................................................................11 2.1.2 Terminologia...............................................................................................11 2.2 Criptografia ........................................................................................................12 2.2.1 Criptografia Simtrica.................................................................................12 2.2.2 Criptografia Assimtrica .............................................................................13 2.3 Funes de Resumo ...........................................................................................14 2.4 Assinatura Digital ..............................................................................................15 2.5 Certificados Digitais ..........................................................................................16 2.5.1 Funcionamento............................................................................................16 2.5.2 Revogando um certificado digital ...............................................................16 3.1 Introduo ..........................................................................................................18 3.2 Documento .........................................................................................................18 3.3 XML e HTML...................................................................................................18 3.4 XML e SGML....................................................................................................18 3.5 Objetivos do desenvolvimento do XML............................................................19 3.6 Validade .............................................................................................................19 3.6.1 Documentos bem-formados ........................................................................19 3.6.2 Documentos Vlidos...................................................................................20 3.7 Documento XML ...............................................................................................20 3.7.1 Elementos....................................................................................................21 3.7.2 Atributos .....................................................................................................21 3.7.3 Referncias de entidade ..............................................................................21 3.7.4 Comentrios ................................................................................................21 3.7.5 Instrues de Processamento ......................................................................22 3.7.6 Sees CDATA............................................................................................22 3.8 Declaraes de Tipo de documento (Document Type Declarations) ................22 3.9 Utilidades ...........................................................................................................23 Captulo 4 Seguranca XML .......................................................................................24 4.1 Assinatura XML.................................................................................................24 4.1.1 Viso Geral e Exemplos..............................................................................24 4.1.2 Regras de Processamento............................................................................26 4.1.3 Validao ....................................................................................................26
4.1.4 Elementos....................................................................................................27 4.2 XML Encryption................................................................................................32 4.2.1 Viso Geral e Exemplos..............................................................................32 4.2.2 Granularidade da Criptografia ....................................................................33 4.2.3 Criptografando um Elemento XML.............................................................33 4.2.4 Sintaxe da Criptografia ...............................................................................35 4.2.5 Regras de Processamento............................................................................38 4.3 XML Key Management (XKMS)......................................................................40 4.3.1 Trocas do Protocolo ....................................................................................40 4.3.2 Descrio do Servio de informao de Chaves.........................................50 4.3.3 Descrio do Servio de Registro de Chaves ............................................58 4.4 Extensible Access Control Markup Language (XACML).................................72 4.4.1 Requisitos....................................................................................................72 4.4.2 Combinao da regra e poltica...................................................................73 4.4.3 Algoritmos de combinao .........................................................................73 4.4.4 Mltiplos Subjects.......................................................................................74 4.4.5 Polticas baseadas nos atributos de subjects e resources ............................74 4.4.6 Atributos Multivalorados ............................................................................75 4.4.7 Polticas baseadas no contedo de resources ..............................................75 4.4.8 Operadores ..................................................................................................75 4.4.9 Polticas Distribudas ..................................................................................76 4.4.10 Indexao de Polticas...............................................................................76 4.4.11 Camada de Abstrao ...............................................................................77 4.4.12 Aes.........................................................................................................77 4.4.13 Modelos (no-normativo) .........................................................................78 Captulo 5 Uso da biblioteca XmlSec (C )................................................................85 5.1 A estrutura da biblioteca ....................................................................................85 5.2 Assinando e Criptografando Documentos .........................................................86 5.2.1 Assinando dados .........................................................................................86 5.2.2 Criptografando Dados.................................................................................87 5.2.3 Verificando e decriptografando documentos ..............................................88 5.2.4 Verificando um documento assinado..........................................................89 5.2.5 Decifrando um documento criptografado ...................................................89 Captulo 6 Consideraes Finais...............................................................................91 6.1 Concluso...........................................................................................................91 Referncias Bibliogrficas ...........................................................................................92 Anexos .........................................................................................................................93
Lista de Figuras
Figura 1: Substituio do elemento <ds:KeyInfo>.......................................................51 Figura 2: O Servio de localizao fornece a resoluo de nome. ..............................51 Figura 3: Servio de validao fornece a validao da chave .....................................55 Figura 4: Uso combinado do servio de Localizao e Validao. .............................58 Figura 5: Registro de uma ligao de chave ................................................................59 Figura 6: Diagrama de Fluxo de Dados. ......................................................................78 Figura 7: Contexto XACML. ........................................................................................80 Figura 8: Modelo de linguagem da poltica. ................................................................81 Figura 9: Biblioteca xmlsec..........................................................................................85 Figura 10: Assinando e criptografando documentos. ..................................................86 Figura 11: Verificando e decriptografando documentos. ............................................88
Lista de Siglas
AC CRL DNS HTTP LRA MRA PAP PDP PEP PGP PIP PKI POP S/MIME SAML SOAP URI URN W3C XACML XKISS XKMS XKRSS XML XSLT Autoridade Certificadora Certification Revocation List Domain Name System Hyper Text Transfer Protocol Local Registration Authority Master Registration Authority Policy Administration Point Policy Decision Point Policy Enforcement Point Pretty Good Privacy Policy Information Point Public Key Infrastructure Post Office Protocol Secure / Multipurpose Internet Mail Extensions Security Assertion Markup Language Simple Object Access Protocol Uniform Resource Indicator Uniform Resource Name The World Wide Web Consortium Extensible Access Control Markup Language XKMS Key Information Service Specification XML Key Management XKMS Key Registration Service Specification Extensible Markup Language Extensible Stylesheet Language Transformations
Resumo
Existem muitos sistemas operando sobre a Rede Mundial de Computadores (Internet), cada qual com seu prprio formato de documentos para troca de informaes, controle de acesso, confiabilidade e integridade dos dados. Tantos formatos no so compatveis entre si, sendo uma regra de acesso ou um documento assinado entendido apenas pelo sistema para o qual foi criado. Alm da falta de integrao, um problema encontrado a dificuldade no desenvolvimento de aplicaes com suporte as funcionalidades do PKI, devido a complexidade das operaes. Descrevemos quatro padres de segurana aplicados a linguagem XML, que tornam os documentos intercambiveis e abstraem a camada PKI, diminuindo o tempo de desenvolvimento das aplicaes e permitindo a reutilizao de regras de controle de acesso para os mesmos recursos. A fim prtico, demonstramos a utilizao da biblioteca xmlsec, que implementa dois destes quatro padres (Criptografia XML e Assinatura XML). Com o uso destes padres possvel a aplicao de segurana aos sistemas de forma geral, padronizada e mais simplificada, diminuindo o uso de tempo e recursos em novas implementaes. Palavras-chave: segurana, xml, criptografia, assinatura digital
Abstract
There are many systems operating on the Internet, each one with his own documents format for information exchange, access control, reliability and data integrity. So many formats are not compatible amongst themselves, so an access rule or a signed document is just compatible with the system for which was created. Besides the integration lack, a problem found is the difficulty in the development of applications with support the PKI functionalities, due to complexity of the operations. We described four security patterns applied to the XML language, that turn the documents interchangeable and abstract the PKI layer, reducing the development time of applications and allowing the reuse of access control rules for the same resources. In pratical, we demonstrated the use of the ' xmlsec' library, that implements two of these four patterns (XML Encrypt and XML Signature). With these patterns it is possible to apply security to systems in a general way, standardized and more simplified, reducing the use of time and resources in new implementations. Keywords: security, xml, cryptography, digital signature
Captulo 1
Introduo
1.1 Justificativa
As cifras envolvendo transaes que utilizam a Internet elevam a segurana a um nvel de preocupao muito grande, e este estudo apresenta uma maneira de incrementar a confiabilidade e integridade das informaes que trafegam pelas redes de forma padronizada e intercambivel utilizando a linguagem XML. As tecnologias de segurana XML se encaixam nos Web Services, e como estes esto se tornando o padro para sistemas distribudos, estas tecnologias tendem a ser amplamente utilizadas.
1.2 Objetivos
So apresentadas aqui as tarefas desenvolvidas e a motivao para realizao do trabalho.
1.2.1 Objetivo Geral

O objetivo geral apresentar meios de incrementar a segurana de sistemas de forma geral, padronizada entre eles e que facilite a implementao destes sistemas. O estudo descreve o modo de funcionamento e estrutura dos padres de segurana na linguagem XML propostos, assim como a utilizao de alguns destes padres de forma prtica, utilizando uma biblioteca que implementa estas especificaes. O principal objetivo a aplicao destes padres em sistemas distribudos, com foco nos Web Services, que esto se tornando a base para sistemas distribudos na Internet. Estes padres permitem tornar documentos intercambiveis, abstraem a camada PKI, diminuindo o tempo de desenvolvimento das aplicaes e permitem a reutilizao de regras de controle de acesso para os mesmos recursos, diminuindo o uso de tempo e recursos na reescrita de regras para cada diferente sistema.
1.2.2 Objetivo Especfico

Com base no estudo realizado, demonstrado na prtica o desenvolvimento de programas simples, que devem garantir a integridade e confiabilidade das mensagens e das partes envolvidas. Os padres estudados so: XML Signature XML Encryption XML Key Management (XKMS) Extensible Access Control Markup Language (XACML)
As atividades realizadas so: Entender os termos e funcionamento da criptografia; Descrever a estrutura e principais componentes dos padres XML propostos; Descrever a seqncia de passos a serem executados para a correta aplicao destes padres; 9
Demostrar a utilizao de uma biblioteca que implementa a especificao dos padres XML Signature e XML Encryption; Exibir os documentos XML de entrada, e os documentos aps serem assinados ou criptografados;
1.3 Contexto e Tecnologia

So apresentadas as linguagem utilizadas e o contexto da aplicao dos padres em questo.
1.3.1 Contexto do trabalho

O estudo dos padres de segurana utilizando a linguagem XML e suas aplicaes reais podem ser aplicadas em qualquer rea computacional que necessite de uma ou mais caractersticas que a segurana da informao pode fornecer, como por exemplo: - autoria - integridade - sigilo - autorizao Assim como meio para alcanar um ambiente intercambivel de regras e dados por aplicaes que suportem os padres XML utilizados.
1.3.2 Tecnologias
Utilizamos como linguagem de programao o C, por seu amplo suporte as tecnologias XML e criptografia. A linguaguem XML utilizada j que a base dos padres estudados, e ser melhor descrita a seguir. A biblioteca xmlsec escrita na linguagem C, e implementa os padres de Criptografia e Assinatura XML. O padro para Gerenciamento de Chaves Pblica est em desenvolvimento nesta biblioteca, mas ainda no funcional.
10
Captulo 2
Conceitos de Criptografia
2.1 Introduo
O objetivo aqui no , de maneira alguma, se aprofundar em criptografia, estudar tcnicas de criptoanlise, muito menos destrinchar algoritmos de criptografia. Mas, por se tratar de um trabalho realizado no campo da Segurana da Informao, devem ser apresentados aqui alguns conceitos bsicos sobre Criptografia, que a base de qualquer sistema seguro. Neste captulo sero apresentados fundamentos em Criptografia, como criptografia de chaves simtricas, criptografia de chaves assimtricas, funes resumo ou funes hash e o funcionamento das assinaturas digitais.
O fluxo normal de informao de uma fonte A para um destino B, sem soluo de continuidade, e sem qualquer interferncia, a situao ideal que se pretende alcanar em uma comunicao eletrnica segura. Segundo Stallings [STA 99] existem vrias formas de ataques em que um agente malicioso inimigo I pode impedir, interferir ou detectar as informaes transmitidas de A para B. A seguir sero apresentadas as quatros formas de deturpao no fluxo de informaes: interrupo, modificao, interceptao e fabricao. Interrupo A informao parte da fonte A, porm no chega ao chega ao destino B, pois o fluxo interrompido no meio do caminho, por algum motivo como, por exemplo, queda de energia ou problemas no meio fsico de transmisso. Modificao O fluxo parte da fonte A, mas interceptado por um inimigo I, que modifica a informao e envia para o destino B. Este tipo de ataque visa afetar a integridade dos dados. Fabricao O inimigo entra no circuito de comunicao e envia uma mensagem para o destino B, se passando pela fonte A, ou seja, a informao fabricada por I, enviada para B, e este a recebe como sendo de autoria de A. Interceptao A informao gerada na fonte A chega normalmente at o destino B. O fluxo de informao aparentemente normal, exceto pelo fato de haver um inimigo I monitorando o fluxo e que tambm conseguiu ter acesso informao, sem que A ou B percebam. Este tipo de ataque afeta a confidencialidade dos dados.
2.1.1 Fluxo de informaes
2.1.2 Terminologia
Para que um sistema oferea um fluxo seguro da informao a partir de A para B, ele deve atender principalmente os seguintes requisitos:
11
Confidencialidade ou sigilo, a garantia de que somente as partes envolvidas na comunicao possam ler e utilizar as informaes transmitidas eletronicamente pela rede. Isto , caso um inimigo consiga interceptar de alguma forma o fluxo de informao, a mensagem transmitida deve ser indecifrvel; Integridade garantia de que o contedo de uma mensagem no ser alterado durante seu trfego, sem sofrer alteraes, isto , os dados que foram gerados em A so os dados que foram recebidos por B; Autenticao garantia da identificao das partes envolvidas na comunicao, tendo certeza de que a comunicao esteja realmente sendo feita entre A e B, ou seja, que no h nenhum agente malicioso se fazendo passar por A para gerar uma informao falsa, ou se passando por B para simular a recepo da mensagem enviada por A; No repdio garantia de que o emissor de uma mensagem no poder, posteriormente, negar sua autoria.
2.2 Criptografia
[BUR02] "A Criptografia converte dados legveis em algo sem sentido, ilegvel. Estes dados podero ser recuperados posteriormente a partir desses dados sem sentido". Criptografia uma palavra originada no grego, kriptos = escondido, oculto e grifo = grafia ou escrita, e a arte ou cincia de escrever em cifras ou cdigos. A criptografia uma das ferramentas mais importantes para proteo dos dados, e a idia principal transformar um conjunto de dados legvel em algo ilegvel, garantindo que o segredo ali codificado permanecer confidencial. Apenas a pessoa que possuir a chave para decifrar poder reverter essa operao, ou seja, tornar esses dados ilegveis em algo que faa sentido novamente. Desde a Antigidade, to logo o homem aprendeu a escrever, ele comeou a pensar em alguma forma de esconder o que ele havia escrito. Foi assim que comeou a se desenvolver a Criptografia, base tecnolgica para problemas de segurana em comunicaes e em computao. Hoje em dia, esta cincia utiliza conceitos e fundamentos matemticos para a construo de seus algoritmos. Um estudo sobre aritmtica modular e teoria dos nmeros primos indispensvel para quem deseja conhecer mais profundamente o assunto. Porm, fato que no existe algum que diga que no precisa de segurana ou que no tenha algum segredo para ocultar. Todos ns temos informaes que queremos manter em segredo, seja pelo simples desejo de privacidade ou at por autoproteo. Ento, nenhuma pessoa ou empresa, quer ver seus dados sigilosos caindo em mos erradas e maliciosas. A Criptografia, de modo algum, a nica tecnologia necessria para assegurar os dados, nem resolver todos os problemas relacionados segurana. apenas um instrumento, dentre outros existentes. Infelizmente, alm disso, a Criptografia no prova de falhas, o que significa que por mais ininteligvel que uma cifra seja, ainda assim existe a possibilidade dela ser quebrada.
2.2.1 Criptografia Simtrica
12
a forma mais convencional de criptografia que existe. Por isso, tambm conhecida por Criptografia Clssica. Os algoritmos de criptografia de chaves simtricas so assim denominados por apresentarem como principal caracterstica o fato de utilizarem apenas uma chave. Isto significa que a mesma chave que utilizada para cifrar tambm usada para decifrar. Os algoritmos para cifrar e decifrar tambm so os mesmos. O que muda apenas a forma como so utilizadas as chaves. tido como pr-requisito que os usurios envolvidos compartilhem esta chave entre si. A troca de chaves geralmente feita atravs do estabelecimento de um canal de comunicao seguro, atravs de tunelamento, entre as duas partes envolvidas. Existem vrios algoritmos de criptografia simtrica, os mais conhecidos e utilizados atualmente so: AES - Advanced Encryption Standard, um algoritmo concebido em outubro de 2000 para substituir o famoso, e cada vez mais vulnervel, algoritmo Data Encryption Standard (DES) e 3DES. Blowfish - cifrador de bloco simtrico desenvolvido por Bruce Schneier, em 1993, e permanece inquebrvel at hoje. Possui as caractersticas de ser rpido, compacto, simples e possuir o tamanho de sua chave variando entre 32 e 448 bits. Opera com blocos de 64 bits. O principal problema encontrado ao utilizar a criptografia simtrica a questo do gerenciamento das chaves. Para cada par de usurios que desejam se comunicar necessrio uma chave, o que torna o gerenciamento muito complexo. Em uma rede com n usurios, sero necessrias n(n-1)/2 chaves para que todos os usurios possam trocar informaes de maneira sigilosa entre si.
2.2.2 Criptografia Assimtrica

Este tipo de criptografia utiliza duas chaves diferentes: uma usada para cifrar o texto na origem e a outra usada para decifrar o texto quando este chegar no destino. Este sistema gera um par de chaves que so, na verdade, nmeros primos muito grandes relacionados entre si, atravs de propriedades da aritmtica modular. Uma das chaves ser chamada de chave privada e dever ser mantida em sigilo. A outra chave ser chamada de chave pblica e dever ser compartilhada com outras pessoas. Se uma pessoa A cifra uma informao com sua chave privada, outra pessoa B somente poder decifrar a mensagem com a chave pblica de A, tendo a certeza de que esta mensagem realmente teve sua autoria em A, pois somente A possui a chave privada. Por outro lado, se A cifrar uma mensagem com a chave pblica de B, somente B poder decifrar a mensagem com sua chave privada, garantindo desta forma o sigilo ou confidencialidade da mensagem. A grande vantagem da criptografia assimtrica a eficincia no sigilo. Porm, como os algoritmos de criptografia assimtrica so um pouco lento quando, em sua entrada, apresentam volume muito grande de dados, para cifragem de mensagens grandes ela ineficiente se for levado em conta o parmetro tempo que tal processo leva. O que muito se faz empregar a criptografia assimtrica para realizar a troca de 13
chave de criptografia simtrica, de modo que esta ltima cifrada com chaves assimtricas, podendo ser transmitida eletronicamente pela rede de maneira de segura.
2.3 Funes de Resumo

Como os algoritmos de criptografia assimtrica so lentos, no uma boa idia cifrar um grande volume de dados, como um texto inteiro. Na prtica, o que geralmente se faz gerar um resumo dos dados e depois cifrar este resumo utilizado a chave privada do autor dos dados. Estes resumos so gerados atravs das chamadas funes de hash, e constituem uma representao da mensagem. Isto significa que, se o resumo possui essencialmente o mesmo valor de identidade da mensagem, muito mais fcil trabalhar com um resumo criptogrfico cujo tamanho de alguns bytes (geralmente 16 ou 24 bytes), do que manipular mensagens demasiadamente grandes. Tais funes so um algoritmo que recebe qualquer comprimento de entrada e mescla a entrada para produzir uma sada pseudo-aleatria de tamanho fixo. A palavra "hash" pode significar desordem ou confuso, o que descreve eficientemente o resultado de uma mensagem resumida. Uma propriedade verificvel nestas funes que elas so irreversveis, isto , no possvel reconstruir o conjunto original de dados a partir do resumo. Outra particularidade que importante saber que at hoje no foram verificadas colises termo tcnico empregado para descrever uma situao em que duas mensagens produzem um mesmo resumo. Elas existem, mas ningum consegue encontrar uma coliso por demanda. Os dois algoritmos mais importantes e conhecidos de resumo, dentre os vrios existentes, so: MD5 - Message Digest 5 Criado por Ron Rivest, do Massachussets Institute of Technology MIT, o sucessor mais bem-sucedido do MD2. Produz um resumo de 128 bits, porm mais robusto e rpido que seu antecessor. Sabe-se de potenciais vulnerabilidades que podem ser exploradas e atualmente est o seu uso tem sido desencorajado por profissionais da rea de Criptografia, pois j foram encontradas colises. Mesmo assim, por ter sido muito utilizado e ainda estar muito presente nos sistemas, vale a pena ser lembrado. SHA-1 - Secure Hash Algorithm Parecido com o MD5, porm mais forte. Sua sada produz um resumo de 160 bits, o que significa em uma probabilidade menor de ocorrncia de colises, pois apresenta um universo de 2160 resumos possveis. altamente recomendado pela comunidade de criptografia, e o resumo mais utilizado hoje em dia em certificados digitais e bibliotecas criptogrficas. A grande vantagem de utilizar resumos criptogrficos que mensagens muito grandes podem ser reduzidas a poucos bytes. Com resumos possvel garantir a integridade dos dados, isto , possvel saber se um conjunto de dados foi alterado a partir da comparao de resumos criptogrficos.
14
Se voc est preocupado com o fato de que as informaes podem ser alteradas, envie seus dados juntamente com um resumo. Se os dados forem alterados, o resumo de verificao tambm ser diferente, e voc saber que alguma coisa aconteceu. Obviamente preciso se assegurar de que o valor do resumo no pode ser alterado para corresponder com quaisquer alteraes na mensagem. neste ponto, portanto, que entra a assinatura digital, que consiste basicamente no procedimento de cifrar o resumo com a chave privada do assinante.
2.4 Assinatura Digital

Verificar a integridade dos dados muitas vezes no basta. preciso tambm poder garantir a autoria destes. Baseadas na aplicao de tcnicas de criptografia assimtrica, as assinaturas digitais foram feitas para que uma entidade possa, digitalmente, "assinar" um documento eletrnico como, por exemplo, um arquivo texto ou um e- mail, comprovando de forma nica e exclusiva a autoria dos dados. Espera-se que uma assinatura digital possua as mesmas caractersticas de uma assinatura qualquer no mundo real. Estas caractersticas desejveis so: 1. A assinatura digital deve ser fcil de produzir por quem assina 2. Deve ser fcil de ser verificada por qualquer pessoa 3. Deve ser muito difcil de ser falsificada 4. Quem assine no possa negar que assinou (no-repdio) Alm das quatro caractersticas citadas acima, requisito fundamental que a assinatura digital dependa do contedo assinado. Isto , a assinatura deve sempre ser diferente para diferentes informaes assinadas. nesta propriedade que se encontra o grande poder das assinaturas digitais. Seno, possvel imaginar como seria fcil de forjar a assinatura: bastaria o inimigo pegar a assinatura em um outro documento assinado e utiliz- la no documento o qual ele deseja falsificar. importante tambm saber que todo conjunto de dados cifrados com uma chave privada uma assinatura digital, pois s pode ter sido gerado pela pessoa que possui a chave privada. Forjar uma assinatura digital significa que algum capaz de criar uma massa de dados, por um outro meio, que fosse idntica assinatura. Isso significaria que o forjador quebrou o algoritmo RSA, o que altamente improvvel. nisso que so baseadas as propriedades do no-repdio e no-falsificao. at possvel alegar que a chave privada foi roubada, o que tornaria possvel uma outra pessoa gerar uma assinatura digital autntica. Porm, existem meios de revogar um certificado digital (o que inclui invalidar a chave privada a ele associado) e tambm possvel proteger a chave privada. As assinaturas digitais tm sido implementadas basicamente utilizando conceito de chaves pblicas com o padro RSA, para cifrar resumos gerados a partir de funes de hash como MD5 e SHA-1. Existem tambm o DSS - Digital Signature Standard que um algoritmo muito utilizado para criao de assinaturas digitais e existe um esforo para torn- lo um padro para tal finalidade. A chave privada utilizada pelo assinante para assinar, enquanto a chave pblica utilizada para verificar a autenticidade da assinatura.
15
muito importante esclarecer que uma assinatura digital no feita para proteger uma mensagem contra um suposto inimigo. Ela tem como principal finalidade garantir que uma determinada pessoa, a autora da assinatura, realmente tenha assinado tal mensagem. Todos que quiserem verificar a assinatura tero que ter acesso assinatura e mensagem. O inimigo, ento, poder verificar a assinatura. A idia evitar apenas que se falsifique a assinatura. Para fins de confidencialidade e se gurana das informaes devem ser utilizadas tcnicas de criptografia simtrica. Uma maneira de criar assinaturas verificveis cifrar o resumo criptogrfico com a chave privada RSA do assinante.
2.5 Certificados Digitais

Pergunta: Como algum pode verdadeiramente saber se uma chave pblica pertence a uma determinada pessoa em questo? A maneira mais comum de verificar isso por meio de um certificado digital, que associa um nome uma chave pblica. Uma analogia para compreender isso melhor o passaporte, que associa uma foto, a um nmero e a um nome. Um certificado digital produzido de tal maneira que torna perceptvel se um impostor pegou um certificado existente e substituiu a chave pblica ou o nome ali contido. Qualquer pessoa ao examinar esse certificado fraudado saber que algo est errado e, portanto, no confiar na combinao desse par de chaves e nome.
2.5.1 Funcionamento
Pegue um nome e uma chave pblica, concatene esses dois dados e assine-os. Isto um certificado digital. Geralmente a assinatura feita por uma Autoridade Certificadora (AC), que responsvel por gerenciar as chaves pblicas e os certificados digitais de terceiros. As ACs servem como terceiros confiveis para associar uma identidade de uma pessoa a sua chave pblica. A AC tem como principal tarefa a autenticao de seus usurios finais. Para isso, preciso que a AC fornea sua prpria chave pblica para todos os usurios finais certificados, bem como para todas as partes verificadoras que podem utilizar as informaes certificadas, pois para poder validar um certificado digital necessrio ter a chave pblica da AC. Os certificados digitais constituem um meio seguro de distribuir a chave pblica para quem quiser verificar sua assinatura digital. O formato de certificado mais amplamente aceito o X.509 v3 da International Telecommunications Unions (ITU-T), e apresenta alguns campos como: verso, nmero serial, identificador do algoritmo de assinatura, nome do emissor (AC), validade, nome do sujeito, chave pblica, identificao do algoritmo de chave pblica, etc.
2.5.2 Revogando um certificado digital

Dentre os dados que so armazenados dentro de um certificado digital est a data de validade. Uma assinatura digital gerada com uma chave privada expirada no ser considerada vlida no momento de sua verificao. 16
Os certificados so criados acreditando-se que estes sero vlidos e usveis durante todo o tempo de vida estimado no campo de Validade. Entretanto, em alguns casos, um certificado ainda em vigor poder no ser mais utilizado. Por exemplo, a chave privada pode ter sido comprometida de alguma forma. Caso o certificado digital de uma pessoa for extraviado, isto , sua chave privada for roubada, ou ainda se for o caso de algum perder o seu certificado digital, possvel entrar com um pedido de revogao do mesmo. O mtodo mais comum de se invalidar certificados a Certification Revocation List CRL que uma lista dos certificados revogados em cada Autoridade Certificadora. Desta forma possvel constatar junto com a AC se o certificado vlido ou no, antes de gerar ou validar uma assinatura digital e verificar se o certificado digital se encontra ou no na CRL. Similarmente, tambm possvel suspender por um tempo determinado a validade de um certificado digital.
17
Captulo 3
XML
3.1 Introduo
XML uma linguagem de marcao para documentos que contm informao estruturada. Uma linguagem de marcao um mecanismo para identificar estruturas em um documento. A especificao XML define um modo padro para acrescentar marcao em documentos.
3.2 Documento
O nmero de aplicaes desenvolvidas atualmente que so baseadas ou fazem uso de documentos XML muito grande. Para nossos propsitos, a palavra "documento" indica no s documentos tradicionais, como este, mas tambm para outros formatos de dados. Estes incluem grficos de vetor, transaes de comrcio eletrnico, equaes matemticas, meta-dados, APIs, e mil outros tipos de informao estruturada.
3.3 XML e HTML

No HTML, a semntica de tag e o conjunto de tags so fixas. Um <h1> sempre o primeiro nvel de cabealho e a tag <ati.product.code> no faz sentido. O W3C, junto com os desenvolvedores de browsers e a comunidade WWW, esto constantemente trabalhando para estender a definio de HTML para permitir que novas tags acompanhem as mudanas da tecnologia e trazer variaes de apresentao (stylesheets) para o Web. Porm, estas mudanas sempre so limitadas pelo que os desenvolvedores de browser programaram e pelo fato que compatibilidade limitada. O XML no especifica nem semntica nem um conjunto de tags. Na realidade o XML uma meta-linguagem para descrever linguagens de marcao. Em outras palavras, XML prov uma facilidade para definir tags e as relaes estruturais entre eles. J que no h nenhum conjunto de tags, no pode haver nenhuma semntica preconcebida. Tudo na semntica de um documento XML ou ser definido pelas aplicaes que o processa ou atravs de stylesheets.
3.4 XML e SGML

O XML definido como um perfil de aplicao de SGML. SGML (Standard Generalized Markup Language) um padro generalizado de linguagem de marcao definido pela ISO 8879. SGML foi a maneira padro, independente de fabricante, para manter repositrios de documentao estruturada por mais que uma dcada, mas no o mais indicado para servir documentos na WEB. Definindo XML como um perfil de aplicao de SGML, significa que qualquer sistema completamente compatvel com SGML ser capaz de ler documentos XML. Porm, para usar e entender documentos de XML no requer um sistema capaz de compreender por completo o SGML. XML ento uma forma restringida de SGML.
18
3.5 Objetivos do desenvolvimento do XML

Para entender o XML, importante entender por que foi criado. O XML foi criado para que documentos estruturados pudessem ser usados na WEB. As nicas alternativas viveis, HTML e SGML, no so prticas para este propsito. O HTML vem acompanhado de um conjunto semntico e no prove a criao de outros tipos de estruturas. O SGML prov a criao de estruturas, mas muito difcil sua implementao, apenas para ser usado por um navegador WEB. Sistemas SGML completos resolvem problemas grandes, complexos que justificam a despesa. Para utilizar documentos estruturados enviados pela WEB raramente justifica esse tipo de implementao. No se pode dizer que o XML substitui o SGML completamente. Como o XML designado para transferir contedo estruturado pela WEB, algumas caractersticas inexistem, fazendo o SGML uma soluo mais satisfatria para a criao e armazenamento a longo prazo de documentos complexos. A especificao XML(W3C) cita os seguintes objetivos para XML: 1. Deve ser fcil usar XML na Internet. Usurios devem poder ver documentos XML assim como vem documentos HTML. 2. XML deve suportar uma grande variedade de aplicaes. 3. XML deve ser compatvel com SGML. Muitas das pessoas envolvidas com o XML so de organizaes que tem uma grande quantidade de material em SGML. Deve ser compatvel com padres existentes, enquanto resolve problemas relativamente novos. 4. Deve ser fcil escrever programas para processar documentos XML. 5. O nmero de caractersticas opcionais deve ser o mnimo possvel, por motivos de compatibilidade. 6. Documentos XML devem ser legveis e claros. Deve ser possvel observar o documento utilizando um editor de textos comum e descobrir o significado daquele contedo. 7. O desenvolvimento do XML deve ser rpido. Padres so notoriamente lentos, mas o XML necessrio imediatamente, e foi desenvolvido o mais rpido possvel. 8. O design do XML deve ser formal e conciso. 9. Documentos XML devem ser fceis de escrever, por exemplo atravs de um editor de texto. 10. Conciso nas tags XML tem importncia mnima.
3.6 Validade
Alguns documentos so vlidos e alguns no so. H duas categorias de documentos XML: bem-formado e vlido.
3.6.1 Documentos bem-formados
19
Um documento s pode ser bem-formado se obedece a sintaxe XML. Um documento que inclui seqncias de caracteres de marcao que no podem ser analisados gramaticalmente ou so invlidos no pode ser bem-formado. Alm disso, o documento tem que estar conforme as seguintes condies (entender algumas destas condies podem requerer experincia com SGML): instancia do documento deve estar em conforme com a gramtica do documento XML. 2. Nenhum atributo deve aparecer mais de uma vez na mesma tag inicial 3. Atributo string no pode conter referencia a entidades externas. 4. Tags no vazias devem ser propriamente aninhadas. 5. Entidades parmetro devem ser declaradas antes de serem utilizadas. 6. Todas entidades, exceto as seguintes devem ser declaradas: amp, lt, gt, apos e
1. A
7. Uma entidade binria no pode ser referenciada no fluxo do contedo, s pode ser utilizada num atributo declarado como ENTITY ou ENTITIES. 8. Nenhum texto ou entidade parmetro so permitidas serem recursivas, diretamente ou indiretamente.
quot
Por definio, se um documento no bem-formado, no XML. Isto significa que no existe um documento XML que no bem-formado, e no se exige de processadores XML fazer qualquer coisa com tal documento.
3.6.2 Documentos Vlidos

Um documento bem-formado s vlido se contiver uma declarao de tipo de documento e se o documento obedece as restries daquela declarao. A especificao de XML identifica todos os critrios em detalhe.
3.7 Documento XML

Se voc estiver familiarizado com HTML ou SGML, documentos XML parecero familiares. Um documento XML simples apresentado: Exemplo. UM Documento XML Simples
<?xml version="1.0"?> <oldjoke> <burns>Say <quote>goodnight</quote>, Gracie.</burns> <allen><quote>Goodnight, Gracie.</quote></allen> <applause/> </oldjoke>
Alguns esclarecimentos: 20
O documento comea com uma instruo de processamento, apesar de no ser obrigatrio, identifica o documento como sendo XML, e indica a verso utilizada. No h uma declarao de tipo de documento (DTD). Diferente do SGML, o XML no necessita de um DTD. Entretanto, o DTD pode ser fornecido, e alguns documentos vo precisar de um para serem entendidos sem ambigidade.
Elementos vazios possuem uma sintaxe modificada (<applause/>). Tambm permitido utilizar <applause></applause>.
Documentos XML so compostos de marcaes e contedo. H seis tipos de marcaes que podem ocorrer em um documento XML: elementos, referncias de entidade, comentrios, processando instrues, sees marcadas, e declaraes de tipo de documento. As sees seguintes introduzem cada um destes conceitos de marcao.
3.7.1 Elementos
Elementos so a forma mais comum de marcao. Delimitado por < >, a maioria dos elementos identifica a natureza do contedo que eles cercam. Alguns elementos podem estar vazios. Se um elemento no estiver vazio, comea com uma tag de inicio, <elemento>, e acaba com uma tag final, </ elemento>.
3.7.2 Atributos
Atributos so pares nome-valor que acontecem dentro de uma tag inicial depois do nome do elemento. Por exemplo, <div classificam = "prefacie"> um elemento de div com a classe de atributo que tem o valor prefacie. Em XML, todos os valores de atributo devem estar entre aspas.
3.7.3 Referncias de entidade

Para introduzir marcao em um documento, alguns caracteres foram reservados para identificar o comeo de marcao. O <, por exemplo, identifica o comeo de um elemento. Para inserir estes caracteres em seu documento como contedo, deve haver um modo alternativo para os representar. Em XML, so usadas entidades para representar estes caracteres especiais. Entidades tambm so usadas para textos que variam ou so repetidos com freqncia, e para incluir o contedo de arquivos externos.
3.7.4 Comentrios
Comentrios comeam com . Comentrios podem conter qualquer dado fora a string --. Voc pode colocar comentrios em qualquer lugar entre marcao em seu documento. Comentrios no fazem parte do contedo textual de um documento XML. Um processador XML no precisa os passar junto para uma aplicao.
21
3.7.5 Instrues de Processamento

Instrues de processamento (PI) uma forma para prover informao a uma aplicao. Como comentrios, no fazem parte textual do documento XML, mas o processador XML os passa a uma aplicao. Instrues processando tm a forma: <?name data?>. O nome, chamado de alvo PI, identifica o PI aplicao. Aplicaes deveriam processar s os alvos conhecidos e ignorar todos os outros PI. Qualquer dado que segue o alvo PI opcional, para a aplicao que reconhece o alvo. Os nomes usados em PI devem ser declarados como anotaes para identific-los formalmente. Nomes PI que comeam com xml so reservados para padronizao XML.
3.7.6 Sees CDATA

Em um documento, uma seo de CDATA instrui o parser para ignorar a maioria dos caracteres de marcao.
<![CDATA[ *p = &q; b = (i <= 3); ]]>
Entre o comeo da seo, <! [CDATA [ e o fim da seo, ]]>, todo o dados de caracteres so passados diretamente aplicao, sem interpretao. A nica string que no pode aparecer em uma seo CDATA ]]>.
3.8 Declaraes de Tipo de documento (Document Type Declarations)

Uma porcentagem grande da especificao XML trata de vrios tipos de declaraes que so permitidas em XML. Se voc tiver experincia com SGML, voc reconhecer estas declaraes de SGML DTDs (Definies de Tipo de Documento). Se voc nunca os viu antes, o significado pode no ser imediatamente bvio. Um das maiores foras de XML que lhe permite criar seus prprios nomes de tags. Mas para qualquer determinada aplicao, no tem significado tags que aparecem em uma ordem completamente arbitrria. Considere o exemplo. Isto seria significante?
<gracie><quote><oldjoke>Goodnight, <applause/>Gracie</oldjoke></quote> <burns><gracie>Say <quote>goodnight</quote>, </gracie>Gracie.</burns></gracie>
No h significado algum no exemplo acima, porm, de um ponto de vista estritamente sinttico, no h nada errado com este documento XML. Assim, se o documento para ter significado, e certamente se voc estiver escrevendo um stylesheet ou aplicao para processar isto, deve haver alguma restrio na seqncia e aninhando das tags. Nas declaraes(DTD) estas restries podem ser expressadas.
22
As declaraes permitem um documento comunicar meta-informao ao parser sobre seu contedo. Meta-informao inclui a seqncia permitida e aninhando de tags, valores de atributo, os tipos e padres, os nomes de arquivos externos que podem ser referenciados e se eles contm ou no XML, os formatos de algum dado externo (non-XML) que pode ser referenciado, e as entidades que podem ser encontradas. H quatro tipos de declaraes em XML: declaraes de tipo de elemento, declaraes de lista de atributo, declaraes de entidade, e declaraes de anotao.
3.9 Utilidades
Como vimos, o contedo XML pode ser processado sem uma declarao de tipo de documento. Porm, h alguns exemplos onde a declarao necessria: Ambientes de Autorizao A maioria dos ambientes de autorizao precisa ler e processar declaraes de tipo de documento para entender e obrigar os modelos de contedo do documento. Valores Padro de Atributo Se um documento XML possui valores padro de atributo, pelo menos parte da declarao deve ser processada para obter os valores padro correto. Manipulando Espaos em Branco A semntica associada com espao em branco no contedo de um elemento difere da semntica associada com espao em branco num contedo misturado. Sem um DTD, no h nenhum modo para o processador distinguir entre estes casos, e todos os elementos so contedo misturado. Em aplicaes onde uma pessoa cria ou edita os dados (ao invs de dados que so gerados diretamente de um banco de dados, por exemplo), um DTD vai ser necessrio para garantia da estrutura.
23
Captulo 4
Seguranca XML
4.1 Assinatura XML

Assinatura XML um mtodo de associar uma chave com dados referenciados (octetos); no possui norma que especifica como as chaves so associadas a pessoas ou instituies, nem o significado dos dados que so referenciados e assinados. Logo, esta especificao um componente importante de aplicaes XML seguras, mas no suficiente para resolver todos os problemas da segurana/confiana que uma aplicao necessita, particularmente com respeito a usar assinatura XML como base para comunicao pessoa para pessoa e acordos. Tal aplicao tem que especificar uma chave adicional, algoritmo, processo e exigncias de retribuio. O namespace XML [XML-ns] URI que deve ser usada para implementaes desta data:
xmlns=http://www.w3.org/2000/09/xmldsig#
4.1.1 Viso Geral e Exemplos

Assinaturas XML so aplicadas em contedos digitais (objetos de dados). Os objetos de dados so resumidos, o valor resultante colocado em um elemento (com outra informao) que resumido e criptograficamente assinado. Assinaturas digitais XML so representadas pelo elemento Signature que tem a estrutura seguinte (onde "? " denota zero ou uma ocorrncia; "+" denota uma ou mais ocorrncias; e "* " denota zero ou mais ocorrncias):
<Signature ID?> <SignedInfo> <CanonicalizationMethod/> <SignatureMethod/> (<Reference URI? > (<Transforms>)? <DigestMethod> <DigestValue> </Reference>)+ </SignedInfo> <SignatureValue> (<KeyInfo>)? (<Object ID?>)* </Signature>
4.1.1.1 Exemplo Simples (Signature, SignedInfo, Methods, e Reference)

O exemplo seguinte uma assinatura avulsa de um contedo qualquer:
[s01] <Signature Id="MyFirstSignature" xmlns="http://www.w3.org/2000/09/xmldsig#"> [s02] <SignedInfo> [s03] <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> [s04] <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/> [s05] <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">
24
[s06] <Transforms> [s07] <Transform Algorithm="http://www.w3.org/TR/2001/RECxml-c14n-20010315"/> [s08] </Transforms> [s09] <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> [s10] <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> [s11] </Reference> [s12] </SignedInfo> [s13] <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue> [s14] <KeyInfo> [s15a] <KeyValue> [s15b] <DSAKeyValue> [s15c] <P>...</P><Q>...</Q><G>...</G><Y>...</Y> [s15d] </DSAKeyValue> [s15e] </KeyValue> [s16] </KeyInfo> [s17] </Signature>
[s02-12] O elemento SignedInfo a informao que de fato assinada. A validao de SignedInfo consiste em dois processos obrigatrios: validao da assinatura sobre SignedInfo e validao de cada resumo de Reference dentro de SignedInfo. Note que os algoritmos usados no calculo do elemento SignatureValue tambm so includos na informao assinada enquanto o elemento SignatureValue est fora de SignedInfo. [s03] CanonicalizationMethod o algoritmo que usado para codificar a estrutura lgica do elemento SignedInfo antes de ser resumido como parte da operao de assinatura. Note que este exemplo, e todos os exemplos nesta especificao, no esto na forma cannica. [s04] SignatureMethod o algoritmo que usado para converter o SignedInfo codificado em SignatureValue. uma combinao de um algoritmo de resumo e um algoritmo baseado em chave e possivelmente outros algoritmos, por exemplo RSASHA1. Os nomes de algoritmo so assinados para resistir a ataques baseados em substituir um algoritmo mais fraco. Para promover interoperabilidade entre aplicao foi especificado um conjunto de algoritmos de assinatura que devem ser implementados, entretanto o uso deles/delas opo do criador da assinatura. O design tambm permite o uso de algoritmos arbitrrios criados pelo usurio. [s05-11] Cada elemento Reference inclui o mtodo de resumo e valor de resumo resultante calculado sobre o objeto de dados identificado. Tambm pode incluir transformaes que produziram a entrada para a operao de resumo. Um objeto de dados assinado computando seu valor de resumo e aplicando uma assinatura em cima daquele valor. A assinatura conferida depois por referncia e validao de assinatura. [s14-16] KeyInfo indica a chave a ser usada para validar a assinatura. Possveis formas para identificao incluem certificados, nomes de chaves, algoritmos de acordo de chave e informaes. KeyInfo opcional por duas razes. Primeiro, o signatrio pode no desejar revelar informao da chave a todos. Segundo, as informaes podem ser conhecidas dentro do contexto da aplicao e no haja necessidade de ser representada explicitamente. Considerando que KeyInfo est fora
25
de SignedInfo, se o signatrio desejar ligar a informao da chave assinatura, um Reference pode facilmente identificar e incluir o KeyInfo como parte da assinatura.
4.1.2 Regras de Processamento

As sees abaixo descrevem as operaes a serem executadas como parte da gerao e validao da assinatura. Os passos exigidos incluem a gerao de elementos Reference e o SignatureValue sobre SignedInfo.
4.1.2.1 Gerao de Referncia

Para cada objeto a ser assinado: dados. 1. Aplique o Transforms, como determinado pela aplicao, para o objeto de 2. Calcule o valor de resumo sobre o objeto de dados resultante. 3. Crie um elemento Reference, inclusive o (opcional) identificador do objeto de dados, qualquer (opcional) elemento transform, o algoritmo de resumo e o DigestValue. (Note, a forma cannica destas referncias que so assinadas e validadas)
4.1.2.2 Gerao da Assinatura

1. Crie o elemento SignedInfo com SignatureMethod, CanonicalizationMethod e Reference(s). 2. Codifique e ento calcule o SignatureValue em cima de SignedInfo baseado nos algoritmos especificados em SignedInfo. 3. Construa o elemento Signature que inclui SignedInfo, Object(s) (se desejado), KeyInfo (se preciso), e SignatureValue.
4.1.3 Validao
Os passos exigidos de validao incluem a validao de Reference, a verificao do resumo contido em cada Reference em SignedInfo, e a validao criptogrfica da assinatura calculada sobre SignedInfo. Implementaes diferentes podem produzir diferentes resumos e assinaturas quando processando o mesmo recurso por causa de uma variao na sua codificao, como por exemplo, espaos acidentais. Mas se sempre utilizada a comparao numrica ou por octeto estes problemas so eliminados.
4.1.3.1 Validao de Reference
26
Codifique o elemento SignedInfo baseado no CanonicalizationMethod em SignedInfo. Para cada Reference em SignedInfo: Obtenha os dados para serem resumidos. Resuma o objeto de dado resultante utilizando o DigestMethod especificado na sua especificao em Reference. Compare o valor de resumo gerado com o valor em DigestValue em SignedInfo Reference; se h qualquer mudana, a validao falha.
4.1.3.2 Validao da Assinatura

Obtenha a informao da chave em KeyInfo ou de uma fonte externa. A Obtenha a forma cannica de SignatureMethod usando o CanonicalizationMethod e use o resultado para confirmar o SignatureValue sobre o elemento SignedInfo.
4.1.4 Elementos
Esta parte descreve a funcionalidade dos principais elementos da especificao da Assinatura XML.
4.1.4.1 O Elemento Signature

O elemento Signature o elemento raiz de uma Assinatura XML. A implementao tem que gerar um esquema vlido [XML-schema] do elemento Signature como especificado pelo esquema seguinte:
Schema Definition: <element name="Signature" type="ds:SignatureType"/> <complexType name="SignatureType"> <sequence> <element ref="ds:SignedInfo"/> <element ref="ds:SignatureValue"/> <element ref="ds:KeyInfo" minOccurs="0"/> <element ref="ds:Object" minOccurs="0" maxOccurs="unbounded"/> </sequence> <attribute name="Id" type="ID" use="optional"/> </complexType> DTD: <!ELEMENT Signature (SignedInfo, SignatureValue, KeyInfo?, Object*) > <!ATTLIST Signature xmlns CDATA #FIXED 'http://www.w3.org/2000/09/xmldsig#' Id ID #IMPLIED >
4.1.4.2 O Elemento SignatureValue

O elemento SignatureValue contm o valor da assinatura digital; que sempre usa a codificao base64 [MIME].
27
Schema Definition: <element name="SignatureValue" type="ds:SignatureValueType"/> <complexType name="SignatureValueType"> <simpleContent> <extension base="base64Binary"> <attribute name="Id" type="ID" use="optional"/> </extension> </simpleContent> </complexType> DTD: <!ELEMENT SignatureValue (#PCDATA) > <!ATTLIST SignatureValue Id ID #IMPLIED>
4.1.4.3 O Elemento SignedInfo

A estrutura de SignedInfo inclui o algoritmo de codificao, um algoritmo de assinatura, e uma ou mais referncias. O elemento SignedInfo pode conter um atributo ID opcional que permitir ser referenciado por outras assinaturas e objetos. SignedInfo no inclui propriedades de resumo ou assinatura (como tempo de clculo, nmero de srie de dispositivo criptogrfico, etc.). Se uma aplicao precisar associar propriedades com a assinatura ou resumo, pode incluir tal informao em um elemento SignatureProperties dentro de um elemento Object.
Schema Definition: <element name="SignedInfo" type="ds:SignedInfoType"/> <complexType name="SignedInfoType"> <sequence> <element ref="ds:CanonicalizationMethod"/> <element ref="ds:SignatureMethod"/> <element ref="ds:Reference" maxOccurs="unbounded"/> </sequence> <attribute name="Id" type="ID" use="optional"/> </complexType> DTD: <!ELEMENT SignedInfo (CanonicalizationMethod, SignatureMethod, Reference+) > <!ATTLIST SignedInfo Id ID #IMPLIED
4.1.4.4 O Elemento CanonicalizationMethod

CanonicalizationMethod um elemento que especifica o algoritmo de codificao aplicado ao elemento SignedInfo antes de executar clculos de assinatura.
Schema Definition: <element name="CanonicalizationMethod" type="ds:CanonicalizationMethodType"/> <complexType name="CanonicalizationMethodType" mixed="true"> <sequence> <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>  </sequence> <attribute name="Algorithm" type="anyURI" use="required"/> </complexType> DTD:
28
<!ELEMENT CanonicalizationMethod (#PCDATA %Method.ANY;)* > <!ATTLIST CanonicalizationMethod Algorithm CDATA #REQUIRED >
4.1.4.5 O Elemento SignatureMethod

SignatureMethod um elemento que especifica o algoritmo usado para gerao e validao da assinatura. Este algoritmo identifica todas as funes criptogrficas envolvidas na operao de assinatura (por exemplo resumo, algoritmos de chave pblica, MACs, etc.).
Schema Definition: <element name="SignatureMethod" type="ds:SignatureMethodType"/> <complexType name="SignatureMethodType" mixed="true"> <sequence> <element name="HMACOutputLength" minOccurs="0" type="ds:HMACOutputLengthType"/> <any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>  </sequence> <attribute name="Algorithm" type="anyURI" use="required"/> </complexType> DTD: <!ELEMENT SignatureMethod (#PCDATA|HMACOutputLength %Method.ANY;)* > <!ATTLIST SignatureMethod Algorithm CDATA #REQUIRED >
4.1.4.6 O Elemento Reference

Reference um elemento que pode aparecer uma ou mais vezes. Ele especifica um algoritmo e valor de resumo, e opcionalmente um identificador do objeto que est sendo assinado, o tipo do objeto, e/ou uma lista de transformaes a serem aplicadas antes do resumo.
Schema Definition: <element name="Reference" type="ds:ReferenceType"/> <complexType name="ReferenceType"> <sequence> <element ref="ds:Transforms" minOccurs="0"/> <element ref="ds:DigestMethod"/> <element ref="ds:DigestValue"/> </sequence> <attribute name="Id" type="ID" use="optional"/> <attribute name="URI" type="anyURI" use="optional"/> <attribute name="Type" type="anyURI" use="optional"/> </complexType> DTD: <!ELEMENT Reference (Transforms?, DigestMethod, DigestValue) <!ATTLIST Reference Id ID #IMPLIED URI CDATA #IMPLIED >
29
Type
CDATA
#IMPLIED>
4.1.4.7 O Elemento Transforms

O elemento opcional Transforms contm uma lista ordenada de elementos Transform; estes descrevem como o signatrio obteve o objeto de dados que foi resumido.
Schema Definition: <element name="Transforms" type="ds:TransformsType"/> <complexType name="TransformsType"> <sequence> <element ref="ds:Transform" maxOccurs="unbounded"/> </sequence> </complexType> <element name="Transform" type="ds:TransformType"/> <complexType name="TransformType" mixed="true"> <choice minOccurs="0" maxOccurs="unbounded"> <any namespace="##other" processContents="lax"/>  <element name="XPath" type="string"/> </choice> <attribute name="Algorithm" type="anyURI" use="required"/> </complexType> DTD: <!ELEMENT Transforms (Transform+)> <!ELEMENT Transform (#PCDATA|XPath %Transform.ANY;)* > <!ATTLIST Transform Algorithm CDATA #REQUIRED > <!ELEMENT XPath (#PCDATA) >
4.1.4.8 O Elemento DigestMethod

DigestMethod um elemento que identifica o algoritmo de resumo a ser aplicado ao objeto.
Schema Definition: <element name="DigestMethod" type="ds:DigestMethodType"/> <complexType name="DigestMethodType" mixed="true"> <sequence> <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </sequence> <attribute name="Algorithm" type="anyURI" use="required"/> </complexType> DTD: <!ELEMENT DigestMethod (#PCDATA %Method.ANY;)* > <!ATTLIST DigestMethod Algorithm CDATA #REQUIRED >
30
4.1.4.9 O Elemento DigestValue

DigestValue um elemento que contm o valor de resumo. O resumo sempre usa a codificao base64 [MIME].
Schema Definition: <element name="DigestValue" type="ds:DigestValueType"/> <simpleType name="DigestValueType"> <restriction base="base64Binary"/> </simpleType> DTD: <!ELEMENT DigestValue (#PCDATA) > 
4.1.4.10 O Elemento KeyInfo

KeyInfo um elemento opcional que permite que os destinatrios obtenham a chave necessria para validar a assinatura. KeyInfo pode conter chaves, nomes, certificados e outras informaes do gerenciamento de chave pblica.
Schema Definition: <element name="KeyInfo" type="ds:KeyInfoType"/> <complexType name="KeyInfoType" mixed="true"> <choice maxOccurs="unbounded"> <element ref="ds:KeyName"/> <element ref="ds:KeyValue"/> <element ref="ds:RetrievalMethod"/> <element ref="ds:X509Data"/> <element ref="ds:PGPData"/> <element ref="ds:SPKIData"/> <element ref="ds:MgmtData"/> <any processContents="lax" namespace="##other"/>  </choice> <attribute name="Id" type="ID" use="optional"/> </complexType> DTD: <!ELEMENT KeyInfo (#PCDATA|KeyName|KeyValue|RetrievalMethod| X509Data|PGPData|SPKIData|MgmtData %KeyInfo.ANY;)* > <!ATTLIST KeyInfo Id ID #IMPLIED >
4.1.4.11 O Elemento KeyName

O elemento KeyName contm uma string que pode ser usada pelo signatrio para comunicar um identificador da chave ao destinatrio. Tipicamente, KeyName contm um identificador relacionado ao par de chaves usada para assinar a mensagem, mas pode conter outras informaes relacionadas ao protocolo que indiretamente identificam um par de chaves.
31
Schema Definition: <element name="KeyName" type="string"/> DTD: <!ELEMENT KeyName (#PCDATA) >
4.1.4.12 O Elemento KeyValue

O elemento KeyValue contm uma nica chave pblica que pode ser til para validar a assinatura.
Schema Definition: <element name="KeyValue" type="ds:KeyValueType"/> <complexType name="KeyValueType" mixed="true"> <choice> <element ref="ds:DSAKeyValue"/> <element ref="ds:RSAKeyValue"/> <any namespace="##other" processContents="lax"/> </choice> </complexType> DTD: <!ELEMENT KeyValue (#PCDATA|DSAKeyValue|RSAKeyValue %KeyValue.ANY;)* >
4.2 XML Encryption

Esta sesso especifica o processo para criptografar dados e representar o resultado no formato XML. Os dados podem ser dados arbitrrios (inclusive um documento de XML), um elemento XML, ou o contedo de um elemento XML. O resultado da criptografia dos dados o elemento EncryptedData que contm os dados cifrados. Quando se criptografa um elemento XML ou contedo de um elemento, o elemento EncryptedData substitui o elemento ou o contedo na verso codificada do documento XML. Ao codificar dados arbitrrios (inclusive documentos XML inteiros), o elemento EncryptedData pode se tornar a raiz do novo documento XML ou pode se tornar um elemento filho de um documento XML escolhido pela aplicao. para esta implementao desta O XML namespace [XML-NS] URI especificao : xmlns:xenc=' http://www.w3.org/2001/04/xmlenc#' Esta especificao faz uso do namespace e definies de esquemas da Assinatura XML [XML-DSIG]: xmlns:ds=' http://www.w3.org/2000/09/xmldsig#'
4.2.1 Viso Geral e Exemplos

Esta parte prov uma viso geral e exemplos da sintaxe da Criptografia XML. 32
O elemento EncryptedData tem a estrutura seguinte (onde "? " denota zero ou uma ocorrncia; "+" denota uma ou mais ocorrncias; "* " denota zero ou mais ocorrncias;
<EncryptedData Id? Type? MimeType? Encoding?> <EncryptionMethod/>? <ds:KeyInfo> <EncryptedKey>? <AgreementMethod>? <ds:KeyName>? <ds:RetrievalMethod>? <ds:*>? </ds:KeyInfo>? <CipherData> <CipherValue>? <CipherReference URI?>? </CipherData> <EncryptionProperties>? </EncryptedData>
O elemento CipherData contm ou referencia os dados criptografados. Se contidos, os dados criptografados so o contedo do elemento CipherValue. Se referenciados, o atributo URI do elemento CipherReference aponta o local onde esto os dados criptografados.
4.2.2 Granularidade da Criptografia

Considere as seguintes informaes fictcias de pagamento que incluem informao de identificao e informao destinadas a um mtodo de pagamento (por exemplo, carto de crdito, transferncia de dinheiro, ou cheque eletrnico):
<?xml version='1.0'?> <PaymentInfo xmlns='http://example.org/paymentv2'> <Name>John Smith</Name> <CreditCard Limit='5,000' Currency='USD'> <Number>4019 2445 0277 5567</Number> <Issuer>Example Bank</Issuer> <Expiration>04/02</Expiration> </CreditCard> </PaymentInfo>
Esta estrutura representa que John Smith est usando um carto de crdito com um limite de $5,000USD.
4.2.3 Criptografando um Elemento XML

O nmero de carto de crdito de Smith uma informao sigilosa! Se a aplicao desejar manter aquela informao confidencial, pode criptografar o elemento CreditCard:
<?xml version='1.0'?> <PaymentInfo xmlns='http://example.org/paymentv2'> <Name>John Smith</Name> <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element' xmlns='http://www.w3.org/2001/04/xmlenc#'>
33
<CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> </PaymentInfo>
Criptografando o elemento CreditCard inteiro da sua tag de inicio at a tag final, a identidade do prprio elemento escondida. (Um intrometido no sabe se ele usou um carto de crdito ou transferncia de dinheiro.) O elemento CipherData contm a serializao criptografada do elemento CreditCard.
4.2.3.1 Criptografando um Elemento XML (Elemento)

Um cenrio alternativo pode ser til para agentes intermedirios saberem que John usou um carto de crdito com um limite particular, mas no o nmero do carto, emissor, e data de expirao. Neste caso, o contedo do elemento CreditCard codificado:
<?xml version='1.0'?> <PaymentInfo xmlns='http://example.org/paymentv2'> <Name>John Smith</Name> <CreditCard Limit='5,000' Currency='USD'> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.w3.org/2001/04/xmlenc#Content'> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> </CreditCard> </PaymentInfo>
4.2.3.2 Criptografando de um Elemento XML (Dados)

Considere o cenrio no qual todas as informaes, excluindo o nmero de carto de crdito, podem estar a vista, inclusive o fato que o elemento Number existe:
<?xml version='1.0'?> <PaymentInfo xmlns='http://example.org/paymentv2'> <Name>John Smith</Name> <CreditCard Limit='5,000' Currency='USD'> <Number> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.w3.org/2001/04/xmlenc#Content'> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> </Number> <Issuer>Example Bank</Issuer> <Expiration>04/02</Expiration> </CreditCard> </PaymentInfo>
CreditCard e Number esto a vista, mas o contedo de Number codificado.
34
4.2.3.3 Criptografando Dados Arbitrrios e Documentos XML

Se o cenrio da aplicao requerer que toda informao seja codificada, o documento inteiro codificado como uma seqncia de octetos. Isto se aplica a dados arbitrrios inclusive documentos XML.
<?xml version='1.0'?> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' MimeType='text/xml'> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData>
4.2.4 Sintaxe da Criptografia

Esta seo prov uma descrio detalhada da sintaxe e caractersticas da Criptografia XML.
Schema Definition: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSchema 200102//EN" "http://www.w3.org/2001/XMLSchema.dtd" [ <!ATTLIST schema xmlns:xenc CDATA #FIXED 'http://www.w3.org/2001/04/xmlenc#' xmlns:ds CDATA #FIXED 'http://www.w3.org/2000/09/xmldsig#'> <!ENTITY xenc 'http://www.w3.org/2001/04/xmlenc#'> <!ENTITY % p ''> <!ENTITY % s ''> ]> <schema xmlns='http://www.w3.org/2001/XMLSchema' version='1.0' xmlns:ds='http://www.w3.org/2000/09/xmldsig#' xmlns:xenc='http://www.w3.org/2001/04/xmlenc#' targetNamespace='http://www.w3.org/2001/04/xmlenc#' elementFormDefault='qualified'> <import namespace='http://www.w3.org/2000/09/xmldsig#' schemaLocation='http://www.w3.org/TR/2002/REC-xmldsigcore-20020212/xmldsig-core-schema.xsd'/>
4.2.4.1 O Elemento EncryptedType

Schema Definition: <complexType name='EncryptedType' abstract='true'> <sequence> <element name='EncryptionMethod' type='xenc:EncryptionMethodType' minOccurs='0'/> <element ref='ds:KeyInfo' minOccurs='0'/> <element ref='xenc:CipherData'/> <element ref='xenc:EncryptionProperties' minOccurs='0'/>
35
</sequence> <attribute name='Id' type='ID' use='optional'/> <attribute name='Type' type='anyURI' use='optional'/> <attribute name='MimeType' type='string' use='optional'/> <attribute name='Encoding' type='anyURI' use='optional'/> </complexType>
EncryptionMethod um elemento opcional que descreve o algoritmo de criptografia aplicado aos dados cifrados. Se o elemento estiver ausente, o algoritmo de criptografia deve ser conhecido pelo destinatrio ou a decriptografia falhar. ds:KeyInfo um elemento opcional e recebe a informao sobre a chave usada para criptografar os dados. Sees subseqentes desta especificao definem elementos novos que podem aparecer como filhos de ds:KeyInfo. CipherData um elemento obrigatrio que contm o CipherValue ou CipherReference com os dados criptografados. EncryptionProperties pode conter informao adicional relativo gerao do EncryptedType (por exemplo, date/hora). Id um atributo opcional que prov um mtodo de nomear um id ao elemento dentro do contexto do documento. Type um atributo opcional que identifica o tipo de informao do contedo criptografado. Se o elemento EncryptedData contm dados do tipo ' element'ou elemento ' content' e substitui os dados em um contexto no documento XML, , recomendado que o atributo Type seja fornecido. Sem esta informao, no ser possvel restabelecer automaticamente o documento XML para sua forma original. MimeType um atributo opcional que descreve o tipo dos dados que foram criptografados. O valor deste atributo uma seqncia de caracteres com valores definidos por [MIMIQUE]. Por exemplo, se o dado criptografado um PNG codificado em base64, o Encondig de transferncia pode ser especificada como ' http://www.w3.org/2000/09/xmldsig#base64' o MimeType como ' e image/png' .
4.2.4.2 O Elemento EncryptionMethod

EncryptionMethod um elemento opcional que descreve o algoritmo de criptografia aplicado aos dados cifrados. Se o elemento estiver ausente, o algoritmo de criptografia deve ser conhecido pelo recipiente ou a decriptografia falhar.
Schema Definition: <complexType name='EncryptionMethodType' mixed='true'> <sequence> <element name='KeySize' minOccurs='0' type='xenc:KeySizeType'/> <element name='OAEPparams' minOccurs='0' type='base64Binary'/> <any namespace='##other' minOccurs='0' maxOccurs='unbounded'/> </sequence> <attribute name='Algorithm' type='anyURI' use='required'/> </complexType>
36
4.2.4.3 O Elemento CipherData

CipherData um elemento obrigatrio que prov os dados criptografados. Ou contm uma seqncia de octetos criptografados como texto codificado em base64 do elemento CipherValue, ou prov uma referncia a um local externo que contm a sequncia de octetos criptografados via o elemento CipherReference.
Schema Definition: <element name='CipherData' type='xenc:CipherDataType'/> <complexType name='CipherDataType'> <choice> <element name='CipherValue' type='base64Binary'/> <element ref='xenc:CipherReference'/> </choice> </complexType>
4.2.4.4 O Elemento EncryptedData

O elemento EncryptedData o elemento chave na sintaxe. No s seu filho, CipherData, contm os dados criptografados, mas tambm o elemento que substitui o elemento criptografado, ou serve como a raiz do novo documento.
Schema Definition: <element name='EncryptedData' type='xenc:EncryptedDataType'/> <complexType name='EncryptedDataType'> <complexContent> <extension base='xenc:EncryptedType'> </extension> </complexContent> </complexType>
4.2.4.5 Extenses para o Elemento ds:KeyInfo

H trs modos para que o material da chave necessrio para decriptografar CipherData possa ser fornecido: 1. O elemento EncryptedData ou EnacryptedKey especificam a chave associado via um filho de ds:KeyInfo. 2. Um elemento destacado (no dentro de ds:KeyInfo) de EncryptedKey pode especificar o EncryptedData ou EncryptedKey, onde a chave para decriptografia ser aplicada via DataReference ou KeyReference. 3. A chave pode ser determinada pelo recipiente atravs de contexto de aplicao e assim no precisa ser mencionado explicitamente no XML transmitido.
4.2.4.6 O Elemento EncryptedKey

Identificador: Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey" 37
O elemento EncryptedKey usado para transportar chaves criptogrficas do remetente para um destinatrio. Pode ser usado como documento XML, por ser colocado dentro de um documento de aplicao, ou aparecer dentro de um elemento EncryptedData como filho um elemento de ds:KeyInfo. O valor da chave sempre codificado para o destinatrio. Quando EncryptedKey decifrado, os octetos resultantes so disponibilizados ao algoritmo de EncryptionMethod sem qualquer processo adicional.
Schema Definition: <element name='EncryptedKey' type='xenc:EncryptedKeyType'/> <complexType name='EncryptedKeyType'> <complexContent> <extension base='xenc:EncryptedType'> <sequence> <element ref='xenc:ReferenceList' minOccurs='0'/> <element name='CarriedKeyName' type='string' minOccurs='0'/> </sequence> <attribute name='Recipient' type='string' use='optional'/> </extension> </complexContent> </complexType>
4.2.5 Regras de Processamento

Esta seo descreve as operaes a serem executadas como parte do processo de criptografia e decriptografia implementadas nesta especificao.
4.2.5.1 Criptografia
Para cada item de dados a ser criptografado como EncryptedData ou EncryptedKey (elementos derivados de EncryptedType), o codificador deve: 1. Selecionar o algoritmo (e parmetros) a serem usados para criptografar os dados. 2. Obter e (opcionalmente) representar a chave 2.1. Se a chave deve ser identificada, construa o ds:KeyInfo 2.2. Se a prpria chave ser criptografada, construa um elemento EncryptedKey recursivamente aplicando este processo de criptografia. O resultado pode ser ento um filho de ds:KeyInfo, ou pode existir em outro lugar e pode ser identificado no prximo passo. 3. Criptografando os dados 3.1. Se o dado um ' elemento' [XML] ou contedo de um elemento [XML], obtenha os octetos, serializando os dados em UTF-8. A serializao deve ser feita pelo crifrador. Se o cifrador no serializar, ento a aplicao tem que executar a serializao. 3.2. Se o dado for de qualquer outro tipo que no octetos, a aplicao tem que serializar.
38
3.3. Criptografe os octetos utilizando o algoritmo e chave dos passos 1 e 2. 3.4. A menos que o decifrador saiba o tipo dos dados criptografados implicitamente, o cifrador deve prover o tipo para representao. 4. Construa o estrutura EncryptedType (EncryptedData ou EncryptedKey): Uma estrutura EncryptedType representa toda informao previamente discutida inclusive o tipo dos dados codificados, algoritmo de criptografia, parmetros, chave, tipo dos dados codificados, etc. 4.1. Se a seqncia de octetos criptografada obtida no passo 3 ser armazenado no elemento CipherData dentro do EncryptedType, ento a seqncia de octetos ser codificada em base64 e inserida como o contedo de um elemento CipherValue. 4.2. Se a seqncia de octetos ser armazenada externamente estrutura EncryptedType, ento guarde ou devolva a seqncia de octetos criptografada, e represente a URI e transformaes exigidas para o decifrador recuperar a seqncia de octetos criptografada dentro de um elemento CipherReference. 5. Processando EncryptedData 5.1. Se o tipo dos dados criptografados um ' elemento' contedo de um ou elemento, ento o cifrador deve poder devolver o elemento EncryptedData aplicao. A aplicao pode usar isto como o elemento topo em um documento XML novo ou pode inserir em outro documento XML que pode requerer uma re-codificao. O cifrador tambm deve poder substituir o ' elemento' contedo do elemento no ou criptografado com o elemento EncryptedData. O cifrador remove o elemento ou contedo identificado e insere o elemento EncryptedData no seu lugar. 5.2. Se o tipo dos dados criptografado no um ' elemento' o contedo de ou um elemento, ento o cifrador sempre tm que devolver o elemento EncryptedData aplicao. A aplicao pode usar isto como o elemento topo em um documento XML novo ou pode inserir isto em outro documento XML que pode requerer uma recodificao.
4.2.5.2 Decriptografia
Para cada EncryptedType, (EncryptedData ou EncryptedKey), para serem decifrados, o decifrador deve: 1. Processar o elemento para determinar o algoritmo, parmetros e elemento ds:KeyInfo a ser usado. Se alguma informao omitida, a aplicao tem que prov-la. 2. Localizar a chave de codificao dos dados de acordo com o elemento ds:KeyInfo que pode conter um ou mais elementos filho. Estes filhos no tm nenhuma ordem de processo includa. Se a chave de codificao dos dados esta codificada, localize a chave correspondente para decifr-la. 3. Decriptografar os dados contidos no elemento CipherData. 3.1. Se um elemento filho de CipherValue estiver presente, ento o valor do texto associado decodificado em base64 para se obter a seqncia de octetos criptografada.
39
3.2. Se um filho do elemento CipherReference est presente, a URI e transform so usados para obter a seqncia de octetos criptografada. 3.3. A seqncia de octetos decriptografada usando o algoritmo, parmetros e chave determinados nos passos 1 e 2. 4. Processo decriptografa dados do tipo ' elemento' o contedo de um elemento. ou 4.1. A seqncia de octetos texto obtida no passo 3 interpretada como caracteres codificados em UTF-8. 4.2. O decifrador deve poder devolver o valor de Type e os caracteres de dados XML codificados em UTF-8. O decifrador no precisa executar a validao do XML serializado. 4.3. O decifrador deve poder substituir o elemento EncryptedData pelo elemento ou pelo contedo do elemento decriptografado, representados em caracteres codificados em UTF-8. 5. Processo de decriptografar dados se o Type no especifidado ou se no um elemento ou o contedo de um elemento. 5.1. A seqncia de octetos obtida no Passo 3 deve ser devolvida aplicao para processo futuro junto com os valores dos atributos Type, MimeType, e Encoding quando especificado.
4.3 XML Key Management (XKMS)

O XKMS (XML Key Management) substitui muitos dos protocolos e formatos de dados do PKI. Atravs dele, o cliente e o servidor compartilham um servio XKMS para se validarem e processarem requisies entre si. Ele tambm pode ser implementado cliente-para-cliente, servidor-para-cliente e servidor-para-servidor. Diferentemente do servio XKMS, o PKI requer que cada usurio e aplicao verifique a identidade das entidades com quem esto se comunicando e se certifiquem que a identidade dessas entidades so vlidas (no foram revogadas) e apropriadas para a transao. Infelizmente a infra-estrutura necessria para suportar tais requisitos torna o desenvolvimento de aplicaes seguras muito demorado e complicado. Com o PKI, todas as decises so feitas na aplicao. Isso requer complicadas bibliotecas de programao e configuraes. J com o XKMS, as decises so feitas em um servidor comum. A nica informao necessria um cliente XKMS a URL do servidor e o certificado que o servidor estar usando para assinar as suas respostas.
4.3.1 Trocas do Protocolo

As trocas do protocolo XKMS consistem de uma seqncia de um ou dois pares de resposta. As mensagens compartilham um formato comum e podem ser utilizadas em uma variedade de protocolos. recomendado que os implementadores do XKMS suportem SOAP sobre HTTP para propsitos de interoperabilidade. No XKMS nenhuma operao idempotente, ou seja, todas as requisies podem causar uma mudana de estado. O protocolo XKMS consiste de pares de requisies e respostas. Cada mensagem de resposta contem um cdigo MajorResult que determina se a resposta final ou se requer um processamento adicional. O protocolo assim especificado: 40
Final = { Success, VersionMismatch, Sender, Receiver } Request -> Result.Final | Request -> Result.Pending->PendingNotification->Request->Result.Final | Request -> Result.Represent->Request->Result.Final As sesses a seguir descrevem o protocolo de mensagem e as etapas de processamento efetuadas por ambas as partes em cada mensagem.
4.3.2.1 Todas as Mensagens

As seguintes etapas so processadas independente de a mensagem ser de requisio ou de resposta: Gerao ID setado para um valor nico gerado aleatoriamente. Service setado para o valor da URI para onde a requisio XKMS direcionada. Assinatura de autenticao gerada (se necessria). Processamento O valor de Service verificado. A assinatura de autenticao verificada (se necessria). Exemplo
<?xml version="1.0" encoding="utf-8"?> <MessageAbstractType Id="1noOYHt5Lx7xUuizWZLOMw==" Service="http://test.xmltrustcenter.org/XKMS"
xmlns="http://www.w3.org/2002/03/xkms#" />
4.3.2.2 Tipos de Requisio

A especificao do XKMS define trs tipos de requisio: Requisio X-KISS Uma requisio de localizao ou validao. Requisio X-KRSS Uma requisio de registro, alterao, revogao ou de recuperao. Requisio Composta Uma requisio composta consiste de um conjunto de uma ou mais requisies X-KISS ou X-KRSS. O protocolo XKMS suporta diversas opes como processamento assncrono, requisio de duas fases e requisio composta. O cliente especifica que opes do protocolo suporta em relao a uma requisio especfica atravs do elemento ResponseMechanism na prpria requisio.
4.3.2.3 Respostas
41
Todas as respostas contm um cdigo de resultado compreendido de um componente major e minor. Se um servio aplica uma opo de processamento de protocolo o cliente informado atravs do valor do elemento MajorResult da resposta.
4.3.2.4 Processamento Sncrono e Assncrono

O protocolo XKMS suporta dois modos de processo: sncrono e assncrono. No processamento sncrono o servio responde uma requisio de modo que ele no tenha de enviar mais nenhuma resposta para aquela requisio. No processamento assncrono o servio no ir completar a requisio imediatamente enviando uma notificao de que outras mensagens de reposta sero encaminhadas. O cliente pode avisar o servio que ir aceitar o processamento assncrono de uma requisio especificando o elemento ResponseMechanism com o valor Pending. Um servio XKMS que recebe uma requisio com o valor Pending para o elemento ResponseMechanism pode responder tanto de modo sncrono como assncrono. Se o servio decidir responder de modo assncrono, ele avisa o cliente especificando o elemento MajorResult com o valor Pending. Um servio XKMS no deve retornar o elemento MajorResult com o valor Pending a no ser que o elemento ResponseMechanism tenha sido especificado com o valor Pending na requisio correspondente. Se o servio receber uma requisio que no possa ser processada de modo sncrono e que o valor Pending no tenha sido especificado para a varivel ResponseMechanism retornado o valor Receiver no elemento MajorResult e NotSynchronous para o elemento MinorResult. O processamento assncrono pode ser utilizado para permitir que o administrador possa intervir durante o processamento da requisio. Por exemplo, pode ser necessrio que o administrador verifique e aprove todas as requisies XKRSS de registro antes que sejam processadas.
4.3.2.4.1 Requisio / Resposta Sncrona

O processamento de uma requisio e resposta sncrona feita da seguinte maneira: Gerao da mensagem de requisio (requisitor) Nonce e OriginalRequestId no esto presentes. ResponseMechanism pode ser especificado com o valor Represent e/ou Pending. Processamento da mensagem de requisio (servio) Verifica se a requisio est de acordo com a poltica de autorizao do servio. Processa a requisio at ser completa. Gerao da mensagem de resposta (servio) RequesId setado com o valor Id da mensagem de requisio. Nonce no est presente. MajorResult setado para um valor de resultado Final. Processamento da mensagem de resposta (requisitor) 42
O valor de RequestId verificado. Exemplo

<?xml version="1.0" encoding="utf-8"?> <LocateRequest Id="I6d995b8d05a9a2ce0573d29e32ab9441" Service="http://test.xmltrustcenter.org/XKMS" xmlns="http://www.w3.org/2002/03/xkms#"> <QueryKeyBinding /> </LocateRequest>
Requisio
<?xml version="1.0" encoding="utf-8"?> <LocateResult Id="I089b18dc1a520b26e2e6689dd3a5a820" Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" RequestId="I6d995b8d05a9a2ce0573d29e32ab9441" xmlns="http://www.w3.org/2002/03/xkms#" />
Resposta
4.3.2.5 Processamento Assncrono

O processamento assncrono consiste na seqncia de dois pares de requisio/resposta, uma requisio inicial que especifica os valores requeridos e uma requisio de pendncia que obtm o resultado da operao.
4.3.2.5.1 Requisio Inicial

A requisio inicial processada da seguinte maneira: Gerao da mensagem de requisio inicial (requisitor) Nonce e OriginalRequestId no esto presentes. ResponseMechanism deve ser especificado com o valor Pending. Processamento da mensagem de requisio inicial (servio) Agenda o processamento da requisio assncrona. Gerao da mensagem de resposta inicial (serivo) RequestId setado para o valor Id da mensagem de requisio inicial. Nonce no est presente. MajorResult setado para Pending. Processamento da mensagem de resposta inicial (requisitor) Registra a requisio como em pendncia e aguarda notificao.
4.3.2.5.2 Requisio de Status

O cliente pode verificar o status da operao assncrona: Gerao da mensagem de requisio de status (requisitor) O elemento de requisio StatusRequest. OriginalRequestId setado para o valor de Id da mensagem de requisio inicial. ResponseId setado para o valor de Id da mensagem inicial de resposta.
43
Processamento da mensagem de requisio de status (servio) Identifica a requisio pendente usando OriginalRequestId e ResponseId. Gerao da mensagem de resposta de status (servio) Request Id setado para o valor de Id na mensagem de requisio de status. Nonce no est presente. Processamento da mensagem de resposta de status (requisitor) Para mensagens simples, o atibuto ResultMajor indica o status da operao. Para mensagens compostas os atributos Success, Failure e Pending indicam o nmero de requisies internas que possuem os respectivos status.
4.3.2.5.3 Requisio de pendncia

Quando notificado, o cliente emite uma mensagem PendingRequest requisitando o retorno do resultado do processamento da requisio inicial. Gerao da mensagem de requisio de pendncia (requisitor) O elemento de requisio PendingRequest. OriginalRequestId setado para o valor Id da mensagem de requisio inicial. ResponseId setado para o valor Id da mensagem de resposta inicial. Processamento da mensagem de requisio de pendncia (servio) Associa requisio de pendncia a resposta pendente. Gerao da mensagem de resposta de pendncia (servio) RequestId setado para o valor Id da mensagem de requisio de pendncia. Nonce no est presente. ResponseId setado para um valor nico gerado aleatoriamente. Processamento da mensagem de resposta de pendncia (requisitor) Se MajorResult est setado com um valor no final, considera como falha. O cliente pode requisitar o retorno do resultado antes do processamento ser completo. Nesse caso o servio responde a mensagem de requisio de pendncia com o valor Pending de MajorResult. Exemplo Requisio
<?xml version="1.0" encoding="utf-8"?> <LocateRequest Id="I6227979ae4073f2b3b145db7a488ce16" Service="http://test.xmltrustcenter.org/XKMS" xmlns="http://www.w3.org/2002/03/xkms#"> <ResponseMechanism>Pending</ResponseMechanism> <QueryKeyBinding /> </LocateRequest>
<?xml version="1.0" encoding="utf-8"?> <LocateResult Id="I98366e407a2a78dff79687dbdb4d974c" Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Pending" RequestId="I6227979ae4073f2b3b145db7a488ce16" xmlns="http://www.w3.org/2002/03/xkms#" />
Resposta
44
Notificao
<?xml version="1.0" encoding="utf-8"?> <Result xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns="http://www.w3.org/2002/03/xkms#"/>
<?xml version="1.0" encoding="utf-8"?> <PendingRequest Id="I6045ff8b2eb204edb538be1fa22e340a" Service="http://test.xmltrustcenter.org/XKMS" OriginalRequestId="I6227979ae4073f2b3b145db7a488ce16" ResponseId="I98366e407a2a78dff79687dbdb4d974c" xmlns="http://www.w3.org/2002/03/xkms#" /> <?xml version="1.0" encoding="utf-8"?> <LocateResult Id="I4da52fc78e0391a11257d64926cd184c" Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" RequestId="I6045ff8b2eb204edb538be1fa22e340a" xmlns="http://www.w3.org/2002/03/xkms#" />
Requisio de Pendncia
Resposta
4.3.2.6 Protocolo de Requisio de Duas Fases

As requisies XKMS podem utilizar o protocolo de requisio de duas fases para se proteger de um ataque de negao de servio. O protocolo de requisio de duas fases permite que o servio execute uma autenticao leve da fonte da requisio XKMS, determinando se o cliente consegue ler as mensagens enviadas para o suposto endereo da fonte. Apesar de esse mecanismo fornecer uma forma fraca de autenticao, ele previne um ataque de negao de servio ao forar o servio a executar uma autenticao de recurso como a verificao de uma assinatura digital. O protocolo de duas fases consiste de duas etapas: Na primeira etapa o requisitor apresenta a requisio e o servio responde com o valor Represent para o elemento MajorResult e apresenta um Nonce. Na segunda etapa o requisitor apresenta a requisio inicial juntamente com o Nonce. O cliente pode avisar o servio que suporta o protocolo de requisio de duas fases especificando o elemento ResponseMechanism com o valor Represent. O servio XKMS avisa o cliente de que necessrio o uso do protocolo de requisio de duas fases especificando com o cdigo Represent o elemento MajorResult. Um servio XKMS no deve retornar o cdigo Represent para o elemento MajorResult a no ser que o elemento ResponseMechanism tenha sido especificado com o valor Represent na requisio correspondente. Se o servio XKMS requer o uso do protocolo de duas fases e o elemento ResponseMechanism no foi especificado com o valor Represent na mensagem de requisio correspondente, retornado o valor Sender para MajorResult e RepresentRequired para o elemento MinorResult. O protocolo de requisio de duas fases se assemelha ao processamento de requisio assncrono. Ambos os mecanismos introduzem uma rodada extra de troca de mensagens, porem para propsitos diferentes. O propsito do processamento assncrono o de permitir que seja introduzido um atraso entre a requisio inicial e o retorno do resultado. J no caso do protocolo de duas fases no h atraso entre a primeira requisio e a primeira resposta ou entre a primeira resposta e a segunda requisio. O propsito do protocolo de duas fases o de permitir que o servio se proteja contra um ataque de negao de servio ao executar uma leve autenticao sobre a fonte da requisio.
45
4.3.2.6.1 Passos do processamento

Primeira Etapa: Gerao da mensagem de requisao da primeira etapa (requisitor) ResponseMechanism deve ser especificado com o valor Represent. Processamento da Mensagem de requisio da primeira etapa (servio) Servio opta por utilizar o processamento de duas fases. Requisio no processada. Gerao da mensagem de resposta da primeira etapa (servio) RequestId setado para o valor Id da mensagem de requisio da primeira etapa. O valor de Nonce setado de acordo com os requisitos de proteo do servio. MajorResult setado para o valor Represent. Processamento da mensagem de resposta da primeira etapa (requisitor) Segue para a segunda etapa. Segunda Etapa: Gerao da mensagem de requisio da segunda etapa (requisitor) OriginalRequestId setado para o valor de id da mensagem de requisio da primeira etapa. O valor de Nonce setado para o valor de Nonce da mensagem de resposta da primeira etapa. Processamento da mensagem de requisio da segunda etapa (servio) Valor de Nonce verificado. Verifica se a requisio est de acordo com a politica de autorizao. Processa a requisio. Gerao da mensagem de resposta da segunda etapa (servio) RequestId setado para o valor de Id da mensagem de requisio da segunda etapa. Nonce no est presente. MajorResult setado para o valor do resultado final. Processamento da mensagem de resposta da segunda etapa (requisitor) Se MajorResult est setado para um valor que no seja final, considera-se como falha. Exemplo Requisio 1
<?xml version="1.0" encoding="utf-8"?> <LocateRequest Id="Ia1d6ca7a067fdd545f1a1396d2f26779" Service="http://test.xmltrustcenter.org/XKMS" xmlns="http://www.w3.org/2002/03/xkms#"> <ResponseMechanism>Represent</ResponseMechanism> <QueryKeyBinding /> </LocateRequest>
<?xml version="1.0" encoding="utf-8"?> <LocateResult Id="Idbc77142059a3a51c9eccd2425d77757" Service="http://test.xmltrustcenter.org/XKMS"
Resposta 1
46
Nonce="Rj2BoUZM7PisPX2ytSAAWA==" ResultMajor="Represent" RequestId="Ia1d6ca7a067fdd545f1a1396d2f26779" xmlns="http://www.w3.org/2002/03/xkms#" />
<?xml version="1.0" encoding="utf-8"?> <LocateRequest Id="I47804adaec32e34afeecdb51f3e0f765" Service="http://test.xmltrustcenter.org/XKMS" Nonce="Rj2BoUZM7PisPX2ytSAAWA==" OriginalRequestId="Ia1d6ca7a067fdd545f1a1396d2f26779" xmlns="http://www.w3.org/2002/03/xkms#"> <QueryKeyBinding /> </LocateRequest>
Requisio 2
<?xml version="1.0" encoding="utf-8"?> <LocateResult Id="I3b0111d2232507a56444c1bc85409a94" Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" RequestId="I47804adaec32e34afeecdb51f3e0f765"
Resposta 2
xmlns="http://www.w3.org/2002/03/xkms#" />
4.3.2.7 Protocolo de duas fases com processamento assncrono

O protocolo de duas fases pode ser combinado com o processamento assncrono. Nesse caso a operao ir consistir de 3 rodadas: Requisio Inicial / Etapa 1 Requisio Inicial / Etapa 2 Resposta Pendente O processamento das mensagens executada como descrito acima com as seguintes excees: OriginalRequestId setado para o valor de Id da Requisio Inicial / Etapa 1 em ambas as requisies subseqentes. O valor de Nonce setado para o valor de Nonce da Etapa 1 em ambas as requisies subseqentes.
4.3.2.8 Requisies e Respostas Compostas

Um servio XKMS pode suportar o processamento de requisies compostas. Uma requisio composta permite que se faa mltiplas requisies XKMS ao mesmo tempo. Ela consiste de uma requisio externa e uma ou mais requisies internas. No h nenhuma ordenao implcita nas requisies internas. A semntica de se fazer um conjunto de requisies como uma requisio composta exatamente igual de como seria se cada requisio individual do conjunto tivesse sido feita separadamente e simultaneamente. A resposta para uma requisio composta uma resposta composta. Uma resposta composta consiste de uma resposta externa e zero ou mais respostas internas. Se o valor de ResultMajor da resposta externa igual a Success, a resposta composta deve conter uma resposta interna correspondente a cada requisio interna da requisio composta. Se o valor de ResultMajor da resposta externa no for igual a Success, a resposta no deve conter nenhuma resposta interna. Se uma resposta composta possui o valor Success para ResultMajor da resposta externa e no contem uma resposta correspondente a uma requisio interna, o valor de ResultMajor assumido como failure para essa requisio.
47
Um servio XMKS pode suportar o uso do protocolo de duas fases na requisio externa de uma resposta composta. O protocolo de duas fases no deve ser usado em uma resposta interna. Se uma requisio interna especificar o valor Represent para ResponseMechanism, o valor deve ser ignorado. Um service XKMS pode suportar o uso de processamento assncrono em conjunto com uma requisio composta. O processamento assncrono pode ser executado em uma requisio composta como um todo, em uma requisio interna ou em ambas. Se um processamento assncrono for executado em uma requisio composta como um todo, a requisio externa deve conter o valor Pending para ResponseMechanism. Se o servio decidir retornar uma resposta assncrona, uma resposta composta retornada com o valor Pending para ResultMajor. Aps receber a notificao, o cliente envia uma mensagem do tipo PendingRequest como requisio externa na qual o servio retorna uma resposta composta com respostas internas correspondentes as requisies internas originais ou um relatrio de erro. Se um processamento assncrono executado nas requisies internas individuais, para cada requisio interna na qual dever ser aceita uma resposta assncrona, deve ser especificado o valor Pending para ResponseMechanism. Se o servio decidir retornar uma resposta assncrona para uma requisio interna, retornada uma resposta composta com o cdigo Success para o ResultMajor externo e o cdigo Pending para o ResultMajor interno para as requisies nas quais uma resposta assncrona deve ser enviada. O servio pode retornar respostas sncronas e assncronas em uma nica resposta composta. J que a semntica de uma requisio composta exatamente a mesma, como se cada requisio interna fosse feita separadamente, o cliente pode enviar requisies de pendncia separadamente para obter os resultados de requisies internas de uma requisio composta anterior. Alternativamente, o cliente pode enviar uma requisio composta contendo mltiplas requisies internas de pendncia correspondendo a requisies que foram feitas independentemente originalmente. Exemplo Requisio 1
<?xml version="1.0" encoding="utf-8"?> <CompoundRequest Id="I264f5da49b1ff367d4e7aef1f7a1df1a" Service="http://test.xmltrustcenter.org/XKMS" xmlns="http://www.w3.org/2002/03/xkms#"> <LocateRequest Id="I8c26be5f1b4dd228b43fb6eaee285faa" Service="http://test.xmltrustcenter.org/XKMS"> <RespondWith>KeyValue</RespondWith> <QueryKeyBinding> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <X509Data> <X509Certificate>MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrDg MCHQUAMBIxEDAOBgNVBAMTB1Rl c3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5WjArMSkwJwYDVQQDEyBBbGljZSBB YXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIs mR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D 0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQggP BLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwOoAQAaVOkaVLLKoF mLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUXjPG1TZxVKg+HutAwCQYFKw4DAh0F AAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObtY3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6j NKYLCQb8zUGk4QOG5Y+HT/QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8 U/kD8UuRkXp4AZh7QsiX8AcO0w==</X509Certificate> </X509Data> </KeyInfo> <KeyUsage>Signature</KeyUsage>
48
</QueryKeyBinding> </LocateRequest> <LocateRequest Id="If8e63d729384ad35498e7b65b3dc785e" Service="http://test.xmltrustcenter.org/XKMS"> <RespondWith>KeyName</RespondWith> <RespondWith>KeyValue</RespondWith> <RespondWith>X509Cert</RespondWith> <RespondWith>X509Chain</RespondWith> <RespondWith>PGPWeb</RespondWith> <RespondWith>PGP</RespondWith> <QueryKeyBinding> <KeyUsage>Encryption</KeyUsage> <UseKeyWith Application="urn:ietf:rfc:2440" Identifier="[email protected]" /> <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="[email protected]" /> </QueryKeyBinding> </LocateRequest> </CompoundRequest>
<?xml version="1.0" encoding="utf-8"?> <CompoundResult Id="If2d286d4a542bd92989aa606d9f1a5ca" Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" RequestId="I264f5da49b1ff367d4e7aef1f7a1df1a" xmlns="http://www.w3.org/2002/03/xkms#"> <LocateResult Id="I69044d458e0bceef5f78c79c32fa9ddf" Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" RequestId="I8c26be5f1b4dd228b43fb6eaee285faa"> <UnverifiedKeyBinding Id="I8f7367375ac134872eab7acf42a8d1bd"> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <KeyValue> <RSAKeyValue> <Modulus>0nIsmR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQCjr8uv mnqtNu8HBupui8LgGthO 6U9D0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVD QggPBLc1XagW20RMvok=</Modulus> <Exponent>AQAB</Exponent> </RSAKeyValue> </KeyValue> </KeyInfo> <KeyUsage>Signature</KeyUsage> <KeyUsage>Encryption</KeyUsage> <KeyUsage>Exchange</KeyUsage> <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="[email protected]" /> </UnverifiedKeyBinding> </LocateResult> <LocateResult Id="Ic3d02a8b1f63ba694a8fad11a74fb499" Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" RequestId="If8e63d729384ad35498e7b65b3dc785e"> <UnverifiedKeyBinding Id="I42604b6f40f46b74b5c30077100fe8e9"> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <KeyValue> <RSAKeyValue> <Modulus>3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV 7twNf2TUXCxYuztUUClM Iy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreynWegpFbITXc8V6Y02QfR5O7Pn1/ 10ElslaF/TF8MQGqYE8=</Modulus> <Exponent>AQAB</Exponent> </RSAKeyValue> </KeyValue> <X509Data> <X509Certificate>MIICCTCCAXagAwIBAgIQe0Sk4xr1VolGFFNMkCx07TAJBgUrDg
Resposta 1
49
MCHQUAMBIxEDAOBgNVBAMTB1Rl c3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5WjAkMSIwIAYDVQQDExlCb2IgQmFr ZXIgTz1Cb2IgQ29ycCBDPVVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDcUW1ZSy8RqNC3 ZJ5IX5G8DFZ08+HkZKVCenxIO++q8LATo9dxFasgaZXu3A1/ZNRcLFi7O1RQKUwjLXgHRD6TV6Pa d6SZgvv4hzcMMZUVVpg+jFpFjRjaVXy06t7KdZ6CkVshNdzxXpjTZB9Hk7s+fX/XQSWyVoX9MXwx AapgTwIDAQABo1YwVDANBgNVHQoEBjAEAwIGQDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6 oRQwEjEQMA4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GBAF4j P1gGDbaq3rg/Vo3JY7EDNTp0HmwLiPMLmdnB3WTIGFcjS/jZFzRCbvKPeiPTZ6kRkGgydFOuCo5H MAxIks/LtnKFd/0qYT+AODq/rCrwSx+F+Ro2rf9tPpja9o7gANqxs6Pm7f1QSPZO57bT/6afiVm7 NdaCfjgMphb+XNyn</X509Certificate> <X509Certificate>MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDg MCHQUAMBIxEDAOBgNVBAMTB1Rl c3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWjASMRAwDgYDVQQDEwdUZXN0IENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEk eXB8oMxwbhdcizWH92zrtm1VfVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVR NK5XmKXA5sEC51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBgNV HQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQMA4GA1UEAxMHVGVz dCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GBABDYD4Fwx2dscu+BgYcZ+GoQQtCJ kwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsiQgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/ MefuTtpOpCN40wy3YwwngDtHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435</X509Ce r tificate> </X509Data> </KeyInfo> <KeyUsage>Signature</KeyUsage> <KeyUsage>Encryption</KeyUsage> <KeyUsage>Exchange</KeyUsage> <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="[email protected]" /> </UnverifiedKeyBinding> </LocateResult> </CompoundResult>
4.3.2 Descrio do Servio de informao de Chaves

Na especificao de assinatura do XML [XML-SIG], um assinante pode optar por incluir informao sobre a sua chave pblica (<ds: KeyIfo>) dentro do bloco de assinatura. Essa informao da chave feita para permitir ao assinante comunicar dicas a um verificador sobre qual chave publica selecionar. Outra propriedade importante da <ds:KeyInfo> que ela pode ou no ser ligada criptograficamente a assinatura. Isso permite que a <ds:KeyInfo> possa ser substituida ou suplementada sem quebrar a assinatura digital. Por exemplo, Alice assina um documento e o envia para Bob com o elemento <ds:KeyInfo> que especifica apenas a informao da chave. Ao receber a mensagem, Bob recupera informaes adicionais necessrias para validar a assinatura e adiciona essa informao ao elemento <ds:KeyInfo> ao passar o documento adiante para Carol (Figura 1).
50
Figura 1: Substituio do elemento <ds:KeyInfo>.
4.3.2.1 XKISS Servio de Localizao

O servio de localizao XKISS resolve o elemento <ds: Keyinfo> mas no requer que se faa uma confirmao da validade da ligao entre a informao no elemento <ds: KeyInfo>. O servio XKMS pode resolver o elemento <ds: KeyInfo> usando informaes locais ou pode requisitar a outros servidores. Por exemplo, o servio XKMS pode resolver um elemento <ds: RetrievalMethod> (Figura 2) ou pode atuar como um gateway para uma camada PKI baseada em uma sintaxe no XML.
Tanto a requisio quanto a resposta podem ser assinadas, para ambas autenticarem o remetente e proteger a integridade da informao sendo transmitida, usando uma assinatura XML [XML-SIG].
Figura 2: O Servio de localizao fornece a resoluo de nome.
51
4.3.2.1.1 Exemplo: Encriptao de dados

Alice quer enviar um email encriptografado para Bob, mas no sabe sua chave criptogrfica. Alice pode usar tanto o S/MIME e o PGP, ambos os formatos de email seguros. O cliente de Alice usa o DNS para localizar o servio XKMS que fornece um servio de localizao de chaves ligadas ao domnio example.com e ento envia uma requisio de localizao XKMS para esse servio XKMS localizado com uma ligao de chave para [email protected] e o protocolo S/MIME ou PGP. A aplicao, ento, verifica se o certificado obtido obedece aos seus critrios de confiana. Requisio:
<?xml version="1.0" encoding="utf-8"?> <LocateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="I8fc9f97052a34073312b22a69b3843b6" Service="http://www.example.org/XKMS" xmlns="http://www.w3.org/2002/03/xkms#"> <RespondWith>http://www.w3.org/2002/03/xkms#KeyName</RespondWith> <RespondWith>http://www.w3.org/2002/03/xkms#KeyValue</RespondWith> <RespondWith>http://www.w3.org/2002/03/xkms#X509Cert</RespondWith> <RespondWith>http://www.w3.org/2002/03/xkms#X509Chain</RespondWith> <RespondWith>http://www.w3.org/2002/03/xkms#PGPWeb</RespondWith> <RespondWith>http://www.w3.org/2002/03/xkms#PGP</RespondWith> <QueryKeyBinding> <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage> <UseKeyWith Application="urn:ietf:rfc:2440" Identifier="[email protected]" /> <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="[email protected]" /> </QueryKeyBinding> </LocateRequest>
Resposta:
<?xml version="1.0" encoding="utf-8"?> <LocateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="I8ce3809ab23500015cc27704b7eb0912" Service="http://www.example.org/XKMS" ResultMajor="http://www.w3.org/2002/03/xkms#Success" RequestId="I8fc9f97052a34073312b22a69b3843b6" xmlns="http://www.w3.org/2002/03/xkms#"> <UnverifiedKeyBinding Id="I809ca03cf85b3cb466859694dbd0627d"> <ds:KeyInfo> <ds:KeyValue> <ds:RSAKeyValue> <ds:Modulus> 3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV7twNf2T UXCxYuztUUClMIy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreyn WegpFbITXc8V6Y02QfR5O7Pn1/10ElslaF/TF8MQGqYE8= </ds:Modulus> <ds:Exponent>AQAB</ds:Exponent> </ds:RSAKeyValue> </ds:KeyValue> <ds:X509Data> <ds:X509Certificate> MIICCTCCAXagAwIBAgIQe0Sk4xr1VolGFFNMkCx07TAJBgUrDgMCHQUAMBIxEDA OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj AkMSIwIAYDVQQDExlCb2IgQmFrZXIgTz1Cb2IgQ29ycCBDPVVTMIGfMA0GCSqGS
52
Ib3DQEBAQUAA4GNADCBiQKBgQDcUW1ZSy8RqNC3ZJ5IX5G8DFZ08+HkZKVCenxI O++q8LATo9dxFasgaZXu3A1/ZNRcLFi7O1RQKUwjLXgHRD6TV6Pad6SZgvv4hzc MMZUVVpg+jFpFjRjaVXy06t7KdZ6CkVshNdzxXpjTZB9Hk7s+fX/XQSWyVoX9MX wxAapgTwIDAQABo1YwVDANBgNVHQoEBjAEAwIGQDBDBgNVHQEEPDA6gBABpU6Rp UssqgWYs3fukLy6oRQwEjEQMA4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUq D4e60DAJBgUrDgMCHQUAA4GBAF4jP1gGDbaq3rg/Vo3JY7EDNTp0HmwLiPMLmdn B3WTIGFcjS/jZFzRCbvKPeiPTZ6kRkGgydFOuCo5HMAxIks/LtnKFd/0qYT+AOD q/rCrwSx+F+Ro2rf9tPpja9o7gANqxs6Pm7f1QSPZO57bT/6afiVm7NdaCfjgMp hb+XNyn </ds:X509Certificate> <ds:X509Certificate> MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAMBIxEDA OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWj ASMRAwDgYDVQQDEwdUZXN0IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg QCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEkeXB8oMxwbhdcizWH92zrtm1V fVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVRNK5XmKXA5sE C51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBg NVHQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQM A4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GB ABDYD4Fwx2dscu+BgYcZ+GoQQtCJkwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsi QgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/MefuTtpOpCN40wy3YwwngD tHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435 </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage> <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage> <KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage> <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="[email protected]" /> </UnverifiedKeyBinding> </LocateResult>
4.3.2.1.2 Exemplo: Assinatura de Documento

Bob recebe o documento assinado por Alice que especifica o certificado X.509v3 de Alice, mas no o valor de sua chave. O cliente de email de Bob no capaz de processar o certificado X.509v3, mas pode obter os parmetros da chave no servio XKMS atravs do servio de Localizao. O cliente de email de Bob envia o elemento <ds:Keyinfo> para o servio de localizao requisitando que o elemento <KeyValue> correspondente seja retornado. Requisio:
<?xml version="1.0" encoding="utf-8"?> <LocateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="I045c66f6c525a9bf3842ecd3466cd422" Service="http://www.example.org/XKMS" xmlns="http://www.w3.org/2002/03/xkms#"> <RespondWith>http://www.w3.org/2002/03/xkms#KeyValue</RespondWith> <QueryKeyBinding> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrDgMCHQUAMBIxEDA OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj ArMSkwJwYDVQQDEyBBbGljZSBBYXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBn zANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIsmR+aVW2egl5MIfOKy4HuMKkk 9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D0CNT5mbmhIA ErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQg
53
gPBLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwO oAQAaVOkaVLLKoFmLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUX jPG1TZxVKg+HutAwCQYFKw4DAh0FAAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObt Y3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6jNKYLCQb8zUGk4QOG5Y+HT/ QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8U/kD8UuRk Xp4AZh7QsiX8AcO0w== </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage> </QueryKeyBinding> </LocateRequest>
O servio de localizao extrai o certificado X.509v3 do elemento <ds:Keyinfo> e retorna os valores da chave. O servio de localizao no reporta o status de revogao ou se o certificado confivel. Resposta:
<?xml version="1.0" encoding="utf-8"?> <LocateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="I04cd4f17d0656413d744f55488369264" Service="http://www.example.org/XKMS" ResultMajor="http://www.w3.org/2002/03/xkms#Success" RequestId="I045c66f6c525a9bf3842ecd3466cd422" xmlns="http://www.w3.org/2002/03/xkms#"> <UnverifiedKeyBinding Id="I012f61e1d7b7b9944fe8d954bcb2d946"> <ds:KeyInfo> <ds:KeyValue> <ds:RSAKeyValue> <ds:Modulus> 0nIsmR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8 HBupui8LgGthO6U9D0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZ drdcDrkNnG7SzbuJx+GDNiHKVDQggPBLc1XagW20RMvok= </ds:Modulus> <ds:Exponent>AQAB</ds:Exponent> </ds:RSAKeyValue> </ds:KeyValue> </ds:KeyInfo> <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage> <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage> <KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage> <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="[email protected]" /> </UnverifiedKeyBinding> </LocateResult>
4.3.2.2 XKISS: Servio de Validao

O servio de validao XKISS prov tudo que o servio de localizao prov, e ainda permite que o cliente obtenha uma afirmao com relao ao status da ligao entre a chave publica e outra informao, por exemplo, um nome ou um conjunto de atributos estendidos. Alm disso, o servio descreve que o status de cada um dos elementos da informao retornado vlido e que todos so ligados a mesma chave pblica. O cliente envia ao servio XKMS um prottipo contendo parte ou todos os elementos os quais so necessrios o status da ligao com a chave. Se a informao no prottipo incompleta, o servio XKMS pode obter a informao adicional necessria de um servio PKI. Uma vez que a validade da ligao com a chave tenha sido determinada, o servio XKMS retorna o resultado do status ao cliente (Figura 3). 54
Figura 3: Servio de validao fornece a validao da chave
4.3.2.2.1 Exemplo: Assinatura de Documento

Bob recebeu uma mensagem de Alice, e seu cliente email verificou a assinatura do documento com a chave pblica no certificado fornecido por Alice. Ainda no se sabe porem, se o certificado confivel. Para determinar isso, o cliente de email de Bob envia o certificado para um servio de validao XKMS. O servio retorna ento, que conseguiu determinar com sucesso que a ligao de chave possui um remetente confivel e que no foi revogada. Requisio:
<?xml version="1.0" encoding="utf-8"?> <ValidateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="Ie26380bfeb9d0c5bc526d5213a162d46" Service="http://www.example.org/XKMS" xmlns="http://www.w3.org/2002/03/xkms#"> <RespondWith>http://www.w3.org/2002/03/xkms#X509Cert</RespondWith> <QueryKeyBinding> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrDgMCHQUAMBIxEDA OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj ArMSkwJwYDVQQDEyBBbGljZSBBYXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBn zANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIsmR+aVW2egl5MIfOKy4HuMKkk 9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D0CNT5mbmhIA ErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQg gPBLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwO oAQAaVOkaVLLKoFmLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUX jPG1TZxVKg+HutAwCQYFKw4DAh0FAAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObt Y3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6jNKYLCQb8zUGk4QOG5Y+HT/ QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8U/kD8UuRk Xp4AZh7QsiX8AcO0w== </ds:X509Certificate> <ds:X509Certificate> MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAMBIxEDA OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWj ASMRAwDgYDVQQDEwdUZXN0IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg QCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEkeXB8oMxwbhdcizWH92zrtm1V fVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVRNK5XmKXA5sE
55
C51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBg NVHQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQM A4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GB ABDYD4Fwx2dscu+BgYcZ+GoQQtCJkwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsi QgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/MefuTtpOpCN40wy3YwwngD tHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435 </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage> <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="[email protected]" /> </QueryKeyBinding> </ValidateRequest>
Resposta:
<?xml version="1.0" encoding="utf-8"?> <ValidateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="I34ef61b96f7db2250c229d37a17edfc0" Service="http://www.example.org/XKMS" ResultMajor="http://www.w3.org/2002/03/xkms#Success" RequestId="Ie26380bfeb9d0c5bc526d5213a162d46" xmlns="http://www.w3.org/2002/03/xkms#"> <KeyBinding Id="Icf608e9e8b07468fde1b7ee5449fe831"> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrDgMCHQUAMBIxEDA OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj ArMSkwJwYDVQQDEyBBbGljZSBBYXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBn zANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIsmR+aVW2egl5MIfOKy4HuMKkk 9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D0CNT5mbmhIA ErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQg gPBLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwO oAQAaVOkaVLLKoFmLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUX jPG1TZxVKg+HutAwCQYFKw4DAh0FAAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObt Y3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6jNKYLCQb8zUGk4QOG5Y+HT/ QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8U/kD8UuRk Xp4AZh7QsiX8AcO0w== </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage> <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage> <KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage> <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="[email protected]" /> <Status StatusValue="http://www.w3.org/2002/03/xkms#Valid"> <ValidReason>http://www.w3.org/2002/03/xkms#Signature</ValidReason> <ValidReason>http://www.w3.org/2002/03/xkms#IssuerTrust</ValidReason> <ValidReason>http://www.w3.org/2002/03/xkms#RevocationStatus</ValidRe ason> <ValidReason>http://www.w3.org/2002/03/xkms#ValidityInterval</ValidRe ason> </Status> </KeyBinding> </ValidateResult>
56
4.3.2.3 Usando os servios de Localizao e Validao

As operaes de validao e localizao so ambas usadas para obter informao sobre uma chave publica de um servio XKMS. Espera-se que ambos os servios de localizao e validao tentem fornecer informaes corretas ao requisitor O servio de localizao deve fornecer apenas informaes que so confiveis mas no fornece nenhuma garantia sobre essa informao. A informao obtida de um servio de localizao no deve ser confiada a no ser que seja validada. A validao pode ser obtida direcionando os dados para um servio de validao. Um sevio de validao apenas fornece informaes que foram validadas positivamente pelo servio XKMS. O cliente pode confiar na informao retornada pelo servio sem a necessidade de uma validao posterior, levando em considerao de que o cliente pode determinar que a informao retornada autentica e que o servio de validao aplicou os meios de validao apropriados a circunstncia. Nenhum conjunto de critrios de validao apropriado para todas as circunstancias. Aplicaes envolvendo transaes financeiras provavelmente necessitam de aplicaes com critrios de validao muito especficos que garantam que certa poltica contratual e/ou regulamentatria seja cumprida. O servio de localizao prov uma funo de descoberta de chave que neutra com relao ao critrio de validao que o cliente de uma aplicao possa aplicar. O servio de validao prov uma funo de descoberta e validao de chave que produz resultados que so especficos para um conjunto de critrios de validao.
4.3.2.3.1 Integrao DNS

Em muitos casos a informao da chave que o cliente necessita est ligada com alguma forma de endereo especificado por uma parte de um protocolo de internet que consiste em um endereo DNS. Por exemplo, o endereo eletrnico de um cliente pode precisar de uma chave confivel para enviar um email encriptografado para [email protected] . A menos que o endereo eletrnico no domnio exemplo.com seja conhecido a priori, alguns meios de localizar o correto servio XKMS so necessrios. A figura 4 mostra um exemplo usando um registro DNS SRV para localizar servios XKMS. O cliente email requisita uma chave para [email protected] de um servio de validao confivel. O servio de validao, ento, consulta o DNS para localizar um servio XKMS que prov informao para chaves ligadas ao endereo na zona exemplo.com. O servio de validao no possui uma relao confivel estabelecida com o servio XKMS do exemplo.com, ento uma requisio de localizao feita para determinar se alguma informao ligada a [email protected] pode ser localizada.O servio de validao, ento, valida a informao recebida da maneira apropriada e a resposta retornada para o cliente email.
57
Figura 4: Uso combinado do service de Localizao e Validao.
4.3.3 Descrio do Servio de Registro de Chaves

A especificao do servio de registro de chaves XML permite gerenciar a informao que est ligada a um par de chaves publicas. A especificao do servio XKRSS suporta as seguintes operaes: Registro (Register) Informao ligada a um par de chaves publicas atravs de uma chave. Alterao (Reissue) O registro de uma chave registrada previamente alterada. Revogao (Revoke) O registro de uma chave registrada previamente revogada. Recuperao (Recover) A chave privada associada com a ligao da chave recuperada. Um servio XKMS pode oferecer todos ou nenhum desses servios. A operao Register por si s no impe que o servio de registro comunique essa informao para outros. No entanto, na maioria das aplicaes, o servio de registro prov informaes sobre a chave para outros servios Web como os descritos na especificao. A operao Register pode ser usada de um modo que as requisies de um cliente sejam aceitas atravs de um intermedirio como uma autoridade de registro local (LRA) e encaminhada para uma autoridade de registro principal (MRA). Esse modo de operao inteiramente transparente para o cliente que atua como se o LRA fosse a nica autoridade de registro envolvida. A construo da prova de possesso da chave privada e a informao de autenticao completamente separada da mensagem de autenticao de assinatura. Isso permite a verificao pelo LRA e qualquer outra autoridade de registro, mesmo que a mensagem de autenticao da assinatura tenha sido alterada pelo LRA.
58
4.3.3.1 Registro
A requisio Register usada para confirmar a ligao de uma informao a um par de chaves publicas. A gerao do par de chaves pblica pode ser feita tanto pelo cliente quanto pelo servio de registro. A mensagem de requisio de registro contm um prottipo da ligao de chave requisitada. O servio de registro pode requisitar que o cliente envie informao adicional para autenticar a requisio. Se o par de chaves publica gerado pelo cliente, o servio pode requisitar que o cliente envie a prova de possesso da chave privada. O prottipo da ligao de chave requisitada pode conter apenas informao parcial, uma chave sem o nome ou um nome sem a chave. Nesse caso, o cliente estar requisitando que o servio de registro fornea a informao adicional necessria para completar a ligao. Toda informao contida no prottipo da ligao de chave requisitada recomendado ao servio e pode ser ignorada ou sobreposta a escolha do servio. Ao receber uma requisio de registro, o servio verifica a autenticidade e a informao POP fornecida (se existente). Se o servio de registro aceitar a requisio uma ligao de chave registrada. Essa ligao de chave pode conter nenhuma, parte ou toda a informao fornecida no prottipo e pode incluir informaes adicionais.
A escolha de gerar o par de chaves publica no cliente ou no servio depende da aplicao e do tipo de chave. No caso da chave ser usada para assinaturas, , geralmente, indesejvel que qualquer outro tenha acesso a chave a no ser o responsvel pela chave. Caso o acesso a chave privada seja perdido, uma nova chave pode ser criada sem afetar a validade das assinaturas criadas usando a chave privada antiga. prefervel que tais chaves sejam criadas no cliente ao invs do servidor. No caso da chave privada ser usada exclusivamente para certos tipos de criptografia, a perda do acesso a chave privada pode resultar na perda de acesso a informaes armazenadas criptografadas com a chave. Nessas circunstncias geralmente desejvel alguma forma de recuperao da chave. Nesse caso o par de chaves geralmente criado no servio e entregue ao cliente. Uma chave usada tanto para criptografia quanto para assinatura pode ser gerada no cliente ou no servidor, dependendo se a recuperao de chave deve ser suportada.
Figura 5: Registro de uma ligao de chave
4.3.3.1.1 Exemplo: Registro de um par de chaves gerado no Cliente

59
Alice requisita o registro de um par de chaves RSA para seu endereo de email [email protected]. Ela recebeu, previamente, do servio XKMS o cdigo 024837 que autentica a sua requisio. Alice seleciona a sua frase chave Help I have revealed my key para se autenticar caso seja necessrio revogar o registro em uma data posterior. A mensagem de requisio X-KRSS contem o elemento <RegisterRequest> . Como a requisio de registro para um par de chaves gerado pelo cliente, o elemento de autenticao contem tanto um elemento <ProofOfPossession>, que demonstra que a requisio autorizada pelo dono da chave privada, como o elemento <KeyBindingAuthentication> que demonstra que a requisio foi feita pela pessoa que conhece o cdigo de autenticao 024837.
<?xml version="1.0" encoding="utf-8"?> <RegisterRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="I1494ac4351b7de5c174d455b7000e18f" Service="http://www.example.org/XKMS" xmlns="http://www.w3.org/2002/03/xkms#"> <RespondWith>http://www.w3.org/2002/03/xkms#X509Cert</RespondWith> <RespondWith>http://www.w3.org/2002/03/xkms#X509Chain</RespondWith> <PrototypeKeyBinding Id="I269e655567dbae568591c0a06957529e"> <ds:KeyInfo> <ds:KeyValue> <ds:RSAKeyValue> <ds:Modulus> 0nIsmR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8 HBupui8LgGthO6U9D0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZ drdcDrkNnG7SzbuJx+GDNiHKVDQggPBLc1XagW20RMvok= </ds:Modulus> <ds:Exponent>AQAB</ds:Exponent> </ds:RSAKeyValue> </ds:KeyValue> </ds:KeyInfo> <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage> <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage> <KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage> <UseKeyWith Application="urn:ietf:rfc:2459" Identifier='C="US" O="Alice Corp" CN="Alice Aardvark"' /> <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="[email protected]" /> <UseKeyWith Application="http://ca.example.com/cps/20030401/class3" Identifier="[email protected]" /> <RevocationCodeIdentifier> 5AEAai06hFJEkuqyDyqNh8k/u3M= </RevocationCodeIdentifier> </PrototypeKeyBinding> <Authentication> <KeyBindingAuthentication> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmacsha1" />
60
<Reference URI="#I269e655567dbae568591c0a06957529e"> <Transforms> <Transform Algorithm="http://www.w3.org/2001/10/xmlexc-c14n#" /> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <DigestValue>WCbpkifxJ1zIJ+V6/knZgxRhR34=</DigestValue> </Reference> </SignedInfo> <SignatureValue>iJSKM+98hj5ae+btC2WjwBYP+/k=</SignatureValue> </Signature> </KeyBindingAuthentication> </Authentication> <ProofOfPossession> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <Reference URI="#I269e655567dbae568591c0a06957529e"> <Transforms> <Transform Algorithm="http://www.w3.org/2001/10/xml-excc14n#" /> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <DigestValue>WCbpkifxJ1zIJ+V6/knZgxRhR34=</DigestValue> </Reference> </SignedInfo> <SignatureValue> DcPw742vN120QNrCjCKw0jiCX3pUvbMeRkYjktZkn4nbgo1b7leXU0sJgXM2CY/ oQugaRsgz18+qUzM0UX+jr1t1wtCMci5fjzVKZB63oZyKZ9+CJLcBCbirsgJAId +Pq9w4WiwKDf2AytsdXHlN5V1byQIkpfR1CypvBzQa1b4= </SignatureValue> </Signature> </ProofOfPossession> </RegisterRequest>
O servio aceita o registro e retorna a seguinte resposta:

<?xml version="1.0" encoding="utf-8"?> <RegisterResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="I92ed24772e43843b3d23020ad9ec9754" Service="http://www.example.org/XKMS" ResultMajor="http://www.w3.org/2002/03/xkms#Success" RequestId="I1494ac4351b7de5c174d455b7000e18f" xmlns="http://www.w3.org/2002/03/xkms#"> <KeyBinding Id="Ia26450ebe93f62b3b3ab137fc6a61c36"> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrDgMCHQUAMBIxEDA OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj ArMSkwJwYDVQQDEyBBbGljZSBBYXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBn zANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIsmR+aVW2egl5MIfOKy4HuMKkk 9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D0CNT5mbmhIA ErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQg gPBLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwO oAQAaVOkaVLLKoFmLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUX
61
jPG1TZxVKg+HutAwCQYFKw4DAh0FAAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObt Y3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6jNKYLCQb8zUGk4QOG5Y+HT/ QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8U/kD8UuRk Xp4AZh7QsiX8AcO0w== </ds:X509Certificate> <ds:X509Certificate> MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAMBIxEDA OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWj ASMRAwDgYDVQQDEwdUZXN0IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg QCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEkeXB8oMxwbhdcizWH92zrtm1V fVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVRNK5XmKXA5sE C51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBg NVHQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQM A4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GB ABDYD4Fwx2dscu+BgYcZ+GoQQtCJkwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsi QgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/MefuTtpOpCN40wy3YwwngD tHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435 </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage> <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage> <KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage> <UseKeyWith Application="urn:ietf:rfc:2459" Identifier="C="US" O="Alice Corp" CN="Alice Aardvark"" /> <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="[email protected]" /> <UseKeyWith Application="http://ca.example.com/cps/20030401/class3" Identifier="[email protected]" /> <Status StatusValue="http://www.w3.org/2002/03/xkms#Valid"> <ValidReason>http://www.w3.org/2002/03/xkms#Signature</ValidReason> <ValidReason>http://www.w3.org/2002/03/xkms#IssuerTrust</ValidReason> <ValidReason>http://www.w3.org/2002/03/xkms#RevocationStatus</ValidRe ason> <ValidReason>http://www.w3.org/2002/03/xkms#ValidityInterval</ValidRe ason> </Status> </KeyBinding> </RegisterResult>
4.3.3.1.2 Exemplo: Registro de um par de chaves gerado no Servio

A requisio de registro de um par de chaves gerado no servio omite os dados da chave pblica e requer que os dados da chave privada sejam retornados com a resposta. Bob requisita um par de chaves gerado pelo servio aps receber o cdigo de autenticao 3N9CJ-K4JKS-04JWF-0934J-SR09JW-IK4 atravs de um mecanismo out-ofband. A requisio especifica apenas Encryption e Exchange. O servio gera um par de chaves (publica-privada) em resposta a requisio, gera os certificados apropriados, e retorna como resultado para o cliente. O resultado inclui o valor da chave privada encriptografada usando uma chave derivada do valor do cdigo de autenticao. O cliente pode decriptografar a chave privada computando-a com o valor do cdigo de autenticao da mesma maneira que o servio. Para evitar que entidades no autorizadas tenham acesso a chave privada, necessrio que o servio e o cliente protejam o cdigo de autenticao. O servio no 62
deve reutilizar valores de cdigo de autenticao nem deve reutilizar chaves derivadas de um cdigo de autenticao para encriptar mais de uma comunicao de chave privada. A resposta inclui tanto os dados da chave pblica quanto a chave privada encriptografada.
<?xml version="1.0" encoding="utf-8"?> <RegisterResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="I2eb0b29bf38eeecfc5f099c8ca149f98" Service="http://www.example.org/XKMS" ResultMajor="http://www.w3.org/2002/03/xkms#Success" RequestId="I4e442fc461a83f320d7a3afb4f2454a9" xmlns="http://www.w3.org/2002/03/xkms#"> <KeyBinding Id="Ia500663f4e4e578447407a38b9049c8b"> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> MIICCTCCAXagAwIBAgIQe0Sk4xr1VolGFFNMkCx07TAJBgUrDgMCHQUAMBIxEDA OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj AkMSIwIAYDVQQDExlCb2IgQmFrZXIgTz1Cb2IgQ29ycCBDPVVTMIGfMA0GCSqGS Ib3DQEBAQUAA4GNADCBiQKBgQDcUW1ZSy8RqNC3ZJ5IX5G8DFZ08+HkZKVCenxI O++q8LATo9dxFasgaZXu3A1/ZNRcLFi7O1RQKUwjLXgHRD6TV6Pad6SZgvv4hzc MMZUVVpg+jFpFjRjaVXy06t7KdZ6CkVshNdzxXpjTZB9Hk7s+fX/XQSWyVoX9MX wxAapgTwIDAQABo1YwVDANBgNVHQoEBjAEAwIGQDBDBgNVHQEEPDA6gBABpU6Rp UssqgWYs3fukLy6oRQwEjEQMA4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUq D4e60DAJBgUrDgMCHQUAA4GBAF4jP1gGDbaq3rg/Vo3JY7EDNTp0HmwLiPMLmdn B3WTIGFcjS/jZFzRCbvKPeiPTZ6kRkGgydFOuCo5HMAxIks/LtnKFd/0qYT+AOD q/rCrwSx+F+Ro2rf9tPpja9o7gANqxs6Pm7f1QSPZO57bT/6afiVm7NdaCfjgMp hb+XNyn </ds:X509Certificate> <ds:X509Certificate> MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAMBIxEDA OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWj ASMRAwDgYDVQQDEwdUZXN0IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg QCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEkeXB8oMxwbhdcizWH92zrtm1V fVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVRNK5XmKXA5sE C51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBg NVHQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQM A4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GB ABDYD4Fwx2dscu+BgYcZ+GoQQtCJkwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsi QgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/MefuTtpOpCN40wy3YwwngD tHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435 </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage> <KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage> <UseKeyWith Application="urn:ietf:rfc:2459" Identifier="C="UK" O="Bob Corp" CN="Bob Baker"" /> <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="[email protected]" /> <Status StatusValue="http://www.w3.org/2002/03/xkms#Valid"> <ValidReason>http://www.w3.org/2002/03/xkms#Signature</ValidReason> <ValidReason>http://www.w3.org/2002/03/xkms#IssuerTrust</ValidReason> <ValidReason>http://www.w3.org/2002/03/xkms#RevocationStatus</ValidRe ason> <ValidReason>http://www.w3.org/2002/03/xkms#ValidityInterval</ValidRe ason> </Status>
63
</KeyBinding> <PrivateKey> <xenc:EncryptedData> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledescbc" /> <xenc:CipherData> <xenc:CipherValue> Em6xEIvjjlqqeEVOdf9Fq2E6ycz5OZrUU3jw7fBMhiM8BciSC3qry7GAlvRFp/D iD5zZduSaDriD27HGOuWo1fLihgOcw5sw+G9nyhfxKo7IZ2DEss0DD5H3AAZnTW reTYwposEBiBcuea4nYwzVWYFsIcplPYsHnXg1cq7MtMfaSu1WA4P/tQLhM1mdO V6FHkEHdyL4FBaZbjfmkB1Z++Yb0OlOUTNCQLcNxDkF6lNM75sprB+2FtwG1u9x ZnFXwP0Yt5euwCKeBRFm8Sfsf67CTIjKQ0+l9b66l/W1VszBgq2hMgSi8w+qILw mFP7p4AhJJNaYlOXHbJAQL6dOe4jtyEkjhEfXXJAO8497Dat9JU5l4Aeb8Mw5BA KDBT8RKnQTHqRTQZ8h5FPTapD1Av3KllxrIwRJG155enFrVwlxm6mLD+z4WeAdn U5l9gUSaS13E0PlBApi98zDjILihycV1m90SzUNRIuSnw/8tV0ykS3uquDSmNAO 5YX7UZtieFMyQ2U8XBNRYYftLaN6RfPCejtxXZxIsGtvxyzzL+Yf3bl595J+IOt n3M73bBvkdq3ACgOG0SCaETlTE5i60Trw19um+f7gAD4QKXawKw72gyQ70GccML Dh4mypfstCbXxCG5nntGAPkCqT/c+t0TdPc7VrtyFLB3ta9z9yiRkeKqvkVZpvb lQwykzDd3fgn9ds1liuy8RagrVO6Zczii9b7AQmQ9dekw+QDVkeS53xNTbByau/ aYAjOjIu4Xb6QNPOrNfHYOLMwGuf19o5nAjZEadZU83QhJq/ofwv3EL7tVMlOpF K7n6Apk7cwmS4OtU71cbAVBMcAsh3KbfrHm0TCy67DEZLtdE9ksTekZMpDKXayQ uRI0nyKugmwOVvI6oxyMt9JHRiSJRfyYF6yQoyGHGyX8nLX5imG8WNxHBur7j9h rt8Nf9XRvXY2N9RRfpoDTexN/KZJIZJhDFsY5gsjs1xy0kZqushvZ+jeElGylXs U/CSXwu3fgeM4qTnMKvJvHl9K4KlDtjIyYIRlBt22n238ADjMLFgUWS4+lyoWZ+ EJPzo0y9CIqb2uUNqp5cSAnb0v7s7gsq6yTqaB9fFSrV0oLH/I65Xoa7XW4mY06 xgwshdC/HHCaTyP/OEgq5Iv2VZUlWTGp1KuEmfko6MaRB/JqMhjNupi1esYTpre JsBexGjBiCpPPieykC8ngC8GEWLRUyWPdDCybiM/CRFdCvgD5n/Js7nkNY0JGLf BY0cGnkrxv7e5+5S1Be33yWonJSs8QQ6+y4/V5vPe+5tH8++VFm6dZXtL/oOU0S DyHruc0yGmdu9GCibRcaU49rPLWbwSfg/g7mVibah2YBXkDDolW1U6pOpry9fHM kEODQrnoIvGZLaOZ8UQ7jnI92WOTySdxylFL2ZvEHadlUKKN2KtW4zs7nhcQ6Tf 6gjYLNXX9ztkNgCKCZRzI4TXOM2khtPhxTv83rfV0hlx1mtRjlifDdbiWInrCW7 7IPgMEIkEa1oXoKcYb1pUw+W9xzeTp4hTx16izBqC9aWNSYJrT1AvX/Xa+oY8F4 p+YGGgOSvn9Cb2h1Va8YTb3ntqWaFSE+0/YyOHYgCIsaeYXV9YFN8A+fw </xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </PrivateKey> </RegisterResult>
4.3.3.2 Alterao
Um servio de registro pode permitir que os clientes editem uma ligao de chave registrada previamente. Uma requisio de alterao similar ao registro inicial de uma chave. A principal razo pela qual o cliente poderia querer fazer uma requisio de alterao seria para que o servio de registro gerasse novas credenciais na camada PKI. Ex: Certificados X.509.
4.3.3.2.1 Exemplo: Alterao

Alice faz uma requisio de alterao de seu par de chaves RSA registrados previamente para seu email. A mensagem de requisio X-KRSS contm o seguinte elemento <ReissueRequest>:
<?xml version="1.0" encoding="utf-8"?> <ReissueRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
64
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="I3a682dfb94cc8e9b3b648026783a8094" Service="http://www.example.org/XKMS" xmlns="http://www.w3.org/2002/03/xkms#"> <RespondWith>http://www.w3.org/2002/03/xkms#X509Cert</RespondWith> <RespondWith>http://www.w3.org/2002/03/xkms#X509Chain</RespondWith> <ReissueKeyBinding Id="I518fc89b03369bccec3d1ee9d985c436"> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrDgMCHQUAMBIxEDA OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj ArMSkwJwYDVQQDEyBBbGljZSBBYXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBn zANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIsmR+aVW2egl5MIfOKy4HuMKkk 9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D0CNT5mbmhIA ErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQg gPBLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwO oAQAaVOkaVLLKoFmLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUX jPG1TZxVKg+HutAwCQYFKw4DAh0FAAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObt Y3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6jNKYLCQb8zUGk4QOG5Y+HT/ QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8U/kD8UuRk Xp4AZh7QsiX8AcO0w== </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> <Status StatusValue="http://www.w3.org/2002/03/xkms#Valid" /> </ReissueKeyBinding> <Authentication> <KeyBindingAuthentication> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmacsha1" /> <Reference URI="#I518fc89b03369bccec3d1ee9d985c436"> <Transforms> <Transform Algorithm="http://www.w3.org/2001/10/xml-excc14n#"> <ec:InclusiveNamespaces PrefixList="ds xenc #default" xmlns:ec="http://www.w3.org/2001/10/xml-excc14n#" /> </Transform> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <DigestValue>qnhsUF9RMxxGydG/5KdJjWhtBFE=</DigestValue> </Reference> </SignedInfo> <SignatureValue>+gKw3b0qi9BaIqmN1gIyvj1UxRs=</SignatureValue> </Signature> </KeyBindingAuthentication> </Authentication> <ProofOfPossession> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
65
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <Reference URI="#I518fc89b03369bccec3d1ee9d985c436"> <Transforms> <Transform Algorithm="http://www.w3.org/2001/10/xml-excc14n#"> <ec:InclusiveNamespaces PrefixList="ds xenc #default" xmlns:ec="http://www.w3.org/2001/10/xml-excc14n#" /> </Transform> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <DigestValue>qnhsUF9RMxxGydG/5KdJjWhtBFE=</DigestValue> </Reference> </SignedInfo> <SignatureValue> sP/RWAA7fnv86ZgwOlfxTwN05akxyf65rCw7rwXNkJmx0fxUNFJ+qKDqmIh2KyvFyBut6 FredSXj t3iDIXUKMmjA2/VPGEX8yyd71DbRqf9dXb2FzkvkKrCbYumlavbrChpEwiMUqk2rd5tjk FAZjYRA tuURoFfmoOYY/M+mNUU= </SignatureValue> </Signature> </ProofOfPossession> </ReissueRequest>
O servio aceita o registro e retorna a seguinte resposta:

<?xml version="1.0" encoding="utf-8"?> <ReissueResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="I4f0f13b32e4f43f0c1b390b5186fa997" Service="http://www.example.org/XKMS" ResultMajor="http://www.w3.org/2002/03/xkms#Success" RequestId="I3a682dfb94cc8e9b3b648026783a8094" xmlns="http://www.w3.org/2002/03/xkms#"> <KeyBinding Id="I9a894fff4149d2351c24241886e3900e"> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrDgMCHQUAMBIxEDA OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj ArMSkwJwYDVQQDEyBBbGljZSBBYXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBn zANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIsmR+aVW2egl5MIfOKy4HuMKkk 9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D0CNT5mbmhIA ErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQg gPBLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwO oAQAaVOkaVLLKoFmLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUX jPG1TZxVKg+HutAwCQYFKw4DAh0FAAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObt Y3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6jNKYLCQb8zUGk4QOG5Y+HT/ QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8U/kD8UuRk Xp4AZh7QsiX8AcO0w== </ds:X509Certificate> <ds:X509Certificate> MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAMBIxEDA OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWj ASMRAwDgYDVQQDEwdUZXN0IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg QCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEkeXB8oMxwbhdcizWH92zrtm1V fVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVRNK5XmKXA5sE C51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBg
66
NVHQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQM A4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GB ABDYD4Fwx2dscu+BgYcZ+GoQQtCJkwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsi QgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/MefuTtpOpCN40wy3YwwngD tHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435 </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage> <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage> <KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage> <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="[email protected]" /> <Status StatusValue="http://www.w3.org/2002/03/xkms#Valid"> <ValidReason>http://www.w3.org/2002/03/xkms#Signature</ValidReason> <ValidReason>http://www.w3.org/2002/03/xkms#IssuerTrust</ValidReason> <ValidReason>http://www.w3.org/2002/03/xkms#RevocationStatus</ValidRe ason> <ValidReason>http://www.w3.org/2002/03/xkms#ValidityInterval</ValidRe ason> </Status> </KeyBinding> </ReissueResult>
4.3.3.3 Revogao
O servio de registro pode permitir que os clientes revoguem ligaes de chaves registradas previamente. Uma requisio de revogao necessita apenas conter informao suficiente para identificar a ligao de chave a ser revogada e a autoridade para a requisio de revogao. Se uma ligao de chave XKMS est ligada a um objeto de dados da camada PKI a revogao para essa ligao de chave deve resultar na revogao do objeto de dados dessa camada.
4.3.3.3.1 Exemplo: Revogao

Por alguma razo Alice faz uma requisio de revogao da ligao de sua chave pblica para o servio. Alice se autentica usando a frase chave estabelecida durante o registro. A mensagem de requisio a seguinte:
<?xml version="1.0" encoding="utf-8"?> <RevokeRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="I2aa2c2f37195c9c4364c55f15df68091" Service="http://www.example.org/XKMS" xmlns="http://www.w3.org/2002/03/xkms#"> <RevokeKeyBinding Id="Ie91dfbf1c948d5cf142099676968caf1"> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrDgMCHQUAMBIxEDA OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj ArMSkwJwYDVQQDEyBBbGljZSBBYXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBn zANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIsmR+aVW2egl5MIfOKy4HuMKkk 9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D0CNT5mbmhIA ErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQg gPBLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwO
67
oAQAaVOkaVLLKoFmLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUX jPG1TZxVKg+HutAwCQYFKw4DAh0FAAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObt Y3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6jNKYLCQb8zUGk4QOG5Y+HT/ QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8U/kD8UuRk Xp4AZh7QsiX8AcO0w== </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> <Status StatusValue="http://www.w3.org/2002/03/xkms#Indeterminate" /> </RevokeKeyBinding> <RevocationCode>PHx8li2SUhrJv2e1DyeWbGbD6rs=</RevocationCode> </RevokeRequest>
O servio responde que a ligao de chave foi revogada:

<?xml version="1.0" encoding="utf-8"?> <RevokeResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="I252433a097631dca9a2775493f39c7d7" Service="http://www.example.org/XKMS" ResultMajor="http://www.w3.org/2002/03/xkms#Success" RequestId="I2aa2c2f37195c9c4364c55f15df68091" xmlns="http://www.w3.org/2002/03/xkms#" />
4.3.3.4 Recuperao de Chave

Um servio de registro pode suportar a recuperao de chaves. Para a recuperao de chaves ser possvel, a chave privada a ser recuperada deve ter sido previamente inserida no servio de recuperao, por exemplo, pelo registro de uma chave gerada pelo servidor XKRSS. Uma requisio de recuperao similar ao registro inicial de uma chave com a exceo de que o cdigo de resultado NotFound pode ser retornado se o servio de registro no tiver registro sobre a ligao de chave a ser recuperada. O servio de recuperao de chave deve, provavelmente, necessitar de tempo para responder a requisio de recuperao. Os clientes que suportam a recuperao de chaves devem suportar processamento assncrono. A poltica de segurana do remetente pode considerar o processo de recuperao de chave como um potencial risco de comprometimento da chave recuperada e, portanto requisitar a revogao de todas as ligaes de chaves associadas, principalmente se a requisio de recuperao de chave tenha sido feita por um terceiro ator como o supervisor do responsvel pela chave.
4.3.3.4.1 Exemplo: Recuperao de chave

Bob esqueceu sua chave privada que havia sido obtida no exmplo de registro anterior. Ele primeiro contacta o administrador do servio de recuperao de chaves usando um procedimento de autenticao out-of-band determinado pela poltica do site. O administrador envia a bob (usando um mtodo out-of-band) o cdigo de autorizao de recuperao de chave A8YUT VUHHU C9H29 8Y43U H9J3I 23. Os parmetros de requisio para a recuperao da chave so:
<?xml version="1.0" encoding="utf-8"?> <RecoverRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="I66f40510c322d281602ce76b9eb04d7d" Service="http://www.example.org/XKMS"
68
xmlns="http://www.w3.org/2002/03/xkms#"> <RespondWith>http://www.w3.org/2002/03/xkms#PrivateKey</RespondWith> <RecoverKeyBinding Id="I29cb8ac8a2ad878f7be44edfe53ea77a"> <ds:KeyInfo> <ds:KeyValue> <ds:RSAKeyValue> <ds:Modulus> 3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV7twNf2T UXCxYuztUUClMIy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreyn WegpFbITXc8V6Y02QfR5O7Pn1/10ElslaF/TF8MQGqYE8= </ds:Modulus> <ds:Exponent>AQAB</ds:Exponent> </ds:RSAKeyValue> </ds:KeyValue> </ds:KeyInfo> <Status StatusValue="http://www.w3.org/2002/03/xkms#Indeterminate" /> </RecoverKeyBinding> <Authentication> <KeyBindingAuthentication> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmacsha1" /> <Reference URI="#I29cb8ac8a2ad878f7be44edfe53ea77a"> <Transforms> <Transform Algorithm="http://www.w3.org/2001/10/xml-excc14n#"> <ec:InclusiveNamespaces PrefixList="ds xenc #default" xmlns:ec="http://www.w3.org/2001/10/xml-excc14n#" /> </Transform> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <DigestValue>GfV3xa/OL6EQAoo5sFL/nHQJCeo=</DigestValue> </Reference> </SignedInfo> <SignatureValue>TtHM/i5L6ynzQHh2Xym8wnbjQ+w=</SignatureValue> </Signature> </KeyBindingAuthentication> </Authentication> </RecoverRequest>
A poltica desse servio de registro em particular a de revogar a chave privada quando uma recuperao de chave for executada. O servio de registro pode adotar a poltica revoke on recover por vrias razes das quais se inclui a preocupao de que o processo de recuperao pode ter comprometido a chave de alguma maneira. O servio retorna a ligao de chave revogada e os parmetros da chave privada:
<?xml version="1.0" encoding="utf-8"?> <RecoverResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="Iacd24dbd4b3c79660f4d26aca7aaaea2" Service="http://www.example.org/XKMS" ResultMajor="http://www.w3.org/2002/03/xkms#Success"
69
RequestId="I66f40510c322d281602ce76b9eb04d7d" xmlns="http://www.w3.org/2002/03/xkms#"> <KeyBinding Id="I29cb8ac8a2ad878f7be44edfe53ea77a"> <ds:KeyInfo> <ds:KeyValue> <ds:RSAKeyValue> <ds:Modulus> 3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV7twNf2T UXCxYuztUUClMIy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreyn WegpFbITXc8V6Y02QfR5O7Pn1/10ElslaF/TF8MQGqYE8= </ds:Modulus> <ds:Exponent>AQAB</ds:Exponent> </ds:RSAKeyValue> </ds:KeyValue> </ds:KeyInfo> <Status StatusValue="http://www.w3.org/2002/03/xkms#Invalid"> <InvalidReason>http://www.w3.org/2002/03/xkms#Signature</InvalidReaso n> <InvalidReason>http://www.w3.org/2002/03/xkms#IssuerTrust</InvalidRea son> <InvalidReason>http://www.w3.org/2002/03/xkms#RevocationStatus</Inval idReason> <InvalidReason>http://www.w3.org/2002/03/xkms#ValidityInterval</Inval idReason> </Status> </KeyBinding> <PrivateKey> <xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Content" MimeType="text/xml"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledescbc" /> <xenc:CipherData> <xenc:CipherValue> DDSIEvW/tshnuCwCC+jX6y/srzMpt3qCIQ5zXmk/cHN4o/BItHsi9BJF85a3hnN C4/aFfPVJ3WgP6vIZNAUaDY2FbAJckWRgWhGku36p7DZTB14vmt5P5C1bXGU5ps CDw5Sbm+s/cFkReyfGk6khJTpbgQABPGIZBy2hiZMdSnu0eRgaVUXk9X5oPAhYU BjiQRq56ckHgEhkuwa+RiA+ybDNn/Ttjt5Uu5BjCONkOdeE8eJMlu0ykj99Vn7G NKUvt86bJsuwu5ZD1vSmVEwUAvHKV09UfVWfcKEINoj30t8Imj9naJ37oVRNPXl EKqZY9cxqzHiYEEhu0wxiTMiLbkEyh1DIcLNW78JXpWHRuRTrU5hgNzGEO1pKo7 1uRT1/lArojeJGCJKAwQJvCDXU9zZSXVLzU/AqUshR3L0AoY8pJ/p+LbmlTh43E 4TeT0iXNWkLz0mdgWdmwhhZtj8NcP/4auqfpv7+4NAP5OFVOEYJgE1I60F49K9m 7FbNygiAczfN1YZwjc5lLoIXo75cXduxOZgTWN8ZnFKwrhG1IMhstrauywur6lr lyxZ1JXEj2aohE4Msa7HKx1LSzDi3dejtK3ZFRqnJcJ1bQ/liOA1IgonN0wvUaH DM9ibo2xUie2DfoSw3kWCDf0bcZEcV33UFNR3w8kOHgpSAwdHJi0pRyHdgfyd8w 3NzvfCNy9AlrU2MbTdFF7hBxmgFK3fvaX7aEcgdqY17dqkiK75TAwzkVh5WkVjS WZGSiN49C8e4bY9zzq33lZwZabd5ts2Dvy3RuKc0hQj2rnCZcowXC+XJ7tVtMG+ lNu1ykyeYmvR8VI5Ame5h1DFPjoFLAjkt/tUu2uZlqLYoSKvJU4FWNMAXRUge+f L3f35lObqwxPJN/LVJgvgGqoMt5hO+/uwgsb3nbR7rTHavPX2kS5LDAtW5xNcfF dJz8l+dDjlYBJMN8cgEKnNtHTcnVJ5NiFPsGIFv/3IGUZsiw7M4dff3GN6quv9A 601e5rqG1ObMT6/7y7T0Z5IBXwiqs4HcdV+kyRfJwX1QpGat3nQsOZ59PTsIt5n oKSH0sB5AZmLJa1zgeOILJ574r+F6kD44R32NoLjqu0QL5IqfQ/0lQJuYhn0uEr FeZIn/lvjqzgf+rGPtgI5wtZ9Fv3qKrTPJOGM8atkzPkUtyJ8kR+WRhdAdFH9HM 0PgyrSGjcCGgFIppsN1KJawrvcXokGRzF81cD/3pVaZC/ZIBtvp4DXM2JSLGoa1 GpLuaIFUP5T/uxFf6MpW2v07bB/jqEZrcsB/ofmvv6RXD/gXrrw99iIiv0k2lyR sHDN5/syXglGGeskPvCUOZZ5oXrZruxER/IXKRnlsD+0wJ3JZCSuPy9wYmQk77F pynJ5//7w8UA2qWvkZ0B4rKXOgZYp2pCWaZIDknHJoY+VL7J3sQyAp7qlkQxSBj bhTEjSYXpHWA+Vj/TiH1ue7/ULlCKfDNvDaWFuEqGT/9H+xUJ5POfTDBhUh+Row rwCcfYe71B+pB/tylQEERKNpqqgu3TbNJZk5G8U9p41+PwJ0kw9EZnv+z8UEyFl
70
qAZZxj64rTelurPUsiehBFwVwh2fATuMrW9fhGew11npVlF5k+WxE1Cz+ </xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </PrivateKey> </RecoverResult>
Os parametros da chave privada decriptograda so:

<?xml version="1.0" encoding="utf-8"?> <RSAKeyPair xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2002/03/xkms#"> <Modulus> 3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV7twNf2TUXCxYu ztUUClMIy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreynWegpFbITXc8V 6Y02QfR5O7Pn1/10ElslaF/TF8MQGqYE8= </Modulus> <Exponent>AQAB</Exponent> <P> 8dnXAObQvcKL0Rr/A+5Ufp1yJgLpH+uohFcJV2kUDCzv5VWKcN+LTq2mciKlnFbAQXKa5 dNPOx4qi3An/4NSMQ== </P> <Q> 6TUX4d9+enb/aLHtck39x7cPQWlKkNFFJAqXaaRScDhjf4d8b009uW/pu3O2BdIJPY8M/ QnURlqXGLqGGl26fw== </Q> <DP> LVEcMFcPlf72I+BjGGF4A6GM2gKBnDGUCfglD/Pohb+F0/sLTcsVV1DCd3B2h6zZqWnID HhjyDgG0MnbNM1ugQ== </DP> <DQ> 0DWm7PMtaQl1X3P8G2Gmgvjdlfj7qfAtWtBZ/ufG8oplyyab4oOD6FwSwlm82dV8iol9f y2XaHjZDir6L/Ae4Q== </DQ> <InverseQ> sD2Vl/CCVTDbhhLwdfc4IQDBOh8xpBUV7PPM5LFGjiLetlfwaYi7Bp2ol8WF1MX88iCV2 E3xOPCNfbMhvEB5dA== </InverseQ> <D> REUnMUhO6ZX6NxoCwkJ7El5wXAVGtlNJsnPqFygbeEjlBvD6TZx9TqnpP/8IX7WK6JUFW d9knQJvCWeJjhbjnImSS/3xc+v+m4glnnebZbaghvfunbI++fQaNAFRVT1hLvEGknqC/7 zsrUM04ogU7hP+XgdFTJ1QYGfGHl5c0IE= </D> </RSAKeyPair>
4.3.3.5 Autenticao de Requisio

O X-KRSS especifica um mecanismo de autenticao de requisio que independente de qualquer outro mecanismo de autenticao fornecido pela ligao da mensagem. Pela sua natureza, necessrio que o protocolo X-KRSS suporte requisies de partes que precisam ainda registrar as suas credenciais ou possuam credenciais danificadas que devero ser revogadas. Um servio X-KRSS deve assegurar que todas as requisies so autenticas e autorizadas. Autenticidade: A mensagem de requisio originada da parte especificada. Integridade: A mensagem de requisio no foi modificada.
71
Possesso: Se uma chave publica especificada em uma mensagem de requisio, prova que a requisio autorizada por uma parte que tem acesso a chave privada correspondente. Os servios de registro definem as suas prprias polticas de autenticao. Essa especificao define um mecanismo de autenticao que emprega um segredo compartilhado estabelecido entre o cliente e o servio de registro. Os servios devem requisitar que o cliente demonstre a prova de possesso dos componentes da chave privada de uma chave pblica se uma requisio feita para registrar uma ligao de chave vlida dessa chave pblica. Os servios devem aceitar a prova de possesso do componente de chave privada de uma chave pblica para efetuar a revogao de qualquer ligao com relao a essa chave.
4.4 Extensible Access Control Markup Language (XACML)

O XACML (Extensible Access Control Markup Language) uma linguagem baseada no XML feito especificamente para criar polticas e automatizar o uso delas, para controlar o acesso de diferentes aplicaes em plataformas distintas em uma rede. Ele descreve tanto uma linguagem de polticas de controle de acesso quanto uma linguagem de requisio/resposta. A linguagem de polticas usada para expressar as politicas de controle de acesso (quem pode fazer o que, quando). A linguagem de requisio/resposta expressa consultas de acesso (requisies) e descreve respostas a essas consultas.
4.4.1 Requisitos
Os requisitos bsicos de uma poltica de linguagem para expressar uma poltica de segurana de um sistema de informao so: Fornecer um mtodo para combinar regras e polticas individuais em uma nica poltica que se aplique a uma requisio de deciso particular; Fornecer um mtodo para definio flexvel de um procedimento no qual as regras e polticas so combinadas; Fornecer um mtodo para lidar com mltiplos subjects atuando em diferentes nveis; Fornecer um mtodo para basear a deciso de autorizao em atributos do subject e do recurso; Fornecer um mtodo para lidar com atributos multivalorados; Fornecer um mtodo para basear a deciso de autorizao no contedo de um recurso de informao; Fornecer um conjunto de operadores lgicos e matemticos para os atributos do subject, recurso e ambiente;
72
Fornecer um mtodo para manipular um conjunto distribudo de componentes da poltica, abstraindo os mtodos de localizao, recuperao e autenticao dos componentes da poltica; Fornecer um mtodo para rapidamente identificar a poltica que se aplica a determinada ao baseada nos valores dos atributos do subject, recurso e ao; Fornecer uma camada abstrata que isole a poltica dos detalhes do ambiente da aplicao; Fornecer um mtodo para especificar um conjunto de aes que devem ser executadas em conjunto com a poltica vigente. A motivao por trs do XACML a de expressar essas idias bem elaboradas no campo da poltica de controle de acesso usando uma linguagem de extenso do XML. As solues do XACML para cada um desses requisitos so discutidas nas sesses seguintes.
4.4.2 Combinao da regra e poltica

A poltica completa aplicada para uma requisio de deciso particular pode ser composta de vrias regras e polticas individuais. Por exemplo, em uma aplicao privada pessoal, o dono da informao pode definir certos aspectos de poltica de divulgao, j uma empresa pode definir outros tipos de aspectos. Para criar uma deciso de autorizao, deve ser possvel combinar as duas polticas separadas para a requisio. O XACML define trs elementos de poltica: <Rule>, <Policy> e <PolicySet>. O Elemento <Rule> contm uma expresso booleana que pode ser avaliada isoladamente, mas no se tem a inteno de ser acessado pelo PDP isoladamente. Portanto no se tem a inteno de formar a base para a deciso de autorizao, e sim de existir isoladamente apenas com o PAP XACML, onde pode formar uma unidade bsica de gerencia, e ser re-utilizada em mltiplas polticas. O Elemento <Policy> contem um conjunto de elementos <Rule> e um procedimento especfico para combinar os resultados de suas avaliaes. a unidade bsica da poltica utilizada pelo PDP e, portanto deve formar a base da deciso de autorizao. O elemento <PolicySet> contem um conjunto de elementos <Policy> ou outros elementos <PolicySet> e um procedimento especfico para combinar os resultados das suas avaliaes.
4.4.3 Algoritmos de combinao

O XACML define alguns algoritmos de combinao que podem ser identificados pelos atributos RuleCombiningAlgId ou PolicyCombiningAlgId dos elementos <Policy> e <PolicySet> respectivamente.O algoritmo rulecombining define um procedimento para chegar a uma deciso de autorizao dado os resultados individuais da avaliao de um conjunto de regras. Similarmente, o algoritmo policy-combining define um procedimento para chegar a uma deciso de
73
autorizao dado os resultados individuais de avaliao de um conjunto de polticas. Os algoritmos padres de combinao so assim definidos: Deny-overrides, Permit-overrides, First-applicable e Only-one-applicable. No caso do algoritmo Deny-overrides, se um nico elemento <Rule> ou <Policy> obtm como resultado da avaliao o valor Deny, ento, independente do resultado da avaliao de outros elementos <Rule> ou <Policy> na politica aplicada, o resultado combinado Deny. Do mesmo modo, no caso do algoritmo Permit-overrides, se um nico resultado Permit encontrado, ento o resultado combinado ser Permit. No caso do algoritmo de combinao First-applicable, o resultado combinado o mesmo resultado da avaliao do primeiro elemento <Rule>, <Policy> ou <PolicySet> na lista de regras que se aplica a requisio de deciso. O algoritmo Only-one-applicable apenas se aplica as polticas. O resultado desse algoritmo assegura que apenas uma policy ou policy set seja aplicada em virtude de suas targets. Se nenhuma policy ou policy set se aplica, ento o resultado NotApplicable, mas se mais de uma policy ou policy set se aplicam, ento o resultado Indeterminate. Quando exatamente uma policy ou policy set se aplica, o resultado do algoritmo o resultado da avaliao dessa nica policy ou policy set aplicada. Os elementos policy e policy set podem levar parmetros que modificam o comportamento dos algoritmos de combinao. Entretanto, nenhum dos algoritmos padres so afetados pelos parmetros. Os usurios dessa especificao podem, se necessrio, definir os seus prprios algoritmos de combinao.
4.4.4 Mltiplos Subjects

As polticas de controle de acesso frequentemente colocam requisitos nas aes de mais de um subject. Por exemplo, a politica que gerencia a execuo de uma transao financeira de alto nvel pode necessitar da aprovao de mais de um indivduo, atuando em diferentes nveis. Portanto o XACML reconhece que pode haver mais de um subject relevante para a requisio de deciso. Um atributo chamado subject-category usado para diferenciar subjects atuando em diferentes nveis. Alguns valores padres para esse atributo so especificados, e os usurios podem definir atributos adicionais.
4.4.5 Polticas baseadas nos atributos de subjects e resources

Outro requisito comum basear a deciso de autorizao em alguma caracterstica do subject ao invs de sua identidade. Provavelmente a aplicao mais comum com essa idia a subjects role [RBAC]. O XACML fornece facilidades para suportar essa abordagem. Atributos de subjects contidos no contexto requisitado podem ser identificados pelo elemento <SubjectAttributeDesignator>. Esse elemento contm uma URN que identifica o atributo. Como alternativa, o 74
elemento <AttributeSelector> pode conter uma expresso XPath sobre o contexto da requisio para identificar o valor de um atributo particular do subject atravs de sua localizao no contexto. O XACML fornece um meio padro de se referenciar atributos, definidos nas series de especificao LDAP [LDAP-1, LDAP-2]. Isso feito para encorajar os implementadores a usarem os identificadores de atributos padres ao invs de alguns atributos de subjects comuns. Outro requisito comum basear a deciso de autorizao em alguma caracterstica do resource ao invs de sua identidade. O XACML fornece facilidades para suportar essa abordagem. Os atributos do resource podem ser identificados pelo elemento <ResourceAttributeDesignator>. Esse elemento contm uma URN que identifica o atributo. Como alternativa o elemento <AttributeSelector> pode conter uma expresso XPath sobre o contexto da requisio para identificar o valor de um atributo de resource particular pela sua localizao no contexto.
4.4.6 Atributos Multivalorados

As tcnicas mais comuns para comunicar os atributos (LDAP, XPath, SAML, etc.) suportam mltiplos valores por atributo. Portanto, quando um PDP XACML recupera o valor de um determinado atributo, o resultado pode conter mltiplos valores. Uma coleo desses valores chamada bag. Uma bag se diferencia de um conjunto, pois pode conter valores duplicados, j um conjunto no. As vezes essa situao representa um erro. Em alguns casos a regra do XACML satisfeita se qualquer um dos atributos possua um valor que se encaixe no critrio expressado na regra. O XACML fornece um conjunto de funes que permite ao criador de polticas ter absoluta clareza sobre como o PDP deve proceder no caso de haver atributos com mltiplos valores.
4.4.7 Polticas baseadas no contedo de resources

Em muitas aplicaes necessrio basear a deciso de autorizao nos dados contidos na informao do resource na qual o acesso requisitado. Por exemplo, um componente comum de poltica privada que a pessoa possa ler os registros na qual ele ou ela fazem parte do subject. A poltica correspondente deve conter uma referncia ao subject identificado na prpria informao do resource. O XACML fornece facilidades para fazer isso quando a informao do recurso pode ser representada como um documento XML. O elemento <AttributeSelector> pode conter uma expresso XPath sobre o contexto da requisio para identificar o dado na informao do recurso a ser usada na avaliao da poltica. Nos casos em que a informao do recurso no um documento XML, podem ser referenciados atributos especficos do recurso.
4.4.8 Operadores
Polticas de segurana da informao operam sobre atributos de subjects, resource, action e environment a fim de chegar a uma deciso de autorizao. Nesse 75
processo, atributos de diferentes tipos podero ter de ser comparados ou computados. Por exemplo, em uma aplicao financeira, a avaliao do crdito de uma pessoa pode ter de ser calculado pela soma do limite de seu credito com a balana de sua conta. O resultado pode ter ento, de ser comparado com o valor da transao. Esse tipo de situao cria a necessidade de operadores aritmticos para atuar sobre atributos do subject (balana da conta e limite de crdito) e resources (valor da transao). Ainda mais comum, a politica pode identificar um conjunto de papeis que permitido uma ao em particular executar. A operao correspondente envolve checar se h uma interseco no nula entre o conjunto de papeis ocupados pelo subject e o conjunto de papeis identificados na poltica. Eis ento a necessidade por um conjunto de operaes. O XACML possui um vasto nmero de funes internas e um mtodo para adio de funes. Essas funes podem ser aninhadas para criar expresses complexas, isso feito utilizando o elemento <Apply>. O elemento <Apply> possui um atributo XML chamado FunctionId que identifica a funo a ser aplicada e o contedo do elemento. Cada funo padro definida para combinaes especficas de argumentos de tipos de dados, e o tipo de dado retornado tambm especificado. Portanto, a consistncia de tipo de dado da politica pode ser checada no momento em que a poltica escrita ou compilada, e os tipos dos valores dos dados presentes no contexto da requisio podem ser checados com os valores esperados pela politica para assegurar um resultado previsvel. Alm de operadores para conjuntos de argumentos e argumentos numricos, so definidos operadores para data, hora e durao de argumentos. Operadores relacionais (comparao e igualdade) so tambm definidos para tipos de dados. H tambm os operadores sobre tipos de dados booleanos que permitem a cominao lgica de predicados em uma regra. Por exemplo, uma regra pode conter uma declarao de que o acesso pode ser permitido durante o horrio comercial e de um terminal no local de trabalho.
4.4.9 Polticas Distribudas

Em um sistema distribudo, declaraes individuais da poltica podem ser escritas por diversos autores. Alm disso, para facilitar a combinao de componentes independentes da politica, essa abordagem permite que as polticas sejam atualizadas quando necessrias. As declaraes das polticas do XACML podem ser distribudas de vrios modos, porem no se descrito nenhum modo normativo de como fazer isso. Independente dos meios de distribuio, se espera que os PDPs confirmem, examinando o elemento <Target> da politica , que a politica aplicvel a requisio de deciso que est sendo processada. Os elementos <Policy> podem ser anexados aos recursos de informao aos quais se aplicam, como descrito por Perritt [Perritt93]. Alternativamente, os elementos <Policy> podem ser mantidos em um ou mais locais de onde eles so recuperados para avaliao. Nesses casos a politica aplicada pode ser referenciada por um identificador ou localizador associado com o recurso da informao.
4.4.10 Indexao de Polticas
76
Para melhorar a eficincia da avaliao e facilitar a gerncia, a poltica em vigncia pode ser expressa por mltiplos componentes policies independentes. Nesse caso necessrio identificar e obter a declarao da politica aplicada e verificar se a correta para a ao requisitada antes de avali-la. Esse o propsito do elemento no <Target> XACML. Duas abordagens so suportadas: 1. Declaraes da politica podem ser armazenadas em um banco de dados. Nesse caso o PDP deve formar uma consulta no banco de dados para obter apenas as polticas que so aplicveis para o conjunto de requisies de deciso que devero ser respondidas. Alm disso, o PDP deve avaliar o elemento <Target> das declaraes policy ou policy set obtida como definido pela especificao do XACML. 2. Alternativamente, o PDP pode carregar todas as polticas disponveis e avaliar os seus elementos <Target> no contexto de uma requisio de deciso particular, com o objetivo de identificar as policies e policy sets que so aplicveis a essa requisio.
4.4.11 Camada de Abstrao

O PEP possui vrias formas. Por exemplo, um PEP pode ser parte de um gateway de acesso remoto, servidor WEB ou de email, etc ... irreal esperar que todos os PEPs em uma empresa faam, ou faro no futuro, uma requisio de deciso para um PDP em um formato comum, nem que uma poltica em particular seja aplicada por mltiplos PEPs. Seria ineficiente forar um criador de polticas a escrever a mesma poltica de vrios modos diferentes para acomodar o formato requerido para cada PEP. Atributos similares podem estar contidos em vrios tipos de envelopes (ex.atributos dos certificados X.509, atributos de diretrizes SAML, etc.). Portanto existe uma necessidade de uma forma cannica de requisio e resposta manipulada por um PDP do XACML. Essa forma cannica chamada de contexto XACML. Sua sintaxe definida no XML schema. Naturalmente, PEPs em conformidade com o XACML podem enviar requisies e receber respostas no formado de um contexto XACML, mas onde essa situao no existe, um passo intermedirio requerido para converter entre o formato requisio/reposta entendido pelo PEP e o contexto XACML entendido pelo PDP. O benefcio dessa abordagem que a poltica pode ser escrita e analisada independente de um ambiente especfico na qual ela ser aplicada. No caso onde o formato nativo requisio/resposta especificado no XML schema, a transformao entre o formato nativo e o contexto XACML pode ser especificado na forma de um XSLT (Extensible Stylesheet Language Transformation). Similarmente, no caso onde o recurso no qual o acesso est sendo requerido ser um documento XML, o recurso em si pode ser includo, ou referenciado, pelo contexto da requisio e atravs das expresses XPath na poltica, os valores no recurso podem ser includos na avaliao da poltica.
4.4.12 Aes
77
Em muitas aplicaes, as polticas especificam aes que devem ser executadas no lugar de ou em adio a aes que podem ser executadas. Essa idia foi descrita por Sloman [Sloman94]. O XACML fornece facilidades para especificar aes que devem ser executas em conjunto com avaliaes da poltica com o elemento <Obligations>. Essa idia foi descrita como uma ao provisria por Kudo [Kudo00]. No h definies padres para esses tipos de aes na verso 2.0 do XACML. Entretanto, so necessrios acordos bilaterais entre o PAP e PEP para reforar a correta interpretao de suas polticas. PEPs que esto de acordo com a verso 2.0 do XACML so necessrios para negar o acesso a menos que entendam e possam satisfazer todos os elementos <Obligations> associados com a poltica aplicada. Os elementos <Obligations> so retornados para o PEP.
4.4.13 Modelos (no-normativo)

Os modelos de fluxo de dados e de linguagem do XACML so descritos nas seguintes subsees.
4.4.13.1 Modelo de fluxo de dados

Os principais atores no domnio do XACML so mostrados no diagrama de fluxo de dados da Figura 6.
Figura 6: Diagrama de Fluxo de Dados.
78
Nota: Alguns fluxos de dados mostrados no diagrama podem ser facilitados por um repositrio. Por exemplo, as comunicaes entre o manipulador de contexto e o PIP ou a comunicao entre o PDP e o PAP podem ser facilitadas pelo repositrio. A especificao do XACML no pretende colocar restries sobre a localizao de tais repositrios ou de prescrever um protocolo de comunicao particular para qualquer fluxo de dados. O modelo opera da seguinte maneira: 1. Os PAPs escrevem polticas e conjuntos de politica e as deixam disponveis para o PDP. Essas polticas ou conjuntos de poltica representam a poltica completa para um alvo especifico. 2. O requisitor de acesso envia uma requisio de acesso para o PEP. 3. O PEP envia a requisio de acesso para o manipulador de contexto no seu formato nativo de requisio, incluindo, opcionalmente, atributos dos subjects, recurso, ao e ambiente. 4. O manipulador de contexto constri um contexto de requisio XACML e o envia para o PDP. 5. O PDP requisita qualquer atributo adicional do subject, recurso, ao e ambiente para o manipulador de contexto. 6. O manipulador de contexto requisite os atributos de um PIP. 7. O PIP obtm os atributos requisitados. 8. O PIP retorna os atributos requisitados para o manipulador de contexto. 9. Opcionalmente, o manipulador de contexto inclui o recurso no contexto. 10. O manipulador de contexto envia os atributos requisitados e (opcionalmente) o recurso para o PDP. O PDP avalia a poltica. 11. O PDP retorna o contexto de resposta (incluindo a deciso de autorizao) para o manipulador de contexto. 12. O manipulador de contexto traduz o contexto de resposta para a forma nativa de resposta do PEP e retorna a resposta para o PEP. 13. O PEP cumpre as obrigaes. 14. (No mostrado) Se o acesso permitido, o PEP permite o acesso ao recurso, caso contrrio ele nega o acesso.
4.4.13.2 Contexto XACML
79
O XACML foi desenvolvido para ser suportado em vrios ambientes de aplicao. O ncleo da linguagem separado do ambiente da aplicao pelo contexto XACML, como mostrado na Figura 7 na qual o escopo da especificao XACML indicado pela rea sombreada. O contexto do XACML definido no XML schema, descrevendo uma representao cannica para as entradas e sadas dos atributos do PDP referenciados por uma instancia da poltica do XACML pode estar presente na forma de expresses XPath sobre o contexto ou designadores de atributos que identificam o atributo pelo subject, recurso, ao ou ambiente e seu identificador, tipo de dados e (opcionalmente) seu remetente. As implementaes devem converter as representaes dos atributos no ambiente da aplicao (ex. SAML, J2SE, CORBA, etc) para a representao de atributos do contexto XACML. Como isso alcanado no faz parte do escopo da especificao do XACML. Em alguns casos, como o do SAML, a converso pode ser feita de um modo automtico atravs do uso de uma transformao XSLT.
Figura 7: Contexto XACML.
Nota: O PDP no necessrio para operar diretamente sobre a representao da poltica XACML. Ele pode operar diretamente em uma representao alternativa.
4.4.13.3 Modelo de Linguagem da Poltica

O modelo de linguagem da poltica mostrado na Figura 8. Os componentes principais do modelo so:

Regra (Rule); Politica (Policy); e Conjunto de politicas (Policy set). Esses componentes so descritos nas subsees seguintes.
80
Figura 8: Modelo de linguagem da poltica.
4.4.13.3.1 Regra (Rule)

A regra a unidade mais elementar da politica. Ela pode existir isolada apenas com um dos atores principais do domnio XACML. Para poder haver uma troca de regras entre os atores principais, elas devem estar encapsuladas em uma poltica. Uma regra pode ser avaliada com base em seu contedo. Os principais componentes da regra so: um alvo (target); um efeito (effect) e uma condio (condition). Eles so discutidos nas subsees seguintes. Alvo da regra (Rule target) O alvo define o conjunto de:
81
recursos (resources); assuntos (subjects); aes (actions) e ambiente (environment)
na qual a regra deve ser aplicada. Atravs do elemento <Condition> pode-se ainda refinar a aplicabilidade definida pelo alvo. Se a regra definida para ser aplicada em todas as entidades de um tipo de dado em particular, ento a entidade correspondente omitida do alvo. Um PDP do XACML verifica se o que foi definido no alvo satisfeito pelos atributos dos assuntos, recursos, aes e ambiente no contexto requisitado. As definies de alvo so discretas para que as regras aplicadas sejam identificas eficientemente pelo PDP. O elemento <Target> pode no estar presente em uma regra. Nesse caso o alvo de uma regra herdado do elemento pai ( <Policy> ). Efeito (Effect) O efeito de uma regra indica a conseqncia esperado pelo criador da regra de uma avaliao verdadeira para a regra. Dois valores so permitidos Permit e Deny. Condio (Condition) A condio representa uma expresso booleana que define a aplicabilidade da regra alem do predicado implicado pelo seu alvo. Portanto pode-se estar ausente.
4.4.13.3.2 Poltica (Policy)

Pelo modelo de fluxo de dados nota-se que as regras no so trocadas entre as entidades do sistema. Portanto o PAP combina as regras em uma poltica. Uma poltica compreendida por quatro componentes principais: um alvo (target); um identificador de algoritmo de combinao de regra (rule-combining algorithm-identifier); um conjunto de regras (set of rules); obrigaes (obligations).
As regras esto descritas acima. Os demais componentes esto descritos nas subsees seguintes. Alvo da poltica (Policy target) Um elemento XACML <PolicySet>, <Policy> ou <Rule> contem um elemento <Target> que especifica o conjunto de assuntos, recursos, aes e ambientes nos quais ele se aplica. O <Target> de um elemento <PolicySet> ou <Policy> pode ser declarado pelo escritor da <PolicySet> ou <Policy>,
82
ou pode ser calculado pelos elementos <Target> contidos nos elementos <PolicySet>, <Policy> e <Rule>. Uma entidade do sistema que calcula o elemento <Target> desse modo definido pelo XACML, mas h dois mtodos lgicos que podem ser usados. Em um dos mtodos, o elemento <Target> da <PolicySet> ou <Policy> exterior (o componente exterior) calculado como a unio de todos os elementos <Target> dos elementos <PolicySet>, <Policy> ou <Rule> referenciados (os componentes internos). No outro mtodo, o elemento <Target> do componente exterior calculado como a interseco de todos os elementos <Target> dos componentes interiores. O resultado da avaliao em cada caso ser muito diferente. No primeiro caso o elemento <Target> do componente exterior o faz aplicvel para qualquer requisio de deciso que combine o elemento <Target> a pelo menos um componente interior; no segundo caso, o elemento <Target> do componente exterior o faz aplicvel apenas as requisies de deciso que combine os elementos <Target> de todos os componentes interiores. Note que computar a interseco de um conjunto de elementos <Target> possvel se o modelo de dados alvo relativamente simples. Nos casos onde o <Target> da <Policy> declarado pelo escritor da politica, qualquer elemento <Rule> na <Policy> que possua o mesmo elemento <Target> que o elemento <Policy> pode omitir o elemento <Target>. Tais elementos <Rule> herdam o <Target> da <Policy> na qual esto contidos. Algoritmo de combinao de regras O algoritmo de combinao de regras (rule-combining algorithm) especifica o procedimento no qual os resultados da avaliao dos componentes de regras so combinados para avaliar a politica. ex. O valor de deciso colocado no contexto de resposta pelo PDP o valor da politica, como definido pelo algoritmo de combinao de regras. Uma politica pode ter combinaes de parmetros que afetam a operao do algoritmo de combinao de regras. Obrigaes (Obligations) Obrigaes podem ser adicionadas pelo criador da politica. Quando um PDP avalia uma politica que contem obrigaes, ele retorna algumas dessas obrigaes ao PEP no contexto de resposta.
4.4.13.3.3 Conjunto de Polticas (Policy set)

Um conjunto de polticas compreendida de quatro componentes principais: um alvo (target); um identificador de algoritmo de combinao de polticas (policy-combining algorithm-identifier) um conjunto de polticas (set of policies); e obrigaes (obligations).
83
O alvo e os componentes da politica esto descritos acima. Os outros componentes so descritos nas subsees seguintes. Algoritmo de combinao de Polticas O algoritmo de combinao de polticas especifica o procedimento no qual o resultado da avaliao dos componentes das polticas combinado para avaliar o conjunto de polticas. ex. O valor de deciso colocado no contexto de resposta pelo PDP o resultado da avaliao do conjunto de polticas como definido pelo algoritmo de combinao de polticas. Um conjunto de polticas pode ter combinaes de parmetros que afetam a operao do algoritmo de combinao de polticas. Obrigaes (Obligations) O escritor do conjunto de polticas pode adicionar obrigaes para o conjunto de polticas, alm daquelas contidas nos componentes de politica e de conjunto de polticas. Quando um PDP avalia um conjunto de polticas que possui obrigaes, ele retorna algumas dessas obrigaes para o PEP em seu contexto de resposta.
84
Captulo 5
Uso da biblioteca XmlSec (C )
Utilizamos a biblioteca xmlsec que implementa as especificaes de assinaturas digitais e criptografia de documentos XML. A biblioteca foi escrita na linguagem C.
5.1 A estrutura da biblioteca

Para fornecer a capacidade de usar mquinas de crifragem diferentes, a Biblioteca de Segurana XML dividida em duas partes: centro da biblioteca (xmlsec) e biblioteca de criptografia (xmlsec-openssl, xmlsec-gnutls, xmlsec-nss, etc).
Figura 9: Biblioteca xmlsec.
85
5.2 Assinando e Criptografando Documentos

A biblioteca executa a assinatura ou criptografia processando o xml de entrada ou dados binrios e um modelo que especifica a assinatura ou esqueleto da criptografia: o transforms, algoritmos, o processo de seleo da chave. Um modelo tem a mesma estrutura que o resultado desejado, mas alguns dos nodos esto vazios. A biblioteca obtm a chave para assinatura/criptografia de gerentes de chaves que usam a informao do modelo, fazem as computaes necessrias e pem os resultados no modelo. O contexto da assinatura ou da criptografia controla o processo inteiro e guarda os dados temporrios necessrios.
Figura 10: Assinando e criptografando documentos.
5.2.1 Assinando dados

O tpico processo de assinatura inclui os seguintes passos: - Criar ou carregar um modelo de assinatura e selecionar o nodo inicial, <dsig:Signature/>
/* create signature template for RSA-SHA1 enveloped signature */ signNodecontexto da assinatura xmlSecDsigCtx usando as funes - Criar o = xmlSecTmplSignatureCreate(doc, xmlSecTransformExclC14NId, /* add <dsig:Signature/> node to the doc */ xmlAddChild(xmlDocGetRootElement(doc), signNode);
xmlSecDSigCtxCreate ou xmlSecDSigCtxInitialize
86
dsigCtx = xmlSecDSigCtxCreate(NULL);
- Carregar a chave de assinatura no gerente de chaves ou gerar uma chave de sesso e fix-la no contexto da assinatura (signKey, membro da estrutura xmlSecDSigCtx).
dsigCtx->signKey = xmlSecCryptoAppKeyLoad(key_file, xmlSecKeyDataFormatPem, NULL, NULL, NULL);
- Assinar os dados chamando a funo xmlSecDSigCtxSign

xmlSecDSigCtxSign(dsigCtx, signNode);
- Destruir contexto da assinatura xmlSecDSigCtx usando as funes xmlSecDSigCtxDestroy ou xmlSecDSigCtxFinalize

xmlSecDSigCtxDestroy(dsigCtx);
5.2.2 Criptografando Dados
O tpico processo de criptografia inclui os seguintes passos: Criar ou carregar o modelo de criptografia e selecionar o nodo inicial <enc:EncryptedData />
/* create encryption template to encrypt XML file and replace * its content with encryption result */ encDataNode = xmlSecTmplEncDataCreate(doc, xmlSecTransformDes3CbcId, NULL, xmlSecTypeEncElement, NULL, NULL);
Criar o contexto da criptografia xmlSecEncCtx usando a funo xmlSecEncCtxCreate ou xmlSecEncCtxInitialize
encCtx = xmlSecEncCtxCreate(mngr);
Carregar a chave para criptografia no gerente de chaves ou gerar uma chave de sesso e fix-la no contexto da criptografia (encKey membro da estrutura xmlSecEncCtx)
encCtx->encKey = xmlSecKeyGenerate(xmlSecKeyDataDesId, 192, xmlSecKeyDataTypeSession);
87
o o o
Criptografar os dados chamando uma das seguintes funes: xmlSecEncCtxBinaryEncrypt xmlSecEncCtxXmlEncrypt xmlSecEncCtxUriEncrypt
xmlSecEncCtxXmlEncrypt(encCtx, encDataNode, xmlDocGetRootElement(doc));
Destruir o contexto da criptografia xmlSecEncCtx usando a funo xmlSecEncCtxDestroy ou xmlSecEncCtxFinalize
xmlSecEncCtxDestroy(encCtx);
5.2.3 Verificando e decriptografando documentos

Considerando que o modelo apenas um arquivo XML, este poderia ser criado com antecedncia e poderia ser salvo em um arquivo. Tambm possvel a aplicao criar modelos sem usar as funes da biblioteca xmlsec. Em alguns casos o modelo deve ser inserido nos dados assinados ou criptografados. A verificao da assinatura e dos dados decriptografados no requer um modelo porque toda a informao necessria provida no documento assinado ou criptografado.
Figura 11: Verificando e decriptografando documentos.
88
5.2.4 Verificando um documento assinado
O processo tpico de verificao de uma assinatura inclui os seguintes passos: Carregar chaves, certificado X509 , etc. no gerente de chaves
/* load public key */ dsigCtx->signKey = xmlSecCryptoAppKeyLoad(key_file, xmlSecKeyDataFormatPem, NULL, NULL, NULL);
Criar o contexto da assinatura xmlSecDSigCtx usando a funo xmlSecDSigCtxCreate ou xmlSecDSigCtxInitialize

dsigCtx = xmlSecDSigCtxCreate(NULL);
Selecionar o nodo inicial de verificao <dsig:Signature/> no documento XML assinado

node = xmlSecFindNode(xmlDocGetRootElement(doc), xmlSecNodeSignature, xmlSecDSigNs);
Verificar a assinatura chamando a funo xmlSecDSigCtxVerify

xmlSecDSigCtxVerify(dsigCtx, node);
Checar o valor de retorno e estado da verificao (status membro da estrutura xmlSecDSigCtx)

if(xmlSecDSigCtxVerify(dsigCtx, node) < 0)
Destruir o contexto da assinatura xmlSecDSigCtx usando a funo xmlSecDSigCtxDestroy ou xmlSecDSigCtxFinalize

xmlSecDSigCtxDestroy(dsigCtx);
5.2.5 Decifrando um documento criptografado
O processo tpico de decriptografia inclui os seguintes passos: Carregar chaves, certificado X509 , etc. no gerente de chaves
key = xmlSecCryptoAppKeyLoad(name, xmlSecKeyDataFormatPem, NULL, NULL, NULL);
89
Criar o contexto da criptografia xmlSecEncCtx usando a funo xmlSecEncCtxCreate ou xmlSecEncCtxInitialize

encCtx = xmlSecEncCtxCreate(mngr);
Selecionar o nodo inicial de decriptografia <enc:EncryptedData>

/* find start node */ node = xmlSecFindNode(xmlDocGetRootElement(doc), xmlSecNodeEncryptedData, xmlSecEncNs);
Decriptografar utilizando a funo xmlSecencCtxDecrypt Verificar o valor de retorno

if((xmlSecEncCtxDecrypt(encCtx, node) < 0) || (encCtx->result == NULL))
Destruir o contexto da criptografia xmlSecEncCtx usando a funo xmlSecEncCtxDestroy ou xmlSecEncCtxFinalize

xmlSecEncCtxDestroy(encCtx);
90
Captulo 6
6.1 Concluso
Consideraes Finais
Descrevemos a utilizao de modelos XML para obteno de autenticao, autorizao, no repdio, sigilo e integridade. Percebemos que com o aumento do uso de dados no formato XML, a segurana pode ser inserida dentro dos prprios documentos, e de forma padronizada, para que um documento possa ser entendido por qualquer sistema compatvel, sendo assim intercambivel, ou seja, no necessrio uma anlise prvia da estrutura do documento, j que est conhecida pelo padro XML. Vimos tambm que o XKMS fornece um mecanismo abstraido para utilizar e integrar o PKI (Public Key Infrastructure) em aplicaes, possibilitando o registro e recuperao de informaes relacionadas a chaves pblicas e/ou privadas, facilitando e diminuindo o tempo de desenvolvimento de aplicaes cliente que necessitem de um ou mais servios providos pelo PKI, j que todo processo criptografico ficaria por parte de um servidor XKMS. Por ltimo, analisamos o XACML, que uma tentativa de padronizar uma linguagem para polticas de segurana e decises de acesso e que prov estruturas para manipular mltiplas regras, polticas e conjuntos de polticas e diferentes algoritmos para processar as requisies de forma eficiente. Hoje cada sistema possui seu prprio padro, sendo necessrio a reescrita da regra para o mesmo recurso em cada diferente sistema, sendo necessrio um esforo mltiplo para uma regra j existente. O XACML seria uma soluo, j que todos os sistemas compatveis com o padro, podem utilizar a mesma regra para um determinado recurso.
91
Referncias Bibliogrficas
[STA99] STALLINGS, W. Cryptography and Network Security: Principles and
Practice. 1999.
Rio de Janeiro: Editora Campus, 2002.
[BUR02] BURNETT, S.; PAINE, S. Criptografia e segurana - O guia oficial RSA.
[XML-SIG] D. Eastlake, J. R., D. Solo, M. Bartel, J. Boyer , B. Fox , E. Simon. XMLSignature Syntax and Processing, W3C Recommendation, 12 February 2002. http://www.w3.org/TR/xmldsig-core/ [Kudo00] Kudo M and Hada S, XML document security based on provisional authorization, Proceedings of the Seventh ACM Conference on Computer and Communications Security, Nov 2000, Athens, Greece, pp 87-96. [LDAP-1] RFC2256, A summary of the X500(96) User Schema for use with LDAPv3, Section 5, M Wahl, December 1997 http://www.ietf.org/rfc/rfc2798.txt [LDAP-2] RFC2798, Definition of the inetOrgPerson, M. Smith, April 2000 http://www.ietf.org/rfc/rfc2798.txt [Perritt93] Perritt, H. Knowbots, Permissions Headers and Contract Law, Conference on Technological Strategies for Protecting Intellectual Property in the Networked Multimedia Environment, April 1993. Disponvel em: http://www.ifla.org/documents/infopol/copyright/perh2.txt [RBAC] Role-Based Access Controls, David Ferraiolo and Richard Kuhn, 15th National Computer Security Conference, 1992. Disponvel em: http://csrc.nist.gov/rbac [Sloman94] Sloman, M. Policy Driven Management for Distributed Systems. Journal of Network and Systems Management, Volume 2, part 4. Plenum Press. 1994. [W3C] W3C, World Wide Web Consortium <http://www.w3.org/ > Acesso em 06/2005.
92
Anexos
A-1) Documento XML a ser criptografado
<?xml version="1.0" encoding="UTF-8"?> <Envelope xmlns="urn:envelope"> <Data> Hello, World! </Data> </Envelope>
A-2) Documento XML resultante da criptografia

<?xml version="1.0" encoding="UTF-8"?> <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#" Type="http://www.w3.org/2001/04/xmlenc#Element"> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#"> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsaoaep-mgf1p"/> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <KeyName>rsakey.pem</KeyName> </KeyInfo> <CipherData> <CipherValue>IPiEu9Nv+EsGyvVeXO9nl5iZhhi+uzQH1I3/DTs3+eamBvioyaawRIlv Tql7LYL5 Mi91Qs8ozfW/fWZ8zB8AE2PosaX37SqiuEta68+65/Ed4v1rkGN0Awux8+gJqJmp c2kJhzAoQIAIGAW4nTGP9tl9QUHfwKh2KPA104vezk70ijvF7TrbTmhdfmULAuWK Tbsg8sXAPhGmPh5KckM2Xe387iPh4ue2+2TGdWqwXygVdvIUIbcIMq6F+/mWlcmf Gs5FVI7CTjaLmeyO4ho+FGmicmqH2hEkZW0a2ktDh4BU/MxYF6L7oayrVWDGp2IH dzQAwUT2qJcFjElO8xUz3g==</CipherValue> </CipherData> </EncryptedKey> </KeyInfo> <CipherData> <CipherValue>xrfPSA+BEI+8ca23RN34gtee5lOMx8Cn+ZGWyxitiktdZ1+XREH+57li 63VutCwp s6ifbZgXIBsFdxPpMBUFlyTWAAO+NLooIwGoczXi14z62lHr7Ck6FA==</CipherValue > </CipherData> </EncryptedData>
A-3) Documento XML a ser assinado

<?xml version="1.0" encoding="UTF-8"?> <Envelope xmlns="urn:envelope"> <Data> Hello, World! </Data> </Envelope>
A-4) Documento XML resultante da assinatura
93
<?xml version="1.0" encoding="UTF-8"?> <!-XML Security Library example: Signed XML doc file (sign2 example). --> <Envelope xmlns="urn:envelope"> <Data> Hello, World! </Data> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-excc14n#"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsasha1"/> <Reference> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#envelopedsignature"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>HjY8ilZAIEM2tBbPn5mYO1ieIX4=</DigestValue> </Reference> </SignedInfo> <SignatureValue>SIaj/6KY3C1SmDXU2++Gm31U1xTadFp04WhBgfsJFbxrL+q7GKSKN 9kfQ+UpN9+i D5fWmuavXEHe4Gw6RMaMEkq2URQo7F68+d5J/ajq8/l4n+xE6/reGScVwT6L4dEP XXVJcAi2ZnQ3O7GTNvNGCPibL9mUcyCWBFZ92Uemtc/vJFCQ7ZyKMdMfACgxOwyN T/9971oog241/2doudhonc0I/3mgPYWkZdX6yvr62mEjnG+oUZkhWYJ4ewZJ4hM4 JjbFqZO+OEzDRSbw3DkmuBA/mtlx+3t13SESfEub5hqoMdVmtth/eTb64dsPdl9r 3k1ACVX9f8aHfQQdJOmLFQ==</SignatureValue> <KeyInfo> <KeyName>rsakey.pem</KeyName> </KeyInfo> </Signature></Envelope>
A) Assinando um documento
/** * Assina um documento XML * * * Uso: * sign <xml-doc> <pem-key> * * Examplo: * ./sign sign-doc.xml rsakey.pem > sign-res.xml */ #include <stdlib.h> #include <string.h> #include <assert.h> #include <libxml/tree.h> #include <libxml/xmlmemory.h> #include <libxml/parser.h> #ifndef XMLSEC_NO_XSLT #include <libxslt/xslt.h> #endif /* XMLSEC_NO_XSLT */
94
#include #include #include #include #include
<xmlsec/xmlsec.h> <xmlsec/xmltree.h> <xmlsec/xmldsig.h> <xmlsec/templates.h> <xmlsec/crypto.h>
int sign_file(const char* xml_file, const char* key_file); int main(int argc, char **argv) { assert(argv); if(argc != 3) { fprintf(stderr, "Error: wrong number of arguments.\n"); fprintf(stderr, "Usage: %s <xml-file> <key-file>\n", argv[0]); return(1); } /* Init libxml and libxslt libraries */ xmlInitParser(); LIBXML_TEST_VERSION xmlLoadExtDtdDefaultValue = XML_DETECT_IDS | XML_COMPLETE_ATTRS; xmlSubstituteEntitiesDefault(1); #ifndef XMLSEC_NO_XSLT xmlIndentTreeOutput = 1; #endif /* XMLSEC_NO_XSLT */ /* Init xmlsec library */ if(xmlSecInit() < 0) { fprintf(stderr, "Error: xmlsec initialization failed.\n"); return(-1); } /* Check loaded library version */ if(xmlSecCheckVersion() != 1) { fprintf(stderr, "Error: loaded xmlsec library version is not compatible.\n"); return(-1); } /* Load default crypto engine if we are supporting dynamic * loading for xmlsec-crypto libraries. Use the crypto library * name ("openssl", "nss", etc.) to load corresponding * xmlsec-crypto library. */ #ifdef XMLSEC_CRYPTO_DYNAMIC_LOADING if(xmlSecCryptoDLLoadLibrary(BAD_CAST XMLSEC_CRYPTO) < 0) { fprintf(stderr, "Error: unable to load default xmlsec-crypto library. Make sure\n" "that you have it installed and check shared libraries path\n" "(LD_LIBRARY_PATH) envornment variable.\n"); return(-1); } #endif /* XMLSEC_CRYPTO_DYNAMIC_LOADING */ /* Init crypto library */ if(xmlSecCryptoAppInit(NULL) < 0) { fprintf(stderr, "Error: crypto initialization failed.\n");
95
return(-1); } /* Init xmlsec-crypto library */ if(xmlSecCryptoInit() < 0) { fprintf(stderr, "Error: xmlsec-crypto initialization failed.\n"); return(-1); } if(sign_file(argv[1], argv[2]) < 0) { return(-1); } /* Shutdown xmlsec-crypto library */ xmlSecCryptoShutdown(); /* Shutdown crypto library */ xmlSecCryptoAppShutdown(); /* Shutdown xmlsec library */ xmlSecShutdown(); /* Shutdown libxslt/libxml */ #ifndef XMLSEC_NO_XSLT xsltCleanupGlobals(); #endif /* XMLSEC_NO_XSLT */ xmlCleanupParser(); return(0); } /** * sign_file: * @xml_file: the XML file name. * @key_file: the PEM private key file name. * * Signs the #xml_file using private key from #key_file and dynamicaly * created enveloped signature template. * * Returns 0 on success or a negative value if an error occurs. */ int sign_file(const char* xml_file, const char* key_file) { xmlDocPtr doc = NULL; xmlNodePtr signNode = NULL; xmlNodePtr refNode = NULL; xmlNodePtr keyInfoNode = NULL; xmlSecDSigCtxPtr dsigCtx = NULL; int res = -1; assert(xml_file); assert(key_file); /* load doc file */ doc = xmlParseFile(xml_file); if ((doc == NULL) || (xmlDocGetRootElement(doc) == NULL)){ fprintf(stderr, "Error: unable to parse file \"%s\"\n", xml_file); goto done;
96
} /* create signature template for RSA-SHA1 enveloped signature */ signNode = xmlSecTmplSignatureCreate(doc, xmlSecTransformExclC14NId, xmlSecTransformRsaSha1Id, NULL); if(signNode == NULL) { fprintf(stderr, "Error: failed to create signature template\n"); goto done; } /* add <dsig:Signature/> node to the doc */ xmlAddChild(xmlDocGetRootElement(doc), signNode); /* add reference */ refNode = xmlSecTmplSignatureAddReference(signNode, xmlSecTransformSha1Id, NULL, NULL, NULL); if(refNode == NULL) { fprintf(stderr, "Error: failed to add reference to signature template\n"); goto done; } /* add enveloped transform */ if(xmlSecTmplReferenceAddTransform(refNode, xmlSecTransformEnvelopedId) == NULL) { fprintf(stderr, "Error: failed to add enveloped transform to reference\n"); goto done; } /* add <dsig:KeyInfo/> and <dsig:KeyName/> nodes to put key name in the signed document */ keyInfoNode = xmlSecTmplSignatureEnsureKeyInfo(signNode, NULL); if(keyInfoNode == NULL) { fprintf(stderr, "Error: failed to add key info\n"); goto done; } if(xmlSecTmplKeyInfoAddKeyName(keyInfoNode, NULL) == NULL) { fprintf(stderr, "Error: failed to add key name\n"); goto done; } /* create signature context, we don't need keys manager in this example */ dsigCtx = xmlSecDSigCtxCreate(NULL); if(dsigCtx == NULL) { fprintf(stderr,"Error: failed to create signature context\n"); goto done; } /* load private key, assuming that there is not password */ dsigCtx->signKey = xmlSecCryptoAppKeyLoad(key_file, xmlSecKeyDataFormatPem, NULL, NULL, NULL); if(dsigCtx->signKey == NULL) {
97
fprintf(stderr,"Error: failed to load private pem key from \"%s\"\n", key_file); goto done; } /* set key name to the file name, this is just an example! */ if(xmlSecKeySetName(dsigCtx->signKey, key_file) < 0) { fprintf(stderr,"Error: failed to set key name for key from \"%s\"\n", key_file); goto done; } /* sign the template */ if(xmlSecDSigCtxSign(dsigCtx, signNode) < 0) { fprintf(stderr,"Error: signature failed\n"); goto done; } /* print signed document to stdout */ xmlDocDump(stdout, doc); /* success */ res = 0; done: /* cleanup */ if(dsigCtx != NULL) { xmlSecDSigCtxDestroy(dsigCtx); } if(doc != NULL) { xmlFreeDoc(doc); } return(res); }
B) Criptografando um documento
/** * Criptografa um documento XML com uma chave de sesso DES * * Uso: * ./encrypt <xml-doc> <rsa-pem-key-file> * * Examplo: * ./encrypt encrypt-doc.xml rsakey.pem > encrypt-res.xml * */ #include <stdlib.h> #include <string.h> #include <assert.h> #include <libxml/tree.h> #include <libxml/xmlmemory.h> #include <libxml/parser.h> #ifndef XMLSEC_NO_XSLT #include <libxslt/xslt.h> #endif /* XMLSEC_NO_XSLT */ #include <xmlsec/xmlsec.h>
98
#include #include #include #include
<xmlsec/xmltree.h> <xmlsec/xmlenc.h> <xmlsec/templates.h> <xmlsec/crypto.h>
xmlSecKeysMngrPtr load_rsa_keys(char* key_file); int encrypt_file(xmlSecKeysMngrPtr mngr, const char* xml_file, const char* key_name); int main(int argc, char **argv) { xmlSecKeysMngrPtr mngr; assert(argv); if(argc != 3) { fprintf(stderr, "Error: wrong number of arguments.\n"); fprintf(stderr, "Usage: %s <xml-file> <key-file>\n", argv[0]); return(1); } /* Init libxml and libxslt libraries */ xmlInitParser(); LIBXML_TEST_VERSION xmlLoadExtDtdDefaultValue = XML_DETECT_IDS | XML_COMPLETE_ATTRS; xmlSubstituteEntitiesDefault(1); #ifndef XMLSEC_NO_XSLT xmlIndentTreeOutput = 1; #endif /* XMLSEC_NO_XSLT */ /* Init xmlsec library */ if(xmlSecInit() < 0) { fprintf(stderr, "Error: xmlsec initialization failed.\n"); return(-1); } /* Check loaded library version */ if(xmlSecCheckVersion() != 1) { fprintf(stderr, "Error: loaded xmlsec library version is not compatible.\n"); return(-1); } /* Load default crypto engine if we are supporting dynamic * loading for xmlsec-crypto libraries. Use the crypto library * name ("openssl", "nss", etc.) to load corresponding * xmlsec-crypto library. */ #ifdef XMLSEC_CRYPTO_DYNAMIC_LOADING if(xmlSecCryptoDLLoadLibrary(BAD_CAST XMLSEC_CRYPTO) < 0) { fprintf(stderr, "Error: unable to load default xmlsec-crypto library. Make sure\n" "that you have it installed and check shared libraries path\n" "(LD_LIBRARY_PATH) envornment variable.\n"); return(-1); } #endif /* XMLSEC_CRYPTO_DYNAMIC_LOADING */ /* Init crypto library */
99
if(xmlSecCryptoAppInit(NULL) < 0) { fprintf(stderr, "Error: crypto initialization failed.\n"); return(-1); } /* Init xmlsec-crypto library */ if(xmlSecCryptoInit() < 0) { fprintf(stderr, "Error: xmlsec-crypto initialization failed.\n"); return(-1); } /* create keys manager and load keys */ mngr = load_rsa_keys(argv[2]); if(mngr == NULL) { return(-1); } /* we use key filename as key name here */ if(encrypt_file(mngr, argv[1], argv[2]) < 0) { xmlSecKeysMngrDestroy(mngr); return(-1); } /* destroy keys manager */ xmlSecKeysMngrDestroy(mngr); /* Shutdown xmlsec-crypto library */ xmlSecCryptoShutdown(); /* Shutdown crypto library */ xmlSecCryptoAppShutdown(); /* Shutdown xmlsec library */ xmlSecShutdown(); /* Shutdown libxslt/libxml */ #ifndef XMLSEC_NO_XSLT xsltCleanupGlobals(); #endif /* XMLSEC_NO_XSLT */ xmlCleanupParser(); return(0); } /** * load_rsa_keys: * @key_file: the key filename. * * Creates simple keys manager and load RSA key from #key_file in it. * The caller is responsible for destroing returned keys manager using * @xmlSecKeysMngrDestroy. * * Returns the pointer to newly created keys manager or NULL if an error * occurs. */ xmlSecKeysMngrPtr load_rsa_keys(char* key_file) { xmlSecKeysMngrPtr mngr;
100
xmlSecKeyPtr key; assert(key_file); /* create and initialize keys manager, we use a simple list based * keys manager, implement your own xmlSecKeysStore klass if you need * something more sophisticated */ mngr = xmlSecKeysMngrCreate(); if(mngr == NULL) { fprintf(stderr, "Error: failed to create keys manager.\n"); return(NULL); } if(xmlSecCryptoAppDefaultKeysMngrInit(mngr) < 0) { fprintf(stderr, "Error: failed to initialize keys manager.\n"); xmlSecKeysMngrDestroy(mngr); return(NULL); } /* load private RSA key */ key = xmlSecCryptoAppKeyLoad(key_file, xmlSecKeyDataFormatPem, NULL, NULL, NULL); if(key == NULL) { fprintf(stderr,"Error: failed to load rsa key from file \"%s\"\n", key_file); xmlSecKeysMngrDestroy(mngr); return(NULL); } /* set key name to the file name, this is just an example! */ if(xmlSecKeySetName(key, BAD_CAST key_file) < 0) { fprintf(stderr,"Error: failed to set key name for key from \"%s\"\n", key_file); xmlSecKeyDestroy(key); xmlSecKeysMngrDestroy(mngr); return(NULL); } /* add key to keys manager, from now on keys manager is responsible * for destroying key */ if(xmlSecCryptoAppDefaultKeysMngrAdoptKey(mngr, key) < 0) { fprintf(stderr,"Error: failed to add key from \"%s\" to keys manager\n", key_file); xmlSecKeyDestroy(key); xmlSecKeysMngrDestroy(mngr); return(NULL); } return(mngr); } /** * encrypt_file: * @mngr: * @xml_file: * @key_name: *
the pointer to keys manager. the encryption template file name. the RSA key name.
101
* Encrypts #xml_file using a dynamicaly created template, a session DES key * and an RSA key from keys manager. * * Returns 0 on success or a negative value if an error occurs. */ int encrypt_file(xmlSecKeysMngrPtr mngr, const char* xml_file, const char* key_name) { xmlDocPtr doc = NULL; xmlNodePtr encDataNode = NULL; xmlNodePtr keyInfoNode = NULL; xmlNodePtr encKeyNode = NULL; xmlNodePtr keyInfoNode2 = NULL; xmlSecEncCtxPtr encCtx = NULL; int res = -1; assert(mngr); assert(xml_file); assert(key_name); /* load template */ doc = xmlParseFile(xml_file); if ((doc == NULL) || (xmlDocGetRootElement(doc) == NULL)){ fprintf(stderr, "Error: unable to parse file \"%s\"\n", xml_file); goto done; } /* create encryption template to encrypt XML file and replace * its content with encryption result */ encDataNode = xmlSecTmplEncDataCreate(doc, xmlSecTransformDes3CbcId, NULL, xmlSecTypeEncElement, NULL, NULL); if(encDataNode == NULL) { fprintf(stderr, "Error: failed to create encryption template\n"); goto done; } /* we want to put encrypted data in the <enc:CipherValue/> node */ if(xmlSecTmplEncDataEnsureCipherValue(encDataNode) == NULL) { fprintf(stderr, "Error: failed to add CipherValue node\n"); goto done; } /* add <dsig:KeyInfo/> */ keyInfoNode = xmlSecTmplEncDataEnsureKeyInfo(encDataNode, NULL); if(keyInfoNode == NULL) { fprintf(stderr, "Error: failed to add key info\n"); goto done; } /* add <enc:EncryptedKey/> to store the encrypted session key */ encKeyNode = xmlSecTmplKeyInfoAddEncryptedKey(keyInfoNode, xmlSecTransformRsaPkcs1Id, NULL, NULL, NULL); if(encKeyNode == NULL) { fprintf(stderr, "Error: failed to add key info\n");
102
goto done; } /* we want to put encrypted key in the <enc:CipherValue/> node */ if(xmlSecTmplEncDataEnsureCipherValue(encKeyNode) == NULL) { fprintf(stderr, "Error: failed to add CipherValue node\n"); goto done; } /* add <dsig:KeyInfo/> and <dsig:KeyName/> nodes to <enc:EncryptedKey/> */ keyInfoNode2 = xmlSecTmplEncDataEnsureKeyInfo(encKeyNode, NULL); if(keyInfoNode2 == NULL) { fprintf(stderr, "Error: failed to add key info\n"); goto done; } /* set key name so we can lookup key when needed */ if(xmlSecTmplKeyInfoAddKeyName(keyInfoNode2, key_name) == NULL) { fprintf(stderr, "Error: failed to add key name\n"); goto done; } /* create encryption context */ encCtx = xmlSecEncCtxCreate(mngr); if(encCtx == NULL) { fprintf(stderr,"Error: failed to create encryption context\n"); goto done; } /* generate a Triple DES key */ encCtx->encKey = xmlSecKeyGenerate(xmlSecKeyDataDesId, 192, xmlSecKeyDataTypeSession); if(encCtx->encKey == NULL) { fprintf(stderr,"Error: failed to generate session des key\n"); goto done; } /* encrypt the data */ if(xmlSecEncCtxXmlEncrypt(encCtx, encDataNode, xmlDocGetRootElement(doc)) < 0) { fprintf(stderr,"Error: encryption failed\n"); goto done; } /* we template is inserted in the doc */ encDataNode = NULL; /* print encrypted data with document to stdout */ xmlDocDump(stdout, doc); /* success */ res = 0; done: /* cleanup */ if(encCtx != NULL) { xmlSecEncCtxDestroy(encCtx);
103
} if(encDataNode != NULL) { xmlFreeNode(encDataNode); } if(doc != NULL) { xmlFreeDoc(doc); } return(res); }
C) Verificando um documento
/** * Verifica validade da assinatura * * Uso: * ./verify sign-res.xml rsapub.pem * * Retorna 0 caso sucesso */ int verify_file(const char* xml_file, const char* key_file) { xmlDocPtr doc = NULL; xmlNodePtr node = NULL; xmlSecDSigCtxPtr dsigCtx = NULL; int res = -1; assert(xml_file); assert(key_file); /* load file */ doc = xmlParseFile(xml_file); if ((doc == NULL) || (xmlDocGetRootElement(doc) == NULL)){ fprintf(stderr, "Error: unable to parse file \"%s\"\n", xml_file); goto done; } /* find start node */ node = xmlSecFindNode(xmlDocGetRootElement(doc), xmlSecNodeSignature, xmlSecDSigNs); if(node == NULL) { fprintf(stderr, "Error: start node not found in \"%s\"\n", xml_file); goto done; } /* create signature context, we don't need keys manager in this example */ dsigCtx = xmlSecDSigCtxCreate(NULL); if(dsigCtx == NULL) { fprintf(stderr,"Error: failed to create signature context\n"); goto done; } /* load public key */
104
dsigCtx->signKey = xmlSecCryptoAppKeyLoad(key_file,xmlSecKeyDataFormatPem, NULL, NULL, NULL); if(dsigCtx->signKey == NULL) { fprintf(stderr,"Error: failed to load public pem key from \"%s\"\n", key_file); goto done; } /* set key name to the file name, this is just an example! */ if(xmlSecKeySetName(dsigCtx->signKey, key_file) < 0) { fprintf(stderr,"Error: failed to set key name for key from \"%s\"\n", key_file); goto done; } /* Verify signature */ if(xmlSecDSigCtxVerify(dsigCtx, node) < 0) { fprintf(stderr,"Error: signature verify\n"); goto done; } /* print verification result to stdout */ if(dsigCtx->status == xmlSecDSigStatusSucceeded) { fprintf(stdout, "Signature is OK\n"); } else { fprintf(stdout, "Signature is INVALID\n"); } /* success */ res = 0; done: /* cleanup */ if(dsigCtx != NULL) { xmlSecDSigCtxDestroy(dsigCtx); } if(doc != NULL) { xmlFreeDoc(doc); } return(res); }
D) Decriptografando um documento
/* Decriptografa um documento XML * * Uso: * ./decrypt <xml-enc> * * Examplo: * ./decrypt encrypt-res.xml * */ #include <stdlib.h> #include <string.h> #include <ctype.h> #include <assert.h>
105
#include <libxml/tree.h> #include <libxml/xmlmemory.h> #include <libxml/parser.h> #ifndef XMLSEC_NO_XSLT #include <libxslt/xslt.h> #endif /* XMLSEC_NO_XSLT */ #include #include #include #include <xmlsec/xmlsec.h> <xmlsec/xmltree.h> <xmlsec/xmlenc.h> <xmlsec/crypto.h>
xmlSecKeyStoreId files_keys_store_get_klass(void); xmlSecKeysMngrPtr create_files_keys_mngr(void); int decrypt_file(xmlSecKeysMngrPtr mngr, const char* enc_file); int main(int argc, char **argv) { xmlSecKeysMngrPtr mngr; assert(argv); if(argc != 2) { fprintf(stderr, "Error: wrong number of arguments.\n"); fprintf(stderr, "Usage: %s <enc-file>\n", argv[0]); return(1); } /* Init libxml and libxslt libraries */ xmlInitParser(); LIBXML_TEST_VERSION xmlLoadExtDtdDefaultValue = XML_DETECT_IDS | XML_COMPLETE_ATTRS; xmlSubstituteEntitiesDefault(1); #ifndef XMLSEC_NO_XSLT xmlIndentTreeOutput = 1; #endif /* XMLSEC_NO_XSLT */ /* Init xmlsec library */ if(xmlSecInit() < 0) { fprintf(stderr, "Error: xmlsec initialization failed.\n"); return(-1); } /* Check loaded library version */ if(xmlSecCheckVersion() != 1) { fprintf(stderr, "Error: loaded xmlsec library version is not compatible.\n"); return(-1); } /* Load default crypto engine if we are supporting dynamic * loading for xmlsec-crypto libraries. Use the crypto library * name ("openssl", "nss", etc.) to load corresponding * xmlsec-crypto library. */ #ifdef XMLSEC_CRYPTO_DYNAMIC_LOADING if(xmlSecCryptoDLLoadLibrary(BAD_CAST XMLSEC_CRYPTO) < 0) { fprintf(stderr, "Error: unable to load default xmlsec-crypto library. Make sure\n"
106
"that you have it installed and check shared libraries path\n" "(LD_LIBRARY_PATH) envornment variable.\n"); return(-1); } #endif /* XMLSEC_CRYPTO_DYNAMIC_LOADING */ /* Init crypto library */ if(xmlSecCryptoAppInit(NULL) < 0) { fprintf(stderr, "Error: crypto initialization failed.\n"); return(-1); } /* Init xmlsec-crypto library */ if(xmlSecCryptoInit() < 0) { fprintf(stderr, "Error: xmlsec-crypto initialization failed.\n"); return(-1); } /* create keys manager and load keys */ mngr = create_files_keys_mngr(); if(mngr == NULL) { return(-1); } if(decrypt_file(mngr, argv[1]) < 0) { xmlSecKeysMngrDestroy(mngr); return(-1); } /* destroy keys manager */ xmlSecKeysMngrDestroy(mngr); /* Shutdown xmlsec-crypto library */ xmlSecCryptoShutdown(); /* Shutdown crypto library */ xmlSecCryptoAppShutdown(); /* Shutdown xmlsec library */ xmlSecShutdown(); /* Shutdown libxslt/libxml */ #ifndef XMLSEC_NO_XSLT xsltCleanupGlobals(); #endif /* XMLSEC_NO_XSLT */ xmlCleanupParser(); return(0); } /** * decrypt_file: * @mngr: the pointer to keys manager. * @enc_file: the encrypted XML file name. * * Decrypts the XML file #enc_file using DES key from #key_file and * prints results to stdout. * * Returns 0 on success or a negative value if an error occurs.
107
*/ int decrypt_file(xmlSecKeysMngrPtr mngr, const char* enc_file) { xmlDocPtr doc = NULL; xmlNodePtr node = NULL; xmlSecEncCtxPtr encCtx = NULL; int res = -1; assert(mngr); assert(enc_file); /* load template */ doc = xmlParseFile(enc_file); if ((doc == NULL) || (xmlDocGetRootElement(doc) == NULL)){ fprintf(stderr, "Error: unable to parse file \"%s\"\n", enc_file); goto done; } /* find start node */ node = xmlSecFindNode(xmlDocGetRootElement(doc), xmlSecNodeEncryptedData, xmlSecEncNs); if(node == NULL) { fprintf(stderr, "Error: start node not found in \"%s\"\n", enc_file); goto done; } /* create encryption context */ encCtx = xmlSecEncCtxCreate(mngr); if(encCtx == NULL) { fprintf(stderr,"Error: failed to create encryption context\n"); goto done; } /* decrypt the data */ if((xmlSecEncCtxDecrypt(encCtx, node) < 0) || (encCtx->result == NULL)) { fprintf(stderr,"Error: decryption failed\n"); goto done; } /* print decrypted data to stdout */ if(encCtx->resultReplaced != 0) { fprintf(stdout, "Decrypted XML data:\n"); xmlDocDump(stdout, doc); } else { fprintf(stdout, "Decrypted binary data (%d bytes):\n", xmlSecBufferGetSize(encCtx->result)); if(xmlSecBufferGetData(encCtx->result) != NULL) { fwrite(xmlSecBufferGetData(encCtx->result), 1, xmlSecBufferGetSize(encCtx->result), stdout); } } fprintf(stdout, "\n"); /* success */ res = 0;
108
done: /* cleanup */ if(encCtx != NULL) { xmlSecEncCtxDestroy(encCtx); } if(doc != NULL) { xmlFreeDoc(doc); } return(res); } /** * create_files_keys_mngr: * * Creates a files based keys manager: we assume that key name is * the key file name, * * Returns pointer to newly created keys manager or NULL if an error occurs. */ xmlSecKeysMngrPtr create_files_keys_mngr(void) { xmlSecKeyStorePtr keysStore; xmlSecKeysMngrPtr mngr; /* create files based keys store */ keysStore = xmlSecKeyStoreCreate(files_keys_store_get_klass()); if(keysStore == NULL) { fprintf(stderr, "Error: failed to create keys store.\n"); return(NULL); } /* create keys manager */ mngr = xmlSecKeysMngrCreate(); if(mngr == NULL) { fprintf(stderr, "Error: failed to create keys manager.\n"); xmlSecKeyStoreDestroy(keysStore); return(NULL); } /* add store to keys manager, from now on keys manager destroys the store if needed */ if(xmlSecKeysMngrAdoptKeysStore(mngr, keysStore) < 0) { fprintf(stderr, "Error: failed to add keys store to keys manager.\n"); xmlSecKeyStoreDestroy(keysStore); xmlSecKeysMngrDestroy(mngr); return(NULL); } /* initialize crypto library specific data in keys manager */ if(xmlSecCryptoKeysMngrInit(mngr) < 0) { fprintf(stderr, "Error: failed to initialize crypto data in keys manager.\n"); xmlSecKeysMngrDestroy(mngr); return(NULL); } /* set the get key callback */
109
mngr->getKey = xmlSecKeysMngrGetKey; return(mngr); } /******************************************************************** ******** * * Files Keys Store: we assume that key's name (content of the * <dsig:KeyName/> element is a name of the file with a key (in the * current folder). * Attention: this probably not a good solution for high traffic systems. * ********************************************************************* ******/ static xmlSecKeyPtr files_keys_store_find_key (xmlSecKeyStorePtr store, const xmlChar* name, xmlSecKeyInfoCtxPtr keyInfoCtx); static xmlSecKeyStoreKlass files_keys_store_klass = { sizeof(xmlSecKeyStoreKlass), sizeof(xmlSecKeyStore), BAD_CAST "files-based-keys-store", /* const xmlChar* name; */ NULL, /* xmlSecKeyStoreInitializeMethod initialize; */ NULL, /* xmlSecKeyStoreFinalizeMethod finalize; */ files_keys_store_find_key, /* xmlSecKeyStoreFindKeyMethod findKey; */ /* reserved for the future */ NULL, NULL, }; /** * files_keys_store_get_klass: * * The files based keys store klass: we assume that key name is the * key file name, * * Returns files based keys store klass. */ xmlSecKeyStoreId files_keys_store_get_klass(void) { return(&files_keys_store_klass); } /** * files_keys_store_find_key: * @store: the pointer to simple keys store. * @name: the desired key name. * @keyInfoCtx: the pointer to <dsig:KeyInfo/> node processing context. * * Lookups key in the @store. The caller is responsible for destroying * returned key with #xmlSecKeyDestroy function. /* void* reserved0; */ /* void* reserved1; */
110
* * Returns pointer to key or NULL if key not found or an error occurs. */ static xmlSecKeyPtr files_keys_store_find_key(xmlSecKeyStorePtr store, const xmlChar* name, xmlSecKeyInfoCtxPtr keyInfoCtx) { xmlSecKeyPtr key; const xmlChar* p; assert(store); assert(keyInfoCtx); /* it's possible to do not have the key name or desired key type * but we could do nothing in this case */ if((name == NULL) || (keyInfoCtx->keyReq.keyId == xmlSecKeyDataIdUnknown)){ return(NULL); } /* we don't want to open files in a folder other than "current"; * to prevent it limit the characters in the key name to alpha/digit, * '.', '-' or '_'. */ for(p = name; (*p) != '\0'; ++p) { if(!isalnum((*p)) && ((*p) != '.') && ((*p) != '-') && ((*p) != '_')) { return(NULL); } } if((keyInfoCtx->keyReq.keyId == xmlSecKeyDataDsaId) || (keyInfoCtx->keyReq.keyId == xmlSecKeyDataRsaId)) { /* load key from a pem file, if key is not found then it's an error (is it?) */ key = xmlSecCryptoAppKeyLoad(name, xmlSecKeyDataFormatPem, NULL, NULL, NULL); if(key == NULL) { fprintf(stderr,"Error: failed to load public pem key from \"%s\"\n", name); return(NULL); } } else { /* otherwise it's a binary key, if key is not found then it's an error (is it?) */ key = xmlSecKeyReadBinaryFile(keyInfoCtx->keyReq.keyId, name); if(key == NULL) { fprintf(stderr,"Error: failed to load key from binary file \"%s\"\n", name); return(NULL); } } /* set key name */ if(xmlSecKeySetName(key, name) < 0) { fprintf(stderr,"Error: failed to set key name for key from \"%s\"\n", name); xmlSecKeyDestroy(key); return(NULL);
111
} return(key); }
112

Padroes de Segurança Aplicados A Linguagem XML

Enviado por

Direitos autorais:

Formatos disponíveis

Padroes de Segurança Aplicados A Linguagem XML

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Padroes de Segurança Aplicados A Linguagem XML

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE FEDERAL DE SANTA CATARINA DEPARTAMENTO DE INFORMTICA E ESTATSTICA CURSO DE GRADUAO EM SISTEMAS DE INFORMAO

PROJETO II Sistemas de Informao

Padres de Segurana Aplicados Linguagem XML

PADRES DE SEGURANA APLICADOS LINGUAGEM XML

Luiz Henrique Wiggers Kato Marcos Hideki Watanabe de Moraes

PADRES DE SEGURANA APLICADOS LINGUAGEM XML

Orientador: Prof. Joo Bosco Mangueira Sobral

1.2.1 Objetivo Geral

1.2.2 Objetivo Especfico

1.3 Contexto e Tecnologia

1.3.1 Contexto do trabalho

2.1.1 Fluxo de informaes

2.2.1 Criptografia Simtrica

2.2.2 Criptografia Assimtrica

2.3 Funes de Resumo

2.4 Assinatura Digital

2.5 Certificados Digitais

2.5.2 Revogando um certificado digital

3.3 XML e HTML

3.4 XML e SGML

3.5 Objetivos do desenvolvimento do XML

3.6.1 Documentos bem-formados

3.6.2 Documentos Vlidos

3.7 Documento XML

3.7.3 Referncias de entidade

3.7.5 Instrues de Processamento

3.7.6 Sees CDATA

3.8 Declaraes de Tipo de documento (Document Type Declarations)

4.1 Assinatura XML

4.1.1 Viso Geral e Exemplos

4.1.1.1 Exemplo Simples (Signature, SignedInfo, Methods, e Reference)

4.1.2 Regras de Processamento

4.1.2.1 Gerao de Referncia

4.1.2.2 Gerao da Assinatura

4.1.3.1 Validao de Reference

4.1.3.2 Validao da Assinatura

4.1.4.1 O Elemento Signature

4.1.4.2 O Elemento SignatureValue

4.1.4.3 O Elemento SignedInfo

4.1.4.4 O Elemento CanonicalizationMethod

4.1.4.5 O Elemento SignatureMethod

4.1.4.6 O Elemento Reference

4.1.4.7 O Elemento Transforms

4.1.4.8 O Elemento DigestMethod

4.1.4.9 O Elemento DigestValue

4.1.4.10 O Elemento KeyInfo

4.1.4.11 O Elemento KeyName

4.1.4.12 O Elemento KeyValue

4.2 XML Encryption

4.2.1 Viso Geral e Exemplos

4.2.2 Granularidade da Criptografia

4.2.3 Criptografando um Elemento XML

<CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> </PaymentInfo>

4.2.3.1 Criptografando um Elemento XML (Elemento)

4.2.3.2 Criptografando de um Elemento XML (Dados)

CreditCard e Number esto a vista, mas o contedo de Number codificado.

4.2.3.3 Criptografando Dados Arbitrrios e Documentos XML

4.2.4 Sintaxe da Criptografia

4.2.4.1 O Elemento EncryptedType