INSTRUÇÃO NORMATIVA ITI N° 20, DE 23 DE NOVEMBRO DE 2020
Aprova a versão revisada e consolidada do
documento Procedimentos Operacionais Mínimos
para os Prestadores de Serviço de Confiança da ICP-
Brasil DOC-ICP-17.01.
O DIRETOR-PRESIDENTE DO INSTITUTO NACIONAL DE TECNOLOGIA DA INFORMAÇÃO, no uso das
atribuições que lhe foram conferidas pelo inciso VI do art. 9° do anexo I do Decreto n° 8.985, de 8 de
fevereiro de 2017, pelo art. 1° da Resolução n° 33 do Comitê Gestor da ICP-Brasil, de 21 de outubro de
2004, e pelo art. 2° da Resolução n° 163 do Comitê Gestor da ICP-Brasil, de 17 de abril de 2020,
CONSIDERANDO a determinação estabelecida pelo Decreto n° 10.139, de 28 de novembro de 2019, para
revisão e consolidação dos atos normativos inferiores a decreto, editados por órgãos e entidades da
administração pública federal direta, autárquica e fundacional,
RESOLVE:
Art. 1° Esta Instrução Normativa aprova a versão revisada e consolidada do documento Procedimentos
Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil DOC-ICP-17.01.
Art. 2° Fica aprovada a versão 3.0 do documento DOC-ICP-17.01 – Procedimentos Operacionais
Mínimos para os Prestadores de Serviço de Confiança, anexa a esta Instrução Normativa.
Art. 3° Ficam revogadas:
I - a Instrução Normativa n° 10, de 15 de dezembro de 2017;
II - a Instrução Normativa n° 06, de 16 de abril de 2018;
III - a Instrução Normativa n° 02, de 12 de março de 2019;
IV - a Instrução Normativa n° 03, de 04 de abril de 2019;
V - a Instrução Normativa n° 07, de 30 de outubro de 2019; e
VI - a Instrução Normativa n° 07, de 29 de maio de 2020.
Art. 4° Esta Instrução Normativa entra em vigor em 1° de dezembro de 2020.
CARLOS ROBERTO FORTNER
Infraestrutura de Chaves Públicas Brasileira
ANEXO
PROCEDIMENTOS OPERACIONAIS MÍNIMOS PARA OS PRESTADORES
DE SERVIÇO DE CONFIANÇA DA ICP-BRASIL
DOC-ICP-17.01
Versão 3.0
23 de novembro de 2020
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 2
SUMÁRIO
CONTROLE DE ALTERAÇÕES ....................................................................................................... 3
LISTA DE SIGLAS E ACRÔNIMOS................................................................................................. 4
1 DISPOSIÇÕES GERAIS ............................................................................................................. 6
2 SEGURANÇA PESSOAL ........................................................................................................... 6
3 SEGURANÇA FÍSICA................................................................................................................ 7
3.1 DISPOSIÇÕES GERAIS DE SEGURANÇA FÍSICA ................................................................................................................... 7
4 SEGURANÇA LÓGICA ........................................................................................................... 10
5 SEGURANÇA DE REDE ......................................................................................................... 11
6 REQUISITOS PARA ARMAZENAMENTO DE CHAVES PRIVADAS .............................. 11
6.1 ARMAZENAMENTO DAS CHAVES E CERTIFICADOS DIGITAIS. ............................................................................................... 11
6.2 PROTOCOLOS.......................................................................................................................................................... 12
6.3 REDE ..................................................................................................................................................................... 20
6.4 REQUISITOS PARA SERVIÇOS DE CONFIANÇA DE USO DE CHAVES PRIVADAS ........................................................................... 20
6.5 LISTA DE PRESTADOR DE SERVIÇO DE CONFIANÇA – LPSC ............................................................................................... 37
7 SERVIÇO DE ASSINATURA DIGITAL, VERIFICAÇÃO DE ASSINATURA DIGITAL. . 38
7.1 INTRODUÇÃO .......................................................................................................................................................... 38
7.2 CRIAÇÃO DE ASSINATURAS ........................................................................................................................................ 38
7.3 DISPOSITIVOS PARA CRIAÇÃO DE ASSINATURAS .............................................................................................................. 39
7.4 INTERFACE DA APLICAÇÃO COM O DISPOSITIVO DE CRIAÇÃO DE ASSINATURAS ....................................................................... 39
7.5 SUÍTES DE ASSINATURA ............................................................................................................................................. 39
7.6 FORMATOS DE ASSINATURAS ..................................................................................................................................... 39
7.7 ASSINATURA COM CARIMBO DO TEMPO ...................................................................................................................... 40
7.8 VALIDAÇÃO DE ASSINATURAS ..................................................................................................................................... 40
7.9 ACORDO DE NÍVEL DE SERVIÇO .................................................................................................................................. 40
8 CLASSIFICAÇÃO DA INFORMAÇÃO .................................................................................. 41
9 SALVAGUARDA DE ATIVOS DA INFORMAÇÃO............................................................. 41
10 GERENCIAMENTO DE RISCOS ............................................................................................ 42
11 PLANO DE CONTINUIDADE DE NEGÓCIOS ..................................................................... 42
12 ANÁLISES DE REGISTRO DE EVENTOS ............................................................................ 42
13 PLANO DE CAPACIDADE OPERACIONAL ........................................................................ 42
14 DOCUMENTOS DA ICP-BRASIL REFERENCIADOS ......................................................... 43
15 REFERÊNCIAS ......................................................................................................................... 45
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 3
CONTROLE DE ALTERAÇÕES
Ato que aprovou a alteração
Item alterado
Descrição da alteração
Instrução Normativa ITI nº 20,
de 23.11.2020
Versão 3.0
Revisão e consolidação, conforme o
Decreto nº 10.139, de 28 de novembro
de 2019
Instrução Normativa nº 07,
de 29.05.2020
Versão 2.3
4.g e 12
Altera o tempo de armazenamento dos
logs, trilhas de auditorias e imagens.
Instrução Normativa nº 07,
de 30.10.2019
Versão 2.2
6.4 e 6.5.7
Corrige endereço do serviço de
recuperação do certificado e inclui
previsão de serviço de autenticação do
titular sem uso de chave. Corrige
numeração dos subitens do item 6.4.5.
Instrução Normativa nº 03,
de 04.04.2019
Versão 2.1
6.4.5.2, 6.4.5.6 e 6.4.6.2.1
Inclusão do parâmetro
hash_algorithm.
Instrução Normativa nº 02,
de 12.03.2019
Versão 2.0
6.4 e 6.5
Atualização dos requisitos para
serviços de confiança de uso de
chaves privadas.
Inclusão da definição da Lista de
Prestadores de Serviço de Confiança –
LPSC.
Instrução Normativa nº 06,
de 16.04.2018
Versão 1.1
6.4
Item incluído – Requisitos para
serviços de confiança de uso de
chaves privadas.
Instrução Normativa nº 10,
de 15.12.2017
Versão 1.0
Criação do DOC-ICP-17.01.
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 4
LISTA DE SIGLAS E ACRÔNIMOS
SIGLA
DESCRIÇÃO
AC
Autoridade Certificadora
AC RAIZ
Autoridade Certificadora Raiz da ICP-Brasil
ACT
Autoridade de Carimbo do Tempo
AES
Advanced Encryption Standard
APF
Administração Pública Federal
API
Application Programming Interface
CAdES
CMS Advanced Electronic Signature
CTR
Counter Mode
DPPSC
Declaração de Prática do Prestador de Serviço de Confiança
EAT
Entidade de Auditoria do Tempo – ICP-Brasil
ETSI
European Telecommunications Standards Institute
HMAC
Hash-based Message Authentication Code
HOTP
HMAC-Based One-Time Password
HSM
Hardware Security Module
HTTPS
Hyper Text Transfer Protocol Secure
ICP-BRASIL
Infraestrutura de Chaves Públicas Brasileira
IETF
Internet Engineering Task Force
ITI
Instituto Nacional de Tecnologia da Informação
JSON
JavaScript Object Notation
KMIP
Key Management Interoperability Protocol
LPA
Lista de Políticas de Assinatura Aprovadas
LPSC
Lista de Prestadores de Serviço de Confiança
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 5
OATH
Open Authentication
PAdES
PDF Advanced Electronic Signature
PCO
Planejamento de Capacidade Operacional
PIN
Personal Identification Number
PSBio
Prestador de Serviço Biométrico
PSC
Prestador de Serviço de Confiança
PKCS
Public Key Cryptography Standards
PUK
PIN Unlock
RFC
Request for Comments
SSL
Secure Sockets Layer
TLS
Transport Layer Security
TOTP
Time-based One-Time Password algorithm
TRC
Teorema do Resto Chinês
TTLV
Tag, type, length, value
XAdES
XML Advanced Electronic Signatures
XML
eXtensible Markup Language
XMPP
Extensible Messaging and Presence Protocol
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 6
1 DISPOSIÇÕES GERAIS
1.1 Este documento tem por finalidade regulamentar os requisitos mínimos de segurança e os
procedimentos operacionais a serem adotados pelos Prestadores de Serviço de Confiança (PSC) de
Assinatura Digital e/ou Armazenamento de Chaves Criptográficas da ICP-Brasil.
1.2 Suplementa, para essas entidades, os regulamentos contidos nos documentos DOC-ICP-03
[1], DOC-ICP-04 [2], DOC-ICP-08 [3] e DOC-ICP-09 [4], tomando como base também a Política
de Segurança da ICP-Brasil – DOC-ICP-02 [5].
1.3 Os requisitos contidos neste documento deverão ser apresentados quando do credenciamento
do PSC para armazenamento de chaves privadas dos usuários finais ou serviços de assinaturas
digitais, verificação de assinaturas digitais, se for o caso, ou ambos e mantidos atualizados durante
seu funcionamento enquanto a entidade estiver credenciada na ICP-Brasil.
1.4 O PSC deverá ter uma Política de Segurança da Informação composta por diretrizes, normas
e procedimentos que descrevem os controles de segurança que devem ser seguidos em suas
dependências e atividades, em consonância com o DOC-ICP-02 [5].
1.5 Deverá existir um exemplar da Política de Segurança da Informação, no formato impresso,
disponível para consulta no Nível 1 (vide regulamento no item 3) de segurança do PSC.
1.6 A Política de Segurança da Informação deverá ser seguida por todo pessoal envolvido nas
atividades realizadas pelo PSC, do seu próprio quadro ou contratado.
1.7 Este documento define normas operacionais e de segurança que deverão ser aplicadas nas
áreas internas ao PSC, assim como no trânsito de informações e materiais com entidades externas,
armazenamento de chaves privadas, serviços de assinatura digital e verificação de assinatura digital.
1.8 A seguir são informados os requisitos que devem ser observados quanto a segurança de
pessoal, segurança física, segurança lógica, segurança de rede, requisitos mínimos para
armazenamento de chaves privadas, serviços de assinatura digital e verificação de assinatura digital,
classificação da informação, salvaguarda de ativos da informação, gerenciamento de riscos, plano
de continuidade de negócios, análise de registros de eventos e plano de capacidade operacional.
2 SEGURANÇA PESSOAL
2.1 O PSC deverá ter uma Política de Gestão de Pessoas que disponha sobre os processos de
contratação, demissão, descrição de cargos, avaliação de desempenho e capacitação.
2.2 A comprovação da capacidade técnica do pessoal envolvido nos serviços prestados pelo
PSC deverá estar à disposição para eventuais auditorias e fiscalizações.
2.3 Todo pessoal envolvido nas atividades realizadas pelo PSC, do próprio quadro ou
contratado, deverá assinar um termo, com garantias jurídicas, que garanta o sigilo das informações
internas e de terceiros, mesmo após a demissão ou o término do contrato.
2.4 O termo de sigilo da informação deverá conter cláusula explícita de responsabilização nos
casos de quebra de regras ou regulamentos da ICP-Brasil.
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 7
2.5 Aplicar-se-á o termo de sigilo de informações a quaisquer outras entidades que porventura
tenham acesso às informações internas e de terceiros originárias dos projetos coordenados pelo
PSC.
2.6 O PSC deverá ter procedimentos formais de apuração e responsabilização em caso de
descumprimento das regras estabelecidas pelas suas políticas ou pelas normas da ICP-Brasil.
2.7 O quadro de pessoal do PSC e contratados deverão possuir um dossiê contendo os seguintes
documentos:
a) contrato de trabalho ou cópia das páginas da carteira de trabalho onde conste o registro da
contratação, termo de posse de servidor ou comprovante de situação funcional;
b) comprovante da verificação de antecedentes criminais;
c) comprovante da verificação de situação de crédito;
d) comprovante da verificação de histórico de empregos anteriores;
e) comprovação de residência;
f) comprovação de capacidade técnica;
g) resultado da entrevista inicial, com a assinatura do entrevistador;
h) declaração em que afirma conhecer as suas atribuições e em que assume o dever de cumprir
as regras aplicáveis da ICP-Brasil;
i) termo de sigilo.
2.8 Não serão admitidos estagiários no exercício fim das atividades do PSC.
2.9 Quando da demissão, o referido dossiê deverá possuir os seguintes documentos:
a) evidências de exclusão dos acessos físico e lógico nos ambientes do PSC;
b) declaração assinada pelo empregado ou servidor de que não possui pendências, conforme
previsto no item sobre processo de liberação do DOC-ICP-02 [5].
3 SEGURANÇA FÍSICA
3.1 Disposições Gerais de Segurança Física
3.1.1 Níveis de acesso
3.1.1.1 São definidos pelo menos 4 (quatro) níveis de acesso físico aos diversos ambientes do PSC.
3.1.1.1.1 O primeiro nível – ou nível 1 – deverá situar-se após a primeira barreira de acesso às
instalações do PSC. O ambiente de nível 1 do PSC na ICP-Brasil desempenha a função de interface
com cliente ou fornecedores que necessita comparecer ao PSC.
3.1.1.1.2 O segundo nível – ou nível 2 – será interno ao primeiro e deverá requerer a
identificação individual das pessoas que nele entram. Esse será o nível mínimo de segurança
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 8
requerido para a execução de qualquer processo operacional ou administrativo do PSC. A passagem
do primeiro para o segundo nível deverá exigir identificação por meio eletrônico e o uso de crachá.
a) o ambiente de nível 2 deverá ser separado do nível 1 por paredes divisórias de escritório,
alvenaria ou pré-moldadas de gesso acartonado. Não deverá haver janelas ou outro tipo
qualquer de abertura para o exterior, exceto a porta de acesso;
b) o acesso a este nível deverá ser permitido apenas a pessoas que trabalhem diretamente com
as atividades de serviços de armazenamento dos certificados para usuários finais e serviços
de assinatura digital e verificação da assinatura digital ou ao pessoal responsável pela
manutenção de sistemas e equipamentos do PSC, como administradores de rede e técnicos
de suporte de informática. Demais funcionários do PSC ou do possível ambiente que esta
compartilhe não deverão acessar este nível;
c) preferentemente, nobreaks, geradores e outros componentes da infraestrutura física deverão
estar abrigados neste nível, para evitar acessos ao ambiente de nível 3 por parte de
prestadores de serviços de manutenção;
d) excetuados os casos previstos em lei, o porte de armas não será admitido nas instalações do
PSC, a partir do nível 2. A partir desse nível, equipamentos de gravação, fotografia, vídeo,
som ou similares, bem como computadores portáteis, terão sua entrada controlada e somente
poderão ser utilizados mediante autorização formal e sob supervisão.
3.1.1.1.3 O terceiro nível – ou nível 3 – deverá situar-se dentro do segundo e será o primeiro
nível a abrigar material e atividades sensíveis da operação do PSC. Qualquer atividade relativa ao
armazenamento de certificados digitais dos usuários e serviços de assinatura digital e verificação da
assinatura digital deverá ser realizada nesse nível. Somente pessoas autorizadas poderão permanecer
nesse nível.
a) no terceiro nível deverão ser controladas tanto as entradas quanto as saídas de cada pessoa
autorizada. Dois tipos de mecanismos de controle deverão ser requeridos para a entrada
nesse nível: algum tipo de identificação individual, como cartão eletrônico, e identificação
biométrica ou digitação de senha;
b) as paredes que delimitam o ambiente de nível 3 deverão ser de alvenaria ou material de
resistência equivalente ou superior. Não deverá haver janelas ou outro tipo qualquer de
abertura para o exterior, exceto a porta de acesso;
c) caso o ambiente de Nível 3 possua forro ou piso falsos, deverão ser adotados recursos para
impedir o acesso ao ambiente por meio desses, tais como grades de ferro estendendo-se das
paredes até as lajes de concreto superior e inferior;
d) deve haver uma porta única de acesso ao ambiente de nível 3, que abra somente depois que
o funcionário tenha se autenticado eletronicamente no sistema de controle de acesso. A porta
deverá ser dotada de dobradiças que permitam a abertura para o lado externo, de forma a
facilitar a saída e dificultar a entrada no ambiente, bem como de mecanismo para
fechamento automático, para evitar que permaneça aberta mais tempo do que o necessário;
3.1.1.1.4 O terceiro nível avançado – ou nível 3.1 –, especificamente para os PSC de
assinatura digital, no interior ao ambiente de nível 3, deverá compreender pelo menos um gabinete
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 9
reforçado trancado, que abrigará todo o hardware e software utilizado pelo PSC de assinatura
digital:
a) para garantir a segurança do material armazenado, os gabinetes deverão obedecer às
seguintes especificações mínimas:
i. ser feitos em aço ou material de resistência equivalente;
ii. possuir tranca com chave.
3.1.1.1.5 O quarto nível – ou nível 4 – especificamente para os PSC de armazenamento de
chaves privadas, interior ao terceiro, é onde deverão ocorrer atividades especialmente sensíveis da
operação do PSC de armazenamento de chaves privadas. Todos os sistemas e equipamentos
necessários a essas atividades deverão estar localizados a partir desse nível. O nível 4 deverá
possuir os mesmos controles de acesso do nível 3 e, adicionalmente, deverá exigir, em cada acesso
ao seu ambiente, a identificação de, no mínimo, 2 (duas) pessoas autorizadas. Nesse nível, a
permanência dessas pessoas deverá ser exigida enquanto o ambiente estiver ocupado.
3.1.1.1.6 No quarto nível, todas as paredes, piso e teto deverão ser revestidos de aço e concreto
ou de outro material de resistência equivalente. As paredes, piso e o teto deverão ser inteiriços,
constituindo uma célula estanque contra ameaças de acesso indevido, água, vapor, gases e fogo. Os
dutos de refrigeração e de energia, bem como os dutos de comunicação, não deverão permitir a
invasão física das áreas de quarto nível. Adicionalmente, esses ambientes de nível 4 – que
constituem as chamadas salas-cofre - deverão possuir proteção contra interferência eletromagnética
externa.
3.1.1.1.7 As salas-cofre deverão ser construídas segundo as normas brasileiras aplicáveis.
Eventuais omissões dessas normas deverão ser sanadas por normas internacionais pertinentes.
3.1.1.2 Poderão existir, no PSC, vários ambientes de terceiro nível avançado, no caso de PSC de
assinatura digital, ou vários ambientes de quarto nível, no caso de PSC de armazenamento de
chaves privadas, para abrigar e segregar, quando for o caso:
a) equipamentos de produção on-line; e
b) equipamentos de rede e infraestrutura (firewall, roteadores, switches e servidores).
3.1.1.3 Todos os servidores e elementos de infraestrutura e proteção do segmento de rede, tais como
roteadores, hubs, switches e firewalls devem:
a) operar em ambiente com segurança equivalente, no mínimo, no terceiro nível avançado para
o caso de PSC de assinatura digital, ou no quarto nível, no caso de PSC de armazenamento
de chaves privadas citados neste documento;
b) possuir acesso lógico restrito por meio de sistema de autenticação e autorização de acesso.
3.1.1.4 Os PSC devem ainda atender aos seguintes requisitos:
a) o ambiente físico do PSC deverá conter dispositivos que autentiquem e registrem o acesso
de pessoas informando data e hora desses acessos;
b) o PSC deverá conter imagens que garantam a identificação de pessoas quando do acesso
físico em qualquer parte de seu ambiente;
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 10
c) é mandatório o sincronismo de data e hora entre os mecanismos de segurança física
garantindo a trilha de auditoria entre dispositivos de controle de acesso físico e de imagem;
d) todos que transitam no ambiente físico do PSC deverão portar crachás de identificação,
inclusive os visitantes;
e) só é permitido o trânsito de material de terceiros pelos ambientes físicos do PSC mediante
registro, garantindo a trilha de auditoria com informações de onde o material passou, a data
e hora que ocorreu o trânsito e quem foi o responsável por sua manipulação;
f) o PSC deverá conter dispositivos de prevenção e controle de incêndios, temperatura,
umidade, iluminação e oscilação na corrente elétrica em todo seu ambiente físico;
g) todo material crítico inservível, descartável ou não mais utilizável deverá ter tratamento
especial de destruição, garantindo o sigilo das informações lá contidas. O equipamento
enviado para manutenção deverá ter seus dados apagados, de forma irreversível, antes de ser
retirado do ambiente físico do PSC;
h) os computadores pessoais, servidores e dispositivos de rede, e seus respectivos softwares,
deverão estar inventariados com informações que permitam a identificação inequívoca;
i) em caso de inoperância dos sistemas automáticos, o controle de acesso físico deverá ser
realizado provisoriamente por meio de um livro de registro onde constará quem acessou, a
data, hora e o motivo do acesso;
j) deverão ser providenciados mecanismos para garantir a continuidade do fornecimento de
energia nas áreas críticas, mantendo os ativos críticos de informação em funcionamento até
que todos os processos e dados sejam assegurados caso o fornecimento de emergência se
esgote;
k) no caso de armazenamento de chaves privadas para usuários finais, deve ter no mínimo dois
ambientes físicos, sendo obrigatoriamente um para operação e outro para contingência;
l) no caso do PSC ser uma AC da ICP-Brasil, pode ser utilizado o nível 4 para abrigo do
hardware criptográfico que armazenará as chaves privadas dos usuários finais, assim como
os serviços de autenticação, desde que em gabinete cadeado, cuja chave do cadeado deve
estar em posse de funcionário distinto dos perfis lógicos do PSC, segregados dos que
operam o ambiente de uma AC;
m) todos os equipamentos e ambiente computacional que serão utilizados no PSC deverão ter
sua data e horário sincronizados com a EAT.
4 SEGURANÇA LÓGICA
4.1 O acesso lógico ao ambiente computacional do PSC se dará no mínimo mediante usuário
individual e senha, que deverá ser trocada periodicamente;
4.2 Todos os equipamentos do parque computacional deverão ter controle de forma a permitir
somente o acesso lógico a pessoas autorizadas;
4.3 Os equipamentos deverão ter mecanismos de bloqueio de sessão inativa;
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 11
4.4 O PSC deverá ter explícita a política de cadastro, suspensão e remoção de usuários em seu
ambiente computacional. Os usuários deverão estar cadastrados em perfis de acesso que permitam
privilégio mínimo para realização de suas atividades;
4.5 Os usuários especiais (a exemplo do root e do administrador) de sistemas operacionais, do
hardware criptográfico, do banco de dados e de aplicações em geral devem ter suas senhas
segregadas de forma que o acesso lógico a esses ambientes se dê por, pelo menos, duas pessoas
autorizadas;
4.6 Todo equipamento do PSC deverá ter log ativo e seu horário sincronizado com uma fonte
confiável do tempo da ICP-Brasil;
4.7 As informações como log, trilhas de auditoria (do armazenamento de chaves privadas e
serviço de assinatura), registros de acesso (físico e lógico) e imagens deverão ter cópia de segurança
cujo armazenamento será de 7(sete) anos;
4.8 Os softwares dos sistemas operacionais, os antivírus e aplicativos de segurança devem ser
mantidos atualizados;
4.9 É vedado qualquer tipo de acesso remoto dos operadores do PSC ao ambiente de nível 3.
5 SEGURANÇA DE REDE
5.1 O tráfego das informações no ambiente de rede deverá ser protegido contra danos ou perdas,
bem como acesso, uso ou exposição indevidos;
5.2 Não poderão ser admitidos acessos externos à rede interna do PSC. As tentativas de acessos
externos deverão ser inibidas e monitoradas por meio de aplicativos que criem barreiras e filtros de
acesso, assim como mecanismos de detecção de intrusão;
5.3 Deverão ser aplicados testes de segurança na rede interna e externa com aplicativos
especializados com periodicidade de, no mínimo, uma vez a cada mês. Os testes na rede deverão ser
documentados e as vulnerabilidades detectadas corrigidas.
6 REQUISITOS PARA ARMAZENAMENTO DE CHAVES PRIVADAS
6.1 Armazenamento das chaves e certificados digitais.
6.1.1 As chaves privadas dos usuários finais, para os tipos de certificados que obrigatoriamente
devem ser gerados e armazenados em hardware criptográficos, devem estar armazenadas dentro dos
espaços (slots), ou equivalente, da fronteira criptográfica e segurança física de um HSM com
certificação Inmetro válida no âmbito da ICP-Brasil, endereçados por conta de usuário;
6.1.2 Esse acesso ou comando de exportação às chaves privadas dos usuários deve ser de uso,
conhecimento e controle exclusivo do titular, sem a possibilidade de ingresso por outros titulares no
mesmo HSM, qualquer funcionário do PSC ou dependentes de outras chaves criptográficas;
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 12
6.1.3 O PSC deve prover mecanismos de duplo fator de autenticação ao titular para acesso à chave
privada, devendo ser um fator dentro da fronteira criptográfica do HSM e outro dentro do ambiente
seguro e primeira interface de comunicação com HSM ou ambos dentro da fronteira criptográfica
do HSM. Cada fator deve ser de uma classe diferente (conhecimento, posse ou biometria). Os
mecanismos de autenticação devem empregar método ou protocolo de validação que proteja a
transmissão e os dados de autenticação por meio de criptografia. Essa funcionalidade será apensada
aos requisitos técnicos na manutenção da certificação Inmetro dos HSM e devem ser:
a) senhas (PIN/PUK): segundo regras da ICP-Brasil;
b) OTP: segundo regras da RFC 6238 (TOTP), RFC 6287, RFC 4226 (HOTP);
c) biometria: segundo regras da ICP-Brasil;
d) certificado de atributo: segundo regras da ICP-Brasil;
e) Push Notification: segundo regras do XMPP extension protocol ou semelhante;
f) outras autenticações semânticas em acordo com esse documento e previamente aprovadas
pela AC Raíz.
6.1.4 Deverá ser feita, em outro ambiente físico de contingência, a cópia das chaves dos usuários
finais, observados os mesmos requisitos de armazenamento do ambiente principal. A entrada do
ambiente de contingência deve ser em até 48 horas.
6.1.5 Esses espaços para armazenamento das chaves privadas dos usuários finais poderão ser
liberados desde que não haja renovação por parte do mesmo ou a revogação da chave, entretanto
deve-se manter o registro de armazenamento das chaves conforme Declaração de Prática do
Prestador de Serviço de Confiança – DPPSC.
6.2 Protocolos
6.2.1 Os HSMs certificados na ICP-Brasil devem suportar a interface PKCS#11, atendendo às
exigências de especificação da ICP-Brasil, além dos relatados nesse documento, os seguintes
requisitos:
a) gerar chaves simétricas especificando os componentes de chaves simétricas em texto claro;
• Gerar par de chaves especificando os componentes de chaves assimétricas em texto
claro. Por exemplo os componentes Módulo, Expoente público, tamanho em bits,
etc;
• Gerar objeto de chaves especificando os componentes de chaves assimétricas (no
mínimo chave pública) em texto claro. Por exemplo os componentes: Módulo,
Expoente público, Expoente Privada em forma reduzida ou em forma de TRC
(Teorema de Resto Chinês);
• Cifrar e decifrar chaves especificando os componentes de chaves simétricas ou
assimétrica em texto claro;
• Exportar e importar chaves (PKCS#12) especificando os componentes de chaves
assimétricas privadas criptografados;
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 13
• Assinar conteúdo especificando os componentes de chaves assimétricas públicas em
texto claro;
• Verificar assinatura especificando os componentes de chaves assimétricas públicas
em texto claro.
b) o módulo criptográfico deve suportar as seguintes chamadas de PKCS#11 (Cryptoki):
• C_Initalize
• C_Finalize
• C_OpenSession
• C_CloseSession
• C_Init_Token
• C_Init_PIN
• C_Login
• C_Logout
• C_CreateObject
• C_DestroyObject
• C_GetAttributeValue
• C_SetAttributeValue
• C_EncryptInit
• C_Encrypt
• C_DecryptInit
• C_Decrypt
• C_DigestInit
• C_Digest
• C_DigestKey
• C_SignInit
• C_Sign
• C_VerifyInit
• C_Verify
• C_GenerateKey
• C_GenerateKeyPair
• C_DeriveKey
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 14
• C_GenerateRandom
• C_WrapKey
• C_UnwrapKey
c) sendo obrigatória a implementação das seguintes funções:
• C_GenerateKey especificando templates de chaves simétricas;
• C_GenerateKeyPair especificando templates de chaves assimétricas;
• C_Sign para realizar assinatura de um conteúdo;
• C_Verify para verificar a assinatura de um conteúdo;
• C_Encrypt para cifrar um dado com uma chave já construída;
• C_Decrypt para decifrar um dado com uma chave já construída;
• C_CreateObject especificando templates de chaves assimétricas (no mínimo chave
pública);
• C_DestroyObject especificando o handle do objeto.
6.2.2 Os HSMs certificados na ICP-Brasil devem suportar o protocolo Key Management
Interoperability Protocol – KMIP, versão 1.3 ou superior, devendo seguir, além dos relatados nesse
documento, os seguintes requisitos:
6.2.2.1 Os PSC devem definir um conjunto de operações que se aplicam aos objetos gerenciados,
relacionados ao conjunto normativo do PSC e ao ciclo de vida das chaves, que por sua vez
consistem em atributos, como mostrado, em exemplo, na tabela a seguir.
Operações do Protocolo
Objetos Gerenciados
Atributos dos Objetos
Create
Certificate
Unique Identifier
Create Key Pair
Symmetric Key
Name
Register
Public Key
Object Type
Re-key
Private Key
Cryptographic Algorithm
Derive Key
Split Key
Cryptographic Length
Certify
Secret Data
Cryptographic Parameters
Re-certify
Key Block (para chaves) ou
Certificate Type
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 15
Value (para certificados)
Locate
Certificate Issuer
Check
Certificate Subject
Get
Digest
Get Attributes
Operation Policy Name
Get Attribute List
Cryptographic Usage Mask
Add Attribute
Lease Time
Modify Attribute
Usage Limits
Delete Attribute
State
Obtain Lease
Initial Date
Get Usage Allocation
Activation Date
Activate
Process Start Date
Revoke
Protect Stop Date
Destroy
Deactivation Date
Archive
Destroy Date
Recover
Compromise Occurrence
Date
Validate
Compromise Date
Query
Revocation Reason
Cancel
Archive Date
Poll
Object Group
Link
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 16
Application Specific ID
Contact Information
Last Change Date
Custom Attribute
6.2.2.2 Os objetos base são:
a) os componentes dos objetos gerenciados.
i. Atributo: identificado pelo seu nome;
ii. Key Block, contém o valor da chave;
b) os elementos do protocolo de mensagens;
c) os parâmetros das operações.
6.2.2.3 Os objetos criptográficos gerenciáveis são:
a) Certificado, com o tipo e valor;
b) Chave Simétrica, com o Key Block;
c) Chave Pública, com o Key Block;
d) Chave Privada, com o Key Block;
e) Chave Dividida, com o par e o Key Block;
f) Dados Reservados, com o tipo e o Key Block.
6.2.2.4 Os atributos contêm os metadados de um objeto gerenciável, nos quais:
a) número identificador único, estado, entre outros;
b) os atributos devem ser pesquisados com a operação “locate”.
6.2.2.5 Os atributos podem ser configurados, modificados e apagados quando a especificação KMIP
permitir esses pelo cliente.
6.2.2.6 Os valores das estruturas de codificações (TTLV, definição dos valores, Text String,
Structure, Byte String, Integer, Big Integer, Long Integer, Boolean, Date-Time e Enumerations),
dos campos dos objetos, dos atributos, dos formatos e conteúdos das mensagens, da manipulação de
erros e dos parâmetros (solicitação e resposta) das operações cliente/servidor devem seguir
integralmente o estabelecido neste documento e no Key Management Interoperability Protocol
Specification Version 1.3, OASIS Standard, 27 December 2016, ou versionamento superior.
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 17
NOTA: O ITI poderá requisitar aos PSC em credenciamento ou credenciados testes dos modelos
descritos, ou outras versões, nos sítios https://www.snia.org/forums/ssif/kmip, http://docs.oasis-
open.org/kmip/profiles/v1.3/csd01/kmip-profiles-v1.3-csd01.html ou equivalente.
6.2.2.7 A criação do usuário deve seguir o estabelecido a seguir (xml):
<RequestMessage>
<RequestHeader>
<ProtocolVersion>
<ProtocolVersionMajor type="Integer" value="1"/>
<ProtocolVersionMinor type="Integer" value="3"/>
</ProtocolVersion>
<Authentication>
<Credential>
<CredentialType type="Enumeration"
value="UsernameAndPassword"/>
<CredentialValue>
<Username type="TextString" value="vco_test"/>
<Password type="TextString" value="Teste112233$"/>
</CredentialValue>
</Credential>
</Authentication>
<BatchCount type="Integer" value="1"/>
</RequestHeader>
<BatchItem>
<Operation type="Enumeration" value="CreateUser"/>
<RequestPayload>
<UserName type="TextString" value="labsec-pw"/>
<UserType type="Enumeration" value="User"/>
</RequestPayload>
</BatchItem>
</RequestMessage>
6.2.2.8 Para a operação do duplo fator de autenticação do titular da chave privada, poderá ser criada
uma nova extensão ao tipo de credencial, conforme relatado a seguir:
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 18
6.2.2.9 Para o novo tipo de credencial deve ser configurado o seguinte:
a) Credential Type: TOKEN
Object
Encoding
Required
Description
Credential Value
Structure
Token
Text String
Yes
Valor atual do “TOKEN”
b) fluxo de uso
i. durante o credenciamento, o PSC deve requisitar a criação de um novo usuário (via
KMIP), indicando que o mesmo necessita de um segundo fator de autenticação para
utilizar seus objetos e cadastrando seu nome de usuário e senha. O PSC indica ao
usuário como instalar seu aplicativo de Token.
ii. o “TOKEN” do usuário deve ser inicializado para sincronizar seus dados. Esse
processo pode ser feito pelo próprio usuário através do aplicativo de “TOKEN” via
KMIP no momento da primeira conexão utilizando seu usuário e senha. O HSM gera
então a chave que será utilizada no “TOKEN”.
iii. na posse de seu “TOKEN” sincronizado e de seu usuário e senha, o usuário pode
então criar sua chave no HSM utilizando a aplicação do PSC diretamente via
comando KMIP.
iv. o usuário já pode utilizar sua chave criada anteriormente utilizando o aplicativo do
PSC, de posse de sua Senha + Token.
6.2.2.10 Este mecanismo de “TOKEN” deve ser configurado na área de execução segura do
HSM.
NOTA: Pode ser encontrada mais referências sobre o protocolo KMIP no sítio https://www.oasis-
open.org/committees/tc_home.php?wg_abbrev=kmip.
6.2.2.11 As soluções do PSC deverão garantir a portabilidade da chave privada do usuário
conforme o descritivo:
a) glossário:
CP
r
U
i
: Chave privada do usuário 'i', armazenada no HSM 1, a ser exportada e importada
para o HSM 2;
CP
r
H
e
2
: Chave privada do HSM 2, a ser utilizada para importação de chaves privadas de
usuários gravadas no HSM 1;
CP
u
H
e
2
: Chave Pública do HSM 2, utilizada para exportação de chaves privadas de
usuários armazenadas no HSM 1, a serem importadas pelo HSM 2. CP
u
H
e
2
deve ser
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 19
armazenada no repositório do ITI, seguindo procedimentos já estabelecidos (CP
u
H
e
2
pode ser transformada em um certificado digital);
CS
i
: Chave simétrica a ser gerada pelo HSM 1, para exportação da chave privada do
usuário 'i', CP
r
U
i
. CS
i
é utilizada para cifração da chave privada do usuário 'i';
Algo
s
: Algoritmo criptográfico simétrico, de sigilo, pode ser o AES ou Serpent, com
modo de operação CTR e tamanho de chave 256 bits.
b) usuário deve solicitar, assinando digitalmente, uma requisição, que estará disponível no sítio
dos PSCs, de portabilidade de sua chave privada, de exportação no PSC atual e de
importação no PSC de destino.
c) os PSCs receberão essa requisição e autorizarão essa portabilidade com os três perfis
(administrador, auditor e operador). Assim que receber a autorização do usuário, PSC 1 e
PSC 2 devem iniciar os procedimentos de exportação e importação.
d) os PSCs devem estabelecer uma conexão ponta a ponta em um canal seguro de comunicação
(HTTPS com dupla autenticação por certificado digital ICP-Brasil).
e) Modo Operacional:
i. procedimentos preliminares:
[a] Cada PSC gera um par de chaves ([CP
u
H
e
, CP
r
H
e
] - pública e privada) em cada
um de seus HSMs. Este par tem como propósito prover portabilidade entre HSMs de
quaisquer PSCs. Este par de chaves deve ser utilizado em possível exportação de
chaves privadas de usuário, Cp
r
U
i
e também na assinatura das requisições para
envelopamento utilizando a sua chave pública. Por analogia, para a chave CP
u
H
e
, 'C'
significa 'Chave', P
u
chave Pública, e H
e
significa chave gerada pelo HSM para
exportação de chave do usuário 'i', CP
r
U
i
. De forma similar, CP
r
H
e
e CP
r
U
i
têm
significados equivalentes;
[b] CP
u
H
e
é armazenada em repositório do ITI, e CP
r
H
e
é mantida no HSM de
origem;
ii. para exportação de chaves privadas dos usuários contidas no HSM 1 para o HSM 2:
[c] No PSC importa-se para o HSM 1 a chave pública do HSM 2, CPuHe2, do
repositório do ITI;
[d] No HSM 1 gera-se uma chave de sessão simétrica, CS
i
, distinta, para cada chave
privada de usuário a ser exportada;
[e] No HSM 1 cifra-se a chave simétrica, CSi, com a chave pública do HSM 2,
CP
u
H
e
2
, de destino, para exportação da chave do usuário 'i', CP
r
U
i
;
[f] No HSM 1 cifra-se a chave privada do usuário 'i', CP
r
U
i
, antes do procedimento
de exportação de chaves, com a chave simétrica gerada, CS
i
, com o algoritmo de
sigilo padrão AES ou Serpent, com o modo de operação CTR e tamanho de chave de
256 bits;
[g] No HSM 1 apaga-se cada chave de sessão simétrica gerada, CS
i
, após o
procedimento de cifração do item 'f' ter sido executado;
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 20
[h] Após a cifração da chave privada do usuário 'i', CP
r
U
i
, ter sido realizada com
sucesso, exporta-se essa chave, e a chave Cs
i
cifrada, para o HSM 2;
iii. para importação de chaves privadas dos usuários contidas no HSM 1 para o HSM 2:
[i] O administrador do HSM 2, de destino, cria novo usuário e o habilita;
[j] O usuário importa do HSM 1 sua chave privada e a chave simétrica cifrada, itens
'e' e 'f';
[k] No HSM 2, de destino, recebe-se a chave privada CP
r
U
i
e a chave simétrica CS
i
cifradas, do usuário 'i';
[l] No HSM 2 decifra-se a chave simétrica, CS
i
, com a chave privada do HSM 2,
CP
r
H
e
2
;
[m] Em seguida, no HSM 2 decifra-se a chave privada do usuário 'i', CP
r
U
i
, que
estava no HSM 1, com a chave simétrica CS
i
, com o algoritmo criptográfico padrão
AES ou Serpent, com o modo de operação CTR e tamanho de chave de 256 bits;
[n] No HSM 2 grava-se a chave privada do usuário 'i', CP
r
U
i
, já decifrada, e
importada do HSM 1;
[o] No HSM 2 destrói-se a chave simétrica CS
i
;
[p] O PSC 2 encaminha para o PSC 1 mensagem indicando que a importação ocorreu
satisfatoriamente. Então, o HSM 1 apaga a chave privada do usuário 'i', CP
r
U
i
.
6.3 Rede
6.3.1 Poderá ser arquitetado um pool de HSM para operação, replicação e gerenciamento das
chaves dos usuários finais, devendo seguir, além dos relatados nesse documento, os seguintes
requisitos.
a) especificação e estabelecimento de uma comunicação segura (sessão SSL/TLS) ou
equivalente entre os HSM;
b) os HSM poderão estar em ambientes distintos desde que os mecanismos de acesso e
segurança se mantenham os descritos neste documento.
6.3.2 Os PSC no âmbito da ICP-Brasil devem atender aos critérios mínimos de 99,99% de “nível
de tempo de atividade” (uptime) a ser verificado por mês.
6.4 Requisitos para serviços de confiança de uso de chaves privadas
6.4.1 Definições para Interface de Serviços de Confiança
6.4.1.1 Deverá ser utilizado o protocolo TLS, definido pela RFC 5246 ou a versão atualizada, para
comunicação com serviços de confiança.
6.4.1.2 Deverá ser utilizado o framework OAuth 2.0 (RFC 6749 e RFC 7636) para implementação
da interface aos serviços de confiança dos PSC.
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 21
6.4.1.3 Adicionalmente, poderá ser implementada outra interface para os serviços de confiança,
desde que o PSC proveja o software necessário para possibilitar ao titular o uso das suas chaves
privadas de forma segura.
6.4.2 Definições para URI de base para Serviços de Confiança
6.4.2.1 A URI de base – URI-base – definirá o estilo e formato dos endereços HTTPS de serviços
de confiança.
6.4.2.2 A URI de base conterá número correspondendo à versão de API definida pela ICP-Brasil.
6.4.2.3 Este documento trata da versão “v0” de API para PSC.
6.4.2.4 Exemplo de URI-base:
https://servico.provedor_de_servico.com.br/v0/
NOTA: O endereço servico.provedor_de_servico.com.br representa neste exemplo a porção
authority da URI em domínio utilizado pelo PSC.
6.4.2.5 As demais porções de URI presentes neste documento devem ser concatenadas à URI-base.
6.4.3 Autorização e Autenticação para Requisição de Serviços
6.4.3.1 Fluxo básico para Uso de Serviços de Confiança
6.4.3.1.1 Seguindo o fluxo de autorização estabelecido pela RFC 6749, o uso de chaves
privadas em PSC deverá ser precedido de solicitação bem-sucedida, por parte de aplicações, dos
seguintes serviços:
a) Código de Autorização
b) Token de Acesso
c) Assinatura
6.4.3.1.2 Quando for necessário utilizar serviço de confiança destinado somente à autenticação
do titular, ou seja, sem o uso de chave privada, deverá ser precedido de solicitação bem-sucedida,
por parte de aplicações, dos seguintes serviços:
a) Código de Autorização
b) Token de Acesso
c) Recuperação de Certificado
6.4.3.2 Trânsito de Fatores de Autenticação
6.4.3.2.1 As aplicações não deverão coletar fatores de autenticação do titular. Para este fim, os
PSC deverão se comunicar diretamente com equipamento do titular, previamente identificado e
cadastrado junto ao PSC de forma segura.
6.4.3.2.2 Excetua-se desta regra o Serviço “Autorização com Credenciais do Titular”.
6.4.3.3 Autenticação de Aplicações de Assinatura
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 22
6.4.3.3.1 Para obter acesso aos serviços de confiança, os PSC deverão implementar
obrigatoriamente o Serviço de Cadastro de Aplicação com Certificado ICP-Brasil para SSL.
6.4.3.3.2 O PSC poderá também implementar Serviços de Confiança Opcionais para Cadastro
de Aplicação sem Certificado, Token de Acesso para Aplicações e Manutenção de Aplicações.
6.4.3.3.3 Os PSC poderão implementar, para as aplicações, outros métodos de acesso aos seus
serviços, desde que os riscos associados sejam avaliados e possibilitem rastreabilidade.
6.4.4 Relação de Serviços de Confiança Disponibilizados por PSC
a) Serviços de Confiança Obrigatórios
i. Código de Autorização
ii. Token de Acesso
iii. Assinatura
iv. Cadastro de Aplicação com Certificado
v. Listagem de Certificados do Titular
vi. Localização de Titular
vii. Recuperação de Certificado
b) Serviços de Confiança Opcionais
i. Cadastro de Aplicação sem Certificado
ii. Token de Acesso para Aplicação
iii. Manutenção de Aplicação
iv. Autorização com Credenciais do Titular
6.4.5 Detalhamento de Serviços de Confiança Obrigatórios
6.4.5.1 Serviços de Autorização
6.4.5.1.1 Código de Autorização (Authorization Code Request)
a) Serviço para obter do titular a autorização de uso da sua chave privada ou autorizar
autenticação sem uso da chave privada.
b) Caso o titular possua mais de um certificado, o PSC deverá apresentá-los para que o titular
faça a escolha no mesmo contexto de aplicação em que transitarem os fatores de
autenticação.
c) Caberá ao PSC apresentar ao titular o escopo da solicitação (vide parâmetro “scope”
abaixo), permitindo a diferenciação inequívoca de solicitações que envolvam assinaturas
daquelas que tratam somente de autenticação. Esta apresentação deverá ser feita durante o
trânsito de fatores de autenticação.
i. Solicitação
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 23
• Path : <URI-base>/oauth/authorize;
• Método HTTPS: GET;
• Parâmetros da requisição: concatenados após o Path como parâmetros http query,
usando o formato "application/x-www-form-urlencoded":
o response_type: obrigatório, valor "code";
o client_id: obrigatório, deve conter a identificação da aplicação;
o redirect_uri: opcional, deve ter a URI para redirecionar o usuário de volta
para a aplicação de origem. A URI deve estar na lista de URI's
autorizadas para a aplicação. Deve ser URL ENCODED. Se não
informado, será considerada a primeira URI cadastrada para a aplicação;
o state: opcional, é retornado sem modificações para aplicação de origem;
▪ Recomendado. Um valor opaco usado pela aplicação para manter
o estado entre a requisição e a resposta. O serviço de autorização
incluirá este valor ao redirecionar o módulo do usuário de volta ao
endereço da aplicação. Este parâmetro deverá ser usado para
prevenir ataques de falsificação de requisições entre sites (cross-
site request forgery).
o lifetime: opcional, indica o tempo de vida desejado para o token a ser
gerado. Inteiro, em segundos;
o scope: opcional, se não informado, será considerado
"authentication_session". (ver lista de escopos abaixo). Possíveis valores
para o parâmetro:
▪ single_signature: token que permite a assinatura de apenas um
conteúdo (hash), sendo invalidado apos a sua utilização;
▪ multi_signature: token que permite a assinatura de múltiplos
hashes em uma única requisição, sendo invalidado apos a sua
utilização;
▪ signature_session: token de sessão OAuth que permite várias
assinaturas em várias chamadas a API, desde que o token esteja
dentro do prazo de validade ou que não tenha sido revogado pela
aplicação ou pelo usuário;
▪ authentication_session: token de sessão OAuth para autenticação
do titular, não permitindo a realização de assinaturas ou outras
utilizações da chave privada.
o code_challenge: obrigatório, ver RFC 7636
o code_challenge_method: obrigatório, valor “S256” (ver RFC 7636).
o login_hint: opcional, valor de CPF ou CNPJ a ser informado como filtro
para seleção do certificado a ser utilizado.
ii. Resposta da Requisição de Código de Autorização:
1. Se o usuário autorizar a solicitação, o PSC emite um código de autorização com
tempo de validade curto e retorna para aplicação cliente com uma URI de
redirecionamento contendo os seguintes parâmetros no componente http query,
usando o formato "application/x-www-form-urlencoded":
• code: obrigatório, código de autorização gerado pelo PSC, a ser usado na
solicitação do token de acesso;
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 24
• state: obrigatório caso tenha sido informado na requisição, deverá conter
o que foi enviado na requisição.
2. Se o usuário não autorizar a solicitação, o PSC retorna para aplicação cliente
através de sua redirect_uri os seguintes parâmetros via http query, usando o
formato "application/x-www-form-urlencoded":
• error: obrigatório, com o valor “user_denied”;
• state: obrigatório caso tenha sido informado na requisição, deverá conter
o que foi enviado na requisição.
6.4.5.1.2 Token de Acesso
Após a obtenção de código de autorização, o token de acesso deve ser solicitado com parâmetros no
formato "application/x-www-form-urlencoded".
a) Solicitação
• Path : <URI-base>/oauth/token;
• Método HTTPS: POST;
• Parâmetros da requisição: formato "application/x-www-form-urlencoded"
o grant_type: obrigatório, valor "authorization_code";
o client_id: obrigatório, deve conter a identificação da aplicação;
o client_secret: obrigatório, deve conter o segredo associado à aplicação;
o code: obrigatório, deve conter código de autorização retornado do Serviço
Código de Autorização;
o redirect_uri: opcional, deve ser igual ao informado no Serviço Código de
Autorização;
o code_verifier: obrigatório, correspondendo a code_challenge enviado na
Requisição de Código de Autorização, ver RFC 7636.
Exemplo:
POST {.../oauth/token} HTTP/1.1
Host: {servidor do PSC}
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&client_id=MyApplicationId
&client_secret=123qwe
&code=09b30f74d40a7fece1a26cccc97746c364e61022
&redirect_uri=https://idg.receita.fazenda.gov.br
&code_verifier={Verifier}
b) Resposta da Requisição de Token de Acesso:
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 25
i. Se a requisição é valida e autorizada o PSC emite um token de acesso e retorna a
requisição com sucesso, via HTTP Status Code 200.
• Parâmetros de retorno: formato "application/json;charset=UTF-8"
o access_token: obrigatório, valor do token de acesso;
o token_type: obrigatório, valor "Bearer";
o expires_in: obrigatório, valor inteiro com validade do token em segundos.
Para acesso a objeto de pessoas físicas não deve ultrapassar (7 dias), sendo
que para pessoas jurídicas este limite será de (30 dias);
o scope: opcional, deve ser informado se o escopo retornado for diferente do
solicitado pela aplicação;
▪ authorized_identification_type: obrigatório, deverá conter “CPF” ou
“CNPJ”
▪ authorized_identification: obrigatório, valor correspondendo ao CPF
ou CNPJ associado ao titular do certificado.
Exemplo:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "b923575f1ced0ee732ee274b2e02784040bd9606",
"expires_in": 300,
"token_type": "Bearer
"authorized_identification_type": "CPF
"authorized_identification": 00000000001
}
NOTA: Não será permitido o refresh_token.
ii. Se a requisição não for válida, houver falha na autenticação da aplicação cliente ou
alguma outra falha, o PSC retorna a requisição com erro, via HTTP Status Code de
erro correspondente à situação ocorrida via JSON com os seguintes parâmetros:
• Parâmetros de retorno: formato "application/json;charset=UTF-8":
o error: obrigatório, representa o código do erro. Possíveis valores para o
parâmetro e HTTP Status Code de erro:
▪ invalid_request: HTTP Status Code 400, ocorre quando algum
parâmetro obrigatório não tiver sido informado ou inclui um valor
de parâmetro não suportado ou algum parâmetro com valor
duplicado informado ou a requisição é mal formada;
▪ invalid_grant: HTTP Status Code 400, ocorre quando o código de
autorização apresentado estiver inválido ou expirado ou tiver sido
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 26
emitido para uma outra aplicação cliente diferente da informada
ou já estiver sido utilizado em um cenário de uso único(scope
single_signature e multi_signature). Ocorre também na validação
da redirect_uri e na validação do code_verifier(ver RFC 7636);
▪ invalid_client: HTTP Status Code 401, ocorre quando houver
falha na autenticação da aplicação cliente, desde aplicação não
identificada até credenciais inválidas;
▪ unsupported_grant_type: HTTP Status Code 400, ocorre quando o
valor informado no parâmetro grant_type não for suportado.
▪ server_error: HTTP Status Code 500, ocorre quando houver
algum erro interno não tratado pelo PSC.
o error_description: opcional, texto com informações adicionais
descrevendo o erro a fim de assistir o entendimento do ocorrido;
o error_uri: opcional, URI de uma página WEB que contém informações
sobre o erro ocorrido.
Exemplo:
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
“error”: “invalid_request”,
“error_description”: “Parâmetro obrigatório não informado: code”,
“error_uri”:“https://psc.exemplo.com.br/docs/oauth2-error#invalid_request”
}
6.4.5.2 Assinatura
6.4.5.2.1 Os parâmetros com conteúdo a ser assinado e assinaturas deverão conter valores em
Base64.
6.4.5.2.2 As assinaturas RAW estarão em Base64.
6.4.5.2.3 Assinaturas CMS estarão em formato CMS PEM de acordo com RFC 7468: o
cabeçalho e rodapé CMS são obrigatórios; quebra de linha e espaços no conteúdo são opcionais; e
as aplicações devem estar preparadas para lidar com diferentes formas de espaços e quebra de
linhas no conteúdo, ou com a ausência destes.
6.4.5.2.4 Se o escopo do token permitir apenas uma assinatura (single_signature) e for
informado mais de um conteúdo, uma mensagem de erro deve ser retornada.
6.4.5.2.5 Se o escopo for omitido ou assinalado para autenticação (authentication_session)
uma mensagem de erro deve ser retornada.
a) Solicitação
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 27
• Path: <URI-base>/oauth/signature
• Método HTTPS: POST
• Cabeçalho:
o Content-type: application/json;
o Accept : application/json;
o Authorization: Bearer access_token;
• Parâmetros: formato "application/json;charset=UTF-8":
o certificate_alias: opcional, identificador do certificado correspondente à
chave utilizada na assinatura;
o hashes: conjunto com valores obrigatórios a serem assinados. Cada
elemento do conjunto conterá:
▪ id: identificador do conteúdo a ser assinado;
▪ alias: forma legível do identificador do conteúdo;
▪ hash: conteúdo a ser assinado;
▪ hash_algorithm: Object Identifier (OID) do algoritmo de hash.
Por exemplo, para SHA256 utilize o OID 2.16.840.1.101.3.4.2.1;
▪ signature_format: deverá conter um dos valores:
• “RAW”,
• “CMS”
Exemplo
"hashes": [{
"id": "Signature request ID 1",
"alias": "Contrato de aluguel XPTO",
"hash": "hash to sign",
"hash_algorithm": "2.16.840.1.101.3.4.2.1",
“signature_format”: “RAW”
},
{
"id": "Signature request ID 2",
"alias": "Documento do Word",
"hash": "hash to sign",
"hash_algorithm": "2.16.840.1.101.3.4.2.1",
“signature_format”: “CMS”
}
{
"id": "Signature request ID n",
"alias": "Firefox",
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 28
"hash": "hash to sign",
"hash_algorithm": "2.16.840.1.101.3.4.2.1",
“signature_format” : “RAW”
}
]}
b) Resposta da Requisição de Assinatura:
O PSC retornará a requisição com sucesso, via HTTP Status Code 200.
• Parâmetros: formato "application/json;charset=UTF-8":
o certificate_alias: obrigatório, identificador do certificado correspondente à chave
utilizada na assinatura;
o signatures: obrigatório, conjunto com identificadores dos conteúdos assinados e
valores assinados. Cada elemento do conjunto conterá:
▪ id: identificador do conteúdo assinado;
▪ Um dos formatos abaixo:
• caso a solicitação tenha sido feita com “signature_format : RAW”
o raw_signature: valor numérico em base64 da assinatura
produzida.
• caso a solicitação tenha sido feita com “signature_format : CMS”
o CMS detached (PKCS#7), contendo os seguintes atributos
assinados:
▪ contentType
▪ signingTime (hora do PSC)
▪ messageDigest (hash informado pela aplicação na
requisição)
▪ signingCertificateV2 (certificado do assinante)
NOTA: Os valores de assinatura deverão produzidos de acordo com a suíte de assinatura, se esta
for informada.
Exemplo
{
"certificate_alias": "CERTIFICADO TESTE 1:1234567889",
"signatures": [{
"id": "Signature request ID 1",
"raw_signature": "my raw signature base64"
},
{
"id": "Signature request ID 2",
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 29
"raw_signature": "my raw signature base64"
},
{
"id": "Signature request ID n",
"raw_signature": "my raw signature base64"
}]}
6.4.5.3 Cadastro de Aplicação com Certificado
6.4.5.3.1 Serviço para cadastro de uma aplicação junto ao PSC, sendo que a aplicação utilizará
um certificado SSL ICP-Brasil para assinar os dados enviados, substituindo neste caso o Serviço de
Cadastro de Aplicação.
6.4.5.3.2 A assinatura dos dados necessários para o cadastro será realizada utilizando o
formato JWT with RSA Signature, conhecido como JWS – Json Web Signature (ver RFC 7515),
utilizando o algoritmo de hash SHA-256.
O header do JWS deverá conter os seguintes parâmetros:
• alg: obrigatório, valor “RS256” representando RSA With SHA-256;
• x5c: obrigatório, valor multivalorado contendo o certificado SSL ICP-Brasil no
formato PEM.
Exemplo do Header do JWS desserializado:
{
“alg”: “RS256”,
"x5c": [“-----BEGIN CERTIFICATE-----ADFAASDFASDFAS. . . -----END CERTIFICATE-----
”]
}
O conjunto de dados JWS deverá conter os seguintes parâmetros:
• name: obrigatório, nome da aplicação;
• comments: obrigatório, descrição da aplicação;
• redirect_uris: obrigatório, valor multivalorado contendo URI’s autorizadas para
redirecionamento (para serviços de requisição de autorização). Devem ser oriundas do
host do certificado de equipamento apresentado, sendo vedada a utilização de
fragments;
• host: obrigatório, valor contendo o host único da aplicação;
• aud: obrigatório, valor contendo o nome único do PSC a qual a assinatura é direcionada.
• email: obrigatório, e-mail para suporte em caso de indisponibilidade, mudança de
versão, entre outros.
Exemplo do Payload do JWS deserializado:
{
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 30
"name": "Nome da Aplicação",
"comments": "Descrição da Aplicação",
"host": "www.aplicacao-exemplo.com",
"redirect_uris": ["https://www.aplicacao-exemplo.com/callback/certificado_nuvem"],
"aud": "nome-unico-psc"
"email": "psc@psc.com.br"
}
a) Solicitação
• Path: <URI-base>/oauth/application_cert
• Método HTTPS: POST
• Cabeçalho:
o Accept: application/octet-stream;
o Body: string contendo o JWS serializado.
b) Resposta do Serviço de Cadastro de Aplicação com Certificado
• Parâmetros: formato "application/json;charset=UTF-8" :
o client_id: obrigatório, identificador único da aplicação gerado pelo PSC;
o client_secret: obrigatório, credencial da aplicação gerada de forma aleatória pelo
PSC;
6.4.5.4 Recuperação de Certificado
Serviço para recuperar certificado armazenado no PSC.
A aplicação deverá ter um Access Token válido.
a) Solicitação
• Path : <URI-base>/oauth/certificate-discovery;
• Método HTTPS: GET
• Cabecalho
o Content-type: application/json;
o Accept: application/json;
o Authorization: Bearer access_token;
• Parâmetros da requisição: concatenados após o Path como parâmetros http query,
utilizando o formato “application/x-form/urlencoded”
o certificate_alias: opcional, é o identificador do certificado a ser recuperado.
b) Resposta
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 31
• Parâmetros
o status: obrigatório, indicando “S” para resultado positivo ou “N” caso contrário;
o certificates: certificado em BASE64 recuperado;
Exemplo
{
"status": "S"
"certificates": [
{
"alias": "CERTIFICADO TESTE 1:123456789
"certificate": "-----BEGIN CERTIFICATE-----\n{CERTIFICADO}\n-----END
CERTIFICATE-----”,
}
{
"alias": "CERTIFICADO TESTE 2:123456789
"certificate": "-----BEGIN CERTIFICATE-----\n{CERTIFICADO}\n-----END
CERTIFICATE-----”,
}
]
}
6.4.5.5 Localização de Titular
Serviço para encontrar um titular mediante informação de CPF ou CNPJ.
a) Solicitação
• Path: <URI-base>/oauth/user-discovery;
• Método HTTPS: POST;
• Parâmetros da requisição: formato "application/json;charset=UTF-8":
o client_id: obrigatório, deve conter a identificação da aplicação;
o client_secret: obrigatório, deve conter o segredo associado à aplicação;
o user_cpf_cnpj: obrigatório, deve conter “CPF” para pessoa física ou “CNPJ”
pessoa jurídica;
o val_cpf_cnpj: obrigatório, deve conter o valor do cpf ou cnpj;
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 32
b) Resposta
• Parâmetros
o slots: opcional, matriz com os alias de slots encontrados, composto pelos pares
ordenados slot_alias e label;
o status: obrigatório, indicando “S” para resultado positivo ou “N” caso contrário;
Exemplo
{
"slots": [
{
"slot_alias": "12345678899-1",
"label": "A3 PESSOAL"
}
{
"slot_alias": "12345678899-2",
"label": "A3 TRABALHO"
}
],
"status": "S”
}
6.4.6 Detalhamento de Serviços de Confiança Opcionais
6.4.6.1 Cadastro de Aplicação sem Certificado
Serviço para cadastro de uma aplicação junto ao PSC. É obrigatório para todas as aplicações que
utilizarem serviços de autorização sem certificados ICP-Brasil.
a) Solicitação
• Path : <URI-base>/oauth/application
• Método HTTPS: POST
• Cabeçalho:
o Content-type: application/json ;
o Accept: application/json;
• Parâmetros: formato "application/json;charset=UTF-8" :
o name: obrigatório, nome/descrição da aplicação;
o comments: obrigatório, observações gerais de uso da aplicação;
o redirect_uris: obrigatório, URI’s autorizadas para redirecionamento (para
serviços de código de autorização).
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 33
o email: obrigatório, e-mail para suporte em caso de indisponibilidade, mudança de
versão, entre outros.
Exemplo:
{
"name": "(Nome/Descricao da aplicacao)",
"comments": "(Observacoes gerais de uso da aplicacao)",
"redirect_uris": [
"URI 1 pre cadastrada para redirecionamento",
"URI 2 pre cadastrada para redirecionamento",
"URI N pre cadastrada para redirecionamento"
]
"email": "psc@psc.com.br"
}
b) Resposta da Requisição de Cadastro de Aplicação
• Parâmetros: formato "application/json;charset=UTF-8" :
o client_id: identificador da aplicação;
o client_secret: segredo associado à aplicação;
o status: obrigatório, “success" para sucesso;
o message: obrigatório, mensagem com informações adicionais.
Exemplo:
{
"client_id": "(identificador da aplicacao)",
"client_secret": "(segredo da aplicacao)",
"status": "success",
"message": "Aplicacao cadastrada com sucesso"
}
6.4.6.2 Serviços de Manutenção de Cadastro de Aplicação
Serviço para manutenção das informações armazenadas de uma aplicação no PSC. É obrigatório
para todas as aplicações que utilizarem serviços de autorização não identificadas por certificados
ICP-Brasil para SSL.
6.4.6.2.1 Token de Acesso para Aplicação
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 34
Requisição para que uma aplicação obtenha token de acesso para manutenção de seu cadastro junto
ao PSC.
a) Solicitação
• Método HTTPS : POST;
• Path: <URI-base>/oauth/client_token;
• Parâmetros da requisição: formato "application/x-www-form-urlencoded":
o grant_type, obrigatório, valor "client_credentials";
o client_id, obrigatório, deve conter a identificação da aplicação;
o client_secret, obrigatório para aplicações que possuem certificado digital;
Exemplo
POST {.../oauth/client_token} HTTP/1.1
Host: {servidor do PSC}
Content-Type: application/x-www-form-urlencoded
client_id=Identificacao_aplicacao
&client_secret=123qwe
&grant_type=client_credentials
b) Resposta da Requisição de Token de Acesso para Aplicações:
• Parâmetros de retorno: formato "application/json;charset=UTF-8" :
o access_token, obrigatório, valor do token de acesso;
o token_type, obrigatório, valor "Bearer";
o expires_in, opcional, validade do token em segundos.
Exemplo:
{
"access_token": "b923575f1ced0ee732ee274b2e02784040bd9606",
"expires_in": 7200,
"token_type": "Bearer"
}
6.4.6.2.2 Manutenção de Aplicação
Serviço para atualização de informações de uma aplicação. Requer um token de acesso para
aplicações, enviado no parâmetro de cabeçalho “Authorization”.
a) Solicitação
• Path: <URI-base>/oauth/client_maintenance;
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 35
• Método HTTPS: PUT;
• Cabeçalho:
o Content-type: application/json ;
o Accept: application/json;
o Authorization: Bearer access_token (“Bearer” concatenado com espaço e
access_token);
• Parâmetros: formato "application/json;charset=UTF-8" :
o client_id, obrigatório, deve conter a identificação da aplicação;
▪ client_secret, opcional, nova senha da aplicação;
▪ name, opcional, nome da aplicação;
o comments, opcional, descrição da aplicação;
▪ redirect_uris, opcional, URI’s autorizadas para redirecionamento (para
requisição de código de autorização).
o email: obrigatório, e-mail para suporte em caso de indisponibilidade, mudança de
versão, entre outros.
Exemplo:
{
"client_id": "identificador da aplicacao",
"client_secret": "(Senha/Segredo da aplicacao)",
"name": "(Nome da aplicacao)",
"comments": "(Descrição da aplicação)",
"redirect_uris": [
"URI 1 pre cadastrada para redirecionamento",
"URI 2 pre cadastrada para redirecionamento",
"URI N pre cadastrada para redirecionamento"
]
"email": "psc@psc.com.br"
}
b) Resposta da Requisição de Manutenção de Aplicações
• Parâmetros de retorno: formato "application/json;charset=UTF-8" :
o client_id: obrigatório, deve conter a identificação da aplicação;
Exemplo:
{
“client_id”: “(identificador da aplicação)”,
}
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 36
6.4.6.3 Autorização com Credenciais do Titular
6.4.6.3.1 Serviço para obter do titular autorização de uso da sua chave privada, com
solicitação de fatores de autenticação.
6.4.6.3.2 No mínimo um fator de autenticação obtido deve ser válido para uma única
solicitação de autorização (OTP- one-time password).
6.4.6.3.3 Os fatores de autenticação deverão ter seus valores concatenados e enviados no
parâmetro “password”.
a) Solicitação
• Path: <URI-base>/oauth/pwd_authorize;
• Método HTTPS: POST;
• Cabeçalho:
o Content-type: application/json;
o Accept: application/json;
• Parâmetros: formato "application/json;charset=UTF-8" :
o grant_type, obrigatório, valor "password”;
o client_id, obrigatório, identificação da aplicação;
o client_secret, opcional, sendo obrigatório apenas quando a aplicação não utilizar
certificado ICP-Brasil;
o username, obrigatório, identificação do usuário por meio de CPF ou CNPJ;
o password, obrigatório, valor da concatenação de fatores de autenticação
informadas pelo usuário;
o lifetime, opcional, valor inteiro, indica o tempo de vida desejado para o token a
ser gerado em segundos. Para acesso a objeto de pessoas físicas não deve
ultrapassar 7 (sete) dias, sendo que para pessoas jurídicas este limite será de 30
(trinta) dias;
o scope, opcional, se não informado será considerado "authentication_session".
(ver lista de escopos para Serviço de Código de Autorização).
o slot_alias: opcional, indica o slot do usuário no qual a autenticação deve ser feita.
Se não informado, o PSC decidirá em qual slot tentar a autenticação.
Exemplo:
{
“client_id": "MyApplicationId",
"client_secret": "123qwe",
"username": "0660457192",
"password": "123456SENHA",
"grant_type": "password",
"scope": "single_signature",
"lifetime": 900,
"slot_alias": "12345678899"
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 37
}
b) Resposta da Requisição de Autorização com Credenciais do Titular
• Parâmetros de retorno para os demais valores de “scope”: formato
"application/json;charset=UTF-8":
o access_token, obrigatório, valor do token de acesso;
o token_type, obrigatório, valor "Bearer";
o expires_in, obrigatório, valor inteiro com validade do token em segundos. Para
acesso a objeto de pessoas físicas, não deve ultrapassar 7 (sete) dias, sendo que
para pessoas jurídicas, esse limite será de 30 (trinta) dias;
o scope, opcional, informado apenas se o escopo retornado for diferente do
solicitado pela aplicação.
o slot_alias: obrigatório, indica o slot do usuário no qual a autenticação foi feita
(sem middleware).
Exemplo:
{
"access_token":
"b923575f1ced0ee732ee274b2e02784040bd9606",
"expires_in": 300,
"token_type": "Bearer",
"slot_alias": "12345678899"
}
6.5 Lista de Prestador de Serviço de Confiança – LPSC
6.5.1 A Lista de Prestadores de Serviço de Confiança – LPSC contem as entidades credenciadas
no âmbito da ICP-Brasil como Prestadores de Serviço de Confiança - PSC. A LPSC será publicada
pela AC Raiz e atualizada no prazo máximo de 180 dias.
6.5.2 A LPSC será publicada no repositório da AC Raiz em versão textual, para leitura humana, e
em XML, para processamento por máquina.
6.5.3 A autenticidade e a integridade da versão processável por máquina da lista compilada é
assegurada por meio de uma assinatura digital XMLDSig suportada por um certificado digital do
ITI.
6.5.4 As versões da LPSC e o certificado que assina a LPSC serão publicados no repositório da
AC Raiz, disponível em:
http://www.iti.gov.br/repositorio
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 38
6.5.5 A autenticidade e integridade da lista compilada devem ser verificadas pelas partes
confiáveis antes de qualquer uso.
6.5.6 A LPSC é codificada em XML, em conformidade com a estrutura proposta pelo padrão
ETSI TS 102 231, e contem os seguintes dados:
a) a informação do esquema (SchemeInformation), onde são apresentados os dados de
identificação do emissor, o ITI, e a data da próxima atualização (NextUpdate) da lista;
b) a lista de prestadores de serviço (TrustServiceProviderList), que contem uma entrada
(TrustServiceProvider) para cada PSC credenciado junto à ICP-Brasil; e
c) assinatura digital no formato XMLdSIG.
6.5.7 A LPSC conterá na URI de base que define o serviço (SchemeServiceDefinitionURI) a
versão da API correspondente, podendo apresentar mais de uma instância de versão para minimizar
comprometimento das aplicações integradas.
7 SERVIÇO DE ASSINATURA DIGITAL, VERIFICAÇÃO DE
ASSINATURA DIGITAL.
7.1 Introdução
7.1.1 Os requisitos a seguir foram baseadas nos padrões para criação e validação de assinaturas
definidas nas especificações do ETSI.
7.2 Criação de Assinaturas
7.2.1 O objetivo da criação de assinaturas é para gerar uma assinatura cobrindo um documento
eletrônico (texto, som, imagem, entre outros) do assinante, o certificado de assinatura ou uma
referência a esse certificado, bem como os atributos da assinatura que suportam essa assinatura.
7.2.2 Um modelo funcional básico de um ambiente para a criação de assinaturas se constitui por:
a) signatário que quer criar uma assinatura em um documento eletrônico;
b) um aplicativo condutor que representa um ambiente de usuário (por exemplo, um aplicativo
de negócios) que o assinante usa para acessar a funcionalidade de assinatura; e
c) um sistema de criação de assinatura, que implementa a funcionalidade de assinatura.
7.2.3 Antes de iniciar o procedimento de assinatura o sistema deve verificar a validade do
certificado. Ao receber o retorno da assinatura o sistema deve bater a resposta com a chave pública.
NOTA: O envolvimento humano de um signatário nem sempre é necessário. A assinatura pode ser
um processo automatizado e implementado na aplicação no ambiente do usuário.
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 39
7.3 Dispositivos para criação de assinaturas
7.3.1 São sistemas ou equipamentos configurados para implementar códigos e/ou outros
mecanismos que possibilitem ativação da chave privada do signatário para a criação das assinaturas
digitais.
7.3.2 Os dispositivos para criação de assinatura devem conter os certificados de assinatura ou
possuírem uma referência inequívoca a eles. Devem, ainda, verificar os dados de autenticação do
assinante.
7.3.3 Os equipamentos para criação de assinaturas devem possuir certificação Inmetro válida no
âmbito da ICP-Brasil, conforme definido no conjunto de documentos DOC-ICP-10 [6], no
documento DOC-ICP-01.01 [7], neste documento e seus complementares.
7.4 Interface da aplicação com o dispositivo de criação de assinaturas
7.4.1 A interface entre a aplicação de assinatura e o dispositivo ou equipamento de criação devem
garantir que somente com a autenticação do titular do certificado, que deve ter controle exclusivo da
chave privada, seja possível requerer a criação dos dados de uma assinatura digital.
7.4.2 O uso do dispositivo de criação deve exigir que o usuário insira dados específicos de
autenticação do assinante. Toda informação trocada entre a aplicação e o dispositivo deve trafegar
de forma criptografada.
7.4.3 Mais de um mecanismo de autenticação deve ser usado para fornecer uma garantia de
autenticação suficiente.
7.4.4 Um mecanismo de autenticação do signatário deve ser de uma forma que evite ataques de
representação.
NOTA 1: A natureza dos mecanismos de autenticação e os dados de autenticação do assinante são
determinados pelo dispositivo de criação de assinaturas. Existem padrões para diferentes interfaces,
tipos dispositivos ou equipamentos e mecanismos de autenticação.
NOTA 2: Em alguns casos, o uso de dados de autenticação do signatário será obrigatório e outros
requisitos sobre a natureza dos mecanismos de autenticação e as interfaces podem ser impostas.
7.5 Suítes de Assinatura
7.5.1 Todos os algoritmos e tamanho de chaves envolvidos no cálculo de qualquer elemento da
assinatura digital encontram-se definidos no documento DOC-ICP-01.01 [7].
7.6 Formatos de Assinaturas
7.6.1 A ICP-Brasil padroniza as assinaturas digitais baseadas em políticas explícitas de assinatura.
As políticas de assinatura preveem os formatos CAdES, XAdES e PAdES.
7.6.2 Todos os formatos e perfis de assinatura digital no âmbito da ICP-Brasil estão definidos no
conjunto de documentos DOC-ICP-15 [8] e seus complementares.
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 40
7.6.3 Os PSC devem implementar assinaturas digitais baseadas nas políticas de assinatura
padronizadas e aprovadas na ICP-Brasil.
7.7 Assinatura com Carimbo do Tempo
7.7.1 Uma assinatura digital com carimbo do tempo evidencia que a assinatura digital já existia na
data contida no carimbo do tempo. Os carimbos do tempo são emitidos pelas Autoridades de
Carimbo do Tempo (ACT) credenciadas na ICP-Brasil e fornece data/hora como uma propriedade
não assinada adicionada à uma assinatura digital.
7.7.2 A ICP-Brasil define no documento DOC-ICP-11 [9] o modelo de carimbo do tempo adotado
em sua infraestrutura.
7.7.3 As políticas de assinatura regulamentadas no âmbito da ICP-Brasil definem o uso de
carimbo do tempo.
7.8 Validação de Assinaturas
7.8.1 O processo de validação de uma assinatura digital deve ser realizada contra uma política
explícita de assinatura digital, que consiste de um conjunto de restrições de validação, denominada
Política de Assinatura, e deve gerar um relatório com indicação da situação de validação (Válida,
Inválida ou Indeterminada), fornecendo os detalhes da validação técnica de cada uma das restrições
aplicáveis, que podem ser relevantes para a aplicação demandante na interpretação dos resultados.
7.8.2 Na ICP-Brasil, conforme disposto no documento DOC-ICP-15 [8], 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. O item 7.6.2, acima, define os formatos e perfis regulamentados no âmbito da
ICP-Brasil.
7.8.3 Os requisitos para geração e verificação de assinaturas digitais no âmbito da ICP-Brasil
estão descritos no documento DOC-ICP-15.01 [10].
7.8.4 A AC Raiz gerencia as Políticas de Assinatura na ICP-Brasil, conforme definido no Anexo 3
do DOC-ICP-15.03 [11]. No processo de validação de uma assinatura digital, deve-se verificar a
validade das Políticas de Assinatura por meio da Lista de Políticas de Assinatura Aprovadas (LPA),
publicada no repositório da AC Raiz.
7.9 Acordo de Nível de Serviço
7.9.1 O acordo de nível de serviço para todos os serviços credenciados do PSC deverá ser de no
mínimo 99,99%.
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 41
8 CLASSIFICAÇÃO DA INFORMAÇÃO
8.1 Toda informação gerada e custodiada pelo PSC deverá ser classificada segundo o seu teor
crítico e grau de confidencialidade, de acordo com sua própria Política de Classificação de
Informação.
8.2 A classificação da informação no PSC deverá ser realizada independente da mídia onde se
encontra armazenada ou o meio pelo qual é trafegada.
8.3 A informação poderá ser classificada em:
8.3.1 Público: Qualquer ativo de informação, de propriedade do PSC ou não, que poderá vir ao
público sem maiores consequências danosas ao funcionamento normal do PSC. Poderá ser acessado
por qualquer pessoa, seja interna ou externa ao PSC. Integridade da informação não é vital.
8.3.2 Pessoal: Qualquer ativo de informação relacionado à informação pessoal. Por exemplo:
mensagem pessoal de correio eletrônico, arquivo pessoal, dados pessoais, entre outros.
8.3.3 Interna: Qualquer ativo de informação, de propriedade do PSC ou não, que não seja
considerada pública. Ativo de informação relacionado às atividades do PSBio que é direcionada
estritamente para uso interno. A divulgação não autorizada do ativo de informação poderia causar
impacto à imagem do PSC. Por exemplo: código fonte de programa, cronograma de atividades, atas
de reuniões, entre outros.
8.3.4 Confidencial: Qualquer ativo de informação que seja crítico para as atividades do PSC em
relação ao sigilo e integridade. Qualquer material e informação recebida para ensaio, assim como
qualquer resultado do ensaio (como relatório) deverá ser considerado confidencial.
NOTA: Caso o PSC seja entidade da Administração Pública Federal – APF, aplicar-se-á as
disposições do Decreto nº 7.845/2012 e demais normas aplicáveis à APF, no que couber.
9 SALVAGUARDA DE ATIVOS DA INFORMAÇÃO
9.1 O PSC deverá, em sua Política de Segurança da Informação, definir como será realizada a
salvaguarda de ativos de informação no formato eletrônico, também denominado backup.
9.2 A salvaguarda de ativos da informação deverá ter descrita as formas de execução dos
seguintes processos:
i. procedimentos de backup;
ii. indicações de uso dos métodos de backup;
iii. tabela de temporalidade;
iv. local e restrições de armazenamento e salvaguarda em função da fase de uso;
v. tipos de mídia;
vi. controles ambientais do armazenamento;
vii. controles de segurança;
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 42
viii. teste de restauração de backup.
9.3 O PSC deverá ter política de recebimento, manipulação, depósito e descarte de materiais de
terceiros.
10 GERENCIAMENTO DE RISCOS
O PSC deverá ter um processo de gerenciamento de riscos, atualizado, para prevenção contra riscos,
inclusive àqueles advindos de novas tecnologias, visando a elaboração de planos de ação
apropriados para proteção aos componentes ameaçados atualizado, no mínimo, anualmente.
11 PLANO DE CONTINUIDADE DE NEGÓCIOS
Um Plano de Continuidade do Negócio – PCN deverá ser implementado e testado no PSC, pelo
menos uma vez por ano, para garantir a continuidade dos serviços críticos ao negócio em caso de
inoperância total ou parcial de seu ambiente.
12 ANÁLISES DE REGISTRO DE EVENTOS
Todos os registros de eventos (logs, trilhas de auditorias e imagens) deverão ser analisados, no
mínimo, mensalmente e um relatório deverá ser gerado com assinatura do responsável pelo PSC.
Todos os registros da transação biométrica por parte do PSC deverão ser guardados por um período
de 7 (sete) anos.
13 PLANO DE CAPACIDADE OPERACIONAL
13.1 Os PSC deverão elaborar e manter atualizado anualmente um Planejamento de Capacidade
Operacional – PCO para determinar a capacidade de produção atual e futura com níveis de
desempenho satisfatórios para responder a novas demandas, fornecendo níveis satisfatórios de
serviços aos usuários, visando dimensionar os sistemas para suportar o crescimento orgânico, picos
de utilização e sazonalidades.
13.2 O PCO deverá, no mínimo:
a) determinar os níveis de serviços requeridos pelos usuários;
b) analisar a capacidade de processamento de dados instalada; e
c) dimensionar a capacidade necessária de infraestrutura, hardware, comunicação de dados e
link de internet para atender os níveis de serviços atuais e futuros.
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 43
14 DOCUMENTOS DA ICP-BRASIL REFERENCIADOS
14.1 Os documentos abaixo são aprovados por Resoluções do Comitê Gestor da ICP-Brasil,
podendo ser alterados, quando necessário, pelo mesmo tipo de dispositivo legal. O sítio
http://www.iti.gov.br publica a versão mais atualizada desses documentos e as resoluções que os
aprovaram.
REF.
NOME DO DOCUMENTO
CÓDIGO
[1]
CRITÉRIOS E PROCEDIMENTOS PARA CREDENCIAMENTO
DAS ENTIDADES INTEGRANTES DA ICP-BRASIL
Aprovado pela Resolução nº 40, de 18 de abril de 2006
DOC-ICP-03
[2]
REQUISITOS MÍNIMOS PARA AS POLÍTICAS DE
CERTIFICADO NA ICP-BRASIL
Aprovado pela Resolução nº 07, de 12 de dezembro de 2001
DOC-ICP-04
[3]
CRITÉRIOS E PROCEDIMENTOS PARA REALIZAÇÃO DE
AUDITORIAS NAS ENTIDADES INTEGRANTES DA ICP-
BRASIL
Aprovado pela Resolução nº 24, de 29 de agosto de 2003
DOC-ICP-08
[4]
CRITÉRIOS E PROCEDIMENTOS PARA FISCALIZAÇÃO DAS
ENTIDADES INTEGRANTES DA ICP-BRASIL
DOC-ICP-09
[5]
POLÍTICA DE SEGURANÇA DA ICP-BRASIL
Aprovado pela Resolução nº 02, de 25 de setembro de 2001
DOC-ICP-02
[6]
REGULAMENTO PARA HOMOLOGAÇÃO DE SISTEMAS E
EQUIPAMENTOS DE CERTIFICAÇÃO DIGITAL NO ÂMBITO
DA ICP-BRASIL
DOC-ICP-10
[8]
VISÃO GERAL SOBRE ASSINATURAS DIGITAIS
NA ICP-BRASIL
Aprovado pela Resolução nº 62, de 09 de janeiro de 2009
DOC-ICP-15
[9]
VISÃO GERAL DO SISTEMA DE CARIMBOS DO TEMPO NA
ICP-BRASIL
Aprovado pela Resolução n° 58, de 28 de novembro de 2008
DOC-ICP-11
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 44
14.2 Os documentos abaixo são aprovados por Instrução Normativa da AC Raiz, podendo ser
alterados, quando necessário, pelo mesmo tipo de dispositivo legal. O sítio http://www.iti.gov.br
publica a versão mais atualizada desses documentos e as instruções normativas que os aprovaram.
REF.
NOME DO DOCUMENTO
CÓDIGO
[7]
PADRÕES E ALGORITMOS CRIPTOGRÁFICOS DA ICP-
BRASIL
Aprovado pela Instrução Normativa nº 04, de 18 de maio de 2006
DOC-ICP-01.01
[10]
REQUISITOS PARA GERAÇÃO E VERIFICAÇÃO DE
ASSINATURAS DIGITAIS NA ICP-BRASIL
Aprovado pela Instrução Normativa nº 01, de 09 de janeiro de 2009
DOC-ICP-15.01
[11]
REQUISITOS DAS POLÍTICAS DE ASSINATURA DIGITAL NA
ICP-BRASIL
Aprovado pela Instrução Normativa nº 03, de 09 de janeiro de 2009
DOC-ICP-15.03
Infraestrutura de Chaves Públicas Brasileira
Procedimentos Operacionais Mínimos para os Prestadores de Serviço de Confiança da ICP-Brasil – DOC-ICP-17.01 versão 3.0 45
15 REFERÊNCIAS
BRASIL, Decreto nº 7.845, de 14 de novembro de 2012. Regulamenta procedimentos para
credenciamento de segurança e tratamento de informação classificada em qualquer grau de sigilo, e
dispõe sobre o Núcleo de Segurança e Credenciamento.
ETSI TS 102 231 - Electronic Signatures and Infrastructures (ESI); Provision of harmonized Trust-
service status information; V3.1.2 (2009-12).
RFC 4226, IETF - HOTP: An HMAC-Based One-Time Password Algorithm, december 2005.
RFC 5246, IETF – The Transport Layer Security (TLS) Protocol Version 1.2, august 2008.
RFC 6238, IETF - TOTP: Time-Based One-Time Password Algorithm, may 2011.
RFC 6287, IETF - OCRA: OATH Challenge-Response Algorithm, june 2011.
RFC 6749, IETF - The Oauth 2.0 Authorization Framework, october 2012.
RFC 7468, IETF - Textual Encodings of PKIX, PKCS, and CMS Structures, april 2015.
RFC 7515, IETF - JSON Web Signature (JWS), may 2015.
RFC 7636, IETF - Proof Key for Code Exchange by Oauth Public Clients, september 2015.
