PPT_CD2_Convencoes_Politicas_Formatos_22h30

Introdução à Computação

•
ESAB

Ziul Otrebor
05/02/2024
E aí, curtiu este material?
Ajude a incentivar outros estudantes a melhorar o conteúdo
Gostou desse material? Compartilhe! 🧡
Introdução à Computação

3.075 Materiais compartilhados
Baixe o app para aproveitar ainda mais
Leia os materiais offline, sem usar a internet. Além de vários outros recursos!
Prévia do material em texto
Certisign
Certificação Digital II
Convenções, Políticas e Formatos
Motivação da implantação da Certificação Digital
Hardwares criptográficos
Motivação da implantação 
da Certificação Digital
Carimbo do Tempo
Gerenciamento de identidades
Plataformas operacionais da tecnologia
Autenticação
Certificados SLL
Políticas de assinatura
Políticas de assinatura na ICP-Brasil
Certificado de Atributo
Comparação os aspectos de segurança
Burocracia, morosidade e custos
Adoção da Certificação Digital na sua Organização
Transferir
a credibilidade baseada 
em conhecimento 
e papel para o ambiente 
digital.
Objetivo
Motivação da implantação da Certificação Digital
Motivação da implantação da Certificação Digital
Adoção da Certificação Digital na sua Organização
Adoção da Certificação Digital na sua Organização
Motivação da implantação da Certificação Digital
Hardwares criptográficos
Motivação da implantação 
da Certificação Digital
Carimbo do Tempo
Gerenciamento de identidades
Plataformas operacionais da tecnologia
Autenticação
Certificados SLL
Políticas de assinatura
Políticas de assinatura na ICP-Brasil
Certificado de Atributo
Comparação os aspectos de segurança
Burocracia, morosidade e custos
Comparação 
Dos Aspectos 
De Segurança
Comparação dos aspectos de segurança: papel (1/2)
Comparação dos aspectos de segurança
Documento
Original
Timbre
Autêntico, Íntegro, 
Não pode ser repudiado
Assinatura original
Confidencial
Envelope Lacrado
Comparação dos aspectos de segurança: digital (2/2)
Comparação dos aspectos de segurança
Hardwares criptográficos
Motivação da implantação 
da Certificação Digital
Carimbo do Tempo
Gerenciamento de identidades
Plataformas operacionais da tecnologia
Autenticação
Certificados SLL
Políticas de assinatura
Políticas de assinatura na ICP-Brasil
Certificado de Atributo
Comparação os aspectos de segurança
Burocracia, morosidade e custos
Burocracia, Morosidade e Custos
Rápido e seguro, com validade jurídica. 
Com Certificação Digital 
Burocracia, Morosidade e Custos
Veremos ao longo do curso como a certificação digital pode nos fornecer todas essas vantagens.
10
Documentos eletrônicos são mais seguros, apesar da maior parte da população pensar o contrário devido à falta de informação. 
Desvantagens na utilização de papel:
 Dificuldade de verificar alteração de conteúdo;
 Ocupa muito espaço.
 Dificuldade de localização;
 Não é possível realizar cópias “originais”;
 Risco de sinistros tais como incêndios, enchentes e traças;
Burocracia, Morosidade e Custos
Antigamente era assim
Agora não é mais 
necessário
sair do digital.
Com isso, conseguimos:
 Outros benefícios aliados à TI.
 Agilidade na localização 
 de documentos;
 Menos árvores cortadas;
 Mais espaço físico;
 Possibilidade de backup;
 Validade jurídica;
Burocracia, Morosidade e Custos
Outras vantagens
Além da assinatura de documentos, a certificação digital nos traz outras vantagens, como por exemplo:
 Autenticação forte; 
 Privacidade dos dados;
 Assinaturas de software;
 Emails assinados e criptografados;
 Conexões Seguras;
 Gerenciamento eletrônico de documentos;
Temos um universo de possibilidades.
Burocracia, Morosidade e Custos
Hardwares criptográficos
Motivação da implantação 
da Certificação Digital
Carimbo do Tempo
Plataformas operacionais da tecnologia
Autenticação
Certificados SLL
Políticas de assinatura
Políticas de assinatura na ICP-Brasil
Certificado de Atributo
Comparação os aspectos de segurança
Burocracia, morosidade e custos
Gerenciamento de identidade
Gerenciamento 
de identidades
Gerenciamento de identidades
Todo certificado passa por várias fases, que chamamos de ciclo de vida do certificado.
Solicitação
Validação 
Emissão
Retirada
Utilização
Suspensão
Revogação
Renovação
Término da Validade
O ciclo de vida do certificado digital é constituído das seguintes etapas:
Solicitação: é o pedido da certificação digital, feito por uma pessoa interessada à Autoridade Certificadora;
Validação da Solicitação: é função da AC garantir que o requerimento seja válido e que os dados do requerentes sejam corretos;
Emissão: é o ato de reconhecimento do título do certificado digital pelo requerente e sua emissão;
Retirada: após emitido, o requerente deve retirá-lo da AC e confirmar a validade do certificado emitido;
Utilização: é de total responsabilidade do requerente o uso do certificado;
Suspensão: é o ato pelo qual o certificado se torna temporariamente inválido para operações por algum motivo especificado pela AC,como, o comprometimento da chave pública;
Revogação: é o processo pelo qual o certificado se torna definitivamente inválido pelo comprometimento da chave privada do titular ou quando ocorrer algum fato que torne o certificado digital pouco seguro para uso. Um certificado suspenso ou revogado deve ser publicado na lista de certificados revogados (LCR) e estar sempre disponível para consulta;
Renovação: Antes do termino da validade do certificado, um novo pode ser solicitado. Dependendo da ICP, pode ser utilizado o mesmo par de chaves ou obrigatoriamente é requerido a geração de um novo.
Término da Validade: o certificado digital tem um período preestabelecido de validade atribuído pela AC. Em geral, este período é de um a três anos, dependendo da importância e finalidade da chave.
15
Gerenciamento de identidades
Conhecendo o ciclo de vida e uso, algumas perguntas surgem.
Imaginem uma organização com 100 usuários utilizando certificados digitais:
 Durante quanto tempo os usuários poderão utilizar seus certificados?
 Eles poderão assinar documentos quando seus certificados estiverem 
 suspensos ou revogados?
 E quando os certificados já estiverem expirados? Será possível se autenticar 
 nos sistemas?
 Se alguns usuários deixarem a empresa? Como será feito o controle de revogação?
16
Gerenciamento de identidades
Conhecendo o ciclo de vida e uso, algumas perguntas surgem.
Imaginem uma organização com 100 usuários utilizando certificados digitais:
Para resolver essas questões é necessário que a organização possua um sistema 
para gerir e monitorar a população de certificados digitais de seus usuários.
Hardwares criptográficos
Motivação da implantação 
da Certificação Digital
Carimbo do Tempo
Plataformas operacionais da tecnologia
Autenticação
Certificados SLL
Políticas de assinatura
Políticas de assinatura na ICP-Brasil
Certificado de Atributo
Comparação os aspectos de segurança
Burocracia, morosidade e custos
Gerenciamento de identidade
Plataformas Operacionais 
da Tecnologia
Plataformas Operacionais da Tecnologia
Plataformas operacionais são ambientes computacionais responsáveis 
por execuções de aplicações de hardware e softwares.
A tecnologia de certificação digital pode ser utilizada, em qualquer 
plataforma operacional que entenda os seus padrões.
Windows
Os sistemas operacionais da Microsoft possibilitam a utilização da tecnologia 
da certificação digital, desde as suas versões mais antigas.
A Cryptografic Application Programing Interface (CAPI), também conhecida 
Como MS-CAPI, possibilitou o desenvolvimento de aplicações compatíveis com 
a tecnologia da certificação digital, graças a ela a tecnologia evoluiu.
O sistema operacional Windows possui um repositório de certificados digitais 
que pode ser utilizado pelas aplicações.
Plataformas Operacionais da Tecnologia
Linux
O Linux diferente do Windows não possui um repositório central, mas diversas aplicações nesse ambiente trabalham com certificação digital, utilizando repositórios próprios. Como servidores, browsers e programas de email. Utilizando ferramentas compatíveis com os padrões da tecnologia de certificação digital, como OPENSSL e Java keytool.
Plataformas Operacionais da Tecnologia
Mac OS
O Mac OS possui um repositório central chamado Keychain, que armazena, 
um grupo de informações sigilosas, entre elas certificados e chaves privadas.Que como no Windows, pode ser acessado pelas aplicações.
Plataformas Operacionais da Tecnologia
Tablets e Smartphones
Existem diversas plataformas operacionais que trabalham com tablets 
e smartphones, entre elas:
iOS – que possui um repositório e algumas soluções que entendem a tecnologia;
Android – assim como o iOS também possui soluções e repositório de certificados;
Windows 8 – que funciona como a plataforma Windows já apresentada.
Plataformas Operacionais da Tecnologia
Hardwares cliptográficos
Motivação da implantação 
da Certificação Digital
Carimbo do Tempo
Plataformas operacionais da tecnologia
Autenticação
Certificados SLL
Políticas de assinatura
Políticas de assinatura na ICP-Brasil
Certificado de Atributo
Comparação os aspectos de segurança
Burocracia, morosidade e custos
Gerenciamento de identidade
Hardwares
Criptográficos
Hardwares Criptográficos
Hardware criptográficos são dispositivos que suportam diversos algoritmos, 
esses hardwares fazem operações matemáticas, geram e armazenam 
chaves criptográficas e certificados digitais.
Assim como os softwares, os hardwares também seguem 
os padrões apresentados, como o PKCS#11 e o FIPS-140.
PKCS#11 – Um dos padrões da família PKCS da RSA, que define a API de comunicação de hardwares criptográficos, conhecida como “Cryptoki”
FIPS-140-2 – Padrão do NIST que define os requisitos mínimos de segurança para Hardware Criptográfico. 
25
Hardwares Criptográficos
Baseado nos padrões internacionais o ITI também possui a sua homologação 
que é realizada pelo Laboratório de Ensaios e Auditoria – LEA.
Para estar nos padrões da ICP-Brasil os fabricantes de hardwares e sofwares devem seguir os MCTs – Manuais de condutas técnicas, que podem ser encontrados 
no site do ITI.
OBS: Essa homologação garante que os produtos cumprem os padrões e não que são bons produtos.
Hoje todos hardwares criptográficos que utilizamos na ICP-Brasil devem 
ser homologados pelo ITI.
Homologação ICP-Brasil
Resolução 89 – Existem hardwares que podem ser utilizados e que não estão homologados, que são os que os fabricantes enviaram toda documentação de homologação até o dia 31/12/2011
26
Hardwares Criptográficos
Exemplo de hardwares: Tokens, Cartões e Leitoras
Cartões criptográficos – cartões semelhantes a cartões bancários, com capacidades criptográficas
Leitora – Dispositivo USB para comunicação entre o cartão e o SO
27
Hardwares Criptográficos
Exemplo de hardwares: HSM
HSM – Hardware Security Module, em português modulo de segurança de hardware, é um tipo de processador criptográfico seguro voltado para o gerenciamento de chaves digitais, acelerando os processos de criptografia em operações por segundo e para fornecer autenticação forte para acesso às chaves críticas para aplicativos de servidor. Estes módulos são dispositivos físicos que, tradicionalmente, vêm na forma de uma placa plug-in ou um dispositivo de segurança externa TCP / IP que pode ser conectado diretamente ao servidor ou computador de propósito geral. Geralmente são utilizados pelas ACs, para manter suas chaves privadas.
28
Hardwares criptográficos
Motivação da implantação 
da Certificação Digital
Carimbo do Tempo
Plataformas operacionais da tecnologia
Autenticação
Certificados SLL
Políticas de assinatura
Políticas de assinatura na ICP-Brasil
Certificado de Atributo
Comparação os aspectos de segurança
Burocracia, morosidade e custos
Gerenciamento de identidade
Autenticação
Autenticação
Hoje em dia, a maneira mais comum de autenticação na web é através 
de login e senha. Mas qual a segurança nesse método de autenticação?
 Senhas fracas;
 Força Bruta;
 Segredo compartilhado.
Exibir: http://howsecureismypassword.net/
O uso de login e senha pode trazer alguns riscos, como o uso de senhas fracas, o que pode abrir brechas para ataques de força bruta, que consiste na tentativa de senhas. Um outro problema é que a senha é um segredo compartilhado, ou seja, tanto o cliente quanto o servidor devem conhecer esse segredo para que possam ser comparados um com o outro, isso abre também brechas para que pessoas acessem a informação por exemplo no banco de dados do sistema.
30
Autenticação
Cartão de senhas
OTP
São seguros?
Autenticação
Apesar de serem mais seguros do que o uso de apenas login e senha, o cartão de senhas e o OTP, geralmente utilizados por instituições bancárias, compartilham um problema com as senhas, são baseados em segredo compartilhado, uma vez descoberto esse segredo todo o sistema estará frágil. Recentemente acessaram o sistema da Lockheed Martin, fornecedora de material bélico do governo americano, foi descoberto o segredo do token OTP da RSA Security.
31
Identificações biométricas
E agora são seguros?
Autenticação
Identificações biométricas
Fontes:
http://idgnow.uol.com.br/ti-corporativa/2012/07/31/especialistas-conseguem-enganar-sistema-de-reconhecimento-pela-iris/
Autenticação
Molde feito com gelatina é capaz de burlar 80% dos sistema de biometria, dedos de silicone já foram utilizados para forjar digitais em sistemas, cientistas já reproduziram uma íris por meio de informações em um banco de dados. Apesar de serem dados únicos de cada pessoa, no mundo digital eles não passam de um conjunto de dados binários que podem ser capturados e reproduzidos.
32
Algo que 
você sabe
Algo que 
Você tem
Algo que você é
Autenticação
Estudiosos consideram que Autenticação Forte é o tipo de autenticação que possui dois ou mais fatores de autenticação.
Existem três tipos de fatores para autenticação:
Algo que você sabe – Ex: usuário, senha, PIN;
Algo que você tem – Ex: Chave privada, OTP;
Algo que você é – Ex: Reconhecimento de íris, digital.
Duplo fator ou autenticação forte é utilizar no mínimo dois fatores para autenticação.
33
Autenticação forte: com certificado digital
A autenticação com certificado digital, quando implementada corretamente, 
traz como benefícios:
 Autenticação de duplo fator;
 Não possui segredo compartilhado;
 Possui validade jurídica (ICP-Brasil).
Autenticação
Quando bem implementada a autenticação com certificado digital, nos traz alguns benefícios, como o duplo fator de autenticação, onde alia algo que só o titular do certificado possui, que é a chave privada, que pode estar armazenada em hardware aumentando mais ainda a segurança, e algo que só o titular sabe que é a senha de acesso à essa chave.
Além disso acabamos com risco do segredo compartilhado, pois esse tipo de autenticação se baseia geralmente na assinatura utilizando a chave privada, de um conjunto de dados gerados aleatoriamente pelo sistema, isso garante que a pessoa que está apresentando o certificado é a detentora da chave privada correspondente a este certificado.
Indo um pouco mais longe podemos também armazenar os logs de acesso ao sistema, já que esse acesso é realizado através de uma assinatura, com isso aliado as normas, podemos garantir judicialmente que foi o titular do certificado que realizou aquele acesso.
34
Hardwares criptográficos
Motivação da implantação 
da Certificação Digital
Carimbo do Tempo
Plataformas operacionais da tecnologia
Autenticação
Certificados SLL
Políticas de assinatura
Políticas de assinatura na ICP-Brasil
Certificado de Atributo
Comparação os aspectos de segurança
Burocracia, morosidade e custos
Gerenciamento de identidade
Certificados SSL
Certificados SSL
 Protocolo SSL/TLS
 Secure Sockets Layer (SSL) é um protocolo desenvolvido pela Netscape 
 Communications Corporation para dar garantia à transmissão de dados 
 nas transações comerciais na Internet.
 O Transport Layer Security (TLS) é o sucessor do protocolo SSL, desenvolvido 
 pelo IETF (Internet Engineering Task Force) e definido pelo RFC 5246.
 Os dados que trafegam através destes protocolos são criptografados, garantido 
 a confidencialidade e integridade na comunicação entre cliente e um servidor web.
 Para habilitar este protocolo em um servidor web é necessário possuir um certificado
 digitalcontendo as informações sobre o web site.
Certificados SSL
 Certificados SSL/TLS
Os certificados SSL são classificados pelo tipo de validação que a Autoridade 
Certificadora utiliza para confirmar os dados empresa solicitante.
Certificados para servidores Web, ou simplesmente certificados SSL,
 são certificados para identificar um web site na Internet.
Certificados SSL
Auto-assinados - Certificados gerados pela própria empresa. São de uso 
interno e não possuem interoperabilidade com os navegadores de internet. 
Os tipos de validação são:
Validação de Domínio - A Autoridade Certificadora apenas valida se a empresa 
solicitante do certificado SSL é proprietária do domínio configurado na solicitação 
do certificado. A validação é feita com base nos dados cadastrados na entidade responsáveis pelo registro de domínio.
Validação de Organização – A Autoridade Certificadora valida se a empresa solicitante do certificado SSL é proprietária do domínio configurado na solicitação do certificado, se a entidade é legalmente constituída, e se a pessoa que solicitou o certificado tem poder para efetuar o pedido.
Validação Extendida (Extended Validation-EV) – Novo padrão de validação definido pelo CA/Browser Forum.
 
Certificados SSL
Características do certificado SSL/TLS 
Hash do Certificado
Validade do Certificado
Nome da Empresa
Departamento da empresa
Common Name: (igual à URL do site) (termina 
em nome de domínio pertencente a sua empresa)
Nome da AC que emitiu o Certificado 
Certificados SSL
Certificados SSL/TLS
 Os certificados para servidores Web, ou certificados SSL, são emitidos 
 para certificar um determinado Common Name;
 O Common Name é composto de Host + Domínio;
 Ex: www.certisign.com.br, 
 www é o Host,
 certisign.com.br é o Domínio.
Certificados SSL
• O navegador verifica:
 • A finalidade do certificado;
 • A data de validade do certificado;
 • A Lista de Certificados Revogados (LCR);
 • A hierarquia do certificado;
 • Se o endereço digitado pelo usuário é o mesmo do certificado;
 • Se existem itens não seguros na comunicação. 
 • As extensões do certificado;
 Ao acessar um site que possui um Certificado Digital, o navegador 
 de internet efetua uma série de verificações no certificado. 
Certificados SSL
Sites com certificados não confiáveis 
Mensagem de alerta do Internet Explorer 7 ou superior
Mensagem de alerta do Mozilla Firefox 3.5 ou superior
Certificados SSL
Tipos de certificados SSL/TLS
Certificado SSL para Múltiplos Domínios
	
É um novo certificado SSL desenvolvido principalmente para o uso no Microsoft Exchange 2007 (ou superior), Live Communications Server 2005 (ou superior) e no Microsoft Office Communications Server 2007 (ou superior) que utilizam 
a solução da Microsoft de Comunicações Unificadas (Microsoft Unified Communications).
Uma das características deste certificado é permitir a inclusão, no campo Subject Alternative Name (SAN), vários endereços 
de internet, intranet e IP’s adicionais.
Com este certificado o Microsoft Exchange 2007 (ou superior) e o Microsoft Office Communications Server 2007 (ou superior) conseguem estabelecer conexões seguras (SSL/TLS) com todos os endereços e IP’s que estão no certificado (Campos: Common Name e SAN).
No mercado este certificado também é chamado de:
Certificado Digital SAN SSL;
Unified Communications Certificate;
SANS UCC Certificate;
UC SSL.
Certificados SSL
Certificado SSL para múltiplos domínios
Vantagens:
Adiciona segurança em vários serviços Exchange (OWA, SMTP, Autodiscovery, ActiveSync e Outlook Anywhere) com apenas um certificado.
Simplifica a configuração SSL do seu Exchange Server, Office Communications Server e Live Communications Server, pois não é necessário configurar múltiplos endereços IP.
Oferece suporte em situações em que os certificados tradicionais SSL e “wildcards” não atendem.
Certificado Digital desenvolvido em parceria com a Microsoft.
Certificados SSL
Certificado SSL Wildcard
É um certificado SSL que permite validar vários subdomínios.
Os certificados SSL Wildcard são emitidos para *.seudominio.com.br. 
Com este certificado SSL é possível certificar todos os host de seu domínio.
Pode trazer risco a segurança de sua infraestrutura; pois um único certificado é responsável por toda a comunicação SSL de sua empresa.
Certificados SSL
A Arquitetura EV foi desenhada para oferecer informação confiável em relação 
à identidade do site para clientes, de forma que eles possam tomar as melhores decisões sobre qual site confiar. Além das convenções para esta interface de fácil compreensão, os certificados EV–SSL se baseiam em:
Certificados SSL EV (Extended Validation)
 Modificação no procedimento de autenticação 
 (auditoria sobre a CA que emite este certificado);
 “Real-time certificate checking” (OCSP e verificação da CA na 
 Microsoft Root Store para garantir que a CA Raiz possa 
 emitir certificados EV-SSL).
Certificados SSL
Benefícios
Processo de validação forte:
Legal Opinion Letter (análise jurídica de terceiros)
Checagem da real existência da empresa 
Maior percepção de valor pelo cliente final:
Página 37 do livro
Aumento da confiança = mais transações
Ambiente seguro 
Identificação visual
Certificados SSL EV (Extended Validation)
Certificados SSL
Funcionamento do EV
I.E. 7 – www.minhavotinha.com.br – SSL (erro) 
I.E. 7 – www.submarino.com.br – SSL (comum)
I.E. 7 – www.certisign.com – EV-SSL
Certificados SSL
Autenticação forte de servidor web
Os certificados de servidor são uma garantia real ao cliente que o website 
acessado pertence, sem dúvida, à organização.
 Protege a instituição contra fraudes perpetradas
 através de sites clonados;
 Garante o sigilo e a integridade da comunicação 
 entre o servidor e o navegador Web;
 Gera aumento das vendas - os clientes se sentem 
 mais confortáveis visitando sites certificados. 
Certificados SSL
Benefícios de um certificado SSL/TLS
Certificados SSL
Importância de um certificado SSL
Interoperabilidade
 Para garantir o reconhecimento e acesso ao HTTPS pelos usuários de um site 
 seguro, faz-se necessário que o certificado seja reconhecido pelos navegadores 
 utilizados pelos clientes clientes (Internet Explorer®, Chrome®, Firefox®, Opera® 
 e outros);
 A raiz do certificado da Autoridade 
 Certificadora precisa estar instalada 
 nos navegadores para ser reconhecida...
A Certisign oferece Certificados com interoperabilidade com 99% dos navegadores usados no mercado.
51
Certificados SSL
 Autenticação do negócio
 O rigor da validação impede que terceiros tenham acesso a certificados emitidos
 para sua empresa. No ambiente atual, onde práticas como “phishing” põem em 
 risco a boa fé do consumidor, somente a autenticação do negócio pode aumentar 
 a confiança nos serviços Web;
 É recomendável procurar uma empresa certificada 
 que adote rigorosos processos de validação, 
 auditados por órgãos internacionais competentes 
 para garantir a confiabilidade que seu negócio precisa 
 e merece. 
Importância de um certificado SSL
Certificados SSL
 Autoridade Certificadora
 Uma Autoridade Certificadora não
 é apenas uma emissora de Certificados 
 Digitais. Seu papel na sociedade atual 
 vai muito além: ela proporciona 
 confiança entre as partes que utilizam 
 o meio eletrônico para realizar 
 transações, trocar informações, 
 assinar contratos, etc. 
Certificados SSL
Confiança na marca
 Importância de um Selo do Site Seguro conhecido no mercado;
 Se as empresas querem que seus visitantes entendam que é seguro compartilhar 
 seu número de cartão de crédito, sua conta bancária, endereço ou outras 
 informações confidenciais através do seu site, é preciso mostrar o Selo do Site 
 Seguro na página e ensinar aos usuários sobre a importância de conferir o 
 endereço https:// que aparece no certificado do navegador.
CertificadosSSL
Clique e verifique
 Um site validado por uma Autoridade Certificadora renomada indica que 
 a empresa concluiu satisfatoriamente todos os procedimentos para determinar 
 que o domínio do website é de propriedade ou se encontra registrado por uma 
 empresa ou organização autorizada a negociar ou exercer qualquer outra 
 atividade lícita.
Certificados SSL
Importância de um certificado SSL
Nome do domínio
certificado
Validade do 
certificado de SSL 
do site
Nome da empresa que foi 
certificada para utilizar o 
Certificado Site Seguro
A Certisign é a responsável por 
certificar mais de 80% dos grandes
sites de comércio eletrônico no Brasil
Os sites certificados pela Certisign
Possuem a Identificação do proprietário do site 
E os dados são criptografados com os certificados SSL.
Hardwares criptográficos
Motivação da implantação 
da Certificação Digital
Carimbo do Tempo
Plataformas operacionais da tecnologia
Autenticação
Certificados SLL
Políticas de assinatura
Políticas de assinatura na ICP-Brasil
Certificado de Atributo
Comparação os aspectos de segurança
Burocracia, morosidade e custos
Gerenciamento de identidade
Carimbo do Tempo
Carimbo do Tempo
Carimbo do Tempo
 Uma analogia com o mundo físico é o carimbo com a data e hora que o funcionário 
 dos Correios aplica sobre uma correspondência. Ele comprova que o mesmo chegou 
 aos correios na data da carimbada.
 O que é um Carimbo do Tempo ?
 Carimbo do Tempo é uma das mais eficientes e eficazes soluções para garantir 
 que um conjunto de dados existia em um determinado momento do tempo;
Carimbo do Tempo
Para que serve? 
 Os Certificados Digitais estão sujeitos a eventos de expiração e/ou revogação. 
 E eles são necessários para verificarmos uma assinatura digital decriptografando 
 com a Chave Pública o o que foi criptografado com a Chave Privativa 
 correspondente); 
 Se o Certificado Digital estiver revogado ou expirado, como comprovar que 
 a assinatura ocorreu no momento em que ele era válido?
Carimbo do Tempo
  Como provar, vinte anos após a realização das assinaturas, que os certificados 
 utilizados nas mesmas não estavam revogados e/ou expirados no momento 
 da realização?
 Os Certificados Digitais para entidades finais na ICP-Brasil tem validade máxima
 de seis anos. Existem muitos documentos no Brasil em que as assinaturas devem
 permanecer válidas por mais de seis anos. 
 Ex.: contratos previdenciários privados devem ser armazenados por vinte anos;
Carimbo do Tempo
 Um Carimbo do Tempo aplicado a uma assinatura digital ou a um documento 
 prova que ele já existia na data incluída no Carimbo do Tempo; 
 No Brasil, os Carimbos do Tempo são emitidos por terceiras partes confiáveis, 
 as Autoridades de Carimbo do Tempo (ACTs). Suas operações são devidamente
 documentadas e periodicamente auditadas pela Autoridade Certificadora (AC) 
 Raiz da ICP-Brasil. 
Carimbo do Tempo
Observatório Nacional
http://www.on.br/conteudo/modelo.php?endereco=institucional/institucional.html
A ele compete gerar, conservar, manter e operar um laboratório primário de tempo 
e freqüência e difundir a Hora Legal Brasileira, nos termos da Lei nº 2.784, de 18 de junho de 1913 e legislação posterior. 
Carimbo do Tempo
 A Entidade de Auditoria do Tempo (EAT) é a AC-Raiz da ICP-Brasil, que utiliza 
 Sistemas de Auditoria e Sincronismo (SASs) ligados a um relógio atômico. 
 A partir deles, a EAT realiza as atividades de auditoria e sincronismo dos 
 Servidores de Carimbo do tempo (SCTs) instalados nas ACTs;
 O relógio atômico da Rede de Carimbo de Tempo da ICP-Brasil está ligado 
 ao relógio atômico do Observatório Nacional.
Carimbo do Tempo
Modelo de funcionamento do Carimbo do Tempo da ICP-Brasil
Carimbo do Tempo
 Na estrutura de Carimbo do Tempo da ICP-Brasil, as Autoridades Certificadoras
 emitem os Certificados Digitais usados nos equipamentos das ACTs e da EAT;
 Autoridade de Carimbo do Tempo (ACT) é a entidade na qual os usuários 
 de serviços de Carimbo do Tempo (isto é, os subscritores e as terceiras partes) 
 confiam para emitir Carimbos do Tempo. A ACT tem a responsabilidade 
 geral pelo fornecimento do Carimbo do Tempo. 
Carimbo do Tempo
 Operar um ou mais Servidores de Carimbo do Tempo (SCTs), conectados à Rede
 de Carimbo do Tempo da ICP-Brasil, que gerem carimbos em nome da ACT; 
Além disso, a ACT deve:
 Manter disponível um serviço de páginas web onde é publicado, entre outras 
 informações, sua Declaração de Práticas de Carimbo do Tempo (DPCT) e suas 
 Políticas de Carimbo do Tempo (PCTs); T3 e/ou T4);
 Operar diversos SCTs, sendo que cada um deles deve utilizar um ou mais pares 
 de chaves criptográficas específicas para essa finalidade(Certificados T3 e/ou T4).
Carimbo do Tempo
Sincronização do tempo 
Para manter o sincronismo dos relógios dos equipamentos que compõem 
a Rede de Carimbo de Tempo, a ICP-Brasil utiliza os seguintes recursos: 
 
O Relógio Atômico, ou Fonte Confiável do Tempo (FCT), fornece a hora UTC para o relógio atômico da AC-Raiz; 
3. O SAS da AC-Raiz, por sua vez, dissemina a hora para os equipamentos instalados na ACT e autoriza seu funcionamento por período de tempo pré- estipulado, emitindo-lhe um alvará, cujo período de validade é aquele em que irá ocorrer a próxima verificação de sincronismo e os principais atributos são: ano, mês, dia, hora, minuto, segundo, compensação e retardo. 
2. O Relógio Atômico da AC-Raiz fornece a hora UTC para o equipamento chamado de Sistema de Auditoria e Sincronismo (SAS) da AC-Raiz; 
Carimbo do Tempo
Sincronização do tempo
 Os SASs e SCTs utilizam, para assinatura dos alvarás, Carimbos de Tempo
 e autenticação, Chaves Privadas vinculadas a Certificados Digitais ICP-Brasil, 
 o que garante a autoria desses documentos. 
 A garantia de que todos os equipamentos estejam sincronizados à hora UTC 
 está baseada no fato de que os equipamentos que compõem a Rede de Carimbo
 do Tempo da ICP-Brasil somente receberão os respectivos alvarás se estiverem 
 adequadamente sincronizados; 
Carimbo do Tempo
Há duas formas de solicitar um Carimbo de Tempo na ICP-Brasil:
Obtenção de um Carimbo do Tempo
1. solicitação presencial; e
2. solicitação remota. 
Cabe à ACT definir quais dessas formas estarão disponíveis aos solicitantes. 
Carimbo do Tempo
Obtenção de um Carimbo do Tempo
 O formato das solicitações e respostas de Carimbo do Tempo e os protocolos
 utilizados para o seu transporte devem atender ao disposto na RFC 3161; 
 Os procedimentos detalhados para solicitação e recebimento de Carimbos do 
 Tempo devem constar nas Declarações de Práticas de Carimbo do Tempo da ACT. 
Carimbo do Tempo
Verificação de um Carimbo do Tempo
Tanto o solicitante do Carimbo do Tempo quanto a terceira parte que irá receber 
o documento com esse carimbo devem executar determinadas ações, antes 
de acreditar ou não na validade do carimbo. 
Como regras geral, devem ser verificadas:
 a identidade da ACT e do respectivo SCT;
 a validade dos Certificados Digitais; e
 a política sob a qual o carimbo foi emitido.
Carimbo do Tempo
Verificação de um carimbo do tempo 
 Os procedimentos detalhados para verificação de carimbos de tempo constam nas Declarações de Práticas de Carimbo de Tempo (DPCT) e nas Políticas de Carimbo de tempo (PCT), que devem estar publicadas nos websites de cada ACT. 
Carimbo do Tempo
Identificação do Conteúdo Assinado
Assinatura da Time Stamping Authority
Algoritmo de Hash usado
Valor de Hash
Número de série
YYYYYMMDDhhmms[.s...]Z
MessageImprint
TSTInfo
TimeStampToken
Algoritmo de Hash usado
Valor de Hash
Carimbo do Tempo
Legalidade
Instituto Nacional de Tecnologia da Informação (ITI) é o responsável por criar e gerir as normatizações de carimbos de tempo no Brasil.
As seguintes Resoluçõesfornecem o embasamento legal dos Carimbos de Tempo no Brasil:
Resolução n° 15 Estabelece as diretrizes para sincronização de freqüência e de tempo na Infra-Estrutura de Chaves Públicas Brasileira - ICP-Brasil.
Resolução n° 58 Aprova a versão 1.0 do documento Visão Geral do Sistema de Carimbos do Tempo na ICP-Brasil.
Resolução n° 59 Aprova a versão 1.0 do documento Requisitos Mínimos para as Declarações de Práticas das Autoridades de Carimbo do Tempo da ICP-Brasil.
Carimbo do Tempo
Legalidade
Resolução n° 60 Aprova a versão 1.0 do documento Requisitos Mínimos para as 
Políticas de Carimbo do Tempo da ICP-Brasil.
Resolução n° 61 Aprova a versão 1.0 do documento Procedimentos para 
Auditoria do Tempo na ICP-Brasil.
Resolução n° 69 Aprova a versão 1.1 dos normativos de carimbo de tempo da ICP-Brasil.
Resolução n° 78 Aprova a versão 1.2 do documento de visão geral do sistema 
de carimbos do tempo na ICP-Brasil (DOC-ICP-11).
Carimbo do Tempo
Legalidade
  Um detalhe importante que consta no DOC-ICP-11 e a informação 
 de que somente são aceitos na ICP-Brasil Carimbos do Tempo emitidos 
 por SCT com alvarás de sincronismo fornecidos por Sistemas de Auditoria 
 e Sincronismo. 
Carimbo do Tempo
Normas internacionais
Além de estudar e discutir em grupos de trabalho da sociedade brasileira, 
o ITI se inspirou nos padrões exaustivamente debatidos internacionalmente 
para criar as normas que nortearam a construção da Rede de Carimbos do Tempo Brasileira. Entre as mais importantes, citamos:
 RFC 3161, IETF - Public Key Infrastructure Time Stamp Protocol (TSP), agosto de 2001;
 RFC 3628, IETF - Policy Requirements for Time Stamping Authorities, novembro 2003; 
 ETSI TS 101.861 - v 1.2.1 Technical Specification / Time Stamping Profile, março 
 de 2002; 
 ETSI TS 102.023 - v 1.1.1 Technical Specification / Policy Requirements for Time 
 Stamping Authorities, abril de 2002. 
Carimbo do Tempo
Exemplos de utilização – apólices de seguro
As apólices digitais têm o mesmo valor jurídico que uma apólice tradicional 
em papel. 
Elas foram regulamentadas pela Superintendência de Seguros Privados (Susep) 
em 2004. Na época, despertaram pouco interesse, devido aos investimentos necessários e do temor de algumas companhias (e dos seus clientes) da segurança das operações pela internet. 
Aos poucos, as seguradoras começaram a aderir, pois entenderam que investindo nesta tecnologia, o retorno é rápido e garantido.
Carimbo do Tempo
Exemplos de utilização
CIRCULAR Nº 277, DE 30 DE NOVEMBRO DE 2004
DOU 02.12.2004
Faculta a utilização da assinatura digital, nos documentos eletrônicos relativos às operações de seguros, 
de capitalização e de previdência complementar aberta, por meio de certificados digitais emitidos 
no âmbito da Infra-estrutura de Chaves Públicas (ICPBrasil), e dá outras providências.
O SUPERINTENDENTE DA SUPERINTENDÊNCIA DE SEGUROS PRIVADOS - SUSEP, na forma do disposto no art. 36, alínea "c" do Decreto-Lei nº 73, de 21 de novembro de 1966, no art. 3º, § 2º do Decreto-Lei nº 261, de 28 de fevereiro de 1967 e art. 73 da Lei Complementar nº 109, de 29 de maio de 2001 e considerando a necessidade de ajustar os procedimentos dos mercados de seguros, de capitalização e de previdência complementar aberta aos ditames da Medida Provisória nº 2.200-2, de 24 de agosto de 2001, e o que consta do Processo SUSEP nº 15414.003906/2004-23, resolve:
Art. 1º Os documentos eletrônicos relativos às operações de seguros, de capitalização e de previdência complementar aberta, respeitadas as exigências da legislação em vigor, poderão ser assinados digitalmente desde que atendam aos seguintes requisitos:
I - sejam utilizados certificados digitais emitidos no âmbito da Infra-estrutura de Chaves Públicas (ICP-Brasil);
II - sejam identificados com a data e a hora de envio e de recebimento.
Carimbo do Tempo
Exemplos de utilização
Art. 2º Os documentos eletrônicos gerados a partir da utilização da assinatura digital deverão ser obrigatoriamente armazenados, pelas sociedades seguradoras, de capitalização, entidades abertas de previdência complementar, corretores de seguros e corretores de seguros de vida, capitalização e previdência, pessoas físicas ou jurídicas, em qualquer meio de gravação eletrônica ou magnética que possibilite a confirmação do processo de validação de tais documentos, sendo dispensada a sua coleta e guarda em papel.
§ 1º O prazo de guarda para os documentos eletrônicos será o mesmo 
prazo de guarda exigido para os documentos impressos.
§ 2º As sociedades e entidades mencionadas no caput estarão obrigadas a reproduzir 
integralmente os documentos eletrônicos sempre que tal procedimento for exigido
 pela SUSEP ou outro órgão público competente.
Art. 3º Esta Circular entra em vigor na data da sua publicação, ficando 
revogadas as disposições em contrário.
RENÊ GARCIA JÚNIOR
Carimbo do Tempo
Ambiente da Autoridade de Carimbo de Tempo
Hardwares criptográficos
Motivação da implantação 
da Certificação Digital
Carimbo do Tempo
Plataformas operacionais da tecnologia
Autenticação
Certificados SLL
Políticas de assinatura
Políticas de assinatura na ICP-Brasil
Certificado de Atributo
Comparação os aspectos de segurança
Burocracia, morosidade e custos
Gerenciamento de identidade
Políticas de assinatura
Políticas de assinatura
Assinatura digital de documentos
Relembrando o que não é uma assinatura digital na ICP-Brasil.
Uma assinatura digitalizada pode ser facilmente copiada e colada em qualquer documento, pois é apenas de um conjunto de bits manipulável.
  
Relembrando o que não é uma assinatura digital na ICP-Brasil.
Uma assinatura física realizada em meio digital (tela eletrônica sensível à toque) possui a mesma fragilidade da assinatura digitalizada, pois é apenas de um conjunto de bits que pode ser copiado e colado indevidamente em qualquer documento.
Políticas de assinatura
Relembrando o que é uma assinatura digital?
Políticas de assinatura
Ao pé da letra, uma assinatura digital é um dado criptografado 
com uma Chave Privada. 
No entanto, ela precisa ser gerada, transmitida e armazenada. 
Para que isto ocorra, faz-se necessária a criação de padrões. 
Os padrões de assinaturas digitais mais amplamente discutidos, 
difundidos e implementados no mundo são o CMS e o XMLDsig.
Ambos descrevem regras de processamento e uma sintaxe para 
se trabalhar com eles.  
Políticas de assinatura
Relembrando o que é uma assinatura digital?
PKCS nº 7: o início
Na década de 90 o grupo de trabalho PKCS da RSA Security Inc, iniciou 
o desenvolvimento e publicação dos padrões (ou normas) de criptografia de Chave Pública. 
Eles publicaram os padrões para promover a utilização das técnicas 
de criptografia para as quais tinham patentes, tais como o algoritmo RSA, o algoritmo de assinatura Schnorr e vários outros. 
As normas não viraram padrões do mercado, porque a empresa detinha a patente destes. No entanto, nos últimos anos algumas organizações têm direcionando seus esforços para criação de padrões abertos para 
o mercado de criptografia, como o Grupo PKIX da ISO, o IETF e o W3C.
Políticas de assinatura
Public Key Cryptography Syntax #7 – PKCS n.º 7 
Descreve uma sintaxe de encapsulamento (ou empacotamento) para proteção de dados, que possui suporte a assinatura digital e criptografia e permite múltiplos encapsulamentos.
Dessa maneira, um usuário pode assinar um documento já encapsulado. 
A sintaxe permite ainda a utilização de co-assinaturas e contra-assinaturas associadas à assinatura original.
Políticas de assinatura
CMS
O  Cryptographic Message Syntax (CMS) é o padrão do IETF para proteger 
e criptografar dados. Ele pode ser usado para assinar digitalmente, resumir, autenticar ou criptografar qualquer forma de dados digitais.
O CMS se baseia na sintaxe do PKCS nº7 e sua última versão (publicada 
em setembro de 2009) foi especificada na RFC 5652.
A arquitetura do CMS foi construída baseada do gerenciamento de chaves 
de certificados(X.509), tal como o perfil definido pelo grupo 
de trabalho PKIX (ITU-T).
Políticas de assinatura
O CMS é usado como o componente de gerenciamento de chaves 
de certificados de muitos outros padrões de criptografia, tais como S/MIME, PKCS nº 12 e do protocolo RFC 3161 de Carimbo 
do Tempo.
Com o CMS, assim como com o PKCS nº 7, ao gerar uma assinatura 
digital estamos empacotando (ou encapsulando) o resumo binário 
do conteúdo que estamos assinando, e este conteúdo pode estar dentro ou fora do pacote.
Políticas de assinatura
CMS
CMS - tipos de conteúdo
O CMS padronizou seis tipos de conteúdos, dentre os quais 
destacamos o Signed-data e o Enveloped-data Content Type.
	Data Content Type
 • Strings de octetos (ex. arquivos de texto ASCII)
	Signed-data Content Type
 • Conteúdo assinado digitalmente (um ou mais assinantes)
	Enveloped-data Content Type
 • Conteúdo em formato de envelope digital para um ou 
mais destinatários (sigilo – criptografia de conteúdo)
	
 
Políticas de assinatura
CMS - tipos de conteúdo
O CMS padronizou seis tipos de conteúdos, dentre os quais 
destacamos o Signed-data e o Enveloped-data Content Type.
	Digested-data Content Type
 • Formato para um conteúdo qualquer mais seu código hash
	Encrypted-data Content Type (sigilo)
 • Formato para um conteúdo qualquer criptografado
	Authenticated-data Content Type
 • Formato para um conteúdo qualquer, um código MAC e 
chaves criptografadas para um ou mais destinatários 
Políticas de assinatura
Políticas de assinatura
Especifica seis tipos de conteúdo:
CMS 
Tipos de conteúdo (ContentInfo)
 data;
 signed-data;
 enveloped-data;
 digested-data;
 encrypted-data;
 authenticated-data. 
CMS – visão esquemática e sintática
 SignedData ::= SEQUENCE {
 version CMSVersion,
 digestAlgorithms DigestAlgorithmIdentifiers,
 encapContentInfo EncapsulatedContentInfo,
 certificates CertificateSet OPTIONAL,
 crls RevocationInfoChoices OPTIONAL,
 signerInfos SignerInfos }
Tipo SignedData
Políticas de assinatura
CMS Attached/Detached (anexado e desanexado)
No padrão CMS, os conteúdos assinados são normalmente anexados às assinaturas digitais. No entanto, os conteúdos assinados podem ser removidos ou as assinaturas digitais podem ser criadas, armazenadas e transmitidas com o conteúdo desanexado.
Portanto, o padrão CMS permite que a assinatura seja do tipo Attached ou Dettached.
Assim, temos:
Attached ou anexado – o conteúdo assinado está contido no pacote 
ou cápsula de assinatura.
Dettached ou desanexado – o conteúdo assinado não está contido 
no pacote ou cápsula de assinatura.
Políticas de assinatura
CMS - Co-assinaturas e Contra-assinaturas
Além de assinaturas digitais anexadas e desanexadas, o padrão CMS 
nos fornece opções para realizar co-assinaturas e contra-assinaturas. 
Co-assinaturas
Tipo de assinatura onde 1 ou N assinantes, geram uma assinatura 
de um mesmo conteúdo paralelamente em um mesmo pacote.
Contra-assinaturas
Tipo de assinatura que possibilita comprovar que uma assinatura 
foi realizada sobre um determinado conteúdo, que é uma assinatura 
sobre uma assinatura.
Políticas de assinatura
CMS SignedData
Políticas de assinatura
Conteúdo vazio ou cheio
Conteúdo(arquivo, mensagem e etc..) 
Opcionalmente: 
Attached ou Dettached
Assinante 1 e assinante 2
Blocos de assinaturas de Co e Contra, um SignerInfo por assinante e N Contra-assinantes 
por signerInfo
CMS signedData - Campo SignerInfo 
(informações do assinante)
 
Version
 Número de versão
sid SignerIdentifier 
 Especifica o certificado digital do assinante
 Duas possibilidades:
	se versão=1: issuerAndSerialNumber
	se versão=3: subjectKeyIdentifier
digestAlgorithm
 Identificação do algoritmo de Hash utilizado e parâmetros.
Políticas de assinatura
CMS signedData - Campo SignerInfo 
(informações do assinante)
 signedAttrs
 	Conjunto de atributos que são assinados 
	junto com a mensagem. 
 	Dois valores mínimos que devem estar 
	presentes no campo signedAttrs do SignerInfo.
 
 content-type attribute
	Deve conter o mesmo valor do 	“encapContentInfo eContentType”.
 message-digest attribute
	Deve conter o valor do hash do conteúdo 	“eContent” (mensagem ou documento
	 a ser assinado).
Políticas de assinatura
CMS signedData - Campo SignerInfo 
(informações do assinante)
signatureAlgorithm
 Identifica o algoritmo de assinatura 
 e seus parâmetros associados.
signature
 Representa a assinatura digital
 A assinatura digital é gerada pela criptografia do valor
 de Hash do campo “signedAttrs” utilizando a Chave 
 Privada do assinante.
unsignedAttrs OPTIONAL
 Conjunto de atributos que não são assinados.
Políticas de assinatura
CMS signedData - Campo SignerInfo 
(informações do assinante)
Tipos de atributos possíveis 
 signedAttributes - assinados 
 unsignedAttributes – não assinados
Formato:
 attrType: Tipo de atributo
 attrValue: Valor do atributo
Exemplos:
Assinados - Atributo “Signing Time”
 Especifica o tempo no qual o assinante realizou 
 a assinatura (tempo não confiável).
Não –assinados - Atributo “Countersignature”
 Especifica uma assinatura em série de 
 outra assinatura existente.
Políticas de assinatura
CMS – Visão esquemática e sintática 
(tipo EnvelopedData)
EnvelopedData ::= SEQUENCE {
version 			CMSVersion,
originatorInfo 		OriginatorInfo OPTIONAL,
recipientInfos 		RecipientInfos,
encryptedContentInfo 	EncryptedContentInfo
unprotectedAttrs 		UnprotectedAttributes OPTIONAL
 }
Políticas de assinatura
CMS – Visão esquemática
Tipo EnvelopedData
[1] Destinatário 1
[2] Destinatário 2
[3] Chave Simétrica Criptografada
Políticas de assinatura
CMS x XMLDsig
 XMLdsig pode definir as partes que devem ser assinadas;
 CMS é direcionado para assinar um documento como um todo;
 Uma aplicação poderia inserir as partes de um XML eContent do CMS 
 para assinatura.
Políticas de assinatura
XMLDsig
 Assinaturas digitais XML são assinaturas digitais projetadas para uso 
 em transações XML; 
 O padrão define um esquema para capturar o resultado de uma operação 
 de assinatura digital aplicada a dados arbitrários ( mas quase sempre XML );
 Tal como as assinaturas digitais binárias (PKCS), as assinaturas digitais 
 XML acrescentam autenticação, controle de integridade e suportam 
 não-repúdio para os dados que assinam;
 Ao contrário das assinaturas digitais não-XML, o XMLDsig foi projetado
 para considerar e tirar vantagem da Internet e do XML;
Políticas de assinatura
 Uma característica fundamental da XMLDsig é a habilidade para assinar somente
 porções específicas de uma árvore XML ao invés de um documento completo;
 Isto é especialmente relevante quando um único documento XML pode 
 ter uma longa história na qual os diferentes componentes foram compostos 
 em tempos diferentes por pessoas diferentes, cada qual assinando apenas os 
 elementos relevantes para si mesmas. 
 Esta flexibilidade será crítica em situações onde for importante garantir
 a integridade de certas porções de um documento XML, enquanto 
 outras porções do documento sejam deixadas abertas para alterações; 
 Por exemplo, um formulário assinado XML é encaminhado para um usuário preencher 
 seus dados. Se a assinatura fosse realizada sobre todo o formulário, qualquer mudança 
 pelo usuário para os valores a serem preenchidos iria invalidaria a assinatura. 
Políticas de assinatura
XMLDsig
A Especificação XMLDsig descreve três tipos de assinaturas 
e cada uma tem sua respectiva utilização:
 Detached - não inclui o conteúdo assinado na assinatura digital;
 Enveloping – o conteúdo digital está incluído na estrutura XMLSignature; 
 Enveloped – a assinatura digital está incluída no conteúdo digital 
 que está sendo assinado.
Políticasde assinatura
XMLDsig
<Signature>
	<SignedInfo>
		(CanonicalizationMethod)
		(SignatureMethod)
		(<Reference(URI=)?> [1]
			(Transforms)? [2]
			(DigestMethod)
			(DigestValue) [3]
		</Reference>)+
	</SignedInfo>
	(SignatureValue) [4]
	(KeyInfo)? [5]
	(Object)*
</Signature>
Os componentes de uma XMLDsig
[1] Each resource to be signed has its own <Reference> element, identified by the URI attribute
Políticas de assinatura
[3] The <DigestValue> element carries the value of the digest of the referenced resource
[2] The <Transform> element specifies an ordered list of processing steps that were applied to the referenced resource´s content before it was digested
[4] The<SignatureValue> element carries the
 value of the encrypted digest of the
 <SignedInfo> element
[5] The <KeyInfo> element indicates the key to be used to validate the signature. Possible forms for identification include certificates, key names, and key agreement algorithms and information
Estrutura de uma XMLDsig
<dsig:Signature ID?> 
 <dsig:SignedInfo>
 <dsig:CanonicalizationMethod Algorithm />
 <dsig:SignatureMethod Algorithm />
 <dsig:Reference URI? >+
 </dsig:SignedInfo>
 <dsig:SignatureValue> 
 <dsig:KeyInfo>?
 (<dsig:Object ID?>)*
</dsig:Signature
Políticas de assinatura
Forma canônica
O elemento <CanonicalizationMethod> indica o algoritmo a ser usado para 
obter a forma canônica do elemento <SignedInfo>. Conjuntos de dados XML
com a mesma informação podem ter representações textuais diversas; 
por exemplo, podem diferir na quantidade de espaços em branco.
Para prevenir verificações inconsistentes, informações XML precisam 
ser convertidas a uma forma canônica antes de extrair sua representação 
binária para o processamento da assinatura.
O elemento <SignatureMethod> identifica o algoritmo usado para produzir 
o valor da assinatura.
Políticas de assinatura
XML canônico
 C14N é uma serialização do documento XML ou de um conjunto de nós
 XPath para um string binário;
 Existem vários algoritmos C14N (W3C: C14N, Exclusive C14N);
 Mesmo dado de entrada (documento XML ou conjunto de nós XPath) 
 e mesmo algoritmo C14N produzem o mesmo string binário;
 A melhor prática: Exclusive C14N.
Políticas de assinatura
O elemento Reference
<dsig:Reference URI? >
	 (<dsig:Transforms>
 (<dsig:Transform Algorithm />)+
	 </dsig:Transforms>)?
	 <dsig:DigestMethod Algorithm >
	 <dsig:DigestValue>
</dsig:Reference>
 
Políticas de assinatura
O elemento KeyInfo
<dsig:KeyInfo>
	<dsig:KeyName>?
	<dsig:KeyValue>?
	<dsig:RetrievalMethod>?
	<dsig:X509Data>?
	<dsig:PGPData>?
	<enc:EncryptedKey>?
	<enc:AgreementMethod>?
	<dsig:KeyName>?
	<dsig:RetrievalMethod>?
	<*>?
</dsig:KeyInfo
Políticas de assinatura
Geração de uma assinatura XML
 Calcular os Hashs sobre os dados assinados apontados por elementos
 <dsig:Reference/>
 Compor o elemento <dsig:SignedInfo/>
 Calcular a assinatura sobre o elemento <dsig:SignedInfo/> e colocar 
 o resultado no elemento <dsig:SignatureValue/>
Políticas de assinatura
XMLDsig
Uma assinatura XML pode proteger mais de um tipo de recurso. 
Por exemplo, uma única assinatura XML pode abranger dados 
codificados em caracteres, dados binários (um arquivo JPEG, 
por exemplo), dados codificados em XML e uma seção específica 
de um arquivo XML.
Políticas de assinatura
 A validação de uma assinatura requer que os dados do objeto assinado 
 estejam disponíveis. A assinatura XML irá geralmente indicar a localização do
 objeto original assinado.
 Esta referência pode:
 Ter uma assinatura XML embutida dentro de si mesma 
 ( a assinatura é a “filha”). 
 Ser uma URI dentro da assinatura XML; 
 Residir dentro do mesmo recurso que a assinatura 
 (a assinatura é uma “irmã”); 
 Estar embutida dentro de uma assinatura XML 
 (a assinatura é o elemento “pai”); 
Políticas de assinatura
XMLDsig
Transforms
Enveloped Signature 
http://www.w3.org/2000/09/xmldsig#enveloped-signature
XSLT
http://www.w3.org/TR/1999/REC-xslt-19991116
XPath
http://www.w3.org/TR/1999/REC-xpath-19991116
Políticas de assinatura
Enveloped
Uma assinatura Enveloped é útil quando você tem um documento XML simples 
e quer garantir a integridade dele. 
Por exemplo, mensagens XKMS podem utilizar assinaturas Enveloped para transmitir respostas “confiáveis” de um servidor de volta para um cliente.
Políticas de assinatura
Enveloped
Políticas de assinatura
<rootElement><price>$12000</price>
 <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
 <SignedInfo>
 <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml- c
 14n-20010315"></CanonicalizationMethod>
 <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"> 
 </SignatureMethod>
 <Reference URI="">
 <Transforms>
 <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped- 
 signature"></Transform>
 <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-
 20010315"></Transform>
 </Transforms>
 <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"> 
 </DigestMethod>
 <DigestValue>gps9eU5GIlAzw188faGc2eQ56L0=</DigestValue>
 </Reference>
 </SignedInfo>
<SignatureValue>kqFSSPN3tNibQT3dYnKKR8FEE3mUf7aGo=</SignatureValue>
 <KeyInfo>….</KeyInfo>
 </Signature>
</rootElement>
Uma assinatura Enveloping é útil quando se deseja adicionar facilmente seus próprios metadados à assinatura (como um Carimbo do Tempo) quando não for preciso alterar o documento de origem, e incluir outros dados abrangidos pela assinatura gerada no documento.
Uma assinatura XMLDSIG pode assinar vários objetos de uma vez. 
Para isso, o Enveloping é geralmente combinado com outro formato.
Enveloping
Políticas de assinatura
Enveloping
Políticas de assinatura
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
 <SignedInfo>
 <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-
 20010315"></CanonicalizationMethod>
 <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"> 
 </SignatureMethod>
 <Reference URI="#Object1">
 <Transforms>
 <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"> 
 </Transform>
 </Transforms>
 <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"> 
 </DigestMethod>
 <DigestValue>iUSD6LYG1b1nrUTUnBHE3iLL3LU=</DigestValue>
 </Reference>
 </SignedInfo>
<SignatureValue>Ir4w44JiqvnpVxD5lQL4srJGeupypXGI4e++RL2BiLQ==</SignatureValue>
 <KeyInfo>….</KeyInfo>
 <Object Id="Object1"><list>
 <item>1234</item><price>$1200</price></list></Object>
</Signature>
Detached
A assinatura Detached é útil quando você não pode modificar 
a fonte. Sua desvantagem é requerer dois documentos XML - a origem 
e sua assinatura - a serem realizados em conjunto. 
Políticas de assinatura
Detached
Políticas de assinatura
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
 <SignedInfo>
 <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-
 20010315"></CanonicalizationMethod>
 <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"> 
 </SignatureMethod>
 <Reference URI="#Object1">
 <Transforms>
 <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"> 
 </Transform>
 </Transforms>
 <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"> 
 </DigestMethod>
 <DigestValue>iUSD6LYG1b1nrUTUnBHE3iLL3LU=</DigestValue>
 </Reference>
 </SignedInfo>
<SignatureValue>Ir4w44JiqvnpVxD5lQL4srJGeupypXGI4e++RL2BiLQ==</SignatureValue><KeyInfo>….</KeyInfo>
 <Object Id="Object1"><list>
 <item>1234</item><price>$1200</price></list></Object>
</Signature>
XMLDsig
Políticas de assinatura
<Signature> 
 <SignedInfo> 
 ….
 </SignedInfo>
 <SignatureValue>
 (<KeyInfo>)?
 (<Object ID?>)*
 </Signature>  
 <CanonicalizationMethod/>
 <SignatureMethod/>
 (<Reference URI? >
 (<Transforms>)?
 <DigestMethod>
 <DigestValue>
 </Reference>)+
Assinar
Políticas de assinatura
<Reference>..
</Reference>
<Reference>.. 
</Reference>
<SignatureMethod>
<CanonicalizationMethod>
 <SignedInfo>
Canonicalizer
Signature
Key
<Signature>
 <SignedInfo>
 ..
 </SignedInfo>
 <SignatureValue>
 </SignatureValue>
</Signature>
<SignatureValue>
……
</SignatureValue>
Verificar
Políticas de assinatura
<Signature>
..
<KeyInfo>
 </KeyInfo>
</Signature>
<KeyInfo>
 ..3E1E84 ..
 </KeyInfo>
<Signature>
..
</Signature>
Yes/No
Root
Certificate 
Store
XML Parser
Trust Engine
Signature Validation
1. Determinar o que será assinado
Identificar os recursos através de URIs.
“http://www.abccompany.com/logo.gif”
para referenciar uma imagem GIF na Web.
“http://www.abccompany.com/index.html”
para referenciar uma página HTML na Web.
“http://www.abccompany.com/xml/po.xml#sender1”
para referenciar um elemento específico em um arquivo XML.
“http://www.abccompany.com/xml/po.xml” 
para referenciar um arquivo XML na Web.
Políticas de assinatura
2. Calcular o Hash de cada recurso
Cada recurso referenciado é especificado através de um elemento <Reference> e seu Hash (calculado no recurso indentificado) é colocado no elemento <DigestValue>
<Reference URI=”http://www.abccompany.com/news/2000/03_27_00.htm”> <DigestMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#sha1” /> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference>
 
<Reference URI=”http://www.w3.org/TR/2000/WD-xmldsig-core-20000228/signature-example.xml”>
<DigestMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#sha1”/> <DigestValue>UrXLDLBIta6skoV5/A8Q38GEw44=</DigestValue> </Reference>  
 
Políticas de assinatura
3. Localizar os elementos Reference
<SignedInfo Id=”foobar”> 
 <CanonicalizationMethod Algorithm=”http://www.w3.org/TR/2001/REC-xml-c14n-20010315”/> 
<SignatureMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#dsa-sha1” />
 <Reference URI=”http://www.abccompany.com/news/2000/03_27_00.htm”> <DigestMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#sha1” /> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference>
 <Reference URI=”http://www.w3.org/TR/2000/WD-xmldsig-core-20000228/signature-example.xml”>
 <DigestMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#sha1”/> <DigestValue>UrXLDLBIta6skoV5/A8Q38GEw44=</DigestValue> </Reference> 
</SignedInfo>
Coletar os elementos <Reference> (com seus Hashs associados) 
dentro dos elementos <SignedInfo>
Políticas de assinatura
4. O valor da assinatura
Calcular o Hash do elemento <SignedInfo>, assiná-lo e colocar 
o valor da assinatura no elemento <SignatureValue>. 
<SignatureValue>
MC0ELE8A233E482A3D2A1E
</SignatureValue> 
Políticas de assinatura
5. Acrescentar a informação de chave
A informação de chave deve ser incluída em um elemento <KeyInfo>. Aqui a informação de chave contém o certificado
 o X.509 que contém a Chave Pública necessária para 
a verificação da assinatura.
 <KeyInfo> 
<X509Data>
 <X509SubjectName>CN=Ed Simon,O=XMLSec Inc.,ST=OTTAWA,C=CA</X509SubjectName>
<X509Certificate>MIID5jCCA0+gA...lVN</X509Certificate> 
</X509Data>
</KeyInfo> 
Políticas de assinatura
6. Encapsular em um elemento Signature
 <?xml version=”1.0” encoding=”UTF-8”?>
 <Signature xmlns=”http://www.w3.org/2000/09/xmldsig#”> 
 <SignedInfo Id=”foobar”> 
 <CanonicalizationMethod Algorithm=”http://www.w3.org/TR/2001/REC-xml-c14n 20010315”/>
 <SignatureMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#dsa-sha1” />
 <Reference URI=”http://www.abccompany.com/news/2000/03_27_00.htm”> 
 <DigestMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#sha1” />
 <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> 
 </Reference>
 <Reference URI=”http://www.w3.org/TR/2000/WD-xmldsig-core-20000228/signature-example.xml”>
 <DigestMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#sha1”/> 
 <DigestValue>UrXLDLBIta6skoV5/A8Q38GEw44=</DigestValue> 
 </Reference> </SignedInfo> 
 <SignatureValue>MC0ELE8A233E482A3D2A1E</SignatureValue> 
 <KeyInfo> 
 <X509Data> 
 <X509SubjectName>CN=Ed Simon,O=XMLSec Inc.,ST=OTTAWA, C=CA</X509SubjectName> 
 <X509Certificate> MIID5jCCA0+gA...lVN </X509Certificate>
 </X509Data> </KeyInfo> </Signature>
Políticas de assinatura
Verificando uma assinatura XML
 Verifique a assinatura do elemento <SignedInfo>.
Para fazê-lo, recalcule o Hash do elemento <SignedInfo> (usando o algoritmo de Hash especificado no elemento <SignatureMethod>) use a Chave Pública para verificar que o valor do elemento <SignatureValue> é correto para 
o Hash do elemento <SignedInfo>.
Se a assinatura confere, recalcule os Hashes das referências contidas dentro do elemento <SignedInfo> e compare-os com os valores de Hash expressos em cada elemento <DigestValue> correspondente a cada elemento <Reference.
Políticas de assinatura
Política de Assinatura
Uma Política de Assinatura, define o significado do ato de assinar 
em um contexto de:
 Criação;
Isso exige um OID e o Hash da informação de referência para definir a assinatura. A descrição de seu significado pode ser feita textualmente (legível às pessoas) 
ou de uma forma estruturada que utilize notação e codificação previamente acordados (legível aos computadores).
 Aprovação.
 Recebimento;
 Entrega;
 Envio;
Políticas de assinatura
Normas Internacionais
ETSI
TS 101 733 - CMS Advanced Electronic Signatures (CAdES);
TR 102 272 – Formato em ASN.1 de políticas de assinaturas;
TS 102 734 – Perfis de “CMS Advanced Electronic Signatures” baseadas no documento TS 101 733 (CAdES);
TS 101 903 - XML Advanced Electronic Signatures (XAdES);
TS 102 904 - Perfis de “XML Advanced Electronic Signatures” baseadas no documento TS 101 903 (XAdES);
TR 102 038 – Formato em XML de políticas de assinaturas.
Políticas de assinatura
IETF
W3C
RFC 5126 – Define uma série de formatos de assinatura eletrônica, incluindo 
a assinatura eletrônica que pode permanecer válida durante longos períodos. 
Esta RFC, é tecnicamente equivalente ao ETSI TS 101 733 V.1.7.4.
Baseia-se no conteúdo da especificação técnica ETSI TS 101 903
http://www.w3.org/TR/XAdES/
Políticas de assinatura
Normas Internacionais
CAdES
CMS Advanced Electronic Signature - uma extensão do padrão CMS que é usado para descrever estrutura para armazenamento de conteúdos assinados digitalmente, em formato ASN-1. Essa extensão incorpora elementos com vistas 
a prover as assinaturas digitais CMS de informações que permitam sua validação 
a mais longo prazo.
XAdES
XML Advanced Electronic Signature - uma extensão do padrão XMLdSig 
que é usado para descrever estrutura para armazenamento de conteúdos assinados digitalmente, em formato XML. Essa extensão incorpora elementos 
com vistas a prover as assinaturas digitais XMLdSig de informações que 
permitam sua validação a mais longo prazo.
Políticas de assinatura
Assinatura digital de longa duração
Quais são os requisitos técnicos necessários para a realização de um processo 
de assinatura digital que permita a verificação de sua autenticidade após muito tempo? 
Políticas de assinatura
Linha do tempo
??
Realização da assinatura
Repensando a questão...
Quais as informações e referências que precisam ser preservadas (congeladas) para que no futuro o contexto possa ser restabelecido de maneira adequada 
a impedir o repúdio de uma assinatura digital?
Políticas de assinatura
Linha do tempo
!!
Certificados Digitais
Referências Cronológicas
Documentos NormativosCadeias de Certificação
Listas de Certificados Revogados
Hardwares criptográficos
Motivação da implantação 
da Certificação Digital
Carimbo do Tempo
Plataformas operacionais da tecnologia
Autenticação
Certificados SLL
Políticas de assinatura
Políticas de assinatura na ICP-Brasil
Certificado de Atributo
Comparação os aspectos de segurança
Burocracia, morosidade e custos
Gerenciamento de identidade
Políticas de assinatura
Na ICP- Brasil
Políticas de Assinatura na ICP-Brasil
Formatos padronizados de assinaturas digitais no Brasil
A utilização de formatos padronizados de assinatura digital no âmbito 
da ICP-Brasil é essencial para a confiabilidade e credibilidade do processo 
de criação e validação de assinaturas no Brasil.
A não utilização destes formatos, compromete a interoperabilidade e pode acarretar a utilização de formatos de assinatura inadequados para o tipo de documento e os tipos de certificados que selarão aquela assinatura.
Documentos da ICP-Brasil sobre Políticas de Assinaturas
DOC-ICP-15 - Visão Geral sobre Assinaturas Digitais na ICP-Brasil - v.2.0. 
Define os principais conceitos e lista os demais documentos que compõem as normas da ICP-Brasil sobre o assunto.
Estabelece os requisitos obrigatórios a serem observados na criação e verificação de assinaturas digitais na ICP-Brasil.
DOC-ICP-15.01 - Requisitos Mínimos para Geração e Verificação de Assinaturas Digitais na ICP-Brasil - v.2.0.
Políticas de Assinatura na ICP-Brasil
DOC-ICP-15.02 - Requisitos Mínimos para Geração e Verificação de Assinaturas digitais na ICP-Brasil - v.2.0.
Delimita a atributos a serem usados na geração de assinaturas digitais no âmbito da ICP-Brasil.
DOC-ICP-15.03 - Requisitos Mínimos para Geração e Verificação
de Assinaturas Digitais na ICP-Brasil - v.2.0.
 
Define o formato, estrutura e sintaxes que devem ser observadas para a criação de novas Políticas de Assinatura Digital. 
Apresenta, adicionalmente, as políticas padrão e o esquema de gerenciamento de políticas na ICP-Brasil.
Políticas de Assinatura na ICP-Brasil
Documentos da ICP-Brasil sobre Políticas de Assinaturas
RESOLUÇÃO Nº 76, DE 31 DE MARÇO DE 2010
Aprova a Versão 2.0 do Documento Visão Geral Sobre Assinaturas Digitais 
na ICP-Brasil (Doc-ICP-15).
Políticas de Assinatura na ICP-Brasil
RESOLUÇÃO Nº 76, DE 31 DE MARÇO DE 2010 
DOC-ICP 15 PRINCIPAIS CONCEITOS
Assinatura digital x assinatura eletrônica 
Uma assinatura eletrônica representa um conjunto de dados, no formato eletrônico, que é anexado ou logicamente associado a um outro conjunto de dados, também no formato eletrônico, para conferir-lhe autenticidade ou autoria. A assinatura eletrônica, portanto, pode ser obtida por meio de diversos
dispositivos ou sistemas, como login/senha, biometria, impostação de Personal Identification Number (PIN) etc.
Políticas de Assinatura na ICP-Brasil
Um dos tipos de assinatura eletrônica é a assinatura digital, que utiliza 
um par de chaves criptográficas associado a um Certificado Digital. 
Uma das chaves – a Chave Privada – é usada durante o processo de geração 
de assinatura e a outra – Chave Pública, contida no Certificado Digital – é usada durante a verificação da assinatura.
 
RESOLUÇÃO Nº 76, DE 31 DE MARÇO DE 2010 
DOC-ICP-15 - PRINCIPAIS CONCEITOS
O conjunto de normativos da ICP-Brasil trata, apenas, das assinaturas digitais geradas no âmbito da ICP-Brasil. Os demais tipos de assinaturas eletrônicas estão fora do seu escopo. 
No contexto destes normativos presume-se que as assinaturas digitais são produzidas com a utilização de chaves criptográficas privadas associadas
 a certificados digitais ICP-Brasil. 
Políticas de Assinatura na ICP-Brasil
RESOLUÇÃO Nº 76, DE 31 DE MARÇO DE 2010 
DOC-ICP-15 - PRINCIPAIS CONCEITOS
Provedores de Serviços de Confiança (PSC) são uma ou mais entidades que ajudam 
a construir uma relação de confiança entre o assinante e o verificador. Eles apoiam 
o signatário e o verificador por meios de serviços de suporte, como emissão 
de Certificados Digitais, de Listas de Certificados Revogados (LCR) ou de respostas
de Online Certificate Status Protocol (OCSP) e emissão de Carimbos do Tempo.
Entidades envolvidas na assinatura digital
Signatário ou assinante é uma entidade que cria a assinatura digital. 
Verificador é uma ou mais entidades que validam a assinatura digital. 
Mediador ou árbitro é uma pessoa ou entidade que pode ser chamada para arbitrar 
a disputa entre o signatário e o verificador sobre a validade da assinatura digital. 
Políticas de Assinatura na ICP-Brasil
Políticas de Assinatura na ICP-Brasil
Ciclo de vida de uma assinatura digital
RESOLUÇÃO Nº 76, DE 31 DE MAR ÇO DE 2010
DOC-ICP-15 - PRINCIPAIS CONCEITOS 
Na ICP-Brasil podem ser usados dois formatos equivalentes 
para representação de assinaturas digitais:
Padrões para assinatura digital
 Assinatura eletrônica avançada sobre o CMS (CAdES); e
 Assinatura eletrônica avançada sobre o XML-Dsig(XAdES). 
Políticas de Assinatura na ICP-Brasil
RESOLUÇÃO Nº 76, DE 31 DE MARÇO DE 2010 
DOC-ICP-15 - PRINCIPAIS CONCEITOS
Perfis de assinatura digital
Os padrões CAdES e XAdES disponibilizam uma diversificada gama de atributos 
ou propriedades, que permite incorporar às assinaturas digitais informações 
com os mais diferentes objetivos.
 
Essa abundância de opções, se por um lado traz flexibilidade, por outro leva 
à criação de sistemas que exigem grande capacidade de processamento dos equipamentos, para conseguir gerar e validar todos os atributos em apenas
alguns atributos para implementar no seu sistema, que podem ser diferentes 
dos escolhidos por outros desenvolvedores, o que acaba comprometendo 
a interoperabilidade entre diferentes sistemas.
 
 
Políticas de Assinatura na ICP-Brasil
RESOLUÇÃO Nº 76, DE 31 DE MARÇO DE 2010 
DOC-ICP-15 - PRINCIPAIS CONCEITOS
Perfis de assinatura digital
Para maximizar a interoperabilidade das assinaturas digitais é necessário identificar um subconjunto de opções que sejam apropriado. Para as 
diferentes comunidades de usuários. 
Tal seleção é chamada de perfil.
Para a ICP-Brasil, foi definido um perfil de assinatura para uso geral, baseado 
nos padrões CAdES e XAdES, que sintetiza os principais atributos e propriedades 
a serem utilizados nas assinaturas digitais. Podem ser criados outros perfis, para uso em segmentos específicos de atividade, como Governo Eletrônico, se julgado necessário.
Políticas de Assinatura na ICP-Brasil
RESOLUÇÃO Nº 76, DE 31 DE MARÇO DE 2010 
DOC-ICP-15 - PRINCIPAIS CONCEITOS.
Uma política de assinatura é um conjunto de regras que formaliza os processos de criação e verificação de uma assinatura digital e define as bases para que a assinatura digital possa ser considerada válida. 
Políticas de assinatura
Uma assinatura digital é criada pelo signatário de acordo com uma Política 
de Assinatura. A validade de uma assinatura digital é avaliada pelo verificador utilizando a mesma Política de Assinatura usada na criação dessa assinatura digital.
A parte que recebe os documentos assinados determina quais políticas de assinatura podem ser aceitas no seu processo de negócios.
Políticas de Assinatura na ICP-Brasil
RESOLUÇÃO Nº 76, DE 31 DE MARÇO DE 2010 
DOC-ICP-15 - PRINCIPAIS CONCEITOS
A utilização de Políticas de Assinatura torna claro e dá pleno conhecimento às partes envolvidas sobre os requisitos para geração e verificação das assinaturas, 
e formaliza as condições de validade de um documento assinado digitalmente. 
Políticas de Assinatura
Na ICP-Brasil, o formato e a estrutura a serem usados para criação de Políticas 
de Assinatura estão estabelecidos no DOC-ICP-15.03, que foi elaborado com base nos documentos ETSI TR 102 272 e ETSI TR 102 038.
Políticas de Assinatura na ICP-Brasil
FORMATOS DE ASSINATURA DIGITAL ADMITIDOS NA ICP-BRASIL
 Assinatura digital com Referência Básica (AD-RB);
Uma assinatura digital ICP-Brasil DEVE ter um dos formatos a seguir.
Políticas de Assinatura na ICP-Brasil
 Assinatura digital com Referência de Tempo (AD-RT);
Políticasde Assinatura na ICP-Brasil
FORMATOS DE ASSINATURA DIGITAL ADMITIDOS NA ICP-BRASIL
 Assinatura digital com Referências para Validação (AD-RV);
Políticas de Assinatura na ICP-Brasil
FORMATOS DE ASSINATURA DIGITAL ADMITIDOS NA ICP-BRASIL
 Assinatura digital com Referências Completas (AD-RC);
Políticas de Assinatura na ICP-Brasil
FORMATOS DE ASSINATURA DIGITAL ADMITIDOS NA ICP-BRASIL
 Assinatura digital com Referências para Arquivamento (AD-RA).
Políticas de Assinatura na ICP-Brasil
FORMATOS DE ASSINATURA DIGITAL ADMITIDOS NA ICP-BRASIL
Uma assinatura digital ICP-Brasil com Referência Básica (AD-RB) é formada por:
• A sequência de códigos da assinatura propriamente dita.
 • Identificador da Política de Assinatura usada para criação
 e verificação de assinatura digital ICP-Brasil;
 • Dados da assinatura, os quais o signatário incluiu na assinatura 
 digital ICP-Brasil (por exemplo: instante de criação da assinatura);
Políticas de Assinatura na ICP-Brasil
FORMATOS DE ASSINATURA DIGITAL ADMITIDOS NA ICP-BRASIL
Uma assinatura digital ICP-Brasil com Referência de Tempo (AD-RT) é formada por:
Uma assinatura digital ICP-Brasil com Referência Básica (AD-RB) na qual foi acrescentado ou logicamente conectado, por algum meio, um Carimbo do Tempo emitido por uma Autoridade de Carimbo do Tempo (ACT) credenciada na ICP-Brasil, criado com base nos procedimentos aprovados pelo documento DOC-ICP-12.
Uma assinatura digital ICP-Brasil com Referências para Validação (AD-RV) é formada por:
Uma assinatura digital ICP-Brasil com Referência de Tempo (AD-RT) na qual foram acrescentadas referências sobre todosos certificados de Chave Pública e sobre todas as Listas de Certificados Revogados (LCR) ou respostas de Online Certificate Status Protocol(OCSP) que são necessários para a validação daquela assinatura. Sobre esses dados é acrescentado ou logicamente conectado outro Carimbo do Tempo, emitido por uma ACT credenciada na ICP-Brasil.
Políticas de Assinatura na ICP-Brasil
FORMATOS DE ASSINATURA DIGITAL ADMITIDOS NA ICP-BRASIL
 Uma assinatura digital ICP-Brasil com Referências Completas (AD-RC) é formada por: 
Uma assinatura digital ICP-Brasil com Referências para Validação (AD-RC) à qual foram acrescentados todos os dado necessários para validação da assinatura, de acordo com o item 2.2.3.1 do DOC-ICP-15.01. 
Uma assinatura digital ICP-Brasil com Referências para 
Arquivamento (AD-RA) é formada por:
Uma assinatura digital ICP-Brasil com Referência de Tempo (AD-RT) 
à qual foram acrescentadas referências de validação e todos 
os dados necessários para validação da assinatura, de acordo 
com o item 2.2.3.1 do DOC-ICP-15.01. 
Um Carimbo do Tempo, emitido por uma ACT credenciada
na ICP-Brasil é criado sobre todo esse conjunto de dados, 
ficando anexado ou logicamente conectado ao conjunto.
Políticas de Assinatura na ICP-Brasil
FORMATOS DE ASSINATURA DIGITAL ADMITIDOS NA ICP-BRASIL
Hardwares criptográficos
Motivação da implantação 
da Certificação Digital
Carimbo do Tempo
Plataformas operacionais da tecnologia
Autenticação
Certificados SLL
Políticas de assinatura
Políticas de assinatura na ICP-Brasil
Certificado de Atributo
Comparação os aspectos de segurança
Burocracia, morosidade e custos
Gerenciamento de identidade
Certificado de Atributo
Certificado de atributo
Certificado de Atributo
Um Certificado de Atributo é um certificado que não possui uma Chave Pública 
e está necessariamente relacionado a um Certificado Digital de Chaves Públicas (X.509), ao qual ele complementa, com atributos que contém informações de autorização de funções do portador. Uma identificação do Certificado Digital de Chaves Públicas (X.509) pode estar presente no Certificado de Atributo, relacionando-os dessa forma. 
Certificados de Atributo podem ser utilizados em vários serviços de segurança. 
Eles fornecem um mecanismo para fornecimento seguro de informações de autorização para apoiar decisões sobre controle de acesso, autenticação da origem 
dos dados e não-repúdio. 
No contexto dos serviços de autenticação da origem dos dados e de não-repúdio, 
por exemplo, os atributos contidos nos Certificados de Atributo fornecem informações adicionais sobre a entidade assinante. Estas informações podem ser utilizadas para confirmar que a entidade está autorizada a assinar um determinado dado.
 
Certificado Digital (X.509) – Associa uma entidade a uma Chave Pública.
A vantagem da utilização de Certificados de Atributos para a função de autorização 
de funções sobre a utilização dos Certificados Digitais (X.509) está nas diferenças entre eles aqui descritas (Tempo de Validade e Privilégios Autorizados por Diferentes Autoridades).
Certificado de Atributo – Tem uma estrutura similar a de um Certificado Digital (X.509), porém não contém uma Chave Pública.
Certificado de Atributo
Analogia entre a diferença de Certificado Digital (X.509) e Certificado de Atributo: 
O Certificado Digital (X.509) pode ser considerado um passaporte: 
 Tende a valer por um longo período; e
 Identifica o detentor;
 Não é fácil de se obter.
Certificado de Atributo
O Certificado de Atributo é mais parecido com um visto:
Como adquirir um visto exige a apresentação do passaporte, a obtenção do visto 
pode ser um processo mais simples que a obtenção do passaporte.
 Normalmente é emitido por uma autoridade diferente; e
 Tende a ter um curto período de validade.
Certificado de Atributo
Distribuição dos Certificados de Atributo
Modelo “PUSH” vs. “PULL”
Existem vários caminhos de comunicação possíveis para os Certificados de Atributos.
Dentre eles:
 Versão: deve ser Versão 2.
Portador: associação da entidade portadora do Certificado de Atributo com o Certificado Digital (X.509) correspondente.
Emissor: informação do Nome do emissor do Certificado de Atributo.
Assinatura: identificador do algoritmo, utilizado para validar a assinatura do Certificado de Atributo.
Perfil de um certificado de atributo
Certificado de Atributo
Número de Série: valor único por emissor para um determinado Certificado de Atributo.
Período de Validade: especifica o período para o qual o emissor do Certificado de Atributo certifica como válida a associação entre o portador e os atributos.
 
Atributos: fornece informações sobre privilégios do portador.
Extensões: fornece informações sobre o Certificado de Atributo.
Certificado de atributo
Tipos de atributo
Os tipos de atributos descritos abaixo são padrões de atributos contidos em Certificados de Atributos. Sistemas específicos podem criar seus próprios atributos. Cada Certificado de Atributo deve conter apenas um tipo de atributo, podendo este ter múltiplos valores associados.
Service Authentication Information: este atributo identifica o portador ao servidor/serviço pelo nome. Normalmente irá conter um par username/password para a acesso a aplicação. Este atributo fornece informação que pode ser apresentada pelo verificador do Certificado de Atributo para ser interpretado e autenticado por uma aplicação do sistema de forma separada.
Access Identity: este atributo identifica o portador ao servidor/serviço. Este atributo fornece informação sobre o portador, que pode ser usada pelo verificador do Certificado de Atributo para autorizar as ações do portador no sistema.
Certificado de atributo
Tipos de atributo
Charging Identity: este atributo identifica o portador para propósitos de cobrança. 
Por exemplo, para cobrança de utilização de serviço. 
 
Group: este atributo carrega informações sobre a participação 
do portador em um Grupo.
Role: este atributo carrega informações sobre a função do portador. 
Clearance: este atributo carrega informação de autorização 
(associado com a classificação de segurança) relacionada ao portador.
Certificado de Atributo
Modelo operacional - exemplo 
AC: Certificado de Atributo
PKC: Certificado Digital (X.509)
170
Certificado de atributo
O Certificado de Atributo emitido pelo Servidor