UIA4

VERSÃO PARA IMPRESSÃO
CRIPTOGRAFIA: ALGORITMOS E CERTIFICAÇÃO

DIGITAL
UIA 4 | CERTIFICAÇÃO DIGITAL
CRIPTOGRAFIA: ALGORITMOS E CERTIFICAÇÃO DIGITAL | UIA 4 | 2
Este material é destinado exclusivamente aos alunos e professores do Centro Universitário IESB, contém
informações e conteúdos protegidos e cuja divulgação é proibida por lei. O uso e/ou reprodução total ou
parcial não autorizado deste conteúdo é proibido e está sujeito às penalidades cabíveis, civil e
criminalmente.
Copyright © 2016 Centro Universitário IESB. Todos os direitos reservados.

SUMÁRIO
Aula 19 | Princípios de Certificação Digital ................................................................................4

Aula 20 | Certificado Digital .........................................................................................................9
Aula 21 | Autoridades Certificadoras ....................................................................................... 14
Aula 22 | Infraestrutura de Chaves Públicas – Brasil (ICP-Brasil) ........................................... 20
Serviço Federal de Processamento de Dados (SERPRO) ...................................................................................................... 23
Caixa Econômica Federal................................................................................................................................................................. 23
Serasa Experian ................................................................................................................................................................................... 23
Receita Federal do Brasil .................................................................................................................................................................. 23
Certisign................................................................................................................................................................................................. 23
Imprensa Oficial do Estado de São Paulo .................................................................................................................................. 23
AC-JUS .................................................................................................................................................................................................... 24
AC PR ....................................................................................................................................................................................................... 24
Casa da Moeda do Brasil .................................................................................................................................................................. 24
Valid Certificadora Digital ............................................................................................................................................................... 24
Soluti Certificação Digital ................................................................................................................................................................ 24
AC DigitalSign ...................................................................................................................................................................................... 24
AC Boa Vista ......................................................................................................................................................................................... 25
Ministério das Relações Exteriores ............................................................................................................................................... 25
Aula 23 | Tópicos em Certificação Digital ................................................................................ 25

Aula 24 | Estudo de caso: SSL/TLS, OpenSSL e Heartbleed .................................................... 30


Aula 19 | PRINCÍPIOS DE CERTIFICAÇÃO DIGITAL
Olá, estudante, bem-vindo(a) à quarta Unidade de Interação e Aprendizagem (UIA). Nesta unidade,
abordaremos todos os principais aspectos da certificação digital, cuja importância para o mundo moderno é
indispensável. Continue os estudos desta disciplina e boa aula!
n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n
Acesse o Ambiente Virtual de Aprendizagem (AVA) da disciplina e

assista à videoaula sobre certificação digital.
Certificação digital é provavelmente o tópico mais genérico em termos de

escopo dentro do mundo criptográfico. A razão principal para tal fato é
que o termo “certificação digital” possui implicações técnicas – dentro do
mundo criptográfico – e jurídicas, especialmente em países onde a
certificação digital já consegue substituir processos manuais de
autenticação pessoal.
Uma outra razão para tal amplitude de escopo é o uso de praticamente
quase todos os conceitos técnicos vistos até agora: algoritmos simétricos,
assimétricos, hashes criptográficos, troca de chaves, gerenciamento e
distribuição de chaves, etc.
Na Aula 16, observamos o uso prático do Pretty Good Privacy (PGP) como a http://tinyurl.com/zkanxvt
implementação de algoritmos de chave pública, de forma não
proprietária, mesmo que a marca “PGP” seja registrada. O PGP é um clássico exemplo dos fundamentos
da certificação digital. Entretanto, o PGP possui ao menos um problema que a certificação digital resolve
legitimamente, juridicamente: a confiança na pessoa a qual se diz ser.
Em outras palavras, no PGP, as pessoas precisam literalmente confiar umas nas outras sem o intermédio
jurídico de um terceiro; elas precisam importar a chave pública de cada pessoa com quem queira trocar
mensagens criptografadas e assinadas digitalmente.
O termo confiar é utilizado muito genericamente, pois se duas pessoas
trocarem suas chaves públicas pessoalmente, isso já é suficiente em termos
de confiança. Na certificação digital, esse trabalho de confiança é delegado
a um terceiro, que possui toda a legitimidade para afirmar que tal é pessoa
é realmente aquela pessoa.
Obviamente, a legitimidade é, de certa forma, também garantida
computacionalmente, pois os algoritmos criptográficos utilizados são
“computacionalmente seguros” o bastante para firmarmos tal pressuposto. De
http://tinyurl.com/zffga6j fato, a simples perda de um certificado digital, cujo conceito será aprofundado,
é motivo para sua revogação, para sua inutilização por parte do titular.

Podemos, nesse momento, inferir então que o termo certificação digital está
ligado a pelo menos dois fatores inegavelmente relevantes:
1. O uso de algoritmos criptográficos comprovadamente seguros.
2. A confiança em um terceiro para criar a legitimidade da existência da
pessoa titular do certificado digital.
Ainda com relação ao exemplo prático do uso do PGP como forma de cifrar e assinar mensagens, há um
outro problema inerente à própria arquitetura do PGP: o gerenciamento das chaves públicas. Fala-se em
gerenciamento aqui abrangendo todos os aspectos de como essas chaves são geradas, armazenadas e
inutilizadas em determinado momento. Infelizmente, o PGP, por si só, não provê essa capacidade
completa de gerenciamento de chaves. Cada titular de um par de chaves, pública e privada, é solidária e
unicamente responsável por ela, em todos os aspectos, inclusive o armazenamento da chave privada em
algum lugar supostamente “seguro”. Além disso, se você não exportar sua chave pública para um
repositório público, ninguém saberá identificá-la.
Leia mais sobre esse assunto acessando o link disponível a seguir.

http://tinyurl.com/kvn8y7e
O armazenamento da chave privada é algo tão crítico na criptografia de chave

pública que a sua “perda”, até mesmo no sentido mais amplo da palavra, pode
ensejar uma quebra criptográfica das informações pertencentes ao seu titular.
Tal fato é tão extraordinário, que a simples perda da chave privada dentro do
mundo da certificação digital é razão suficiente para inutilizar a chave, como
dito anteriormente.
Talvez a forma mais comum de se guardar uma chave privada é dentro de um
arquivo texto (ASCII). Lembre-se que, a exemplo do PGP, uma chave privada
por ser até exposta, embora não seja uma boa prática. Veja o exemplo da chave
PGP privada utilizada anteriormente pelo usuário “crypto-teste” (perceba a palavra “PRIVATE” no bloco
PGP):
-----BEGIN PGP PRIVATE KEY BLOCK-----

Version: GnuPG/MacGPG2 v2.0.27
Comment: GPGTools - http://gpgtools.org
lQc+BFVkb1kBEADZcaoXgNP1xE6TsHJj4hA633/EEddRqTZ5SxPslBIPAs2jj5ht
FpNJsjA/q4nGFJw/OGqXBoctUKFMqVb7pn4MC823ZOqck8FX01D0eRtU3WEA6Fs8
02uSFj82GnNira7kzq0+Y/mCaMias3wb5mhBWWzZWMnOwot3tQwJccAE8UWH184I
gLlhR3AdgRPH3/y9qqZMSLDryy9ldczWhusMxX84vEdooEGg5yQSCPCxH/LBElIY
X7Sq5jx51o2LPgdizE028AENoNGmxF68GTIGn/8+SamsU2n95uyxPEjIqehI5+ig
szGggRRVtVXOCl9jeQoqg/6HB0wMN+XaXqFjx4/1o2dXBpvoxh/riCyThN4z3d4X
eVWX3Zb967su6X5M8Msb5EkDk9CcEuFtGmPia5zghCA9OH+C8adN/3Em+WARW7ST
5EoHBlveY82I41ZRcRr7AD7mYxlLMAP09qYneYzNHvwZCBGpebEOEn1ALC3AqnOM
3SXKS/JsBXJaZJuziWeP5K03GixvR0q2KMKPbbPWB1kKM1XIsA2URKAVkVNKEIA7
qLW+692ysxG3u42QIYT+/yTnoLMI+2VQqMGss91MeN5z/5tcYyAYIGCbu5p7Q7bg
Yxrqg86lWpHET8vtzSW+j6t7PywRWh3X+0NSeGZqCMXclNGpSA3oS4nZSQARAQAB
/gMDArioq08KczVS3oidzhNPA9t1K6m3dw3fKCn254bxnF6F6oFxQSARvNqvX1Ve
2a4MbqSFYYV/BX9ngHlX7oNPShtcqhs++AEdCzoRNwjRdAOlpKOKvghZafp06p4+
Tp9yuYGgdcwbh56ae9kUZRIrojhqjyuIMxDp5C+TmkAocgnmTGTUVvPUAyWIxniV
t78yvNyZrXM46DRWnk5mcHW7v23X9NuvRk/+qfv31RULNBb391/LhzR+MlizdaYl
H5ptoRoutCZZ+yhpR3v2FhBoiFNLZbft5E7aBdbXWJd8zSlcs2Z3J/Kq0cl/kntX
Ybivd7wYFUJqP8oywM2Qhrt7LQ6YlBF9P3Z+e4bvNRtbcvwUT5sWbBoUpwqcmZhx
rq+glOCiX2vHq4bOkQ5lhYVTdwHVNa75BkvuvWjOUcTaPGCeo0N4b9o9TPn0yr9Y
2Um0rcT5PY8QWqFkcdJjwgXNgD4CUAOLCNEhsBTGBjNC5NKyj2tT3xpOAWqzKSOP
QcQ5QHCaglRX9LysWTVb5tsuXo84pzwdDsz8uuFiAbhOd11vU5odtsCyLmVjjHdk
BRt9abNEDbieY2/3i4Rsc24A5u1jSe7MkyNQQTTQC7Ytm8FpAfF1gY6B50ZUGB+m
o7qR8SbbEjENWjug4qHpkAK6vT7Sv7oBY+VpJ7IposqPAkHZoR61b2ekKB9Nzvv9
Y2N7YfKtii7FOZ/OgbGI49Z5pcJp0eYu6bindVpAoYYXrbZhTvUd+dVjxL90KiDo
bYylZIHaqZMGCttRyX1Wz3fvDCP/UdBMH1aAe2LJBee8uGHixzCtkqCYu3fqjgUN
o73xffSwguaCtz3Uy2HfdwEbbfenSuqru/tRltA0gRj2FxZkobpqKVgFlJxAjn1a
kvynrDllshX+wcCsiTY1lBkdISbnWdUtQq8WTkklOLmWBL8FHLUipLfsgJQ5FrBf
J0UXipV/o8rShDRxfKNkOUhSM4xyudNgUpW5abbsW0Mgtdh0vZ4vCCRmNEy65WC/
NdTK7rzYFla8u61/33TuV/iTAyETbnxahJ9lrqVd3HBKykkJCbu6XiLvNDLnHfWm
eBsWbfebN/Pd9CMExxyw61tS8BsBSs+Mw46TNrVj582y+foaaqYj06WvQFXHEUnp
yx+omomOLTogQ6to1EnPaneF5IAY+1Isy/4VHa1IdvpeEXmihqXw1DGu/dpSZc7/
7zUx/j5oEj+88piZEr0MnK1/MtCzj/b+5OReZtLnkcY0Tg9Iw8Klvn79Dsc1fN5l
PlMkXabanGOrl2f7dqCsr6u7RneUSAgnNBLdok3nT4cvSaX707kY8yUrZsfirKm0
dapbh2wY4b/mcqygbSaaduZt7ye93MdGIrlKmrHb9If3DTdSSMCFn4HtK62nvuDJ
ylP0iuSvo0De4thGs1vUeJvU6wUb07nAr5y8CQW9uR5H/lxQ2B0yM2m/qzSQ0dFE
/B/sNvOV3Ry0oH5CQlTH0H/tiQE5y0tgXAH3Agh7Ua/yYgHAit299fXhPWmFLF66
xrSARXdiDaCYtFKtMUGbXw0QAjAFbu8FuEkREFY85gFOswp2ZVLwm5JamyWBJT0e
uTQwYE9PALmV5iOxcUpQ/ZigVl5CMUbRbaiw6a0MiMKqWuzj7w/M46Sa17kbq36M
pqZoxq75/+foeSGydBgZ5QB6LDAxHg+f9g1b7+KwtMx+bMCgz8xRHl/40KMGdtHi
lDq97lB5o+L1z9INXtebW7QJ4DAU6TuM8d8BH8uKiqCmtDNPU0lGTjRBIChDaGF2
ZSBQR1AgVHVybWEgT1NJRk40QSkgPG9zaWZuNGFAaWVzYi5icj6JAj8EEwEIACkF
AlVkb1kCGwMFCQEguIAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRDSc1FX
XPNGH75iD/9iJ2qJyEatVu8+c6OJ4nAY410LFa8bqcy+Rbq8ITERUUYbXeWXkQNg
RvWQUhcnwDjjWEyujU0UpxbFtcaiDQyezIj7Nhp7Emp5l510K0tEA/7m40iZmTD/
K6xMQ9K4kRjaqmyREnLeJeTFrAD1y6zp/lxBGKgBP0bpt5fO6omUBQQKpVU5nyKw
NHb2R6zi0e9NvSHNdh4CI/5HWF5CykSrndf8Z7d/02TE0DywKPmadgrgk7moO0cx
qSQiIP/8+EuBgQa/MY9rJDonBKi5UX7aZr/L0jvXYUY6phzodBHJJWIi6cSi78Ai
NGjbMofzOBV5rt5Tkj+NsUARr1GHvuh7jgZ9gw7ZbxSdizmnnJpYdOKoZQi9mQFb
0ptrgapQPI0wLCmjBDnAlpDWTefoYW/jVLqqtiLB9crdXFA0qAVW4pPWEkBkoAcF
5VpvjnzeP++ZySPCOpTZ+SEOkHwyNMjd+Pvv4ispEkLhf7d5JmOSB3AwCkB/f6rx
+glmsgz7Y71PD/5lf8qfgD5yUljHLnDO0CmhDFUYby+18m19NW/1sRWQ99qEXjeJ
c6f6tV9o8DiXeZS7XLMySyq87+mYny0XynLuW8V6gl5NB6+3gdQMTKcBojIkIY03
OF+ZpPGNuIdXyPIqpoY3vDIGG6LySMkDVr84EsbSwtPXoUlKkbPxqZ0HPgRVZG9Z
ARAAphrPAkHmzIRV8trwrYk91h53VEtxyG/76V7A78XV4hY3V5WoI1w5AZB0UGqV
GIueX9/oWqN3SIHhCSD8jEWXVA07kbr4CNiNvAlzzAfbbtRbxfWPEzLLgmW03QcC
AWzUI5o+EkyWHvGzN1vlYwEXPLsKKmURPYa8xh+QY4HJt222JXM2J/BZZ5XGqxhO
9R+MYWb2t/5I+/cY1JkaihHk0u2YJ4J4CnB1tMnGfH0MEuOWXQLplZIG5KpDpU2+
vFCAcA0EbYbqleAi7Fnilil7SN/AAROmkOnD3GsYvKvjLFUx6vHK3x8/6vRtOIay
3ZR0JNbAGLUztNs2UKqxBh+UApm/PSbeDn4u9XJe85BV3a5wNRG77PLAiYzbPlby
wJTJ1IS3DBbFTdeu/TnwCUkE2FoS5KUCEJixi2ZrDjDlDmldKCtTpyGaCbFvhFbO
VxHnEI1r7BNws2LkV4Yrm0jogC/ibBnjg43IwQbNsbjllBerlEkD6SgU/rx2uDBl
yXsX3VgOy9ap4tjfcqMG/q33So61s5C5z3SqweHIkNf0sB/+sZV1mB6zArwMsOxs
pogByJBeoiDmgTWLRSCnw5EixFR87ENMWwoAafR3q8NV2cbyn36DIRfRcTpqoWqE
UDD8qEE/6krQMpZyymwDkh1zGxra23iDDEJvzcVc+V3P8/0AEQEAAf4DAwK4qKtP
CnM1Ut5WZr5LEizFE+ItFmJx+BNXwRyrMtfOyKTGXaTWzeiFGtqcw3lvDpo6yCey
HjxZCu9bEkqMEJvV5cBmZQ3sy2S+pxDeYdFgOBbiF0cvsw6mUve1puf/8z7l02Y5
C6YUYLZYaGqissK79UYNgbZyXSGW97K87aYGLqAAIEXGZg/lHwnUQ4dHTCdLSMYE
1Ke41skKzAcCnIxiylbAXDVdWKm3tyS5azO0V4t7uU85EsBhUVJ8JKZ5OQwvJV2T
Aaj5/7Sw0tNCY75TgzzX/tNYiy4qha29xGF/XVMBSpN0m6+Bgyv7NJAkuouAveE+
cIkAjEeBv+1Y4ofRHsEk6U8Fh840S1aGCskV4G5RfGexf3jlrydUpTJZsVDpf/Li
wkOfHk2vWxEeN1qduiKoOFGiYkXQPuwrd9hclGEfFXXMAPlOMvyWzVYCTBUitZcT
V25igoNRrgKaLQf29LikNyDmKThb+taut2FOpho0ujPJQr/enh4wDmB6Xwl4FVFH
w7jKoe658gTupPKZz8ZDEgIigBs9Ep8mehhhQaC7G5/5DdUewE0cNfKpcFpXh3BN
6euOFwtzrE0cAqSKSNAt0cGjx7BwyENZn5juIhThc8SMCTeITCRMhuk3/HXh6hrk
kJ3m11iuyTzgzhmcYn+4olbPs+LvWvqNGdQCC+kUpnRKUrFcssxmwpB+Fd2j5q5V
OMZgvUQzLRr8IHuCfpXzBPIv8XFLxiBSCS60R47nJN9mg4nLhjGKv7vhOtIWan0Q
7/jaAcKoTz553lBC6Ugm1u6dTwxFymLOwd+1W6hTTGhkYrxKp1+lfdSiyZbc4mOL
ssb8+10ZGlMv6HwwTAxhEC6/auJeXSkzPYmF8F+hi1A/kYRj08xtixPcuZidg9jT
RPkbInsGXN8dVxHecHxUEqTE/QKfKPxivg86tv5iylIWMHVsZw1oZ7Xxos/e/5q7
8NGWCdLEhiKboqQQJR6v94xre6HqEFM4RDGq3Kiw+WF1kkn1nTiJeRPJ5QY8/eU6
LV2nOaKeTOEuHJoUShTRyt9gAjpbFHf1L3KpSco13RYbdgxi5VRANp3c36zNjdzw
j6Z8mEytex97XJgcux9vXpH3BDWttpUQjSj960+gTU8koCoxI96l0jvP0TGdUZGe
8mdMaKZeq0JVDfhqB5SqGOguXSQo/svIeou8rcBsXmAWt+avVNjiSwWF7998ECmT
PVuTmndA+4ohy8cMZa3jCusuMeRZcJav14GjpwL9VGiTsSTwS3J/iHx+gUFZJbbD
2Zft7Saajh6yGmxDD5cLk+ZC3ILmKmOK4yIJlX0FyOfPiaD/rk3LCGBydikfl3Br
+ZmuZCVr/IzTaqA8GH1y+Wwf65y2qb9NCDwnf9VbAvtGG7QgfyHDH2nb6zkJwWhW
nikQipexH6NPduzBUDuiLUBoNpYwLwiuEW6ZeQiU0QUkAV2ia5nbokoE7kdeN6wj
dYn4WZut2cqNpYOgWUas9GA9kfcBHx9oa326SYOhQiujbCQ5MlKs7JFG/3oq6RfM
ZYvFKJ1eS4NmZJrN3ShNPnSG+sTItwDRJ+a1NaWPdk6eCVkcdyB2iDbsZxYl/dXP
qSQ7ecnmKzJ0y7SPzfpFh9swFHmA3VppQ3/M1SOt1F1w/jwKAT55iiXyDDpVtB7L
TuzrD7+stBx9dgKkk+r63VVDA0qBeh/XfawFUiqycLInhXueRkVg3l0WmOCHD+lB
tKbvH56cPeyWsI0UIhik9iKGCJfwliSmkYkCJQQYAQgADwUCVWRvWQIbDAUJASC4
gAAKCRDSc1FXXPNGHyaTEADLcXyTIOntp7I161IKreS+wIY8jzdR1hH9ih/zDfSr
QXn7kt/yus2LTfVuBzdy5+gphqeazjuW5D8AhzNyUXvSCkW6kK87hbQ+8ZAd4pQn
0HhNPBOArrnnlgk5Uz+eIDxONWtLsXg7H1JbolAOiZLEClTc7tl+x19eL7SU48O3
HGXH1D3cuxq1iMhd50/nwQySCXD3qoBvM4dEfj/mwkqu74u70HIUtgjgRlIKEksl
yZOXrCNnmkMpnKygD5vBmCB6HhABJg9CF6xa7WsFhgeEV7TpjSzRxFcE8/eShf7D
8b/J1fkJvsA2es2R8n70GKrI3rIiut2ZyUncMpH2bPMGG4jGSPURHe9Ilkk7Z+FV
qaQYWutCiWVoXCcCw50acrFkQJzMWPDU7VivUtu8nRTWfd/N6aZ298guuLnP+psL
LwxSm+ZyIIKab3d+WuzWRRgtbZmLE4JCOU7quEKpK4jeNPwsZuly4RZ8WCmVAwen
aObfwS4dcJA9HIyU4kqy7xHbBD9+JZ2OxSOaIN2OhwiRRyvK0kGyiPE892LS1zmK
Zpcgarhr0/Vf1ABSI7BcikIN85pBV32bRl6Lq8Cofo6qJBFVm3hrSrUYY32b4Wuk
kAYMz+dpCSGIY+smAD5ybaCd93eG+6C8UUTu+gSZYdjboGjyEGarZHazZg4TdV/e
bQ==
=2fnp
-----END PGP PRIVATE KEY BLOCK-----
Perceba que o problema não está necessariamente na forma de

armazenamento, mas sim em como evitar que os “atacantes”
consigam chegar nesse arquivo, nesse conteúdo, ou seja, é
necessário que haja algum outro mecanismo para minimizar a
exposição da chave privada para o mundo externo.
Você pode estar se perguntando agora: mas a

chave privada não é geralmente protegida com
uma frase-senha? A resposta é sim, mas
dependendo da qualidade da frase-senha, ela pode ser facilmente “quebrada”.
Tal conceito de como gerar e salvaguardar chaves privadas de forma segura será abordado
oportunamente, mormente quando se fala de certificados digitais.
Relativo ao mundo da certificação digital, vários conceitos estão interligados, desde conceitos técnicos,
até conceitos jurídicos. No Brasil, a parte de certificação digital é, de certa forma, controlada pelo
Governo Federal. Veremos mais adiante os detalhes sobre essa centralização.
A certificação digital vem então resolver ao menos três grandes problemas que o PGP
ainda não tem a capacidade (por limitações da arquitetura, não técnicas):
• Garantir a autenticidade do titular da chave privada (e consequentemente, a
chave pública).
• Prover meios para o gerenciamento das chaves, como expiração automática.

• Prover o mecanismo de assinatura digital, cujo conceito depende da

autenticidade.
Aprenda mais, acesse o link a seguir com mais informações sobre como
garantir a autenticidade do titular das chaves privada e pública.
http://tinyurl.com/gru33ew
A partir do momento em que um par de chaves é gerado dentro do mundo da certificação digital, esse
par de chaves passa a ser chamado de certificado digital. A geração desse certificado é feita por uma
autoridade certificadora. O conceito mais detalhado desses termos será abordado posteriormente.
O que difere a geração de um par de chaves pelo PGP ou por uma autoridade
certificadora?
Basicamente, a presunção ou a certeza de que a pessoa que está naquele

momento gerando o par de chaves é ela mesma. Essa “certeza” é uma
espécie de garantia dada pela autoridade certificadora não porque ela
possui mecanismos criptográficos mais avançados, ou mais seguros, como
muitas pessoas pensam. O grande diferencial está nos procedimentos de
segurança adotados por tais autoridades, como:
• Apresentação de um documento legal que ateste a identidade

da pessoa.
http://tinyurl.com/znz58n4
• A presença da pessoa perante a autoridade.
• A autoridade certificadora está auditada perante normas internacionais.
• O lugar da autoridade certificadora (ou de registro, conforme veremos mais adiante) deve ser
relativamente seguro.
• A geração do par de chaves depende também da autorização por alguém da autoridade
certificadora, pois o certificado não é gerado automaticamente (geralmente).
Por fim, esses princípios norteadores da certificação digital é o que difere em termos de garantia de
segurança, incluindo a segurança física. Entretanto, não podemos presumir que haja segurança perfeita
dentro das autoridades certificadoras.
Termina aqui nossa primeira aula desta unidade. Introduzimos conceitos que serão importantes ao longo da
unidade. Continue os estudos desta disciplina e até breve!


Aula 20 | CERTIFICADO DIGITAL
Bem-vindos(as) mais uma aula! Vimos, na aula anterior, os fundamentos da certificação digital e o que a
diferencia entre o sistema PGP e uma autoridade certificadora. Aqui discutiremos os conceitos técnicos
principais de certificados digitais e brevemente o conceito de assinatura digital. Bons estudos!

assista à videoaula a respeito de autoridades certificadoras.
Diante desses princípios norteadores, o que é um certificado digital?
Certificado digital é um conjunto de informações que atestam que uma chave

pública foi gerada por uma entidade confiável para uma determinada pessoa (no
caso do Brasil, pessoa física ou pessoa jurídica) e que ela pertence naquele
determinado momento àquela pessoa.
Veremos mais adiante que há vários tipos de certificados digitais, normalmente associados com o tipo de uso.
Depreende-se então que um certificado digital, em geral, pode possuir mais informações que atestem
sua veracidade, em comparação a uma chave PGP. Portanto, tenha a certeza de que essas informações
inseridas dentro do certificado digital têm um significado mais abrangente do que um par de chaves
PGP, pois, no caso do Brasil, elas possuem uma validade jurídica, a qual discutiremos oportunamente.
Considerando que já vimos o formato de uma chave PGP, na prática, do que consiste um
certificado digital? De basicamente três elementos:
1. A chave pública.
2. O ID do usuário, que pode variar conforme as necessidades do uso.
3. Ao menos uma assinatura digital.
Praticamente todos os certificados digitais emitidos mundo afora

seguem um padrão mundial conhecido como X.509. O X.509 é um
formato criado pelo ITU-T e a ISO/IEC que contém as informações
necessárias para identificar o certificado digital. A especificação X.509 é
um padrão que especifica o formato dos certificados digitais, de tal
maneira que possamos associar um nome, ou uma identidade qualquer,
a uma chave pública, permitindo não somente o que chamamos de
autenticação forte, mas todos os outros benefícios da criptografia como
um todo. Faz parte da série X.500 de recomendações a estrutura de
diretório global, baseadas em nomes distintos (DN, OU, O, CN) para sua
http://tinyurl.com/z2jzx64
localização. Isso significa que mesmo utilizando o mesmo padrão, várias
entidades podem ser identificadas unicamente.
Um certificado X.509 é, na prática, um arquivo contendo campos ou informações

sobre um usuário ou dispositivo e sua respectiva chave pública.
O padrão X.509 define qual informação será inserida no certificado e descreve como codificar isto (o
formato do certificado e o tipo associado a ele).
Todos os certificados X.509 possuem os seguintes campos:
• Número da versão 509 do certificado – identifica qual padrão é aplicado na versão do X.509
para este certificado, o que afeta qual informação pode ser especificada.
• A chave pública do possuidor do certificado – a chave pública, junto com um algoritmo de
identificação que especifica a qual sistema de criptografia pertence a chave e quaisquer
parâmetros associados.
• O número de série do certificado – a entidade (organização, aplicação ou pessoa) que criou o

certificado é responsável por distinguir este de outros certificados. Esta informação é usada
de várias maneiras; por exemplo, quando um certificado é revogado, seu número serial é
colocado em uma Lista de Revogação de Certificados (LCR), cujo conceito será detalhado
posteriormente.
• Identificação única do proprietário do certificado (ou DN – Distinguished Name – nome único):

este nome precisa ser único, sobretudo quando se fala em aplicações na internet. Um DN
consiste em várias subcampos e pode parecer com algo do tipo: CN=Marcos, OU=EaD,
O=IESB C=BR (Estes atributos se referem ao Nome Comum, Unidade Organizacional,
Organização e País). Você já pode ter percebido uma semelhança desses atributos com os
utilizados pelo Active Directory da Microsoft.
• O período de validade do certificado: a data de início da validade do certificado e data de

vencimento, o que indica quando o certificado expira.
• O nome único do emissor do certificado: o nome único da

entidade que assinou o certificado. Este campo normalmente é
associado a uma autoridade certificadora, o que implica na
confiança explícita na emissão desse certificado.
• Assinatura digital do emissor: a assinatura que usa a chave

privada da entidade que emitiu o certificado. Detalharemos
logo em seguida o conceito de assinatura digital.
• Identificador do Algoritmo de assinatura: identifica o algoritmo

usado pela autoridade para assinar o certificado. Pode ser
http://tinyurl.com/hsbca7e
simplesmente um algoritmo de HASH, como o SHA-512.
• Atributos ou extensões: a grande maioria dos certificados X.509 emitidos possui campos
chamados extensões (OID) que proveem algumas informações extras, como cadastros
adicionais do titular e do emitente, especificações de propósito do certificado, etc.

O certificado a seguir representa o certificado raiz da da ICP-Brasil, cujos

detalhes veremos mais adiante. Você pode fazer o download do
certificado no link a seguir.
http://tinyurl.com/gwk6nvl
O formato desse certificado digital pode ser representado conforme o seguinte comando em Shell UNIX:
mc$ openssl x509 -in ICP-Brasilv5.crt -text -noout

(Conteúdo Decodificado):
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha512WithRSAEncryption
Issuer: C=BR, O=ICP-Brasil, OU=Instituto Nacional de Tecnologia da
Informacao - ITI, CN=Autoridade Certificadora Raiz Brasileira v5
Validity
Not Before: Mar 2 13:01:38 2016 GMT
Not After : Mar 2 23:59:38 2029 GMT
Subject: C=BR, O=ICP-Brasil, OU=Instituto Nacional de
Tecnologia da Informacao - ITI, CN=Autoridade Certificadora Raiz
Brasileira v5
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
00:f7:2d:78:1a:6d:45:ac:17:e8:14:5f:0f:fa:60:
e0:de:17:65:e4:a8:4c:9f:93:75:5e:85:db:08:c7:
ed:ff:11:18:1d:8c:24:bf:a2:ec:58:47:41:29:8b:
68:5d:a0:c5:15:24:33:5f:dd:74:1f:8c:05:97:27:
20:a8:4e:77:87:60:09:76:31:c3:1d:be:8a:ad:2c:
1d:a2:95:e4:25:26:28:ac:d1:f4:ed:61:32:5a:c9:
e7:bd:04:02:1d:22:b0:a8:af:52:dc:d2:fa:33:5c:
2a:43:b6:ae:67:4f:08:63:22:87:1a:66:d7:2e:16:
c7:6b:92:5f:a7:6d:f6:31:97:99:bb:be:34:e4:4c:
c4:ba:8f:c7:df:8e:61:73:6c:d3:c3:94:9b:95:dd:
5c:bb:03:36:a9:3d:52:6b:32:5e:94:1c:f5:c2:1c:
c6:0c:ce:5d:0a:c5:1f:f8:ed:2e:57:1a:09:8b:62:
46:2d:f1:b3:42:1c:0d:df:83:4e:f2:f8:6b:6f:82:
ef:92:36:13:0f:c1:62:88:83:08:58:c3:ef:6f:12:
b3:a7:6a:f4:61:3a:29:98:a3:83:36:03:03:69:34:
ad:0e:28:b2:3b:22:6e:55:d3:de:23:16:9e:13:cb:
e9:a5:99:f4:07:d3:49:3c:9e:44:94:10:df:b5:4c:
61:a4:86:fd:7a:73:68:6e:91:bc:7d:88:27:db:9a:
4e:e2:9b:68:46:2a:34:00:f1:e1:fa:e1:53:d8:a1:
2d:aa:74:a6:cf:6d:dd:f1:0c:31:cd:d9:ca:e8:60:
aa:72:d9:4d:a8:41:35:41:49:ff:61:0b:7a:3a:7c:
aa:37:ce:9d:14:dd:d3:62:c3:b6:60:58:a4:bd:53:
03:f7:d5:0d:20:c2:00:75:a2:b6:60:2e:e1:7e:2c:
8a:69:1d:8c:31:71:31:bf:02:8b:cd:59:ae:2c:4c:
fb:a4:32:25:f6:2f:ea:7b:b8:81:c4:c5:36:49:25:
4e:18:a0:36:9c:42:1f:e6:7d:b3:c8:cf:7d:ba:d4:
77:b8:60:59:90:df:9b:1f:c3:77:8a:1d:04:8e:2f:
28:95:7d:eb:ff:9f:49:7f:af:7d:3c:3e:28:c4:77:
e7:7e:1f:3e:51:9a:a2:33:4b:c8:d8:5d:92:1e:27:
1c:a6:e2:61:23:13:57:ca:a5:e3:f9:e8:46:b9:d8:
b9:48:27:c6:6a:b0:9d:f1:cc:75:ae:dd:69:00:57:
3e:21:32:aa:d7:e8:13:cc:19:6d:88:c4:eb:84:51:

0c:88:68:20:60:d6:52:3a:40:b8:8f:30:7b:e8:db:
f2:7b:82:ee:18:7e:a4:5c:1f:a8:b6:ed:6d:c7:cb:
36:a6:11
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Certificate Policies:
Policy: 2.16.76.1.1.0
CPS: http://acraiz.icpbrasil.gov.br/DPCacraiz.pdf
X509v3 CRL Distribution Points:
Full Name:
URI:http://acraiz.icpbrasil.gov.br/LCRacraizv5.crl
X509v3 Authority Key Identifier:
keyid:69:A8:BE:75:D9:C4:EF:6C:E7:13:45:E4:61:6E:E5:68:F8:B6:40:5E
X509v3 Subject Key Identifier:
69:A8:BE:75:D9:C4:EF:6C:E7:13:45:E4:61:6E:E5:68:F8:B6:40:5E
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
14:6d:db:f2:62:59:aa:5e:7f:ba:3f:a6:58:51:e0:fc:72:9a:
53:08:a7:f2:5e:67:91:74:05:9d:57:69:f9:98:a6:5e:60:ea:
94:68:90:5a:c8:44:c1:57:2f:21:21:96:0a:39:d4:8d:39:22:
7c:82:73:d4:dd:e9:45:e3:96:c3:80:49:37:3f:2d:16:af:ca:
30:7f:f0:d7:10:8e:54:58:0e:1e:b1:7f:b3:9d:3f:4e:66:15:
c4:ff:d3:ee:9b:61:1b:4d:82:c9:d4:6e:bd:74:a5:fb:0a:fd:
4c:f2:52:f4:16:6e:e9:86:4b:9e:e1:09:9a:c0:64:ec:9d:f4:
cc:ee:92:21:7f:6b:30:1a:e8:97:e8:66:4d:a7:0e:41:2e:74:
a3:98:f2:d4:72:4e:93:26:0f:33:79:7e:e7:cf:48:2d:ef:ee:
d4:89:52:a4:ea:a3:9c:fb:ae:83:7f:16:67:24:47:31:80:63:
2c:f9:5e:e9:5b:39:ce:7f:52:c0:13:fe:d9:3e:28:ff:dc:95:
b6:ea:77:f8:61:7a:f9:a6:74:97:25:2e:bf:6a:59:96:5c:3a:
0c:ee:15:4d:98:b2:03:eb:a2:d5:6e:d1:f1:4d:5c:6a:fa:28:
af:5f:bb:8e:29:38:76:a3:98:cb:13:5c:ad:d7:ee:bf:cf:c2:
1d:7d:90:54:68:c3:91:77:45:03:14:64:2e:91:7b:46:0b:7d:
78:7e:ca:99:d4:48:2c:c0:fa:e2:f8:24:fb:47:20:6c:af:91:
b5:a2:ba:59:2e:b2:da:4e:29:44:95:c0:13:f3:bc:0d:ac:41:
43:af:a9:d6:c0:47:b0:bc:8d:c1:d8:14:93:2e:2b:61:d9:16:
38:bb:a7:17:16:59:a6:ff:34:ab:05:70:9d:ec:96:e0:e3:9a:
18:b3:a5:06:b1:6d:84:df:01:55:ee:de:af:32:77:4b:2e:fc:
11:c7:84:1a:6d:7b:21:ef:63:2c:b3:d0:46:fd:2d:4c:ac:47:
67:0c:b5:6b:df:3d:4e:af:9e:83:e0:62:f3:86:3b:50:b3:8b:
21:84:b2:02:94:2e:40:87:e2:8d:95:82:5d:60:42:e2:96:3b:
85:7a:f2:b1:56:f1:af:e3:be:ad:bc:b1:b6:3e:cb:f0:28:d0:
8e:68:86:99:c1:71:03:80:6b:08:85:6f:3e:b2:26:d3:9b:6a:
36:0c:bb:3b:43:0c:ff:28:63:ae:7a:12:eb:89:5c:12:61:b8:
a0:09:3c:8f:fb:58:3b:60:7d:5f:1f:7c:e8:7f:89:01:90:01:
35:4c:b6:00:cd:d2:0b:fc:6e:7e:4d:75:45:fc:50:c3:57:d6:
c1:e1:53:71:f5:52:9a:16
Dessa saída, podemos depreender algumas informações importantes sobre esse certificado digital raiz da
ICP1-Brasil:
• Validade: 02/03/1026 13:01:38 GMT até 02/03/2029 23:59:38 GMT.
• Algoritmo de criptografia: RSA (4096 bits).
• Algoritmo de assinatura digital: SHA-512.

1
O conjunto de procedimentos, normas e tecnologias necessárias para formar uma cadeia de certificação digital.
• Identificador da autoridade certificadora:

69:A8:BE:75:D9:C4:EF:6C:E7:13:45:E4:61:6E:E5:68:F8:B6:40:5E.
• Identificador padrão X.509: Subject: C=BR, O=ICP-Brasil, OU=Instituto Nacional de Tecnologia

da Informacao - ITI, CN=Autoridade Certificadora Raiz Brasileira v5.
Um dos benefícios diretos de um certificado digital é o que chamamos de assinatura digital. Uma
assinatura digital é basicamente um procedimento computacional que se utiliza de algoritmos
criptográficos e funções de hash para garantir à informação “assinada” os princípios da autenticidade
(onde o receptor pode comprovar a assinatura feita pelo emissor), da integridade (onde há a garantia de
que a informação não foi modificada) e da irretratabilidade (onde o emissor não pode negar a autoria
da assinatura, justamente pela garantia legal e computacional).
Na prática, a assinatura digital funciona como um hash criptográfico isolado. Contudo, esse hash é
calculado a partir de um certificado digital emitido por uma autoridade certificadora reconhecidamente
idônea. De fato, a idoneidade dos procedimentos de segurança adotados pelas autoridades
certificadoras é o que confere todas as garantias das quais falamos. Logo, o valor da assinatura digital,
que normalmente é um resultado numérico, pode ser conferido de forma a comprovar que a entidade
que assinou a informação não somente é coerente com sua identidade, mas que a integridade da
informação também foi mantida.
Quando utilizada em conjunto com a criptografia de chave pública, o
algoritmo assimétrico criptografa antes a assinatura digital e a envia
junto à mensagem. O receptor irá utilizar a chave pública para decifrar
a assinatura do remetente e irá calcular o valor do hash. Se os valores
forem iguais, a mensagem manteve as propriedades de autenticidade,
integridade e irretratabilidade (ou não repúdio). Note que não se fala
necessariamente em confidencialidade dos dados, mas este é um
benefício já explicitado quando falamos do PGP (Pretty Good Privacy).
Com isso, para que o princípio da autenticidade e da irretratabilidade
sejam assegurados é necessária a implementação todos os
procedimentos legais que consigam dar suporte à assinatura digital.
Todo esse processo é denominado de certificação digital.
Aprofunde-se um pouco mais sobre os conceitos apresentados e a

aplicabilidade deles assistindo ao vídeo disponível no link a seguir.
http://tinyurl.com/jgcbam3
Chegamos ao final de mais uma aula. As noções aqui estudadas são essenciais para o dia a dia profissional e
para o estudioso(a) da área. Continue os estudos desta disciplina e até breve!


Aula 21 | AUTORIDADES CERTIFICADORAS
Bem-vindos à Aula 21. Nesta aula, trataremos do conceito provavelmente mais importante desta Unidade de
Interação e Aprendizagem (UIA): as autoridades certificadoras. Vamos lá?
Vimos na anteriormente os conceitos técnicos acerca do que é um certificado digital e um exemplo

prático do conteúdo de um certificado digital. De fato, o certificado digital pode ser apresentado para o
usuário de diversas formas, desde um simples arquivo texto, bem como uma tela gráfica que represente
tais informações.
No cerne da certificação digital encontra-se o termo autoridade certificadora (AC2). O

que é uma autoridade certificadora? Em poucas palavras, uma AC (ou CA –
Certitication Authority) é uma entidade capaz de gerar certificados digitais. Simples
não?
Contudo, essa simplicidade traz consigo uma série de implicações técnico-jurídicas, pois ser uma
“autoridade” implica em “confiança”. Ora, se confiança é o que difere um par de chaves PGP de um
certificado digital emitido por uma AC reconhecida, podemos inferir que é preciso uma série de
procedimentos para criar tal “confiança”, não é mesmo?
Antes de nos aprofundarmos em alguns desses procedimentos e
terminologias, é preciso esclarecer que uma AC é, por si só e tecnicamente,
constituída de um par de chaves: pública e privada. Isso cria um novo
conceito que chamamos de cadeia de certificação. A cadeia de certificação
nada mais do que é uma hierarquia criada a partir do par de chaves da
própria AC, também chamado de par de chaves “raiz”, ou simplesmente
“certificado raiz”. Isso equivale dizer que qualquer outro certificado gerado a
partir do certificado raiz, ou “Root Key”, possui primariamente uma relação
http://tinyurl.com/hnvhzg9 matemático-computacional com ele. Há outras implicações, que serão
explanadas posteriormente.
Uma autoridade certificadora (AC) é, então, a essência de todos os benefícios que

vimos até agora.
Você – estudante – pode estar se perguntando agora: e se o certificado raiz for comprometido, toda a
cadeia de certificação também é comprometida? Absolutamente, sim! Daí decorre a necessidade de não
somente haver algoritmos criptográficos envolvidos, mas procedimentos que abranjam também
pessoas, pois em geral certificados digitais não são gerados automaticamente; eles passam por uma série
de procedimentos, como vimos brevemente nas Aulas 18 e 19.
Diante do exposto, é necessário que o certificado raiz seja gerado mediante certos cuidados. De fato, um
certificado raiz, que representa em sua totalidade uma AC, é na maioria das vezes gerado com uma cerimônia
auditável, ou seja, ela tem que passar pelo crivo de uma auditoria que constate a veracidade não somente das
pessoas envolvidas na geração, mas também fatores como data, horário, local, armazenamento, etc.

2
Entidade responsável pela emissão de certificados digitais de nível 1 e 2.
Dependendo da política de segurança adotada pela entidade, das leis aplicáveis à região geográfica, a
geração requer também testemunhas oculares, reconhecimento de firmas e outros procedimentos
jurídicos. Percebam então que a cerimônia de geração da AC-raiz não é somente automatizar um
software que seja capaz de gerar o par de chaves: é na prática um procedimento rígido, auditável e
confiável.
Para se ter uma breve ideia dos rígidos procedimentos adotados, podemos listar alguns
deles:
1. A sala-cofre onde será gerado certificado raiz não pode ter comunicação com o
mundo externo.
2. As pessoas dentro da sala-cofre precisam se identificar, notadamente as
envolvidas na geração propriamente dita.
3. Todo o procedimento é gravado em vídeo para auditorias futuras.
4. Mais de uma pessoa digitará a “frase-senha” de forma composta, a qual protegerá
o certificado raiz.
5. Cada pedaço da “frase-senha” é guardado em um envelope separado, que será
posteriormente armazenado em um cofre para uma possível recuperação de
senha, quando aplicável.
Assim, podemos perceber claramente uma AC-raiz não é feita somente de softwares e dispositivos
computacionais. O nível de confiabilidade deve ser atestado de forma que a AC-raiz atinja um nível de
idoneidade não somente em termos de segurança da informação, mas também dentro de todos os
aspectos jurídicos envolvidos. É o caso da cadeia de certificação digital no Brasil, sobre a qual
discutiremos oportunamente.
Um fator crucial na criação da AC-raiz é a composição da “frase-senha” que protegerá o certificado raiz.
Por que utilizar mais de uma pessoa para compor essa “frase-senha”? É o que
denominamos, dentro do mundo da segurança da informação, de múltipla
custódia.
Deve haver uma ordem em que as pessoas digitam a sua parte da senha. A múltipla custódia garante
pelo menos a resolução de dois problemas:
1. Não há uma única senha compartilhada entre várias pessoas.
2. Nenhuma das pessoas sabe o que a outra digitou.
Portanto, a múltipla custódia é a escolha de como proteger a “Root Key” na
maioria dos casos de uma AC-raiz. Trata-se de um procedimento, e não
especificamente de uma tecnologia. Dessa forma, a probabilidade de
comprometimento do certificado raiz é minimizada porque as pessoas
envolvidas não possuem total poder sobre as operações dentro da AC-raiz.
Uma depende da outra, necessariamente.
Falamos até agora somente em AC-raiz, mas na prática um certificado digital
http://tinyurl.com/h27wcp4
http://tinyurl.com/japq23e
de usuário, ou de servidor, ou qualquer que seja ele, é gerado por uma AC que
denominamos de intermediária. A AC intermediária tem sua chave gerada a partir da chave-raiz. Existe
ainda o conceito de autoridade de registro, que nada mais é do que uma entidade em um lugar
geográfico específico com poderes legais para gerar certificados a partir da AC intermediária.
Observe conceitos mais aprofundados acessando o link a seguir.

http://tinyurl.com/zey6vnx
Com isso, conseguimos criar uma cadeia de certificação, cuja ordem de importância está descrita a
seguir:
1. AC Raiz
2. AC Intermediária
3. Autoridade de Registro (AR3)
4. Certificado de usuário/servidor
Note que todos os pares de chaves são, de alguma forma, derivados computacionalmente da AC-raiz.
Podemos agora inferir, computacionalmente, que se o certificado raiz for comprometido, toda a cadeia
de certificação abaixo dele está comprometida também.
Quais as implicações de tal fato?
A geração de novos certificados para toda a cadeia, sem exceção. Isso é

facilmente demonstrável porque é possível, uma vez de posse do certificado
raiz, a criação de um novo certificado, seja intermediário ou mesmo de um
usuário, ou ainda a revogação de quaisquer dos certificados abaixo dele. A
confiança é quebrada a partir do momento do comprometimento. Entenda o
termo comprometimento como qualquer ação que exponha a AC-raiz a
qualquer pessoa alheia, qualquer pessoa fora do contexto da AC-raiz.
Uma outra característica inerente a uma AC-raiz é que o

certificado raiz não é gerado de forma derivada, ele é http://tinyurl.com/gw2pxae
autoassinado. O que isso significa?
Primeiro, ele não foi gerado por nenhum outro par de chaves. Segundo, uma entidade qualquer pode
criar um certificado e, a partir dele, gerar os demais certificados. O termo autoassinado é utilizado nesse
contexto por conta dos procedimentos auditáveis adotados. Isso significa que podemos confiar em todos
os certificados autoassinados? Absolutamente, não. Se assim fosse, navegadores como o Google Chrome
ou Firefox não nos avisariam que o certificado de um “site seguro” não é confiável.

3
Entidade responsável pela emissão de certificados digitais de usuários finais e de servidores.
Acesse o link a seguir para mais detalhes sobre a situação de mensagem

de conexão não confiável.
http://tinyurl.com/gv5xcm7
A aplicabilidade dos certificados digitais será abordada posteriormente.

A biblioteca OpenSSL, presente em praticamente qualquer distribuição UNIX, permite a criação de um
certificado autoassinado. Observe como um certificado SSL4 ou TLS5 pode ser criado. Não são levados em
consideração nesse exemplo os procedimentos de segurança citados anteriormente.
Exemplo da criação de um certificado autoassinado utilizando o algoritmo RSA com 4096 bits (utilizando
um Shell UNIX):
mc$ openssl genrsa -out key.pem 4096

Generating RSA private key, 4096 bit long modulus
.....................................++
.............................................++
e is 65537 (0x10001)
mc:~ mc$ openssl req -new -key key.pem -out csr.pem
You are about to be asked to enter information that will be
incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or
a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:BR
State or Province Name (full name) [Some-State]:DF
Locality Name (eg, city) []:Brasilia
Organization Name (eg, company) [Internet Widgits Pty Ltd]:IESB
Organizational Unit Name (eg, section) []:EAD
Common Name (e.g. server FQDN or YOUR name) []:ead.iesb.br
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:criptografia
An optional company name []:
mc:~ mc$ openssl req -x509 -days 365 -key key.pem -in csr.pem -out
certificate.pem
mc$ cat certificate.pem
-----BEGIN CERTIFICATE-----
MIIFkzCCA3ugAwIBAgIJAIFBuFIHPvRLMA0GCSqGSIb3DQEBCwUAMGAxCzAJBgNV
BAYTAkJSMQswCQYDVQQIDAJERjERMA8GA1UEBwwIQnJhc2lsaWExDTALBgNVBAoM
BElFU0IxDDAKBgNVBAsMA0VBRDEUMBIGA1UEAwwLZWFkLmllc2IuYnIwHhcNMTYw
NDE1MTIxNTExWhcNMTcwNDE1MTIxNTExWjBgMQswCQYDVQQGEwJCUjELMAkGA1UE
CAwCREYxETAPBgNVBAcMCEJyYXNpbGlhMQ0wCwYDVQQKDARJRVNCMQwwCgYDVQQL
DANFQUQxFDASBgNVBAMMC2VhZC5pZXNiLmJyMIICIjANBgkqhkiG9w0BAQEFAAOC
Ag8AMIICCgKCAgEAz9PzKWvRMtMvQIrF36O6G/0vuD9JaEEykI4Yb43boNYtrFZy
Y7UkTcImOfaNuihgmWFgnvW22zA/iY6Adr1Yg/JE9Vg+VsS481UvpfqGynrgkdKS
Hdo3QvnK4Vhrmzrq6NdUT42/SXB7KCDmB9NH+QcADWDmVAFSByMAntYzB6bLfIUm
lWWPWvuCuaZMd5KT/jQMw+mV5PQF7hR9vddTDDSCtFCvmb1KJPT6QWvLf02viGd8
FC7ehBeWiZ9XMZL3tkSuVytfFUPc3wX05hHSCSwiTGJHKP7k6zwOH18TuN220ONU

4
Protocolo criptográfico predecessor do TLS. Situa-se entre a camada de transporte e de aplicação do modelo TCP/IP.
5
Protocolo criptográfico sucessor do SSL. Situa-se entre a camada de transporte e de aplicação do modelo TCP/IP.
eLLrX0GKCciOpZqTUc79ZrJnWCamhVBd8/UGPcsCeDLdeIzglQsmCNb/jY1gepnC
owL5D+NMJWchEcpnaUa8/J3709YYFJ5rgU8Ea1w0D5nuBHmAEb8zEE72Qf6rdp/w
rssRHG22Vxt8TRAfXEv0l0pBI1/ZkzqsNJIWFSKPLozf/xnVlXFHg74jzTGevtpa
lEEmF10g29samPiZqzLS+6gz5IcbibjtGRyGAAKAUHIio0wEQBcxd2pc5nRJrACG
YSZspqZdoG7neaASj6LdH3bG6dYp3xmuKD7/9Vuvvpv4/qrpi7vfxCsALeP2nJwd
zuMjyMWUTCW6kfmXSEMt9v9XGc//a6jm1GVqal/e4DCrY3kdxEK/B0jKHpMCAwEA
AaNQME4wHQYDVR0OBBYEFGcJ3vZSr6tcew119yPiJLMfRp2pMB8GA1UdIwQYMBaA
FGcJ3vZSr6tcew119yPiJLMfRp2pMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEL
BQADggIBAAMmR2/I/RfSPBABnjp1yAh0B8ez4dwWqabHv/q3a9bi0FESWZUmd4KT
gLxDSJ3ZGzfBlkZTu5NOlZ2R0UhbaLOU0txdLPlWVP5DnZAK6xs5y9OBj5TKBjuv
TDp93D3+1cnUAHmIw5CfqKNtgREcb4GXsrV94hztqU3aABRAN8bSCXKgGtocix8r
q56REkMr0AibDxYJk+AFXFUm+qqzZWU5hDVT9wipfW4ma/WpkLmHcsfcJcyf9gey
7Pvmxdohw8EL3/uTrSK1UEC8+Q0vPw6VyxIdKZcM7MydTYJG5es2Ehxm3H9n0I/2
smrdV0fQX/JZ0LFYu3YUIdI/uK9aIWssyE0Iut4AJ9/8bvq4NUh8OXte0gUNOgjO
JslURzqcsIXWbmAnyAeA3LFUCEbSlPss6GtR2kYbz//EKCUQjwTn9pjIWSmkRfWa
3+hv+FU0MeNUl8B/1mTzw9f5vJysQj6JI8NtWfYk9CcMomyMJosAqTuuR8rswC+U
hSYJufv5xcLPY5iTzv6jC7exP9vsPQCl2d6sD/ZDOerEogV+a0TA+gixgoJ3hHtR
r1vDqADesfF32NM2B8jkbeQCmFYlRgx3rPuIFoLZFSg0y2iRaMPMxWMGmK/jYvNk
zH2WQ5SGNz70eXx0GAkZ/1vugWvywJ5cbVoNSCdRu+aIjE+Iyws7
-----END CERTIFICATE-----
RESULTADO DA GERAÇÃO DO CERTIFICADO AUTOASSINADO:
mc$ openssl x509 -in certificate.pem -text -noout

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 9313928166827291723 (0x8141b852073ef44b)
Issuer: C=BR, ST=DF, L=Brasilia, O=IESB, OU=EAD,
CN=ead.iesb.br
Validity
Not Before: Apr 15 12:15:11 2016 GMT
Not After : Apr 15 12:15:11 2017 GMT
Subject: C=BR, ST=DF, L=Brasilia, O=IESB, OU=EAD,
CN=ead.iesb.br
Modulus:
00:cf:d3:f3:29:6b:d1:32:d3:2f:40:8a:c5:df:a3:
ba:1b:fd:2f:b8:3f:49:68:41:32:90:8e:18:6f:8d:
db:a0:d6:2d:ac:56:72:63:b5:24:4d:c2:26:39:f6:
8d:ba:28:60:99:61:60:9e:f5:b6:db:30:3f:89:8e:
80:76:bd:58:83:f2:44:f5:58:3e:56:c4:b8:f3:55:
2f:a5:fa:86:ca:7a:e0:91:d2:92:1d:da:37:42:f9:
ca:e1:58:6b:9b:3a:ea:e8:d7:54:4f:8d:bf:49:70:
7b:28:20:e6:07:d3:47:f9:07:00:0d:60:e6:54:01:
52:07:23:00:9e:d6:33:07:a6:cb:7c:85:26:95:65:
8f:5a:fb:82:b9:a6:4c:77:92:93:fe:34:0c:c3:e9:
95:e4:f4:05:ee:14:7d:bd:d7:53:0c:34:82:b4:50:
af:99:bd:4a:24:f4:fa:41:6b:cb:7f:4d:af:88:67:
7c:14:2e:de:84:17:96:89:9f:57:31:92:f7:b6:44:
ae:57:2b:5f:15:43:dc:df:05:f4:e6:11:d2:09:2c:
22:4c:62:47:28:fe:e4:eb:3c:0e:1f:5f:13:b8:dd:
b6:d0:e3:54:78:b2:eb:5f:41:8a:09:c8:8e:a5:9a:
93:51:ce:fd:66:b2:67:58:26:a6:85:50:5d:f3:f5:
06:3d:cb:02:78:32:dd:78:8c:e0:95:0b:26:08:d6:
ff:8d:8d:60:7a:99:c2:a3:02:f9:0f:e3:4c:25:67:
21:11:ca:67:69:46:bc:fc:9d:fb:d3:d6:18:14:9e:
6b:81:4f:04:6b:5c:34:0f:99:ee:04:79:80:11:bf:
33:10:4e:f6:41:fe:ab:76:9f:f0:ae:cb:11:1c:6d:
b6:57:1b:7c:4d:10:1f:5c:4b:f4:97:4a:41:23:5f:
d9:93:3a:ac:34:92:16:15:22:8f:2e:8c:df:ff:19:
d5:95:71:47:83:be:23:cd:31:9e:be:da:5a:94:41:
26:17:5d:20:db:db:1a:98:f8:99:ab:32:d2:fb:a8:
33:e4:87:1b:89:b8:ed:19:1c:86:00:02:80:50:72:
22:a3:4c:04:40:17:31:77:6a:5c:e6:74:49:ac:00:
86:61:26:6c:a6:a6:5d:a0:6e:e7:79:a0:12:8f:a2:
dd:1f:76:c6:e9:d6:29:df:19:ae:28:3e:ff:f5:5b:
af:be:9b:f8:fe:aa:e9:8b:bb:df:c4:2b:00:2d:e3:
f6:9c:9c:1d:ce:e3:23:c8:c5:94:4c:25:ba:91:f9:
97:48:43:2d:f6:ff:57:19:cf:ff:6b:a8:e6:d4:65:
6a:6a:5f:de:e0:30:ab:63:79:1d:c4:42:bf:07:48:
ca:1e:93
Exponent: 65537 (0x10001)
X509v3 extensions:
67:09:DE:F6:52:AF:AB:5C:7B:0D:75:F7:23:E2:24:B3:1F:46:9D:A9
X509v3 Authority Key Identifier:
keyid:67:09:DE:F6:52:AF:AB:5C:7B:0D:75:F7:23:E2:24:B3:1F:46:9D:A9
X509v3 Basic Constraints:

CA:TRUE
03:26:47:6f:c8:fd:17:d2:3c:10:01:9e:3a:75:c8:08:74:07:
c7:b3:e1:dc:16:a9:a6:c7:bf:fa:b7:6b:d6:e2:d0:51:12:59:
95:26:77:82:93:80:bc:43:48:9d:d9:1b:37:c1:96:46:53:bb:
93:4e:95:9d:91:d1:48:5b:68:b3:94:d2:dc:5d:2c:f9:56:54:
fe:43:9d:90:0a:eb:1b:39:cb:d3:81:8f:94:ca:06:3b:af:4c:
3a:7d:dc:3d:fe:d5:c9:d4:00:79:88:c3:90:9f:a8:a3:6d:81:
11:1c:6f:81:97:b2:b5:7d:e2:1c:ed:a9:4d:da:00:14:40:37:
c6:d2:09:72:a0:1a:da:1c:8b:1f:2b:ab:9e:91:12:43:2b:d0:
08:9b:0f:16:09:93:e0:05:5c:55:26:fa:aa:b3:65:65:39:84:
35:53:f7:08:a9:7d:6e:26:6b:f5:a9:90:b9:87:72:c7:dc:25:
cc:9f:f6:07:b2:ec:fb:e6:c5:da:21:c3:c1:0b:df:fb:93:ad:
22:b5:50:40:bc:f9:0d:2f:3f:0e:95:cb:12:1d:29:97:0c:ec:
cc:9d:4d:82:46:e5:eb:36:12:1c:66:dc:7f:67:d0:8f:f6:b2:
6a:dd:57:47:d0:5f:f2:59:d0:b1:58:bb:76:14:21:d2:3f:b8:
af:5a:21:6b:2c:c8:4d:08:ba:de:00:27:df:fc:6e:fa:b8:35:
48:7c:39:7b:5e:d2:05:0d:3a:08:ce:26:c9:54:47:3a:9c:b0:
85:d6:6e:60:27:c8:07:80:dc:b1:54:08:46:d2:94:fb:2c:e8:
6b:51:da:46:1b:cf:ff:c4:28:25:10:8f:04:e7:f6:98:c8:59:
29:a4:45:f5:9a:df:e8:6f:f8:55:34:31:e3:54:97:c0:7f:d6:
64:f3:c3:d7:f9:bc:9c:ac:42:3e:89:23:c3:6d:59:f6:24:f4:
27:0c:a2:6c:8c:26:8b:00:a9:3b:ae:47:ca:ec:c0:2f:94:85:
26:09:b9:fb:f9:c5:c2:cf:63:98:93:ce:fe:a3:0b:b7:b1:3f:
db:ec:3d:00:a5:d9:de:ac:0f:f6:43:39:ea:c4:a2:05:7e:6b:
44:c0:fa:08:b1:82:82:77:84:7b:51:af:5b:c3:a8:00:de:b1:
f1:77:d8:d3:36:07:c8:e4:6d:e4:02:98:56:25:46:0c:77:ac:
fb:88:16:82:d9:15:28:34:cb:68:91:68:c3:cc:c5:63:06:98:
af:e3:62:f3:64:cc:7d:96:43:94:86:37:3e:f4:79:7c:74:18:
09:19:ff:5b:ee:81:6b:f2:c0:9e:5c:6d:5a:0d:48:27:51:bb:
e6:88:8c:4f:88:cb:0b:3b
O certificado acima foi criado hipoteticamente e pode ser utilizado por exemplo para criar uma conexão
criptografada entre um servidor web e um navegador. A confiança depositada nesse certificado depende
basicamente de quem está utilizando-o, pois ele não está atrelado a uma autoridade certificadora (CA).
Chegamos ao final de mais uma aula. Continue estudando para desenvolver as competências e habilidades
necessárias a essa área de atuação e do conhecimento. Até a próxima.
Aula 22 | INFRAESTRUTURA DE CHAVES PÚBLICAS – BRASIL (ICP-

BRASIL)
Bem-vindos à Aula 22. Estamos na metade do caminho para adquirir as competências e habilidades
proporcionadas por esta Unidade de Interação e Aprendizagem (UIA). Nesta aula, abordaremos os conceitos
principais da infraestrutura de chaves públicas brasileira.
Embora não tenhamos citado o termo infraestrutura, a reunião de todos os procedimentos e tecnologias
de segurança, bem como os algoritmos de criptografia vistos até aqui resumem-se em uma infraestrutura
de chave pública. Este é o ponto-chave no que diz respeito ao uso da criptografia de forma escalável, de
forma global e confiável. Entretanto, não podemos afirmar que a existência de uma infraestrutura de
chaves públicas resolve todos os problemas de segurança existentes.
Antes de solidificarmos os conceitos, precisamos definir, de acordo com
todo o contexto já exposto, o que é uma infraestrutura de chave
pública. O conceito mais abrangente é este: Uma infraestrutura de
chave pública, ou simplesmente (ICP), ou ainda “Public Key
Infrastructure (PKI)”, é um conjunto completo de regras,
procedimentos, tecnologias e leis necessárias para criar, distribuir e
revogar certificados digitais, permitindo operações criptográficas
envolvendo o uso desses certificados digitais de forma confiável, por
muitas vezes juridicamente válidos. Obviamente, cada país possui sua
http://tinyurl.com/hvpogf3
http://tinyurl.com/znz58n4
soberania para lidar com as questões jurídicas.
Pode-se afirmar que uma PKI é uma cadeia de confiança que parte de
uma AC-raiz e segue até o usuário final (usuário, servidores web, etc.). Essa cadeia de confiança começa
com a própria criação do certificado raiz. Do ponto de vista estritamente criptográfico, uma ICP é uma
entidade que gerencia chaves públicas geradas por seus titulares, assinadas e “certificadas” por ela. O
titular fica de posse da chave privada e da chave pública, mas qualquer comprometimento do par de
chaves deve ser reportado à autoridade certificadora.
Vimos na anteriormente que a cerimônia de geração da chave-raiz é um exemplo completo do nível de
confiança dado às autoridades certificadoras. Assim, uma PKI é composta de procedimentos, mas toda a
infraestrutura necessária para a execução desses procedimentos é composta também de software e
hardware. Na prática, toda autoridade certificadora deve possuir também uma conexão com a internet e
ser alcançável de qualquer parte do mundo, uma vez que a lista de revogação de certificados deve estar
disponível a qualquer momento para a consulta de certificados válidos.
Um outro conceito de fundamental importância, mas não mencionado até agora, é a precisão do tempo. Para
que todos os procedimentos de segurança, e até mesmo legais, sejam validados juridicamente, o tempo da
geração dos certificados é uma variável central. Isso equivale a dizer que a hora da geração de um certificado
também precisa estar atrelado à precisão do tempo, que, no Brasil, é fornecida como “Hora Legal Brasileira”.


O órgão responsável pela precisão do tempo no Brasil é o Observatório

Nacional, que fornece com precisão a data e hora através de um relógio
atômico, além de fornecer um carimbo de precisão. Leia mais sobre a
Hora Legal Brasileira acessando o link a seguir.
http://tinyurl.com/nmtd6o
O Brasil adotou o modelo de certificação de raiz única, o que significa

dizer que a cadeia de certificação gerada no Brasil é autoassinada e que
todos os certificados utilizados por autoridades certificadoras brasileiras
intermediárias são derivados unicamente desse certificado raiz. A base
legal para a geração dessa cadeia própria foi criada em 2001, através do
Decreto nº 3.872, de 18 de julho de 2001.
Esse decreto pode ser lido no link a seguir.
http://tinyurl.com/h2jwogl
Esse decreto foi revogado pelo Decreto nº 6.605, de 14 de outubro de
2008, disponível a seguir.
http://tinyurl.com/jodu6of
O nome dado a essa estrutura foi Infraestrutura de Chaves Públicas

Brasileira, ou simplesmente ICP-Brasil. O Comitê Gestor da
Infraestrutura de Chaves Públicas Brasileira (CG ICP-Brasil) tem como
função operar na formulação e domínio da execução das políticas
públicas relacionadas à Infraestrutura de Chaves, até mesmo nos
aspectos de normatização e nos procedimentos administrativos,
técnicos, jurídicos e de segurança da informação, que formam a cadeia
de confiança da ICP-Brasil.
A AC-raiz, Autoridade Certificadora Raiz, é a primeira autoridade da
cadeia de certificação brasileira e assina digitalmente os certificados
http://tinyurl.com/guzanzg
das Autoridades Certificadoras de primeiro nível, que, por sua vez,
assinam os de segundo nível. Todas as operações da AC-raiz ficam a cargo do Instituto Nacional de
Tecnologia da Informação (ITI). O ITI é uma autarquia federal vinculada à Casa Civil da Presidência da
República, cujo objetivo é manter a ICP Brasil e sua AC Raiz desde a publicação da Medida Provisória
2.200-2, de 24 de agosto de 2001. O ITI segue regras de funcionamento estabelecidas pelo Comitê Gestor
da ICP Brasil, cujos membros são nomeados pelo presidente da República, entre representantes dos
poderes da República, bem como de segmentos da sociedade e da academia, como forma de dar
estabilidade, transparência e confiabilidade ao sistema.
Um fator crucial acerca da confiabilidade dos certificados digitais emitidos pela ICP-Brasil é como dar
credibilidade a uma cadeia de certificação autoassinada. Conforme dito anteriormente, os processos de
geração de chaves, revogação, entre outros, são auditáveis. As auditorias no âmbito da Infraestrutura de
Chaves Pública Brasileira (ICP-Brasil) são realizadas de forma independente.
Os normativos norteiam o conceito de metodologia da auditoria, como manuais, roteiros, papéis de
trabalho, mapa de riscos, procedimentos, técnicas, formulários, relatórios e modelos. Os trabalhos de
auditoria são regidos pelo Código de Ética e princípios éticos para o exercício das atividades de auditoria
interna e independente estabelecidos pelos diversos órgãos reguladores ou de classe, como o Tribunal
de Contas da União (TCU), Controladoria Geral da União (CGU), Conselho Federal de Contabilidade (CFC),
Comissão de Valores Monetários (CVM), Instituto dos Auditores Independentes do Brasil (Ibracon),
Information Systems Audit and Control Association (Isaca), Instituto dos Auditores Internos do Brasil
(Audibra) e Instituto dos Auditores Internos (IIA).
As auditorias são em geral divididas em dois tipos: pré-operacionais e
operacionais. As auditorias pré-operacionais são as realizadas antes do
início das atividades do candidato a Prestador de Serviço de Certificação
(PSC), quer seja Autoridade Certificadora (AC), Autoridade de Carimbo do
Tempo (ACT), Autoridade de Registro (AR) ou Prestador de Serviço de
Suporte (PSS).
Para que a cadeia de certificação da ICP-Brasil seja reconhecida
mundialmente, ou seja, que pessoas de fora do Brasil possam, por exemplo,
confiar em um site de comércio eletrônico que utiliza um certificado ICP-
http://tinyurl.com/h5us667
brasil, é necessário que alguns dos grandes provedores de conteúdo e
fabricantes de aplicativos e navegadores mundiais confiem na cadeia.
Como exemplo prático, tais procedimentos hoje estão automáticos por parte da Microsoft. Uma vez que
o sistema operacional Windows detém grande parte do “Market Share” de usuários finais e desktops, os
certificados principais da ICP-Brasil já são distribuídos em conjunto com os de outras autoridades
certificadoras já bem conhecidas.
Em servidores HTTP do tipo Apache, a importação pode ser feita

utilizando estes procedimentos, disponíveis no seguinte link.
http://tinyurl.com/j3lm3vw
Como funciona em geral o processo de emissão de um certificado digital pela ICP-

Brasil?
Etapas:
• Solicitação do certificado: esta etapa é realizada, em geral, no site da Autoridade

Certificadora escolhida pelo usuário ou entidade, em que o solicitante preenche um
formulário eletrônico com seus dados, submete-o à AC e agenda uma data e hora para fazer a
validação presencial.
• Validação presencial: nesta fase, o solicitante se dirige até um ponto de atendimento da
Autoridade de Registro (que pode ser na própria AC), em posse de documentos de
identificação válidos, como RG, Carteira Nacional de Habilitação, Passaporte, etc. Um agente
autorizado valida a documentação, arquiva os documentos do solicitante e autoriza a
emissão do certificado.
• Emissão do certificado: nela ocorre efetivamente a emissão do certificado digital. Essa etapa
só ocorre se no mínimo dois agentes de registro confirmarem que a validação presencial
correu sem quaisquer irregularidades. Em algumas Autoridades Certificadoras, esta etapa

ocorre no mesmo momento da validação presencial e o titular do certificado emitido já sai da

Autoridade de Registro, dependendo do tipo do certificado, com um dispositivo de
armazenamento token ou cartão (smart card) contendo o certificado digital.
• Instalação do certificado: quando a emissão ocorre em uma etapa subsequente à validação
presencial, a instalação do certificado emitido consiste na última etapa do processo de
emissão. Nesse caso, é comum que a Autoridade Certificadora informe ao usuário, por e-mail,
que seu certificado digital está disponível para ser instalado. É o caso dos certificados A1, que
são instalados diretamente no computador do usuário, após a validação presencial. Veremos
posteriormente os tipos de certificado válidos no Brasil.
Lista de autoridades certificadoras credenciadas pela ICP-Brasil:
SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO)

Primeira Autoridade Certificadora de 1º nível credenciada pela ICP-Brasil, a empresa busca desde a
criação de seu Centro de Certificação Digital (CCD), em 1999, divulgar o uso dessa tecnologia para os
vários segmentos com que trabalha.
CAIXA ECONÔMICA FEDERAL

Única instituição financeira credenciada como Autoridade Certificadora ICP-Brasil, a Caixa Econômica
Federal tem trabalhado também para que a certificação digital integre serviços que resultem em
melhoras para seus funcionários, clientes e titulares das contas de Fundo de Garantia por Tempo de
Serviço (FGTS).
SERASA EXPERIAN
Autoridade Certificadora do setor privado, a Serasa fornece a segurança dos certificados digitais para
quase todos os grupos financeiros participantes do Sistema de Pagamentos Brasileiro (SPB).
RECEITA FEDERAL DO BRASIL

A Receita Federal do Brasil (RFB) disponibiliza uma grande quantidade de serviços com o objetivo de
simplificar ao máximo a vida dos contribuintes, facilitando o cumprimento espontâneo das obrigações
tributárias para os que possuem certificados digitais ICP-Brasil.
CERTISIGN
A Certisign tem duplo foco no ramo da certificação digital. Além de fornecer a ferramenta tecnológica, o
grupo desenvolve soluções para uso exclusivo com certificados digitais ICP-Brasil.
IMPRENSA OFICIAL DO ESTADO DE SÃO PAULO

A Imprensa Oficial é a Autoridade Certificadora Oficial do Estado de São Paulo credenciada para oferecer
produtos e serviços de certificação digital para os poderes executivo, legislativo e judiciário, incluindo
todas as esferas da administração pública, direta e indireta, nos âmbitos federal, estadual e municipal.
AC-JUS
A AC-JUS alavancou definitivamente a implantação da Certificação Digital no Judiciário fomentando o
desenvolvimento de aplicações para comunicação e troca de documentos eletrônicos, viabilizando entre
outros, o Processo Judicial Eletrônico (PJ-e). A AC-JUS por ser AC de 1º nível não emite certificados para
usuários finais, isto é, apenas emite certificados para as suas Autoridades Certificadoras subordinadas.
Estas sim, emitem os certificados para os usuários finais, que podem ser magistrados e servidores,
equipamentos e aplicações dos poderes judiciário, executivo ou legislativos federal ou estadual.
Atualmente, compõe a cadeia da AC-JUS: Certisign-JUS, SERASA-JUS, VALID-JUS SOLUTI-JUS, SERPRO-JUS
e CAIXA-JUS.
AC PR
Credenciada a emitir Certificados Digitais totalmente aderentes às normas, padrões estabelecidos pelo
Comité Gestor da ICP-Brasil, a Autoridade Certificadora da Presidência da República (ACPR) foi criada em
abril de 2002, por uma iniciativa da Casa Civil, no âmbito do governo eletrônico (e-Gov). A ACPR emite
certificados para autoridades e servidores da Presidência da República e da Vice-Presidência da República
e para autoridades e servidores do Poder Executivo Federal que necessitam utilizar certificado digital
para autenticação em aplicativos geridos pela PR.
CASA DA MOEDA DO BRASIL

Entre as mais antigas instituições públicas brasileiras, a instituição consolida o objetivo de modernização
de sua estrutura produtiva e administrativa, bem como se habilita para atender ao mercado de segurança
na era virtual.
VALID CERTIFICADORA DIGITAL

A AC Valid, 10ª entidade a credenciar-se como AC de 1° nível, atua no mercado de certificação digital
focando suas atividades em tecnologias que resultem na prestação de serviços. Além da emissão dos
certificados, a Valid oferece serviços de tecnologia para infraestrutura de chaves públicas, consultoria e
suporte no comando de processos e atividades de apoio a Autoridades de Registro.
SOLUTI CERTIFICAÇÃO DIGITAL

Especializada em tecnologia da informação com atuação em todo o território brasileiro, em 2012, a Soluti
tornou-se a 11ª Autoridade Certificadora (AC) de 1° nível vinculada a ICP-Brasil. A Soluti já atuava como
Autoridade de Registro (AR) em vários estados do País oferecendo serviços, produtos e soluções em
certificação digital.
AC DIGITALSIGN
A DigitalSign é uma empresa portuguesa, que através da DigitalSign Certificadora – empresa brasileira,
tornou-se a 12ª Autoridade Certificadora - AC de 1º nível da ICP-Brasil. O grupo é composto pelas
empresas DigitalSign Portugal, AET Europe e Thomas Greg & Sons.

AC BOA VISTA
A AC Boa Vista é a unidade de negócios de Certificação Digital da Boa Vista SCPC e completa a oferta da
empresa com soluções para a tomada de decisões sustentáveis de crédito e gestão de negócios.
Controlada por brasileiros, a Boa Vista SCPC opera o cadastro positivo no país e investe continuamente
em tecnologia de ponta para atender à sua carteira de clientes em todo o território nacional.
MINISTÉRIO DAS RELAÇÕES EXTERIORES

14º Autoridade Certificadora credenciada à ICP-Brasil, a AC-MRE é responsável exclusivamente pela
emissão do certificado digital que assina os componentes eletrônicos do novo passaporte brasileiro,
aderente ao Public Key Directory – PKD da Organização da Aviação Civil Internacional – ICAO, agência
especializada das Nações Unidas.
E aí, muito conteúdo? Estamos ficando cada vez mais especialistas no assunto, com isso, cresce a quantidade
e a qualidade daquilo que aprendemos ao longo da disciplina. Continue os estudos desta disciplina e até
breve!
Aula 23 | TÓPICOS EM CERTIFICAÇÃO DIGITAL
Bem-vindos à penúltima aula da Unidade de Interação e Aprendizagem (UIA) 4. Nesta aula, traremos à tona
tópicos importantes na parte de certificação digital não cobertos pelas aulas anteriores. Bons estudos!
Vimos nas aulas anteriores os conceitos de certificado digital, autoridades certificadoras e infraestrutura
de chaves públicas, bem como a relação desses conceitos com a parte jurídica. Ficou claro que, no Brasil,
toda a cadeia de certificação, denominada de ICP-Brasil, é controlada pelo Governo Federal através do ITI.
Quando um certificado digital é criado, conforme exemplos dados utilizando o próprio PGP e a biblioteca
OpenSSL, em geral, coloca-se um tempo de validade para tal certificado.
Por que isso é necessário na maioria dos casos?
Como primeiro fator, o usuário final; em segundo, o espaço amostral da frase-senha que protege o
certificado. O usuário final, ou o titular do certificado, por vezes não
possui uma consciência tão sólida sobre como tomar certos cuidados
no mundo cibernético: ele então escolhe senhas fáceis, não executa
procedimentos de atualização de software, clica em quaisquer links de
propagandas milagrosas que chegam em seu e-mail, entre outros
diversos cuidados. Todos esses fatores são subjetivos, mas têm uma
relação direta com a probabilidade de o certificado digital ser
comprometido de alguma forma, pois a superfície de ataque hoje é
muito grande em relação aos usuários finais.
Além disso, na hora da geração de um certificado digital, o par de
chaves é normalmente protegido com uma frase-senha. Algumas autoridades certificadoras impõem
certas condições para que a frase-senha não seja tão óbvia. Mesmo assim, a frase-senha pode não ser
suficientemente grande de forma a evitar ataques de força bruta, até por dicionário de palavras. Com
isso, a proteção do par de chaves, mormente a chave privada, pode ter um espaço amostral
relativamente pequeno que faça com que supercomputadores consigam quebrá-la em questão de
meses.
Daí decorrem algumas das razões que fazem com que boa parte dos certificados tenham um prazo
médio de validade relativamente curto, de 1 a 3 anos. Se houvesse a certeza plena de que o usuário
tomasse todos os cuidados necessários para evitar o comprometimento do certificado, certamente ele
nem necessitaria de um tempo curto de expiração, ou que ficasse até mesmo indefinidamente válido.
Diferentemente dos certificados de usuários e até mesmo de servidores, os certificados-raiz possuem um
tempo de validade médio alto exatamente por conta de todos os procedimentos de segurança adotados
por uma AC. Eles é quem garantem que a probabilidade de comprometimento seja muito baixa, pois são
procedimentos rígidos, cíclicos e auditáveis.
Em relação aos tipos de certificados digitais, eles variam muito conforme as autoridades certificadoras e
as necessidades dos usuários. Por exemplo, determinados usuários necessitam apenas assinar
documentos, ou assinar e criptografar documentos. A ICP-Brasil emite essencialmente duas categorias de
certificados digitais: A e S, sendo que cada uma se divide em quatro tipos: A1, A2, A3 e A4; S1, S2, S3 e S4.
Os certificados da categoria A costumam ser usados para fins de identificação e autenticação. Você pode
usá-los para assinar documentos ou validar transações eletrônicas, por exemplo. Já a categoria S é
direcionada a atividades sigilosas, como a proteção de arquivos confidenciais.
Seguem as características que tornam as versões de ambas as categorias diferentes entre si:
• A1 e S1: geração das chaves feita por software; chaves de tamanho mínimo de
1024 bits; armazenamento em dispositivo como HDs e pendrive; validade máxima
de um ano;
• A2 e S2: geração das chaves feita por software; chaves de tamanho mínimo de
1024 bits; armazenamento em cartão inteligente (com chip) ou token USB
(dispositivo semelhante a um pendrive); validade máxima de dois anos;
• A3 e S3: geração das chaves feita por hardware; chaves de tamanho mínimo de
1024 bits; armazenamento em cartão inteligente ou token USB; validade máxima
de cinco anos;
• A4 e S4: geração das chaves feita por hardware; chaves de tamanho mínimo de
2048 bits; armazenamento em cartão inteligente ou token USB; validade máxima
de seis anos.
Os certificados A1 e A3 são os mais comumente utilizados. No certificado tipo A1, o par de chaves
pública/privada é gerado em seu computador, no momento da solicitação de emissão do certificado. A
chave pública será enviada para a Autoridade Certificadora (AC) com a solicitação de emissão do
certificado, enquanto a chave privada ficará armazenada em seu computador, devendo,
obrigatoriamente, ser protegida por senha de acesso. Este certificado é instalado no mesmo computador
onde foi efetuada a solicitação do certificado e tem validade de 1 ano.
O certificado tipo A3 oferece maior nível de segurança, já que o par de chaves é gerado em um hardware
específico, em um cartão inteligente ou em um token que não permite a exportação ou qualquer outro tipo
de reprodução ou cópia da chave privada. Ainda, no certificado do tipo A3 a chave pública será enviada para a
AC junto com a solicitação de emissão do certificado, enquanto a chave privada ficará armazenada no cartão
ou token, impedindo tentativas de acesso de terceiros. Com este método, é possível transportar a chave
privada e o seu certificado digital de maneira mais segura. O certificado tipo A3 tem validade de 3 anos.
Cabe ainda mencionar os certificados do tipo T. Essa categoria descreve certificados de tempo
(timestamp), que atestam a hora e a data em que um documento foi assinando digitalmente, além de
confirmar a identidade do emissor do carimbo do tempo. Lembremo-nos que a data e hora são
essenciais em todos os processos de certificação digital.
Ainda sobre os tipos de certificados digitais, nem todos eles são emitidos diretamente por e para usuários
finais. Muitos deles são utilizados para criarem sessões criptografadas entre servidores web e cliente
(navegador). Portanto, uma conexão com um servidor que possua um certificado digital válido é
considerada uma conexão segura.
Na prática, os certificados digitais podem ser utilizados em inúmeros protocolos de serviços internet,
como:
• HTTPS6 para serviços web e comércio eletrônico
• STARTTLS para serviços de transporte de mensagens de e-mail
• SSH para conexões de shell remotas
• RDP para controle remoto de terminais gráficos Windows
• IRC para chats seguros

Vimos há pouco que certificados do tipo A1 e A3 se diferem basicamente pela sua geração e
armazenamento. Ressaltemos que a forma de armazenamento da chave privada é um fator capital para a
segurança do certificado digital em si, pois uma vez comprometido, o usuário no Brasil responde civil e
criminalmente pelo seu uso indevido, não podendo alegar a irretratabilidade.
A forma mais segura atualmente de armazenamento de uma chave privada é utilizar um dispositivo físico
chamado smartcard ou token (cartões inteligentes ou simplesmente “chips”). O que difere um do outro é
basicamente como ele será lido por um dispositivo computacional: ou por um leitor de smartcards ou via
entrada USB.
O formato de um “chip” é exatamente o mesmo utilizado em
cartões de crédito ou débito bancários, “chips” para celulares do
padrão GSM, entre outros. Eles também são chamados de sistemas
embarcados dentro do mundo da engenharia eletrônica e da
computação porque possuem tanto uma parte de hardware como
de software. Sem adentrarmos em muitos detalhes técnicos, eles são munidos de circuitos eletrônicos,
um software de comunicação com o computador e uma série de protocolos de segurança que garantem
um nível de segurança relativamente alto, mesmo exposto a qualquer indivíduo.
Obtenha mais informações sobre tokens e smartcards (em inglês),

acessando o link a seguir.
http://tinyurl.com/jq2tnr5

6
Protocolo de aplicação do modelo TCP/IP utilizado para acesso a páginas no formato web (WWW).
Um outro ponto importante dentro dos tópicos desta aula é a forte tendência do uso de criptografia
entre vários protocolos na internet. Em parte, essa tendência se fortificou
com o caso Edward Snowden, que revelou que o governo americano possui
mecanismos para interceptar o tráfego de diversos países. Portanto, o
objetivo maior é evitar a leitura em texto claro de um tráfego interceptado
na Internet, como mensageria instantânea e até mesmo transações
bancárias.
Diante disso, organizações como a EFF (Electronic Frontier Foundation),
Mozilla, Universidade de Michigan nos EUA, Cisco e Akamai reuniram
recentemente esforços para criar uma autoridade certificadora
independente que emite certificados digitais para websites, sem custo Edward Snowden
Fonte: http://tinyurl.com/q9rk4sv
algum. A força-tarefa, de nome Internet Security Research Group (ISRG), teve
como resultado o projeto batizado de Let’s Encrypt.
A CA “Let’s Encrypt” possui os seguintes princípios norteadores:
• Custo zero: Qualquer um que possua um domínio na Internet pode emitir um

certificado digital sem custo algum.
• Automático: O software executado no servidor pode interagir com a CA de forma

automatizada para as principais operações.
• Segura: A “Let’s Encrypt” servirá como uma plataforma global para avançar o uso
massivo do protocolo TLS.
• Transparente: Todos os certificados emitidos e revogados podem ser consultados
livremente via internet.
• Aberto: A emissão e renovação automáticas são publicadas abertamente de forma

que outras pessoas possam utilizar os mesmos padrões.
• Cooperativo: Assim como os principais protocolos de Internet, como o HTTP, a

“Let’s Encrypt” é um esforço conjunto com o intuito de beneficiar a sociedade sem
intervenção de órgãos controladores.
Você pode ler o certificado raiz da “Let’s Encrypt” no link a seguir.

http://tinyurl.com/jy592kb
Informações detalhadas do certificado raiz “Let’s Encrypt” extraídas com o comando openssl,
disponível em SHELL UNIX:
mc$ openssl x509 -in letsencrypt.txt -text -noout

Certificate:
Data:
Version: 3 (0x2)
Serial Number:
82:10:cf:b0:d2:40:e3:59:44:63:e0:bb:63:82:8b:00
Issuer: C=US, O=Internet Security Research Group, CN=ISRG
Root X1
Validity
Not Before: Jun 4 11:04:38 2015 GMT
Not After : Jun 4 11:04:38 2035 GMT
Subject: C=US, O=Internet Security Research Group, CN=ISRG
Root X1
Modulus:
00:ad:e8:24:73:f4:14:37:f3:9b:9e:2b:57:28:1c:
87:be:dc:b7:df:38:90:8c:6e:3c:e6:57:a0:78:f7:
75:c2:a2:fe:f5:6a:6e:f6:00:4f:28:db:de:68:86:
6c:44:93:b6:b1:63:fd:14:12:6b:bf:1f:d2:ea:31:
9b:21:7e:d1:33:3c:ba:48:f5:dd:79:df:b3:b8:ff:
12:f1:21:9a:4b:c1:8a:86:71:69:4a:66:66:6c:8f:
7e:3c:70:bf:ad:29:22:06:f3:e4:c0:e6:80:ae:e2:
4b:8f:b7:99:7e:94:03:9f:d3:47:97:7c:99:48:23:
53:e8:38:ae:4f:0a:6f:83:2e:d1:49:57:8c:80:74:
b6:da:2f:d0:38:8d:7b:03:70:21:1b:75:f2:30:3c:
fa:8f:ae:dd:da:63:ab:eb:16:4f:c2:8e:11:4b:7e:
cf:0b:e8:ff:b5:77:2e:f4:b2:7b:4a:e0:4c:12:25:
0c:70:8d:03:29:a0:e1:53:24:ec:13:d9:ee:19:bf:
10:b3:4a:8c:3f:89:a3:61:51:de:ac:87:07:94:f4:
63:71:ec:2e:e2:6f:5b:98:81:e1:89:5c:34:79:6c:
76:ef:3b:90:62:79:e6:db:a4:9a:2f:26:c5:d0:10:
e1:0e:de:d9:10:8e:16:fb:b7:f7:a8:f7:c7:e5:02:
07:98:8f:36:08:95:e7:e2:37:96:0d:36:75:9e:fb:
0e:72:b1:1d:9b:bc:03:f9:49:05:d8:81:dd:05:b4:
2a:d6:41:e9:ac:01:76:95:0a:0f:d8:df:d5:bd:12:
1f:35:2f:28:17:6c:d2:98:c1:a8:09:64:77:6e:47:
37:ba:ce:ac:59:5e:68:9d:7f:72:d6:89:c5:06:41:
29:3e:59:3e:dd:26:f5:24:c9:11:a7:5a:a3:4c:40:
1f:46:a1:99:b5:a7:3a:51:6e:86:3b:9e:7d:72:a7:
12:05:78:59:ed:3e:51:78:15:0b:03:8f:8d:d0:2f:
05:b2:3e:7b:4a:1c:4b:73:05:12:fc:c6:ea:e0:50:
13:7c:43:93:74:b3:ca:74:e7:8e:1f:01:08:d0:30:
d4:5b:71:36:b4:07:ba:c1:30:30:5c:48:b7:82:3b:
98:a6:7d:60:8a:a2:a3:29:82:cc:ba:bd:83:04:1b:
a2:83:03:41:a1:d6:05:f1:1b:c2:b6:f0:a8:7c:86:
3b:46:a8:48:2a:88:dc:76:9a:76:bf:1f:6a:a5:3d:
19:8f:eb:38:f3:64:de:c8:2b:0d:0a:28:ff:f7:db:
e2:15:42:d4:22:d0:27:5d:e1:79:fe:18:e7:70:88:
ad:4e:e6:d9:8b:3a:c6:dd:27:51:6e:ff:bc:64:f5:
33:43:4f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
79:B4:59:E6:7B:B6:E5:E4:01:73:80:08:88:C8:1A:58:F6:E9:9B:6E
55:1f:58:a9:bc:b2:a8:50:d0:0c:b1:d8:1a:69:20:27:29:08:
ac:61:75:5c:8a:6e:f8:82:e5:69:2f:d5:f6:56:4b:b9:b8:73:
10:59:d3:21:97:7e:e7:4c:71:fb:b2:d2:60:ad:39:a8:0b:ea:
17:21:56:85:f1:50:0e:59:eb:ce:e0:59:e9:ba:c9:15:ef:86:
9d:8f:84:80:f6:e4:e9:91:90:dc:17:9b:62:1b:45:f0:66:95:
d2:7c:6f:c2:ea:3b:ef:1f:cf:cb:d6:ae:27:f1:a9:b0:c8:ae:
fd:7d:7e:9a:fa:22:04:eb:ff:d9:7f:ea:91:2b:22:b1:17:0e:
8f:f2:8a:34:5b:58:d8:fc:01:c9:54:b9:b8:26:cc:8a:88:33:
89:4c:2d:84:3c:82:df:ee:96:57:05:ba:2c:bb:f7:c4:b7:c7:
4e:3b:82:be:31:c8:22:73:73:92:d1:c2:80:a4:39:39:10:33:
23:82:4c:3c:9f:86:b2:55:98:1d:be:29:86:8c:22:9b:9e:e2:
6b:3b:57:3a:82:70:4d:dc:09:c7:89:cb:0a:07:4d:6c:e8:5d:
8e:c9:ef:ce:ab:c7:bb:b5:2b:4e:45:d6:4a:d0:26:cc:e5:72:
ca:08:6a:a5:95:e3:15:a1:f7:a4:ed:c9:2c:5f:a5:fb:ff:ac:
28:02:2e:be:d7:7b:bb:e3:71:7b:90:16:d3:07:5e:46:53:7c:
37:07:42:8c:d3:c4:96:9c:d5:99:b5:2a:e0:95:1a:80:48:ae:
4c:39:07:ce:cc:47:a4:52:95:2b:ba:b8:fb:ad:d2:33:53:7d:
e5:1d:4d:6d:d5:a1:b1:c7:42:6f:e6:40:27:35:5c:a3:28:b7:
07:8d:e7:8d:33:90:e7:23:9f:fb:50:9c:79:6c:46:d5:b4:15:
b3:96:6e:7e:9b:0c:96:3a:b8:52:2d:3f:d6:5b:e1:fb:08:c2:
84:fe:24:a8:a3:89:da:ac:6a:e1:18:2a:b1:a8:43:61:5b:d3:
1f:dc:3b:8d:76:f2:2d:e8:8d:75:df:17:33:6c:3d:53:fb:7b:
cb:41:5f:ff:dc:a2:d0:61:38:e1:96:b8:ac:5d:8b:37:d7:75:
d5:33:c0:99:11:ae:9d:41:c1:72:75:84:be:02:41:42:5f:67:
24:48:94:d1:9b:27:be:07:3f:b9:b8:4f:81:74:51:e1:7a:b7:
ed:9d:23:e2:be:e0:d5:28:04:13:3c:31:03:9e:dd:7a:6c:8f:
c6:07:18:c6:7f:de:47:8e:3f:28:9e:04:06:cf:a5:54:34:77:
bd:ec:89:9b:e9:17:43:df:5b:db:5f:fe:8e:1e:57:a2:cd:40:
9d:7e:62:22:da:de:18:27
Perceba que a validade desse certificado raiz é de 20 anos.
Isso reflete exatamente o que foi mencionado nesta aula: que os procedimentos para a geração e
armazenamento da chave privada são bem mais rígidos do que aqueles adotados por seus usuários finais.
Chegamos ao final de mais uma aula. Até a próxima.
Aula 24 | ESTUDO DE CASO: SSL/TLS, OPENSSL E HEARTBLEED
Bem-vindos à última aula desta disciplina. Nesta aula, abordaremos os protocolos SSL/TLS, a biblioteca
OpenSSL e uma das vulnerabilidades de segurança mais graves descobertas até o presente momento. Fiquem
atentos e boa aula!
Os certificados digitais possuem inúmeros benefícios, conforme vimos nas aulas anteriores. Uma das
aplicações mais comuns dos certificados digitais é o uso deles em conjunto com os protocolos TLS
(Transport Layer Security) e SSL (Secure Sockets Layer). O TLS e o SSL são “protocolos criptográficos” que
impõem segurança de comunicação de dados na internet para serviços como e-mail (SMTP), navegação
por páginas web (HTTP) e outros tipos de transferência de dados. Há algumas breves diferenças entre o
SSL 3.0 e o TLS 1.0, contudo o protocolo permanece essencialmente o mesmo. O termo “SSL” utilizado
nesta aula aplicar-se-á a ambos os protocolos.
O SSL garante que a informação seja enviada sem alterações e tão somente para o servidor para o qual se
pretende enviar. Na prática, ambos são largamente utilizados para prover confidencialidade de dados em
trânsito, ou seja, conteúdo transmitido via redes de computadores, normalmente entre cliente e
servidores web na internet. Sites de comércio eletrônico e pagamentos online o utilizam proteger suas
informações, como dados pessoais dos usuários e números de cartões de crédito.

Em termos de arquitetura TCP/IP, o SSL é implementado entre os protocolos da camada de aplicação e a

camada de transporte (usualmente o protocolo TCP), transformando a conexão entre cliente e servidor
numa sessão segura, a exemplo da porta 443 HTTPS (Hyper Text Transfer Protocol Secure). Quaisquer
outros protocolos podem implementar o SSL para prover privacidade de dados em trânsito. Note que o
SSL é sempre correlacionado com dados em trânsito, e não dados armazenados em mídias comuns de
armazenamento como discos rígidos ou “storages”.
Em relação ao desempenho de envio e recebimento de pacotes, tanto cliente como servidor podem
adicionar latência a cada pacote enviado, já que cada um deles é criptografado. A cada pacote criado
com o conteúdo enviado junto a ele, uma série de negociações é feita entre cliente e servidor, incluindo
operações criptográficas comuns, como cifragem dos dados, garantia de integridade e autenticação.
As fases da negociação de uma sessão HTTPS, por exemplo, podem ser descritas assim:
1. O cliente envia a mensagem ClientHello propondo uma conexão segura com as
opções SSL.
2. O servidor responde com uma mensagem ServerHello selecionando a opção SSL.
3. O servidor envia seu certificado contendo sua chave pública (certificado X.509
emitido por uma AC) na mensagem Certificate.
4. O servidor conclui essa parte da negociação com a mensagem ServerHelloDone.
5. O cliente então envia a chave de sessão (encriptado com a chave pública do
servidor) na mensagem ClientKeyExchange.
6. O cliente envia a mensagem ChangeCipherSpec para acionar as opções já
negociadas para as próximas mensagens a serem enviadas.
7. O cliente envia a mensagem Finished para que o servidor verifique as opções
recentemente ativadas.
8. O servidor envia a mensagem ChangeCipherSpec para ativar as opções
previamente negociadas para as próximas mensagens enviadas.
9. O servidor envia a mensagem Finished para confirmar que todas as operações de
negociação de chaves e autenticação foram concluídas com sucesso.
Na maioria das sessões SSL e HTTPS, o certificado digital está presente somente do lado servidor, mas é
possível a troca de chaves públicas entre cliente e servidor, o que depende da implementação por parte
dos desenvolvedores das aplicações e da versão do protocolo SSL/TLS.
Os dados que trafegam entre o cliente e o servidor são criptografados utilizando um algoritmo simétrico,
como o AES, o DES, o RC4. Um algoritmo de chave pública – comumente o RSA – é empregado para
trocar as chaves simétricas criptografadas e para as assinaturas digitais. A sessão utiliza a chave pública
do certificado digital do servidor. Com a chave pública do servidor, o cliente pode conferir a identificação
do servidor através da cadeia de certificação da AC.
As versões 1 e 2 do protocolo SSL fornecem somente autenticação de servidor. A versão 3 inclui
autenticação de cliente, utilizando os certificados digitais do servidor e do cliente. A vantagem clara de se
utilizar algoritmos simétricos para a criptografia dos dados é o desempenho, já que algoritmos de chave
pública como o RSA são mais “lentos” para criptografia de dados em geral, conforme vimos em aulas
anteriores.
É possível afirmar que há uma forte tendência em se abandonar de

vez o protocolo SSL 3.0 para firmar o uso do protocolo TLS versão 1.2.
Embora o TLS seja o sucessor do SSL e contenha praticamente as
mesmas funcionalidades, ele adiciona algumas características
inexistentes no SSL, como o OCSP (Online Certificate Status Protocol)
Stapling, também conhecida como TLS Certificate Status Request.
Fundamentalmente, essa funcionalidade elimina a necessidade de se
verificar a lista de certificados revogados na autoridade certificadora
para cada pacote criado. Ainda, o TLS 1.2 eliminou o uso do algoritmo
RC4, por conter certas brechas nos processos criptográficos, e
adicionou o algoritmo de hash SHA-256 para verificação de integridade.
De acordo com o consórcio PCI DSS (Payment Card Industry Data Security Standard), formado por
empresas como Visa, Mastercard e American Express, o uso do SSL e de versões mais antigas do TLS não é
mais recomendado após 30 de junho de 2016. Esse movimento demonstra que a adoção do TLS 1.2 deve
ser acompanhada também pelos fabricantes dos principais navegadores de internet, como Google,
Mozilla e Microsoft.
Paradoxalmente, o uso massivo de selos com o dizer “Site Seguro” por conta do uso
de certificados digitais pode gerar uma falsa sensação de segurança.
Isso ocorre porque o SSL (termo mais genérico) cifra apenas dados em trânsito
entre as duas partes. Além disso, a exploração de uma vulnerabilidade presente
na aplicação web ou até mesmo no sistema operacional remoto passará de
modo cifrado, ou seja, indetectável por sistemas de detecção de intrusão na
maioria dos casos.
A própria biblioteca OpenSSL, utilizada em mais de 50% de todos os websites
no mundo todo, é um exemplo prático desse paradoxo. Em abril de 2014, Neel
Mehta, um engenheiro do time de segurança do Google descobriu, analisando
o código-fonte do OpenSSL, uma falha de segurança que permitia explorar
remotamente qualquer site utilizando SSL. A vulnerabilidade ficou conhecida Logo representativa da falha Heartbleed
Fonte: http://tinyurl.com/jugxlb2
como “Heartbleed” e foi reportada ao projeto OpenSSL de forma coordenada.

assista à videoaula sobre a falha Heartbleed.
Mais detalhes podem ser lidos (em inglês) no link a seguir.

http://tinyurl.com/h3jrtgk

De acordo com especialistas da área de segurança da informação,

incluindo Bruce Schneier, um dos mais conhecidos criptológos mundo
afora e autor de algoritmos criptográficos, categorizou a falha como
“catastrófica”, e numa escala de 0 a 10, ele próprio a classificou como
11. O porquê disso? Porque a vulnerabilidade, além de permitir a
execução de códigos remotamente, era indetectável e trazia para o
atacante informações altamente sensíveis (do ponto de vista do
atacante e do serviço web em si).
A mecânica do Heartbleed era basicamente explorar um componente

da biblioteca OpenSSL chamado de “Heartbeat”, que serve para manter
Bruce Scheneier a sessão aberta por um tempo maior, já que o protocolo HTTP não
Fonte: http://tinyurl.com/z5s4d2t
mantém sessões de forma persistente.
Resumidamente, o componente Heartbeat do OpenSSL permite que o cliente diga: "Estou lhe enviando
alguns dados. Envie um reconhecimento desses dados." Esses dados podem ser de até 64 KB de
tamanho. Por uma falha de verificação do tamanho do buffer do OpenSSL Heartbeat, o servidor envia de
volta, ao invés de 1 byte apenas, blocos de 64 KB dados da memória RAM.
Os detalhes técnicos da correção da falha podem ser lidos na íntegra na

página oficial, que contém o código-fonte do OpenSSL, disponível no
link a seguir.
http://tinyurl.com/zn22ovv
O problema todo reside no fato de que, na memória RAM de cada computador, são armazenados todos
os códigos em execução da máquina, nomes de usuários, senhas, daí por diante, tudo em texto claro.
Você conseguiria imaginar uma exploração dessa vulnerabilidade em um servidor com o selo “Site
Seguro” que contenha cartões de crédito ou até mesmo chaves privadas de criptografia? Além de
retornar dados extremamente sensíveis, eles retornam esses dados, paradoxalmente, de forma
criptografada por uma sessão SSL.
Segue um exemplo de prova de conceito utilizando uma máquina

virtual vulnerável através de um “exploit” criado em 2014. O código-
fonte em Python do “exploit” pode ser lido neste link.
http://tinyurl.com/hklkqed
Resultado da exploração da falha “Heartbleed” em um Shell UNIX (partes da memória RAM foram
retiradas por serem muito grandes):
mc$ ./heartbleed-poc.py X.X.X.X

Scanning X.X.X.X on port 443
Connecting...
Sending Client Hello...
Waiting for Server Hello...

... received message: type = 22, ver = 0302, length = 54
Server TLS version was 1.2
Sending heartbeat request...
Received heartbeat response:
0000: 02 40 00 D8 03 02 53 43 5B 90 9D 9B 72 0B BC 0C
.@....SC[...r...
0010: BC 2B 92 A8 48 97 CF BD 39 04 CC 16 0A 85 03 90
.+..H...9.......
0020: 9F 77 04 33 D4 DE 00 00 66 C0 14 C0 0A C0 22 C0
.w.3....f.....".
0030: 21 00 39 00 38 00 88 00 87 C0 0F C0 05 00 35 00
!.9.8.........5.
0040: 84 C0 12 C0 08 C0 1C C0 1B 00 16 00 13 C0 0D C0
................
0050: 03 00 0A C0 13 C0 09 C0 1F C0 1E 00 33 00 32 00
............3.2.
0060: 9A 00 99 00 45 00 44 C0 0E C0 04 00 2F 00 96 00
....E.D...../...
0070: 41 C0 11 C0 07 C0 0C C0 02 00 05 00 04 00 15 00
A...............
0080: 12 00 09 00 14 00 11 00 08 00 06 00 03 00 FF 01
................
0090: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00
..I...........4.
00a0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00
2...............
00b0: 0A 00 16 00 17 00 08 00 06 00 07 00 14 00 15 00
................
00c0: 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0F 00
................
00d0: 10 00 11 00 23 00 00 00 0F 00 01 01 1D F2 9C 16
....#...........
00e0: 27 85 54 F1 3E 0D A1 EE 73 59 CC F9 4E 1F 64 B7
'.T.>...sY..N.d.
00f0: 79 F1 59 BE 2E B5 AA CB A8 33 F5 07 C5 46 F6 86
y.Y......3...F..
0100: 00 BD 60 BD A5 D3 A3 3E 70 63 D7 3F A7 02 02 02
..`....>pc.?....
0110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
0120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
3d00: 94 06 E0 2D 75 20 00 00 7C A4 E2 2D 71 44 03 00 ...-u ..|..-
qD..
3d10: 18 04 E0 2D 18 04 E0 2D 08 E0 41 2E 08 E0 41 2E ...-...-
..A...A.
3d20: 00 00 00 00 48 C1 12 2E 48 C1 12 2E 4C C1 12 2E
....H...H...L...
3d30: 80 7D E3 2D 00 00 00 00 EC E0 EF 2D 90 AA 03 1F .}.-.......-
....
3d40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
3d50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 47 45
..............GE
3d60: 54 20 2F 66 6F 6C 64 65 72 20 48 54 54 50 2F 31 T /folder
HTTP/1
3d70: 2E 30 0D 0A 48 6F 73 74 3A 20 20 11 0D 0A 41 75 .0..Host:
...Au
3d80: 74 68 6F 72 69 7A 61 74 69 6F 6E 3A 20 42 61 73 thorization:
Bas
3d90: 69 63 20 63 6D 39 76 64 44 70 68 63 48 52 34 4E ic
cm9vdDphcHR4N
3da0: 44 67 32 4F 51 3D 3D 0D 0A 55 73 65 72 2D 41 67
Dg2OQ==..User-Ag
3db0: 65 6E 74 3A 20 4D 6F 7A 69 6C 6C 61 2F 34 2E 30 ent:
Mozilla/4.0
3dc0: 20 28 48 79 64 72 61 29 0D 0A 58 2D 46 6F 72 77 (Hydra)..X-
Forw
3dd0: 61 72 64 65 64 2D 50 72 6F 74 6F 3A 20 68 74 74 arded-Proto:
htt
3de0: 70 73 0D 0A 58 2D 46 6F 72 77 61 72 64 65 64 2D ps..X-
Forwarded-
3df0: 46 6F 72 3A 20 31 30 39 2E 32 33 35 2E 32 35 34 For:
109.235.254
3e00: 2E 31 38 31 0D 0A 0D 0A 00 00 00 00 00 00 00 00
.181............
WARNING: server X.X.X.X returned more data than it should - server is
vulnerable!
Observe a mensagem acima “WARNING: server X.X.X.X returned more data than it
should - server is vulnerable!”. Ela indica claramente que o servidor está vulnerável.
Observe também partes da memória RAM do servidor web. Note que a conexão foi feita através de uma
sessão SSL, de forma criptografada. Além de não ser possível ler o conteúdo durante o tráfego desses
dados, à época da descoberta, ficou indetectável até que pesquisadores de segurança desenvolvessem
uma assinatura capaz de reconhecer o ataque por algumas características dos pacotes, mas não baseada
em seu conteúdo.
Não se trata de um paradoxo ter uma conexão criptograficamente segura, mas estar vulnerável por uma
simples falha de checagem de dados? Vale a pena ressaltar que o “Heartbleed” não foi uma falha dos
protocolos de criptografia em si, mas sim da implementação errônea de um de seus componentes.
Chegamos ao final de nossa disciplina. Espero que tenham aproveitado ao máximo. Até a próxima e bons
estudos!
Você terminou o estudo desta unidade. Chegou o momento de verificar sua aprendizagem.
Ficou com alguma dúvida? Retome a leitura.
Quando se sentir preparado, acesse a Verificação de Aprendizagem da unidade no menu
lateral das aulas ou na sala de aula da disciplina. Fique atento, essas questões valem nota!
Você terá uma única tentativa antes de receber o feedback das suas respostas, com
comentários das questões que você acertou e errou.
Vamos lá?!

REFERÊNCIAS
KONHEIM, Alan G. Computer security and cryptography. USA: Wiley-Interscience, 2007.
SCHENEIR, B. Applied cryptography. New York: John Wiley & Sons, 1996.
STALLINGS, William. Criptografia e segurança de redes: princípios e práticas. São Paulo: Prentice-Hall, 2008.
GLOSSÁRIO
TLS (Transport Layer Security): Protocolo criptográfico sucessor do SSL. Situa-se entre a camada de
transporte e de aplicação do modelo TCP/IP.
SSL (Secure Sockets Layer): Protocolo criptográfico predecessor do TLS. Situa-se entre a camada de
transporte e de aplicação do modelo TCP/IP.
HTTPS (Hyper Text Transfer Protocol Secure): Protocolo de aplicação do modelo TCP/IP utilizado para
acesso a páginas no formato web (WWW).
AC (Autoridade Certificadora): Entidade responsável pela emissão de certificados digitais de nível 1 e 2.
AR (Autoridade de Registro): Entidade responsável pela emissão de certificados digitais de usuários
finais e de servidores.
ICP (Infraestrutura de chaves públicas): O conjunto de procedimentos, normas e tecnologias
necessárias para formar uma cadeia de certificação digital.

UIA4

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

UIA4

Încărcat de

Drepturi de autor:

Formate disponibile

VERSÃO PARA IMPRESSÃO

CRIPTOGRAFIA: ALGORITMOS E CERTIFICAÇÃO

Copyright © 2016 Centro Universitário IESB. Todos os direitos reservados.

Aula 19 | Princípios de Certificação Digital ................................................................................4

Aula 23 | Tópicos em Certificação Digital ................................................................................ 25

Copyright © 2016 Centro Universitário IESB. Todos os direitos reservados.

Aula 19 | PRINCÍPIOS DE CERTIFICAÇÃO DIGITAL

Acesse o Ambiente Virtual de Aprendizagem (AVA) da disciplina e

Certificação digital é provavelmente o tópico mais genérico em termos de

Copyright © 2016 Centro Universitário IESB. Todos os direitos reservados.

Leia mais sobre esse assunto acessando o link disponível a seguir.

O armazenamento da chave privada é algo tão crítico na criptografia de chave

-----BEGIN PGP PRIVATE KEY BLOCK-----

Perceba que o problema não está necessariamente na forma de

Você pode estar se perguntando agora: mas a

• Prover meios para o gerenciamento das chaves, como expiração automática.

Copyright © 2016 Centro Universitário IESB. Todos os direitos reservados.

• Prover o mecanismo de assinatura digital, cujo conceito depende da

Basicamente, a presunção ou a certeza de que a pessoa que está naquele

• Apresentação de um documento legal que ateste a identidade

• A autoridade certificadora está auditada perante normas internacionais.

Copyright © 2016 Centro Universitário IESB. Todos os direitos reservados.

Aula 20 | CERTIFICADO DIGITAL

Acesse o Ambiente Virtual de Aprendizagem (AVA) da disciplina e

Diante desses princípios norteadores, o que é um certificado digital?

Certificado digital é um conjunto de informações que atestam que uma chave

Praticamente todos os certificados digitais emitidos mundo afora

entidades podem ser identificadas unicamente.

Um certificado X.509 é, na prática, um arquivo contendo campos ou informações

• O número de série do certificado – a entidade (organização, aplicação ou pessoa) que criou o

• Identificação única do proprietário do certificado (ou DN – Distinguished Name – nome único):

• O período de validade do certificado: a data de início da validade do certificado e data de

• O nome único do emissor do certificado: o nome único da

• Assinatura digital do emissor: a assinatura que usa a chave

• Identificador do Algoritmo de assinatura: identifica o algoritmo

Copyright © 2016 Centro Universitário IESB. Todos os direitos reservados.

O certificado a seguir representa o certificado raiz da da ICP-Brasil, cujos

mc$ openssl x509 -in ICP-Brasilv5.crt -text -noout

Copyright © 2016 Centro Universitário IESB. Todos os direitos reservados.

• Validade: 02/03/1026 13:01:38 GMT até 02/03/2029 23:59:38 GMT.

• Algoritmo de criptografia: RSA (4096 bits).

• Algoritmo de assinatura digital: SHA-512.

• Identificador da autoridade certificadora:

• Identificador padrão X.509: Subject: C=BR, O=ICP-Brasil, OU=Instituto Nacional de Tecnologia

Todo esse processo é denominado de certificação digital.

Aprofunde-se um pouco mais sobre os conceitos apresentados e a

Copyright © 2016 Centro Universitário IESB. Todos os direitos reservados.

Aula 21 | AUTORIDADES CERTIFICADORAS

Vimos na anteriormente os conceitos técnicos acerca do que é um certificado digital e um exemplo

No cerne da certificação digital encontra-se o termo autoridade certificadora (AC2). O

Uma autoridade certificadora (AC) é, então, a essência de todos os benefícios que

Observe conceitos mais aprofundados acessando o link a seguir.

Quais as implicações de tal fato?

A geração de novos certificados para toda a cadeia, sem exceção. Isso é

Uma outra característica inerente a uma AC-raiz é que o

autoassinado. O que isso significa?

Acesse o link a seguir para mais detalhes sobre a situação de mensagem

A aplicabilidade dos certificados digitais será abordada posteriormente.

mc$ openssl genrsa -out key.pem 4096

RESULTADO DA GERAÇÃO DO CERTIFICADO AUTOASSINADO:

mc$ openssl x509 -in certificate.pem -text -noout

X509v3 Basic Constraints:

Aula 22 | INFRAESTRUTURA DE CHAVES PÚBLICAS – BRASIL (ICP-

Copyright © 2016 Centro Universitário IESB. Todos os direitos reservados.