( PDF ) Aspectos técnicos e teóricos da gestão do ciclo de vida de chaves critptográficas no openHSM

Download PDF

ads:

UNIVERSIDADE FEDERAL DE SANTA CATARINA

PROGRAMA DE P

OS-GRADUAC¸

AO EM CI

ENCIA DA

COMPUTAC¸

ulio C

ıcero Salvaro de Souza

Aspectos T

ecnicos e Te

oricos da Gest

ao do Ciclo de

Vida de Chaves Criptogr

aﬁcas no OpenHSM

Dissertac¸

ao submetida

a Universidade Federal de Santa Catarina como parte dos

requisitos para a obtenc¸

ao do grau de Mestre em Ci

encia da Computac¸

ao.

Prof. Ricardo Felipe Cust

odio, Dr.

Orientador

Florian

opolis, Outubro de 2008

ads:

Livros Grátis

http://www.livrosgratis.com.br

Milhares de livros grátis para download.

Aspectos T

ecnicos e Te

oricos da Gest

ao do Ciclo de Vida de

Chaves Criptogr

aﬁcas no OpenHSM

ulio C

ıcero Salvaro de Souza

Esta Dissertac¸

ao foi julgada adequada para a obtenc¸

ao do t

ıtulo de Mestre em Ci

encia

da Computac¸

ao,

area de concentrac¸

ao Sistemas de Computac¸

ao e aprovada em sua forma

ﬁnal pelo Programa de P

os-Graduac¸

ao em Ci

encia da Computac¸

ao.

Prof. Frank Augusto Siqueira, Dr.

Coordenador do Curso

Banca Examinadora

Prof. Ricardo Felipe Cust

odio, Dr.

Orientador

Prof. Jeroen Antonius Maria van de Graaf, PhD.

Prof. Joni da Silva Fraga, Dr.

Prof. Michael Anthony Stanton, Dr.

Prof. Olinto Jos

e Varella Furtado, Dr.

Prof. Renato da Silveira Martini, PhD.

ads:

iii

”Me abafa Dalila ... que eu estou abanado!”

Marco Aur

elio Salvaro de Souza 2005.

Ao meu grande av

o Silvino.

Agradecimentos

Primeiramente, gostaria de agradecer a toda minha fam

ılia, principal-

mente aos meus pais, Mariano e Ilda, e a Giani, que se tornou minha esposa durante

a execuc¸

ao deste trabalho.

E o apoio de voc

es que garante o sucesso de todas minhas

escolhas de vida.

Tamb

em sou grato ao meu orientador, professor Cust

odio, que est

pronto para ajudar a qualquer momento, mantendo sempre a situac¸

ao sobre controle. Sua

experi

encia serve de guia para os membros do LabSEC. Membros estes que, mesmo a um

oceano de dist

ancia, continuam apoiando e ajudando na minha caminhada de descobertas.

Com certeza todos ganham muito convivendo neste ambiente de aprendizado.

ao poderia deixar de citar minha gratid

ao ao professor, tio, padrinho e

amigo Olinto. Ele v

em me guiando desde a escolha do curso de graduac¸

ao ideal. Nunca

vou esquecer o dia que estava em sua sala, desabafando sobre o meu descontentamento

com o tema do meu trabalho de conclus

ao de curso. Ele virou pra mim e disse: “por qu

voc

e n

ao vai ali conversar com o Professor Cust

odio, eu acho que voc

e tem o perﬁl para

trabalhar na

area de seguranc¸a”. Obrigado pelas dicas certas nas horas certas.

E ﬁnalmente, agradec¸o a Rede Nacional de Ensino e Pesquisa, entidade

que v

em promovendo o uso de tecnologias avanc¸adas nas instituic¸

oes parceiras, proporci-

onando aos professores e pesquisadores ferramentas e meios de grande valia na pesquisa

e ensino no Brasil.

Sum

ario

Lista de Figuras x

Lista de Tabelas xi

Lista de Siglas xii

Lista de S

ımbolos xv

Resumo xvi

Abstract xvii

1 Introduc¸

ao 1

1.1 Infra-estrutura de Chaves P

ublicas para Pesquisa e Ensino . . . . . . . . 3

1.2 Contextualizac¸

ao das Contribuic¸

oes . . . . . . . . . . . . . . . . . . . . 5

1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3.2 Objetivos Espec

ıﬁcos . . . . . . . . . . . . . . . . . . . . . . . . 8

1.4 Justiﬁcativa e Motivac¸

ao . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.5 Trabalhos Correlatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.6 Organizac¸

ao deste Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Hardware Criptogr

aﬁco 12

2.1 Introduc¸

ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Smartcards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

vii

2.2.1 Smartcards para HSMs . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 M

odulo de Seguranc¸a Criptogr

aﬁca (HSM) . . . . . . . . . . . . . . . . 15

2.3.1 Ciclo de vida de chaves criptogr

aﬁcas . . . . . . . . . . . . . . . 15

2.3.2 M

odulos de Seguranc¸a Criptogr

aﬁca de Mercado . . . . . . . . . 16

2.4 Conclus

ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Normas 20

3.1 Introduc¸

ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 FIPS PUB 140 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 Especiﬁcac¸

ao do M

odulo Criptogr

aﬁco . . . . . . . . . . . . . . 22

3.2.2 Portas F

ısicas e Interfaces L

ogicas . . . . . . . . . . . . . . . . . 22

3.2.3 Pap

eis, Servic¸os e Mecanismos de Autenticac¸

ao . . . . . . . . . 23

3.2.4 Modelo de estados ﬁnitos . . . . . . . . . . . . . . . . . . . . . 25

3.2.5 Seguranc¸a F

ısica . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.6 Ambiente Operacional . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.7 Gerenciamento de Chaves Criptogr

aﬁcas . . . . . . . . . . . . . 27

3.2.8 Interfer

encia e Compatibilidade Eletromagn

etica . . . . . . . . . 28

3.2.9 Auto-testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.10 Garantia de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2.11 Mitigac¸

ao de Outros Ataques . . . . . . . . . . . . . . . . . . . . 29

3.3 Manual de Condutas T

ecnicas 7 (LEA/ITI) . . . . . . . . . . . . . . . . 30

3.3.1 Requisitos de Especiﬁcac¸

ao . . . . . . . . . . . . . . . . . . . . 31

3.3.2 Portas F

ısicas e Interfaces L

ogicas . . . . . . . . . . . . . . . . . 31

3.3.3 Pap

eis, Servic¸os e Mecanismos de Autenticac¸

ao . . . . . . . . . 32

3.3.4 Modelo de Estado Finito . . . . . . . . . . . . . . . . . . . . . . 32

3.3.5 Seguranc¸a F

ısica . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.3.6 Ambiente Operacional . . . . . . . . . . . . . . . . . . . . . . . 33

3.3.7 Gerenciamento de Chaves Criptogr

aﬁcas . . . . . . . . . . . . . 33

3.3.8 Interfer

encia e Compatibilidade Eletromagn

etica . . . . . . . . . 34

3.3.9 Auto-testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

viii

3.3.10 Garantia de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.3.11 Mitigac¸

ao de Outros Ataques . . . . . . . . . . . . . . . . . . . . 34

3.3.12 Requisitos de Gerenciamento . . . . . . . . . . . . . . . . . . . 34

3.3.13 Requisitos de Interoperabilidade . . . . . . . . . . . . . . . . . . 35

3.3.14 Requisitos para restric¸

ao de subst

ancias nocivas . . . . . . . . . . 35

3.4 Conclus

ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4 OpenSSL 37

4.1 Introduc¸

ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2 Aplicac¸

ao de Linha de Comando . . . . . . . . . . . . . . . . . . . . . . 38

4.3 Infra-estrutura de Suporte . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.3.1 Arquivos de Conﬁgurac¸

ao . . . . . . . . . . . . . . . . . . . . . 39

4.3.2 Func¸

oes de Callback . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3.3 Suporte Multi-thread . . . . . . . . . . . . . . . . . . . . . . . . 41

4.3.4 Matem

atica de Precis

ao Arbitr

aria . . . . . . . . . . . . . . . . . 42

4.3.5 Tratamento de Erros . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3.6 Abstrac¸

ao de Entrada e Sa

ıda . . . . . . . . . . . . . . . . . . . 44

4.4 Documentac¸

ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.5 Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.6 OpenSSL FIPS 140-2 n

ıvel 1 . . . . . . . . . . . . . . . . . . . . . . . . 49

4.7 Conclus

ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5 ASI-HSM 53

5.1 Introduc¸

ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.2 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.3 Aplicativos de Administrac¸

ao Remota . . . . . . . . . . . . . . . . . . . 56

5.4 Engine OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.5 Conclus

ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6 OpenHSM - Operacionalizac¸

ao 59

6.1 Aspectos Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.2 Inicializac¸

ao do HSM e criac¸

ao do grupo de Administradores . . . . . . . 64

6.3 Criac¸

ao de um grupo de Auditores . . . . . . . . . . . . . . . . . . . . . 65

6.4 Criac¸

ao de um grupo de Operadores . . . . . . . . . . . . . . . . . . . . 67

6.5 Criac¸

ao de Chave Gerenciada . . . . . . . . . . . . . . . . . . . . . . . . 69

6.6 Liberando uma Chave Gerenciada para Uso . . . . . . . . . . . . . . . . 70

6.7 Troca do grupo de Administratores . . . . . . . . . . . . . . . . . . . . . 71

6.8 Alterando os respons

aveis por uma chave gerenciada . . . . . . . . . . . 73

6.9 Criando o ponto de conﬁanc¸a de um grupo de Operadores em relac¸

ao aos

Administradores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.10 Exportac¸

ao dos Registros de Atividades . . . . . . . . . . . . . . . . . . 75

6.11 Limpeza dos Registros de Atividades . . . . . . . . . . . . . . . . . . . . 76

6.12 Conclus

ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

7 OpenHSM - C

opias de Seguranc¸a 79

7.1 Preparando um HSM para ser uma unidade de backup . . . . . . . . . . . 80

7.2 Importando o Certiﬁcado de Backup em HSM Operacional . . . . . . . . 81

7.3 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

7.4 Recuperac¸

ao do Backup . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7.5 Utilizac¸

ao de M

ultiplos Ambientes Operacionais . . . . . . . . . . . . . 86

7.6 Conclus

ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

8 Conclus

ao 89

8.1 Resumo das Contribuic¸

oes . . . . . . . . . . . . . . . . . . . . . . . . . 90

8.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Refer

encias Bibliogr

aﬁcas 92

A Convenc¸

oes 97

Lista de Figuras

1.1 Contextualiza a

area de atuac¸

ao do trabalho . . . . . . . . . . . . . . . . 6

4.1 Funcionamento das func¸

oes de callback, empregadas no OpenSSL. . . . . 41

5.1 Vis

ao geral da arquitetura do HSM da GT ICPEDU II . . . . . . . . . . . 54

5.2 Interface texto para administrac¸

ao remota do HSM do GT ICPEDU II . . 56

5.3 Interface gr

aﬁca para administrac¸

ao remota do HSM do GT ICPEDU II . 57

7.1 Processo de criac¸

ao de um HSM de backup . . . . . . . . . . . . . . . . 79

Lista de Tabelas

2.1 Categorias dos estados do ciclo de vida de chaves criptogr

aﬁcas quanto a

sua disponibilidade de uso. . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 Caracter

ısticas do HSM nShield F3 2000 da nCipher . . . . . . . . . . . 17

2.3 Caracter

ısticas do HSM Luna PCI 3000 da SafeNet . . . . . . . . . . . . 18

2.4 Caracter

ısticas do HSM Keyper PCI da AEP Networks . . . . . . . . . . 19

4.1 Arquivo de conﬁgurac¸

ao do OpenSSL para carga da engine do ASI-HSM. 40

4.2 Algoritmos Criptogr

aﬁcos Aprovados no OpenSSL FIPS vers

ao 1.1.2 . . 50

A.1 Sistemas de armazenamento de dados utilizados no OpenHSM . . . . . . 97

Lista de Siglas

AC Autoridade Certiﬁcadora

ACT Autoridade de Carimbo de Tempo

AES Advanced Encryption Algorithm (Algor

ıtmo de Cifragem Avanc¸ada)

ASN Abstract Syntax Notation (Notac¸

ao para Sintaxe Abstrata)

ANSI American National Standards Institute (Instituto Nacional de

Padr

oes Americanos)

API Application Program Interface (Interface de Programac¸

ao de Aplica-

tivos)

AR Autoridade de Registro

BIO I/O Abstraction (Abstrac¸

ao de Entrada e Sa

ıda )

CBC Cipher Block Chaining (Encadeamento de Blocos Cifrados)

CC Common Criteria (Crit

erios Comuns)

CSP Critical security parameter (Par

ametro Cr

ıtico de Seguranc¸a)

DER Distinguished Encoding Rules

DES Decryption and Encryption Standard (Padr

ao de Cifragem e Decifra-

gem)

EAL Evaluation Assurance Level (N

ıvel de Garantia de Avaliac¸

ao)

FCC Federal Communications Commission

FIPS Federal Information Processing Standard (Padr

ao Federal de Proces-

samento de Informac¸

oes)

GSM Global System for Mobile communications (Sistema Global para

Comunicac¸

oes M

oveis)

xiii

GT Grupo de Trabalho

HSM Hardware Security Module (M

odulo de Seguranc¸a Criptogr

aﬁca)

ICP Infra-estrutura de Chaves P

ublicas

ICPEDU Infra-estrutura de Chaves P

ublicas Educacional

ICP-Brasil Infra-estrutura de Chaves P

ublicas Brasileira

IEEE Institute of Electrical and Electronics Engineers (Instituto de Enge-

nharia El

etrica e Eletr

onica)

ISO Internal Organization for Standardization (Organizac¸

ao Internacio-

nal para Padronizac¸

ao)

ITI Instituto Nacional de Tecnologia da Informac¸

JCA Java Communications API (API de comunicac¸

ao Java)

JCE Java Cryptography Extension (Extens

ao de criptograﬁa JAVA)

LCR Lista de Certiﬁcados Revogados

LEA Laborat

orio de Ensaios e Auditoria

MCT Manual de Condutas T

ecnicas

NIST National Institute of Standards and Technology (Instituto Nacional

de Padr

oes e Tecnologia)

NSF N

ıvel de Seguranc¸a F

ısica

NSH N

ıvel de Seguranc¸a de Homologac¸

OSSI Open Source Software Institute (Instituto de Software de C

odigo

Aberto)

PEM Privacy Enhanced Mail

PIN Personal Identiﬁcation Number (N

umero de Identiﬁcac¸

ao Pessoal)

PKCS Public Key Crypto System

PUK Personal Unlocking Code (C

odigo de Desbloqueio Pessoal)

RNP Rede Nacional de Ensino e Pesquisa

RoHS Restriction to the use of Hazardous Substances

RSA Rivest, Shamir e Adelman

SGC Sistema de Gerenciamento de Certiﬁcados Digitais

xiv

SHA Secure Hash Algorithm (Algoritmo Seguro de Resumo Crip-

togr

aﬁco)

SO Sistema Operacional

SSL Secure Sockets Layer

TLS Transport Layer Security

UFSC Universidade Federal de Santa Catarina

UFMG Universidade Federal de Minas Gerais

UG Unidade Gestora

Unicamp Universidade de Campinas

US Unidade de Seguranc¸a

USB Universal Serial Bus

WEEE Waste from Electrical and Electronic Equipament

Lista de S

ımbolos

≤ Menor ou igual que

⊕ XOR / Ou exclusivo

Resumo

O OpenHSM

e um protocolo aberto para gest

ao do ciclo de vida de

chaves criptogr

aﬁcas em m

odulos de seguranc¸a criptogr

aﬁca, voltado principalmente

para implantac¸

ao de Infra-estruturas de Chaves P

ublicas. Esta dissertac¸

ao formaliza

e apresenta os v

arios sub-protocolos que juntos permitem a gest

ao conﬁ

avel das cha-

ves criptogr

aﬁcas. Os protocolos foram implementados e embarcados em um hardware

criptogr

aﬁco especialmente desenvolvido para evitar o acesso ao material sens

ıvel dos

mesmos. Deu-se especial atenc¸

ao aos aspectos pr

aticos da implementac¸

ao tal como sua

ader

encia as normas nacionais e internacionais – MCT-7 e FIPS PUB 140-2 – e sua in-

terface de comunicac¸

ao com a aplicac¸

ao de gest

ao de certiﬁcados digitais. Tamb

em s

tratados os processos de criac¸

ao e recuperac¸

ao de c

opias de seguranc¸a do OpenHSM,

possibilitando a continuidade do ciclo de vida das chaves gerenciadas mesmo em caso de

falhas ou desastres.

Abstract

The OpenHSM is an open protocol that has been developed to manage

the life cycle of the cryptographic keys in hardware security modules, mainly addres-

sed to public key infrastructure deployment. This thesis formalises and presents all sub-

protocols that together provide reliable management of cryptographic keys. The protocols

have been implemented and embedded in a cryptographic hardware especially develo-

ped to avoid unauthorized access to its sensitive data. Special attention was given to the

practical aspects of the implementation, such as adherence to national and international

standards – MCT-7 and FIPS PUB 140-2 – and integration with certiﬁcate management

systems. The processes of creation and recovery of backup copies are also included in

this thesis, permitting the continuity of the management keys’ life-cycle even in the event

of hardware failures or disasters.

Cap

ıtulo 1

Introduc¸

Hardware ou m

odulos criptogr

aﬁcos

em sido usados como

ancoras

de conﬁanc¸a em sistemas de informac¸

ao e comunicac¸

ao. S

ao dispositivos especialmente

projetados para o armazenamento e o processamento seguro de informac¸

oes sens

ıveis, tal

como chaves criptogr

aﬁcas. Entre os modelos mais conhecidos est

ao os cart

oes inteligen-

tes ou smartcards e os m

odulos de seguranc¸a criptogr

aﬁca (HSMs)

. Ambos s

ao usados

para a gerac¸

ao, protec¸

ao e processamento de chaves criptogr

aﬁcas. Os smartcards s

mais simples que os HSMs em termos de funcionalidades, quantidade e qualidade dos

mecanismos de protec¸

ao das chaves e registro dos eventos associados ao ciclo de vida das

chaves criptogr

aﬁcas, capacidade de processamento e formato f

ısico.

Os smartcards s

ao amplamente usados como dispositivo de autenticac¸

de clientes em aplicac¸

oes banc

arias e cidad

aos em sistemas de governo eletr

onico (e-

CPF). Em alguns pa

ıses europeus e estados norte-americanos, por exemplo, os smartcards

ao utilizados como cart

ao de identiﬁcac¸

ao do cidad

ao ou licenc¸a de motorista.

Os HSMs, por sua vez, s

ao dirigidos a sistemas mais complexos que

requerem um maior rigor no controle e auditoria do material sens

ıvel armazenado e pro-

cessado.

O grande mercado dos HSMs s

ao as aplicac¸

oes militares e banc

arias.

Nessas aplicac¸

oes, os HSM s

ao usados para processar informac¸

oes de autenticac¸

ao de

Neste trabalho os termos hardware criptogr

aﬁco e m

odulo criptogr

aﬁco s

ao usados indistintamente.

HSM vem do Ingl

es e signiﬁca Hardware Security Module.

usu

arios, registros de eventos cr

ıticos, assinatura de mensagens e execuc¸

ao segura de

odigo.

Um nicho pouco explorado mas importante para o uso de HSMs s

ao as

infra-estruturas de chaves p

ublicas (ICP) e suas aplicac¸

oes, tais como autoridades certi-

ﬁcadoras (AC), autoridades de registro (AR) e autoridades de carimbo de tempo (ACT).

Neste nicho, n

ao seriam necess

arias algumas das funcionalidades e potencialidades exis-

tentes nos HSM dispon

ıveis no mercado, ao mesmo tempo em que precisariam de outras

caracter

ısticas n

ao contempladas, tal como um tratamento mais elaborado da criac¸

ao e

recuperac¸

ao de c

opia de seguranc¸a do material sens

ıvel. Esta lacuna

e exaustivamente

explorada neste trabalho.

Para a garantia da qualidade e padronizac¸

ao dos servic¸os e mensagens

processadas pelos hardwares criptogr

aﬁcos, estes podem e devem ser desenvolvidos se-

gundo normas e recomendac¸

oes de entidades tais como o National Institute of Standards

and Technology (NIST) e a Organizac¸

ao Internacional para Padronizac¸

ao (ISO). Dentre

as v

arias normas existentes, a FIPS 140-2 promovida pelo NIST trata especiﬁcamente de

hardware criptogr

aﬁco, com a criac¸

ao de um servic¸o de homologac¸

ao de tais dispositivos.

O fabricante de um hardware criptogr

aﬁco pode solicitar a homologac¸

ao de seu equipa-

mento segundo os requisitos e recomendac¸

oes apostas na norma. Ap

os a avaliac¸

ao pelo

NIST ou por uma entidade credenciada, o hardware criptogr

aﬁco recebe um atestado de

ader

encia. Este atestado

e exigido por in

umeras organizac¸

oes como requisito para a sua

aquisic¸

ao.

Entretanto, al

em de preocupac¸

oes t

ecnicas, deve-se considerar a quest

de seguranc¸a nacional, principalmente quando o HSM

e usado para proteger informac¸

oes

de governo, militares e de empresas brasileiras. Em determinadas aplicac¸

oes, conside-

radas de seguranc¸a nacional, tais dispositivos devem ser de absoluta conﬁanc¸a. N

suﬁciente ter uma declarac¸

ao do NIST ou de outra entidade internacional atestando que o

hardware criptogr

aﬁco

e seguro e respeita os requisitos, recomendac¸

oes e boas pr

aticas de

um hardware a ser usado como

ancora de conﬁanc¸a.

E necess

ario que o HSM seja pass

ıvel

de auditoria - deve ser poss

ıvel avaliar a seguranc¸a dos mecanismos criptogr

aﬁcos e, em

particular, a gerac¸

ao de chaves criptogr

aﬁcas. Como tais dispositivos precisam ser natu-

ralmente lacrados para evitar que seja poss

ıvel o acesso a informac¸

ao sens

ıvel, tal audito-

ria n

ao pode ser realizada.

E necess

ario conﬁar-se cegamente na entidade certiﬁcadora e

no fabricante.

Com esta preocupac¸

ao em mente, o governo brasileiro, sabiamente,

atrav

es do Instituto Nacional de Tecnologia da Informac¸

ao (ITI), estabeleceu normas e

criou laborat

orios de ensaios e an

alises (LEA) para avaliac¸

ao de sistemas e equipamen-

tos a serem usados pela Infra-estrutura de Chaves P

ublicas Brasileira (ICP-Brasil) e suas

aplicac¸

oes. Foi criado uma s

erie de normas de avaliac¸

ao dos equipamentos e sistemas,

com v

arios n

ıveis de an

alise. A mais rigorosa requer o dep

osito do c

odigo fonte da

aplicac¸

ao e do sistema operacional embarcado.

Apesar do grande mercado e de quest

oes de seguranc¸a nacional, o Bra-

sil ainda est

a engatinhando em relac¸

ao ao dom

ınio tecnol

ogico e fabril de dispositivos

de hardware criptogr

aﬁcos. Duas louv

aveis iniciativas merecem destaque quanto ao de-

senvolvimento de compet

encia nacional na

area de hardware criptogr

aﬁco: o programa

ao de Barro criado pelo ITI a ordem do Comit

e Gestor da ICP-Brasil e a Infra-estrutura

de Chaves P

ublicas para Pesquisa e Ensino (ICPEDU) da Rede Nacional de Ensino e

Pesquisa (RNP)[1].

1.1 Infra-estrutura de Chaves P

ublicas para Pesquisa e

Ensino

A RNP tem-se utilizado de grupos de trabalho, constitu

ıdo por pesqui-

sadores de instituic¸

oes p

ublicas e privadas escolhidos a partir de editais p

ublicos peri-

odicamente lanc¸ados, como forma de absorver e realizar inovac¸

ao tecnol

ogica, adquirir

experi

encia e desenvolver ferramentas para melhorar e disponibilizar novos servic¸os para

seus clientes, normalmente universidades e centros de pesquisa brasileiros.

Especiﬁcamente, em 2003, foi criado o Grupo de Trabalho de Infra-

estrutura de Chaves P

ublicas (GT ICPEDU) com o objetivo de estudar e implantar um

servic¸o piloto para a emiss

ao de certiﬁcados digitais para ﬁns educacionais e de pesquisa.

Participaram desse esforc¸o as Universidades Federais de Santa Catarina (UFSC) e de Mi-

nas Gerais (UFMG) e a Universidade de Campinas (UNICAMP). O GT ICPEDU teve

es edic¸

oes. A primeira, GT ICPEDU I, teve como resultado o dom

ınio da tecnologia de

certiﬁcac¸

ao digital, com o desenvolvimento de um sistema de gerenciamento do ciclo de

vida de certiﬁcados digitais (SGCI). O GT ICPEDU II teve como objetivo o desenvolvi-

mento de um HSM, enquanto, o GT ICPEDU III, preocupou-se com a guarda da chave

privada dos usu

arios, com o desenvolvimento de smartcards virtuais.

Entre os servic¸os almejados pela ICPEDU estavam a utilizac¸

ao de certi-

ﬁcados digitais para a autenticac¸

ao dos usu

arios nos servic¸os de rede e a realizac¸

ao de as-

sinatura digital de documentos eletr

onicos em substituic¸

ao ao papel, principalmente para

viabilizar a utilizac¸

ao de formul

arios eletr

onicos nos processos acad

emicos.

E objetivo

tamb

em, a disseminac¸

ao da tecnologia de certiﬁcac¸

ao digital, atrav

es de cursos, reuni

oes

e participac¸

ao ativa das entidades na concepc¸

ao da Infra-estrutura de Chaves P

ublicas

para Pesquisa e Ensino (ICPEDU). V

e-se a ICPEDU como uma vers

ao acad

emico e de

pesquisa da ICP-Brasil.

A ICPEDU

e hoje condic¸

ao e insumo b

asico para a integrac¸

ao e o

compartilhamento de recursos das instituic¸

oes de ensino e pesquisa brasileiros e en-

tre estas, incluindo as instituic¸

oes aﬁns de outros pa

ıses. V

arios projetos associados a

disponibilizac¸

ao de recursos computacionais pela Internet necessitam dos servic¸os pres-

tados pela ICPEDU. Destaca-se o esforc¸o da RNP na implantac¸

ao de um sistema de

federac¸

oes de forma a compartilhar os processos de autenticac¸

ao entre as instituic¸

oes

usu

arias.

Um dos grandes desaﬁos a ser superado pelos participantes na

implantac¸

ao da ICPEDU era o alto custo do HSM necess

ario

a criac¸

ao de ACs e ARs

e suas aplicac¸

oes. O custo era proibitivo para maioria dessas instituic¸

oes. Al

em do custo,

a tecnologia de fabricac¸

ao de hardwares criptogr

aﬁcos n

ao estava dispon

ıvel no Brasil e

haviam restric¸

oes quando a sua importac¸

ao, devido ao car

ater de “seguranc¸a nacional”

que os governos dos pa

ıses detentores dessa tecnologia impunham aos fabricantes. De-

vido a isso, a RNP aceitou a proposta do GT ICPEDU II para desenvolver, projetar e

construir um HSM de baixo custo e que provesse os requisitos de seguranc¸a apostos na

FIPS 140-2.

Assim, foram estabelecidos os seguintes requisitos gerais para o HSM:

• baixo custo;

• c

odigo aberto para facilitar a auditoria;

• visando atender os requisitos dos componentes de infra-estruturas de chaves

ublicas (rastreabilidade de chaves e um sistema de auditoria forte);

• capacidade m

ınima de processamento de 10 assinaturas RSA/segundo;

• compat

ıvel com o Sistema de Gerenciamento de Certiﬁcados Digitais da ICPEDU

(SGCI).

O estudo e projeto do HSM tem sido alvo de v

arias dissertac¸

oes de

mestrado e trabalhos de conclus

ao de curso na Universidade Federal de Santa Catarina.

Ao mesmo tempo em que estudam e se formam na

area de protocolos criptogr

aﬁcos e

sistemas criptogr

aﬁcos embarcados, os alunos e professores se dedicam a desenvolver a

tecnologia e o produto HSM da ICPEDU (ASI-HSM). O software de gerenciamento do

ciclo de vida das chaves criptogr

aﬁcas foi desenvolvido neste seio. O hardware, dese-

nhado pelo GT ICPEDU II, foi projetado pela empresa brasileira Kryptus

em parceria

com a RNP.

1.2 Contextualizac¸

ao das Contribuic¸

oes

A implantac¸

ao de ACs e ARs no contexto de ICPs

e bem estabelecida,

devendo seguir pol

ıticas previamente deﬁnidas de forma a nortear todas as atividades

envolvidas no seu gerenciamento. A ﬁgura 1.1 apresenta a estrutura documental normal-

mente adotada na implantac¸

ao de uma infra-estrutura de chaves p

ublicas.

As pol

ıticas s

ao descritas na forma de documentos, seguindo preceitos

regidos por normas, padr

oes e recomendac¸

oes nacionais e internacionais. Parte desses

http://www.kryptus.com.br

Figura 1.1: Contextualiza a

area de atuac¸

ao do trabalho

documentos orientam como um certiﬁcado deve ser emitido para ser aplic

avel um uma

determinada situac¸

ao, respeitando os requisitos de uma pol

ıtica de seguranc¸a, na forma

de Pol

ıticas de Certiﬁcado (PC). Outra parte, o conjunto de requisitos que promovem a

protec¸

ao adequada dos ativos dos sistemas de informac¸

ao das entidades da ICP, constitue

a pol

ıtica de seguranc¸a (PS).

A declarac¸

ao de pr

aticas de certiﬁcac¸

ao (DPC), por sua vez, descreve

como a PC

e implementada, levando em considerac¸

ao as boas pr

aticas de seguranc¸a esta-

belecidas na PS, englobando os requisitos da organizac¸

ao que hospeda a ICP.

Como forma de facilitar a escrita destes documentos, o comit

e gestor

da ICP deﬁne requisitos m

ınimos das PC e DPC para todas as ACs e ARs existentes na

arvore da ICP. Desta forma, todas a entidades participantes da ICP podem facilmente

seguir a mesma orientac¸

ao.

Uma vez consolidado o documento DPC, pode-se implementar o am-

biente de produc¸

ao e elaborar as cerim

oniais. O ambiente de produc¸

ao consiste de um

ambiente seguro com sistemas de controle de acesso, ambiente de registro, entre outros.

Esses controlam o acesso ao material criptogr

aﬁco, gerando evid

encias de seu uso atrav

de registros de evid

encias (logs). As cerim

onias s

ao normalmente escritas na forma de

roteiro em ordem cronol

ogica de execuc¸

ao, para todas as atividades previstas no ambi-

ente de produc¸

ao. O produto das cerim

onias s

ao as atas cerimoniais. A partir das atas

e registros de atividades dos componentes envolvidos s

ao realizadas as auditorias, que

produzir

ao relat

orios, demonstrando a conﬁabilidade de toda a estrutura para a parte con-

ﬁante.

Este trabalho contribui no contexto de implementac¸

ao de ICPs nas

areas

de Cerim

onias (detalhando todos os passos realizados no gerenciamento do ciclo de vida

das chaves privadas), Ambiente de Produc¸

ao (ASI-HSM com o OpenHSM) e Audito-

ria (registro de todas as etapas realizadas no interior do HSM com a possibilidade de

exportac¸

ao), conforme a

area em destaque na ﬁgura 1.1.

Em termos de ambiente de produc¸

ao, destacam-se os protocolos que s

propostos para o estrito controle do ciclo de vida das chaves criptogr

aﬁcas, mesmo consi-

derando v

arias c

opias operacionais destas chaves, atrav

es do uso de grupos de operadores

(custodiantes de material sens

ıvel), grupos de administradores e grupos totalmente inde-

pendentes de auditores. Todos os passos executados dentro do HSM s

ao registrados em

arquivos de registro de auditoria e exportados com a autorizac¸

ao dos auditores.

Os passos de todos os sub-protocolos do HSM s

ao mapeados dentro das

cerim

onias, detalhando principalmente as atividades diretamente relacionadas ao geren-

ciamento do ciclo de vida das chaves criptogr

aﬁcas de uma ICP. Esta associac¸

ao mostra

perfeita sintonia entre o roteiro cerimonial e o registro de sua execuc¸

ao nos registros de

atividades do HSM. Garante-se com isso maior conﬁanc¸a das testemunhas presentes na

cerim

onia quanto a corretude do uso das chaves criptogr

aﬁcas.

Por

ultimo, sentem-se os auditores capazes de produzir suas an

alises e

relat

orios com a certeza de mostrar que tudo foi feito respeitando as pol

ıticas preconiza-

das.

As contribuic¸

oes deste trabalho s

ao de car

ater t

ecnico e te

orico-

cient

ıﬁco. Quando se exp

oe a contribuic¸

ao t

ecnica procura-se organizar o material j

existente na literatura t

ecnica e documentac¸

ao das soluc¸

oes existentes de forma a eluci-

dar e dirigir tal escrito

as necessidades dos desenvolvedores de componentes destinados a

ICP. Um forte exemplo deste tipo de contribuic¸

e a apresentac¸

ao did

atica para desenvol-

vimento de Engines – padr

ao utilizado para a comunicac¸

ao entre aplicac¸

oes e provedo-

res de servic¸os criptogr

aﬁcos em ambientes de c

odigo aberto suportados pela plataforma

OpenSSL.

Por outro lado, este trabalho apresenta diversas contribuic¸

oes te

orico-

cient

ıﬁcas. A principal delas esta relacionada ao protocolo que permite a gest

ao conﬁ

avel

de v

arias inst

ancias simult

aneas do material criptogr

aﬁco em HSM. Tal protocolo est

implementado no HSM do projeto ICP-EDU II, ASI-HSM.

1.3 Objetivos

1.3.1 Objetivo Geral

Este trabalho tem por objetivo geral descrever, e propor modiﬁcac¸

oes

onde necess

ario, nos sub-protocolos criptogr

aﬁcos de gest

ao do ciclo de vida de cha-

ves criptogr

aﬁcas que comp

oem o OpenHSM, com

enfase nos esquemas de c

opia e

recuperac¸

ao de chaves e a instanciac¸

ao de ambientes de produc¸

ao com c

opias das chaves

gerenciadas, respeitando as principais recomendac¸

oes nacionais e internacionais relacio-

nadas

a implementac¸

ao de hardware criptogr

aﬁcos.

1.3.2 Objetivos Espec

ıﬁcos

Visando alcanc¸ar o objetivo geral, foram deﬁnidos alguns objetivos es-

pec

ıﬁcos, tais como:

• apresentar os principais dispositivos criptogr

aﬁcos utilizados no contexto de uma

infra-estrutura de chaves p

ublicas;

• levantar as normas e recomendac¸

oes nacionais e internacionais que regem o desen-

volvimento de dispositivos criptogr

aﬁcos;

• descrever o OpenSSL e suas funcionalidades, com foco na implementac¸

ao de engi-

nes para integrac¸

ao de hardware criptogr

aﬁcos;

• aprofundar o entendimento dos mecanismos de criac¸

ao e recuperac¸

ao de c

opias de

seguranc¸a do OpenHSM, capazes de proporcionar o uso simult

aneo de v

arias c

opias

das chaves gerenciadas em ambientes paralelos;

• gerar, quando inexistente, documentac¸

ao sobre os recursos tecnol

ogicos utilizados

no produtac¸

ao do OpenHSM, na forma do ASI-HSM.

1.4 Justiﬁcativa e Motivac¸

A certiﬁcac¸

ao digital tem se tornado uma ferramenta essencial

modernizac¸

ao das instituic¸

oes p

ublicas e privadas brasileiras. V

e-se o uso desta tec-

nologia na emiss

ao de notas ﬁscais eletr

onicas, nos sistemas banc

arios e na gest

ao de

documentos eletr

onicos, para citar alguns exemplos.

Um dos elementos chaves desse sucesso

e o investimento que o Estado

Brasileiro tem feito para o total dom

ınio desta tecnologia no Brasil. O uso acad

emico

de certiﬁcac¸

ao digital nas instituic¸

oes de pesquisa e ensino nacionais formar

ao os recur-

sos humanos necess

arios para garantir a adoc¸

ao em larga escala dos certiﬁcados digitais

nas mais diversas situac¸

oes, sem ﬁcarmos ref

ens de corporac¸

oes que est

ao unicamente

subordinadas ao arcabouc¸o jur

ıdico de outros pa

ıses.

Em especial, o dom

ınio no desenvolvimento de dispositivos de hard-

ware ir

a permitir, n

ao s

o um maior uso destes nas mais diversas aplicac¸

oes, como um

substancial barateamento da tecnologia. Isso sem falar que tais dispositivos sofrem de

controle rigoroso nos pa

ıses que dominam sua tecnologia, e n

ao s

ao poucos os casos em

que a tecnologia

e vista como de seguranc¸a nacional, impondo restric¸

oes a sua exportac¸

ao.

Foi neste cen

ario que a RNP criou e mant

em um grupo de pesquisado-

res, de v

arias universidades e instituic¸

oes de pesquisa, com o objetivo de implantar uma

infra-estrutura de chaves p

ublicas para pesquisa e ensino.

O HSM, resultado desse esforc¸o, foi concebido para prover aos inte-

grantes da ICPEDU e parceiros de um dispositivo de baixo custo que permitisse a gest

segura de chaves criptogr

aﬁcas.

1.5 Trabalhos Correlatos

Um dos primeiros trabalhos que se tem not

ıcia sobre a protec¸

ao de cha-

ves criptogr

aﬁcas no contexto de uma AC

e devido a Jeff Schiller[2]. Seu trabalho prop

duas abordagens diferentes para a gest

ao do ciclo de vida da chave, dependendo de quem

tem acesso ao material criptogr

aﬁco. A primeira, quando o ser humano tem acesso direto

as chaves e a segunda, quando este acesso direto n

e poss

ıvel. O trabalho, de car

ater

mais geral, discute as diferentes preocupac¸

oes quanto ao controle do ciclo de vida das

chaves nestes dois contextos.

Os primeiros estudos sobre o gerenciamento de chaves criptogr

aﬁcas no

Laborat

orio de Seguranc¸a em Computac¸

ao (LabSEC) da Universidade Federal de Santa

Catarina foram feitos em 2003. Assim que o GT ICPEDU II foi aprovado pela RNP,

iniciou-se o desenvolvimento de um prot

otipo do HSM. Como resultado acad

emico do GT

teve-se dois trabalhos: um trabalho conclus

ao de curso (TCC) de Graduac¸

ao em Sistemas

de Informac¸

ao e uma dissertac¸

ao de mestrado no Programa de P

os-Graduac¸

ao em Ci

encia

da Computac¸

ao (PPGCC) da Universidade Federal de Santa Catarina (UFSC).

No in

ıcio dos trabalhos foi feita uma revis

ao da literatura sobre esta

area

em particular e obteve-se somente refer

encias a produtos comerciais de empresas fabri-

cantes de HSM. Muito pouco se sabe sobre os protocolos que esses produtos implemen-

tam, provavelmente devido a protec¸

ao de propriedade intelectual e ao segredo industrial.

Souza[3] tratou em seu trabalho o gerenciamento de chaves crip-

togr

aﬁcas em hardwares embarcados. Martina[4] desenvolveu sua dissertac¸

ao de mes-

trado estudando e propondo modiﬁcac¸

oes nos dispositivos de hardware criptogr

aﬁcos de

forma a atender melhor as necessidades funcionais de uma autoridade certiﬁcadora.

Em 2007, Martina[5] apresentou os protocolos de gest

ao dos grupos de

administrac¸

ao, operac¸

ao e auditoria de chaves criptogr

aﬁcas no OpenHSM. E em 2008,

Souza[6] publicou um trabalho que aprimorava os protocolos de c

opia e recuperac¸

ao do

material criptogr

aﬁco no OpenHSM.

1.6 Organizac¸

ao deste Trabalho

O Cap

ıtulo 2 apresenta os dispositivos mais utilizados para armazena-

mento de chaves criptogr

aﬁcas. Nesse, s

ao apresentados os smartcards, com

enfase no

modelo utilizado no OpenHSM, tokens criptogr

aﬁcos e HSM dispon

ıveis no mercado.

No cap

ıtulo 3, as normas nacionais e internacionais de certiﬁcac¸

com maior relev

ancia s

ao analisadas.

E apresentada para cada norma, seus n

ıveis de

certiﬁcac¸

ao,

areas de atuac¸

ao e requisitos deﬁnidos para cada

area.

A seguir, no cap

ıtulo 4,

e apresentado o OpenSSL, poderosa ferramenta

criptogr

aﬁca, na qual o ASI-HSM est

a baseado. O cap

ıtulo descreve a aplicac¸

ao de linha

de comando, suporte a engines para integrac¸

ao de m

odulos criptogr

aﬁcos e a vers

ao sim-

pliﬁcada da biblioteca com certiﬁcac¸

ao FIPS 140-2 n

ıvel 1. Justiﬁca-se a inclus

ao deste

material neste texto uma vez que a documentac¸

ao original

e desatualizada e dispersa.

O cap

ıtulo 5 apresenta a soluc¸

ao como um todo do HSM, na forma do

ASI-HSM, incluindo sua arquitetura, interfaces de gerenciamento e engine para utilizac¸

de seus servic¸os criptogr

aﬁcos.

Na seq

encia, o cap

ıtulo 6 aborda o protocolo OpenHSM para gerencia-

mento do ciclo de vida das chaves criptogr

aﬁcas, incluindo os sub-protocolos para criac¸

e uso de chaves criptogr

aﬁcas gerenciadas.

O cap

ıtulo 7 descreve todos os sub-protocolos do OpenHSM res-

pons

aveis pela criac¸

ao e recuperac¸

ao de c

opias de seguranc¸a do HSM, de forma a garantir

a continuidade do ciclo de vida das chaves criptogr

aﬁcas gerenciadas mesmo em caso de

falhas de hardware ou desastres.

Finalmente, no cap

ıtulo 8, conclui-se o trabalho, apresentando suas

contribuic¸

oes e trabalhos futuros.

Cap

ıtulo 2

Hardware Criptogr

aﬁco

2.1 Introduc¸

Um hardware criptogr

aﬁco

e um dispositivo que visa atender aos requi-

sitos de seguranc¸a encontrados em aplicac¸

oes que usam servic¸os criptogr

aﬁcos onde n

e poss

ıvel segregar o material sens

ıvel unicamente dentro da estac¸

ao hospedeira, que em-

barca a aplicac¸

ao, ou em situac¸

oes onde

e necess

ario um alto volume de processamento

criptogr

aﬁco. Um HSM, por exemplo,

e tipicamente de 10 a 100 vezes mais r

apido que

um computador pessoal para as ﬁnalidades especializadas.

Algumas aplicac¸

oes, como servidores seguros de p

aginas Web, reque-

rem grande capacidade de processamento criptogr

aﬁco, que pode ser alcanc¸ado com o

emprego de um HSM que

e usado como um co-processador para operac¸

oes criptogr

aﬁcas,

liberando unidade de processamento dos servidores para outras ﬁnalidades.

Este cap

ıtulo apresenta os dois principais tipos de hardware crip-

togr

aﬁcos, sendo na sec¸

ao 2.2 apresentado os smartcards, com especial atenc¸

ao aos re-

quisitos referentes ao modelo de smartcards utilizados no HSM alvo do OpenHSM. A

Sec¸

ao 2.3 apresenta uma vis

ao geral dos HSMs, hardware que permite um controle rigo-

roso do ciclo de vida de chaves criptogr

aﬁcas, sendo um dispositivo fundamental para a

gest

ao da chave privada de uma autoridade certiﬁcadora raiz de uma ICP. Adicionalmente,

alguns HSMs comerciais s

ao destacados.

2.2 Smartcards

Primeiramente empregados por empresas de telefonia da Franc¸a e Ale-

manha nos anos 80, os smartcards ganharam mercado com o desenvolvimento da crip-

tograﬁa moderna e evoluc¸

ao da tecnologia de semicondutores, sendo considerados uma

gerac¸

ao mais nova, inteligente e segura dos cart

oes de identiﬁcac¸

ao. Os celulares com

tecnologia GSM e cart

oes de cr

editos incorporam smartcards, visando principalmente sua

efetividade no combate a fraudes[7].

Smartcards cont

em um circuito integrado embarcado, capaz de receber,

transmitir, armazenar e processar dados. A comunicac¸

ao pode ser feita com ou sem con-

tato f

ısico, sendo no

ultimo caso utilizadas ondas de r

adio.

Uma das grandes caracter

ısticas dos smartcards

e que os dados nele

armazenados podem ser protegidos contra acesso e manipulac¸

ao n

ao autorizados. Seu

sistema operacional estabelece uma l

ogica de seguranc¸a que controla a entrada e sa

ıda de

comandos e dados atrav

es de sua interface de comunicac¸

ao serial.

E poss

ıvel, por exem-

plo, gerar um par de chaves assim

etricas em um smartcard e conﬁgur

a-lo de tal forma que

a chave privada nunca poder

a ser exportada. Neste caso, as operac¸

oes criptogr

aﬁcas para

utilizar esta chave podem ser realizadas somente dentro do mesmo.

O controle de acesso ao smartcard

e realizado com a utilizac¸

ao de se-

nha ou controle biom

etrico. A senha

e conhecida como n

umero de identiﬁcac¸

ao pes-

soal (PIN)

, que deve ser conhecida somente pelo dono do smartcard, e consiste de uma

seq

uencia num

erica normalmente entre 4 e 6 d

ıgitos. Os smartcards podem implementar

um modelo de PIN ﬁxo ou modiﬁc

avel. O modelo de PIN ﬁxo n

ao permite que seus

usu

arios alterem o PIN, obrigando sua memorizac¸

ao, enquanto o modelo de PIN modi-

ﬁc

avel atende as necessidades de seus usu

arios, permitindo a alterac¸

ao do PIN.

Os smartcards, por quest

ao de seguranc¸a, possuem um controle do

umero de tentativas consecutivas sem

exito na liberac¸

ao do acesso, bloqueando o PIN

quando digitado mais de tr

es vezes incorretamente. Este comportamento evita o ataque de

tentativa e erro, tamb

em chamada de ataque de forc¸a bruta. Em caso de bloqueio, o smart-

do ingl

es Personal Identiﬁcation Number

card precisa ser submetido a um processo de desbloqueio, utilizando uma senha chamada

de chave de desbloqueio pessoal (PUK)

, normalmente entre 6 e 8 d

ıgitos num

ericos. Ela

reinicia o contador de tentativas sem sucesso e permite a conﬁgurac¸

ao de um novo PIN.

O PUK, al

em de n

ao ser alter

avel, tamb

e bloqueado se digitado incorretamente 10

vezes, inutilizando o smartcard.

O uso de smartcards se d

a atrav

es de leitores especialmente desenvol-

vidos para este ﬁm. Eles s

ao o meio pelo qual um computador pode interagir com seu

conte

udo, provendo energia para o sistema operacional.

Os conceitos de smartcard tamb

em s

ao empregados em tokens crip-

togr

aﬁcos, no formato de dispositivos USB[8], n

ao necessitando de leitora espec

ıﬁca para

sua utilizac¸

ao.

2.2.1 Smartcards para HSMs

O objetivo do emprego de smartcards no projeto piloto do HSM

e a

segura identiﬁcac¸

ao dos membros de seus grupos. Cada membro possui um smartcard,

no qual ser

a armazenado um par de chaves criptogr

aﬁcas RSA[9] e um certiﬁcado. A

utilizac¸

ao deste smartcard com o PIN correto garante a autenticac¸

ao do membro.

Apesar de existirem in

umeros modelos comerciais de smartcards atual-

mente no mercado, com diferentes caracter

ısticas e capacidades, o GT ICP-EDU II deﬁniu

o seguinte conjunto de requisitos na escolha do smartcard apropriado:

• ser utiliz

avel a partir de contato f

ısico;

• suportar a gerac¸

ao de chaves assim

etricas RSA[9] de do m

ınimo 1024 bits;

• permitir a importac¸

ao de pares de chaves RSA gerados fora do smartcard;

• suportar criptograﬁa de dados com chaves assim

etricas RSA de at

e de 1024 bits;

• ter capacidade de gerac¸

ao e veriﬁcac¸

ao de assinaturas digitais utilizando chaves

RSA;

do ingl

es Personal Unblocking key

• suportar armazenamento de certiﬁcados X.509v3[10];

• ser compat

ıvel com a norma ISO 7816 1/2/3/4[11];

• implementar uma estrutura de objetos e arquivos compat

ıvel com PKCS#15[12];

• possuir no m

ınimo 32 kilobytes de capacidade de armazenamento.

2.3 M

odulo de Seguranc¸a Criptogr

aﬁca (HSM)

odulos de seguranc¸a criptogr

aﬁca s

ao empregados em soluc¸

oes onde

o controle do ciclo de vida de suas chaves criptogr

aﬁcas

e crucial para seu funcionamento.

Esses m

odulos devem permitir que as chaves criptogr

aﬁcas sejam criadas, armazenadas,

utilizadas e apagadas internamente, sem nunca serem vis

ıveis ao mundo externo.

Os HSMs possuem mais capacidade de processamento que os smart-

cards, servindo na sua maioria como aceleradores criptogr

aﬁcos, sendo capazes de geren-

ciar o ciclo de vida de v

arias chaves ao mesmo tempo.

2.3.1 Ciclo de vida de chaves criptogr

aﬁcas

O ciclo de vida de uma chave criptogr

aﬁca consiste da seq

uencia de

estados por ela assumida, desde sua gerac¸

ao at

e a sua destruic¸

ao[13], com o m

odulo

criptogr

aﬁco garantindo seu correto manuseio em cada estado assumido.

A continuidade do ciclo de vida das chaves deve ser poss

ıvel mesmo

em caso de falha de hardware ou acontecimento de um desastre, atrav

es da utilizac¸

ao de

mecanismos de criac¸

ao e recuperac¸

ao de c

opias de seguranc¸a. Entretanto, no caso de

destruic¸

ao de uma chave, deve-se ter garantia que todas suas inst

ancias foram destru

ıdas,

inclusive as c

opias de seguranc¸a.

A seguir, apresenta-se uma lista dos principais estados que uma chave

criptogr

aﬁca pode assumir durante seu ciclo de vida em um HSM:

• gerac¸

ao: o ponto inicial do ciclo de vida de uma chave criptogr

aﬁca;

• armazenamento: a chave est

a armazenada de forma segura no interior do per

ımetro

criptogr

aﬁco;

• uso: utilizac¸

ao da chave para realizac¸

ao de operac¸

oes criptogr

aﬁcas;

• backup: referente as c

opias de seguranc¸a da chave, que deve estar armazenado em

lugar independente, possibilitando a recuperac¸

ao em caso de falha de hardware ou

desastre;

• recuperac¸

ao: refere-se a recuperac¸

ao de uma c

opia de seguranc¸a da chave, utilizado

quando a chave foi perdida de alguma forma, sem seu comprometimento;

• destruic¸

ao: a chave n

e mais necess

aria, ﬁnalizando seu ciclo de vida.

Os estados ainda podem ser categorizados quanto a disponibilidade de

uso de uma chave criptogr

aﬁca[14], como

e descrito na tabela 2.1.

Tabela 2.1: Categorias dos estados do ciclo de vida de chaves criptogr

aﬁcas quanto a sua dispo-

nibilidade de uso.

Categoria Descric¸

e-operacional per

ıodo desde a criac¸

ao do par de chaves at

e sua liberac¸

ao para

realizac¸

ao de operac¸

oes criptogr

aﬁcas;

operacional a chave est

a dispon

ıvel para uso

os-operacional a chave n

ao pode ser mais utilizada ativamente para realizac¸

de operac¸

oes criptogr

aﬁcas. Sua utilidade

e prover garantia das

operac¸

oes realizadas no passado.

obsoleta todas as inst

ancias da chave criptogr

aﬁca s

ao apagadas

2.3.2 M

odulos de Seguranc¸a Criptogr

aﬁca de Mercado

Existem diversos fabricantes de HSMs no mundo e alguns de seus pro-

dutos s

ao descritos nas tabelas 2.2, 2.3 e 2.4, salientando suas caracter

ısticas e capacida-

des. Os principais fabricantes s

ao: nCipher, SafeNet e AEP Networks.

O nShield F3 2000 da nCipher, al

em das caracter

ısticas apresentadas na

tabela 2.2, suporta execuc¸

ao segura de c

odigo, o que permite ao seu usu

ario importar um

trecho de c

odigo para ser executado dentro do HSM, considerado um ambiente seguro.

em disso, conta com rel

ogio interno de alta precis

ao, permitindo sua utilizac¸

ao em

sistemas de carimbo do tempo.

Tabela 2.2: Caracter

ısticas do HSM nShield F3 2000 da nCipher

Item Caracter

ısticas

Certiﬁcac¸

ao FIPS 140-2 n

ıvel 3

Capacidade de Processamento 2000 assinaturas RSA de 1024 bits por segundo

Conectividade Interface PCI

API integrac¸

ao OpenSSL, PKCS#11, Microsoft CryptoAPI

Algoritmos criptogr

aﬁcos (As-

sim

etricos)

DSA, ECDSA, RSA

Algoritmos criptogr

aﬁcos

(Sim

etricos)

AES, Triple-DES

Algoritmos criptogr

aﬁcos

(Func¸

oes de Resumo)

Triple-DES MAC, SHS, HMAC

Backup Propriet

ario e para HSMs do mesmo fabricante

Uso Prop

osito geral

Da mesma forma que o HSM da nCipher, o Luna PCI 3000 da Sa-

feNet apresenta caracter

ısticas adicionais ao gerenciamento do ciclo de vida de chaves

criptogr

aﬁcas, como a utilizac¸

ao de um teclado diretamente conectado ao HSM para au-

tenticar seus usu

arios, provendo uma caminho conﬁ

avel para a digitac¸

ao do PIN. Suas

caracter

ısticas gerais podem ser vistas na tabela 2.3.

O HSM Keyper PCI da AEP Networks possui uma funcionalidade in-

teressante para ambientes que demandem alto poder de processamento, suportando ba-

lanceamento de carga entre v

arios HSMs. Em caso de uma falha em um dos HSMs, os

restantes automaticamente assumem o controle. As caracter

ısticas gerais do KeyPer PCI

podem ser encontradas na tabela 2.4.

2.4 Conclus

A utilizac¸

ao de hardwares criptogr

aﬁcos

e crucial em ambientes com al-

gum tipo de valor agregado, j

a que, idealmente, a seguranc¸a dos algoritmos criptogr

aﬁcos

Tabela 2.3: Caracter

ısticas do HSM Luna PCI 3000 da SafeNet

Item Caracter

ısticas

Certiﬁcac¸

ao FIPS 140-2 n

ıvel 2 e 3

Capacidade de Processamento 3000 assinaturas RSA de 1024 bits por segundo

Conectividade Interface PCI

API integrac¸

ao OpenSSL, PKCS#11, Microsoft CryptoAPI 2.0, Java JCA/JCE

Algoritmos criptogr

aﬁcos (As-

sim

etricos)

RSA, DSA, Difﬁe Hellman

Algoritmos criptogr

aﬁcos

(Sim

etricos)

DES/3DES, AES, RC2, RC4, RC5

Algoritmos criptogr

aﬁcos

(Func¸

oes de Resumo)

SHA-1, SHA-256, SHA-384, SHA-512, MD2, MD5

Backup Propriet

ario e para HSMs do mesmo fabricante

Uso Prop

osito geral

est

a diretamente relacionada ao correto manuseio de suas chaves.

Os dois principais exemplares de hardware criptogr

aﬁcos s

ao o smart-

card e o HSM. O smartcard tem o formato de uma cart

ao e

e utilizado para proteger a

chave privada de pessoas ou de sistemas, onde n

ao h

a a necessidade de uma taxa elevada

de processamento criptogr

aﬁco. J

a os HSMs, como visto neste cap

ıtulo, tem um controle

maior do ciclo de vida de chaves criptogr

aﬁcas e alto poder de processamento.

Pode-se observar que os HSMs de mercado s

ao normalmente destinados

a aplicac¸

oes gerais e n

ao s

ao projetados para a instanciac¸

ao de autoridades certiﬁcadoras.

Uma das principais deﬁci

encias dos HSMs comerciais

e a falta de um

padr

ao aceit

avel para realizar a c

opia e a restaurac¸

ao do seu material cr

ıtico, tal como as

chaves criptogr

aﬁcas. Os fabricantes alegam que possuem tal funcionalidade, mas esta

e limitada a produtos do pr

oprio fabricante. Alegam que isso

e necess

ario para manter

a protec¸

ao das chaves. Acontece que num ambiente de produc¸

ao, por exemplo, uma

AC Raiz, normalmente a chave

e gerada e deve ser mantida no m

odulo por per

ıodo de

tempo superior a 10 anos. E os produtos comerciais s

ao descontinuados antes de vencer

a validade da chave.

Como ser

a visto nos pr

oximos cap

ıtulos, esta dissertac¸

ao de mestrado

trata desta funcionalidade com especial atenc¸

ao. Ou seja, como podem ser criadas c

opias

Tabela 2.4: Caracter

ısticas do HSM Keyper PCI da AEP Networks

Item Caracter

ısticas

Certiﬁcac¸

ao FIPS 140-1 n

ıvel 3

Capacidade de Processamento n

ao informada

Conectividade Interface PCI mas utiliz

avel atrav

es da rede

API integrac¸

ao OpenSSL, PKCS#11, Microsoft CryptoAPI 2.0, Java JCA/JCE

Algoritmos criptogr

aﬁcos (As-

sim

etricos)

RSA, DSA, Difﬁe Hellman

Algoritmos criptogr

aﬁcos

(Sim

etricos)

DES/3DES

Algoritmos criptogr

aﬁcos

(Func¸

oes de Resumo)

SHA-1, MD5

Backup Propriet

ario e para HSMs do mesmo fabricante

Uso Prop

osito geral

de seguranc¸a, que permitem posterior recuperac¸

ao em dispositivos adicionais, sem perder

a rastreabilidade de todas as inst

ancias das chaves criptogr

aﬁcas em operac¸

ao.

Cap

ıtulo 3

Normas

3.1 Introduc¸

A falta de interoperabilidade entre hardware criptogr

aﬁcos torna sua

utilizac¸

ao custosa, pois cada vez que

e necess

ario mudar um hardware, deve-se adaptar

a aplicac¸

ao que o utiliza. Neste sentido, governos e empresas se uniram e propuseram

padr

oes de interoperabilidade que devem ser seguidos no projeto e fabricac¸

ao de tais

dispositivos.

Desta forma, este cap

ıtulo apresenta as principais normas nacionais e

internacionais que devem ser consideradas no contexto de hardware criptogr

aﬁcos. Dentre

eles est

ao a FIPS PUB 140-2 (sec¸

ao 3.2) e o Manual de Condutas T

ecnicas 7 do LEA-ITI

(sec¸

ao 3.3). Ambas estabelecem requisitos na construc¸

ao de HSMs.

Os crit

erios comuns[15], que podem ser aplicados na construc¸

ao de

qualquer dispositivo eletr

onico, tamb

em pode ser utilizado na construc¸

ao de HSMs. En-

tretanto, por ser mais gen

erico, n

ao ser

a abordado aqui, permanecendo o foco nas normas

FIPS PUB 140-2 e no MCT-7.

3.2 FIPS PUB 140

A norma FIPS PUB 140-2[16], publicada pelo Instituto Nacional de

Padr

oes e Tecnologia

do governo norte-americano, deﬁne um conjunto de requisitos de

seguranc¸a para hardware criptogr

aﬁcos empregados na protec¸

ao de informac¸

oes sens

ıveis

em sistemas computacionais e de telecomunicac¸

ao. Esta norma

e a evoluc¸

ao da FIPS PUB

140-1[17].

Os requisitos de seguranc¸a cobrem diversas

areas relacionadas com o

projeto e implementac¸

ao de um m

odulo criptogr

aﬁco, devendo o m

odulo satisfazer todos

os requisitos do n

ıvel de certiﬁcac¸

ao desejado. A FIPS 140-2 prev

e quatro n

ıveis: 1, 2, 3

ou 4. Nos n

ıveis em que os requisitos se diferem, aplica-se o comportamento acumulativo,

ou seja, as certiﬁcac¸

oes em n

ıveis mais altos (4) devem tamb

em satisfazer os requisitos

dos n

ıveis mais baixos (1).

Em um processo de avaliac¸

ao de um m

odulo criptogr

aﬁco, atribui-se o

ıvel de cada

area analisada individualmente. Posteriormente, a

area com o n

ıvel mais

baixo estabelecer

a o n

ıvel de certiﬁcac¸

ao do m

odulo criptogr

aﬁco.

A FIPS 140-2 utiliza o termo ”par

ametros cr

ıticos de seguranc¸a

(CSP)”para informac¸

oes que, se divulgadas ou modiﬁcadas, podem comprometer a

seguranc¸a do m

odulo criptogr

aﬁco, tais como segredos e chaves privadas criptogr

aﬁcas e

dados de autenticac¸

ao (PINs e senhas).

A norma ainda inclui outros quatro documentos, complementando o

documento principal, chamados de anexo A, B, C e D, respectivamente a fam

ılia de al-

goritmos criptogr

aﬁcos aprovados, perﬁs de protec¸

ao, geradores de n

umeros aleat

orios

aprovados e t

ecnicas de estabelecimento de chaves

sim

etricas e assim

etricas.

As sub-sec¸

oes seguintes sumarizam cada uma das

areas cobertas pela

norma, com uma

enfase nas principais diferenc¸as entre os n

ıveis de seguranc¸a.

do ingl

es National Institute of Standards and Technology - NIST

do ingl

es key establishment

3.2.1 Especiﬁcac¸

ao do M

odulo Criptogr

aﬁco

Esta

area cont

em as deﬁnic¸

oes de m

odulo e fronteira criptogr

aﬁcos que

devem ser utilizadas na norma como um todo, al

em de sumarizar uma lista com toda a

documentac¸

ao de hardware, software e ﬁrmware, diretamente relacionada

a seguranc¸a do

odulo, que

e necess

aria no processo de certiﬁcac¸

ao. Entre os documentos requeridos

est

ao:

• especiﬁcac¸

ao f

ısica do m

odulo;

• portas f

ısicas e interfaces l

ogicas empregadas;

• especiﬁcac¸

ao dos controles f

ısicos e l

ogicos do m

odulo;

• lista de todas as func¸

oes de seguranc¸a, aprovadas ou n

ao, empregadas pelo m

odulo,

especiﬁcando todos os modos de operac¸

ao suportados, aprovados ou n

ao;

Adicionalmente, requer-se que os m

odulos criptogr

aﬁcos possuam uma

pol

ıtica de seguranc¸a

, contendo regras derivadas dos requisitos da norma FIPS 140-2 e

quaisquer outras regras derivadas dos requisitos impostos pelo fabricante do m

odulo.

Por ﬁm, deﬁne-se que a documentac¸

ao deve conter um diagrama de blo-

cos, detalhando os principais componentes de hardware e suas interconex

oes, tais como

microprocessadores, buffers e mem

orias. Al

em disso,

e necess

ario prover documentac¸

do projeto dos componentes de hardware, software e ﬁrmware.

3.2.2 Portas F

ısicas e Interfaces L

ogicas

A FIPS 140-2 deﬁne que o ﬂuxo de dados e acesso f

ısico de um m

odulo

criptogr

aﬁco devem estar limitados as suas portas f

ısicas e interfaces l

ogicas, identiﬁ-

cando assim, todos os pontos de entrada e sa

ıda existentes.

As interfaces l

ogicas s

ao divididas em quatro tipos. Apesar de cada tipo

poder compartilhar da mesma porta f

ısica, elas devem ser logicamente independentes

umas das outras. Os tipos de interfaces s

ao:

do ingl

es security policy

• entrada de dados: todos os dados que s

ao direcionados ao m

odulo criptogr

aﬁco para

serem processados devem utilizar este tipo de interface;

• sa

ıda de dados: todos os dados, com excec¸

ao de dados de estado, devem sair do

odulo atrav

es deste tipo de interface;

• entrada de controle: os comandos, sinais e dados de controle para operacionalizac¸

do m

odulo criptogr

aﬁco devem utilizar este tipo de interface;

• sa

ıda de estado: todos os dados utilizados para indicar estado do m

odulo, incluindo

leds e displays, devem utilizar este tipo de interface.

Os n

ıveis 1 e 2 somente requerem que exista uma interface l

ogica de

cada um dos tipos descritos anteriormente. Nos n

ıveis 3 e 4, al

em do requisito ante-

rior, a norma requer que a porta de entrada e sa

ıda de CSP do m

odulo criptogr

aﬁco -

par

ametros de chaves criptogr

aﬁcas em texto claro e dados de autenticac¸

ao - sejam ﬁsica-

mente separadas de outras portas ou utilizem uma interface l

ogica de caminho conﬁ

avel

Adicionalmente, a entrada dos dados deve ser de forma direta, atrav

es de um cabo dire-

tamente conectado ao m

odulo, ou tamb

em, com a utilizac¸

ao de um caminho conﬁ

avel de

dados. O uso de caminho conﬁ

avel visa cumprir os dois requisitos dos n

ıveis 3 e 4.

3.2.3 Pap

eis, Servic¸os e Mecanismos de Autenticac¸

O m

odulo criptogr

aﬁco deve suportar pap

eis de usu

arios, onde cada

papel

e associado a um conjunto deﬁnido de servic¸os, por

em,

e opcional para o m

odulo,

o emprego ou n

ao de mecanismos para autenticac¸

ao dos mesmos. Os servic¸os que n

modiﬁquem, substituam ou revelam chaves criptogr

aﬁcas e CSP do interior do m

odulo,

podem ser executados sem que os usu

arios sejam autenticados.

Entre os pap

eis de usu

arios que devem ser suportados pelo m

odulo

est

ao:

• operador: executa servic¸os gerais de seguranc¸a, incluindo operac¸

oes criptogr

aﬁcas;

do ingl

es trusted path.

• administrador (crypto ofﬁcer): respons

avel pela inicializac¸

ao e gerenciamento do

odulo criptogr

aﬁco, incluindo a gerac¸

ao de chaves criptogr

aﬁcas e auditoria;

• manutenc¸

ao: papel opcional, utilizado durante reparos f

ısicos ou l

ogicos no m

odulo

criptogr

aﬁco. Todos os segredos e chave privadas em aberto e CSPs desprotegidos

devem ser apagados utilizando o circuito zerador

sempre que este papel

e autenti-

cado.

E opcional para o m

odulo criptogr

aﬁco a deﬁnic¸

ao de pap

eis ou sub-

pap

eis adicionais aos citados acima.

Existem alguns servic¸os que o m

odulo deve obrigatoriamente prover,

tais como mostrar o estado do m

odulo, executar auto-testes e suportar a execuc¸

ao de

pelo menos uma operac¸

ao criptogr

aﬁca em um algoritmo aprovado. Al

em destes, muitos

outros servic¸os podem existir, at

e operac¸

oes criptogr

aﬁcas de algoritmos n

ao aprovados,

operando em modo tamb

em n

ao aprovado.

Os mecanismos de autenticac¸

ao de um m

odulo criptogr

aﬁco, quando

implementado, devem ser classiﬁcados em uma das seguintes categorias:

• baseado em papel: a autenticac¸

e realizada no papel selecionado (impl

ıcita ou

explicitamente). O m

odulo n

ao autentica a identidade individual do usu

ario.

• baseado em identidade: o usu

ario

e individualmente identiﬁcado e veriﬁca-se se ele

pode assumir o papel selecionado. O papel pode ser selecionado direta ou indireta-

mente.

E opcional para o m

odulo a possibilidade de executar v

arios servic¸os

uma vez que um papel est

a autenticado ou solicitar uma autenticac¸

ao para cada servic¸o.

Entretanto, os resultados das autenticac¸

oes depois de desligar e ligar o m

odulo n

ao podem

ser armazenados, necessitando re-autenticac¸

ao de qualquer um dos pap

eis existentes.

O n

ıvel 1 da norma FIPS 140-2 n

ao requer nenhum mecanismo de

autenticac¸

ao dos operadores. J

a o n

ıvel 2, requer a autenticac¸

ao baseada em papel, e

os n

ıveis 3 e 4 baseada em identidade.

do ingl

es zeroized

3.2.4 Modelo de estados ﬁnitos

Todos os n

ıveis de certiﬁcac¸

ao da FIPS 140-2 requerem que a operac¸

do m

odulo criptogr

aﬁco seja especiﬁcada em um modelo de estados ﬁnitos, representado

por um diagrama ou tabela de transic¸

ao de estados, incluindo:

• todos os estados operacionais e de erro;

• as transic¸

oes de um estado para outro;

• os eventos de entrada que causam uma transic¸

ao;

• os eventos de sa

ıda ap

os a transic¸

ao para outro estado.

Alguns exemplos de estados operacionais obrigat

orios s

ao a execuc¸

dos auto-testes, autenticac¸

ao do papel administrador, estado de manutenc¸

ao, entre outros.

3.2.5 Seguranc¸a F

ısica

O FIPS 140-2 deﬁne que um m

odulo criptogr

aﬁco deve empregar meca-

nismos de seguranc¸a para restringir acesso f

ısico n

ao autorizado ao conte

udo do m

odulo,

prevenindo sua utilizac¸

ao e modiﬁcac¸

ao.

O n

ıvel 1 de certiﬁcac¸

ao n

ao possui nenhum requisito para m

odulos

criptogr

aﬁcos de chip

unico, como um smartcard, por

em, deﬁne que o m

odulo deve estar

embalado por um inv

olucro de metal ou pl

astico duro, podendo incluir portas ou capas

remov

ıveis.

O n

ıvel 2 requer a utilizac¸

ao de travas e a evid

encia de qualquer tentativa

de invas

ao do per

ımetro criptogr

aﬁco do m

odulo. No n

ıvel 3, al

em de ﬁcar evidente

a tentativa de invas

ao, deve existir alta probabilidade de ocorrer danos irrepar

aveis ao

odulo, por exemplo, envolvendo o m

odulo em uma pasta para criac¸

ao de um bloco

unico, r

ıgido e opaco a luminosidade.

ultimo n

ıvel, requer ainda que o m

odulo responda ativamente a ten-

tativa de invas

ao, ativando o circuito zerador que apaga segredos, chaves privadas e PCSs

em texto claro.

3.2.6 Ambiente Operacional

O ambiente operacional de um m

odulo criptogr

aﬁco se refere ao ge-

renciamento de software, ﬁrmware e hardware necess

arios para sua operac¸

ao, sendo o

sistema operacional (SO) um dos principais componentes. O ambiente operacional de um

odulo deve se enquadrar em uma das seguintes categorias:

• ambiente operacional de prop

osito geral: se refere ao uso de um sistema operacional

de prop

osito geral e comercialmente dispon

ıvel.

• ambiente operacional limitado: ambiente operacional est

atico n

ao modiﬁc

avel, que

ao requer um sistema de prop

osito geral para seu suporte.

• ambiente operacional modiﬁc

avel: se refere a ambiente operacional que pode ser

reconﬁgurado, adicionando, deletando ou modiﬁcando funcionalidades. Sistemas

operacionais s

ao considerados ambientes operacionais modiﬁc

aveis se componen-

tes de software/ﬁrmware, que n

ao foram inclu

ıdos no processo de certiﬁcac¸

ao, po-

dem ser importados e executados no m

odulo por seus usu

arios.

Os requisitos desta

area se aplicam apenas para ambientes operacionais

modiﬁc

aveis, tendo abrang

encias diferentes para cada n

ıvel de certiﬁcac¸

ao.

O n

ıvel b

asico requer que apenas um usu

ario possa utilizar o m

odulo

criptogr

aﬁco por vez, prevenindo acesso de outros processos a segredos, chaves privadas

e CSPs armazenados em aberto, sendo que o requisito anterior

e aplic

avel somente para

o n

ıvel 1 da certiﬁcac¸

ao. O software/ﬁrmware do m

odulo deve estar instalado de uma

tal forma que bloqueie modiﬁcac¸

oes ou acesso de usu

arios n

ao autorizados, utilizando

alguma t

ecnica de integridade aprovada pela fam

ılia de algoritmos FIPS.

Os n

ıveis 2, 3 e 4, requerem, respectivamente, um sistema operacional

de n

ıvel EAL2, EAL3 e EAL4 do Crit

erios Comuns[15], ou uma avaliac¸

ao equivalente.

Um mecanismo de auditoria

e requisito do n

ıvel 2, incluindo uma lista de eventos que

precisam obrigatoriamente ser registrados. O n

ıvel 3 inclui outros eventos e requer a

utilizac¸

ao de caminho conﬁ

avel

e modelo de pol

ıtica de seguranc¸a

do ingl

es trusted path (FTP TRP.1 dos crit

erios comuns).

do ingl

es Security Policy Model (ADV SPM.1 do crit

erio comum).

3.2.7 Gerenciamento de Chaves Criptogr

aﬁcas

Esta

area apresenta requisitos de seguranc¸a que visam proteger o ge-

renciamento de todo o ciclo de vida de chaves criptogr

aﬁcas, componentes de chaves

criptogr

aﬁcas e CSPs empregados pelo m

odulo.

Os requisitos s

ao agrupados em v

arias atividades do processo de geren-

ciamento de chaves criptogr

aﬁcas, tais como:

• gerac¸

ao de n

umeros aleat

orios: o gerador utilizado para gerac¸

ao de chaves crip-

togr

aﬁcas deve obrigatoriamente ser aprovado pela fam

ılia de padr

oes FIPS. En-

tretanto, se o m

odulo criptogr

aﬁco emprega geradores n

ao aprovados, os dados

gerados devem apenas ser utilizados para gerar sementes para um gerador aprovado

ou para gerar vetores de inicializac¸

ao para algoritmos sim

etricos;

• gerac¸

ao de chaves criptogr

aﬁcas: se o m

odulo suportar essa funcionalidade, os

etodos de gerac¸

ao devem ser aprovados pela fam

ılia de padr

oes FIPS [16, anexo

A];

• estabelecimento de chaves: o processo de estabelecer uma chave sim

etrica para

a comunicac¸

ao de duas ou mais partes, podendo ser realizado atrav

es de m

etodo

autom

atico, manual ou uma combinac¸

ao de etapas manuais e autom

aticas;

• importac¸

ao e exportac¸

ao de chaves criptogr

aﬁcas: o m

odulo pode suportar

importac¸

ao e/ou exportac¸

ao de chaves, que podem ser realizados de forma manual,

atrav

es do teclado, ou autom

atica, utilizando smartcards;

• armazenamento de chaves criptogr

aﬁcas: as chaves criptogr

aﬁcas podem ser arma-

zenadas cifradas ou em claro. Segredo e chaves armazenados em claro n

ao podem

ser acess

ıveis a usu

arios n

ao autorizados;

• circuito zerador de chaves criptogr

aﬁcas: o m

odulo deve prover um m

etodo para

apagar segredos, chaves privadas e CSPs armazenados em claro dentro do m

odulo.

em disso, deﬁne-se que chaves criptogr

aﬁcas e CSPs cifrados com

algoritmos n

ao aprovados s

ao considerados em formato de texto claro.

3.2.8 Interfer

encia e Compatibilidade Eletromagn

etica

O m

odulo criptogr

aﬁco deve estar em conformidade em relac¸

ao a in-

terfer

encia

e compatibilidade

eletromagn

etica deﬁnida pela comiss

ao de comunicac¸

federal do governo americano (FCC)[18]. Os n

ıveis 1 e 2 da certiﬁcac¸

ao devem seguir os

requisitos para uso comercial, enquanto os n

ıveis 3, 4 para uso dom

estico.

3.2.9 Auto-testes

O m

odulo criptogr

aﬁco deve realizar auto-testes que visam garantir seu

funcionamento apropriado, devendo entrar em um estado de erro se qualquer auto-teste

falhar. O m

odulo n

ao poder

a realizar nenhuma operac¸

ao criptogr

aﬁca enquanto estiver

neste estado, devendo a interface de sa

ıda de dados ser fechada. Existem duas categorias

de auto-teste: de energizac¸

ao e condicional.

Os auto-testes de energizac¸

ao s

ao automaticamente realizados quando

o m

odulo

e energizado, sem intervenc¸

ao dos usu

arios. Entre os testes necess

arios est

ao:

testes de algoritmos criptogr

aﬁcos, testes de integridade de software e ﬁrmware, testes

de func¸

oes cr

ıticas para o funcionamento seguro do m

odulo. Deﬁne-se que todos os

algoritmos criptogr

aﬁcos devem ser submetidos a testes de resposta conhecida.

Os auto-testes condicionais s

ao realizados quando determinadas

operac¸

oes ocorrerem no m

odulo:

• gerac¸

ao de par de chaves: testes de consist

encias do par;

• carregamento de software/ﬁrmware externo: testes de validac¸

ao de soft-

ware/ﬁrmware carregados para dentro do m

odulo;

• quando chaves ou componentes de chaves s

ao entradas manualmente no m

odulo:

mecanismos de veriﬁcac¸

ao de corretude do seu conte

udo;

• utilizac¸

ao de um gerador de n

umeros aleat

orios: executar testes cont

ınuos para

detectar gerac¸

ao de valores constantes.

do ingl

es electromagnetic interference - EMI

do ingl

es electromagnetic compatibility - EMC

• quando o m

odulo troca de modo de operac¸

ao normal para de desvio

: testes para

conﬁrmar o comportamento correto de func¸

oes que operam com material crip-

togr

aﬁco no momento de troca de modo de operac¸

ao.

3.2.10 Garantia de Projeto

A garantia de projeto se refere ao uso de boas pr

aticas do fabricante

do m

odulo criptogr

aﬁco durante seu projeto, distribuic¸

ao e operac¸

ao. O fabricante deve

fornecer garantias que o m

odulo

e devidamente testado, conﬁgurado, entregue, instalado e

desenvolvido, contendo guias de manuseio adequado para seus usu

arios (administradores

e operadores).

Esta

area requer a utilizac¸

ao de ger

encia de conﬁgurac¸

ao para todo o

ciclo de desenvolvimento do m

odulo, incluindo a deﬁnic¸

ao dos requisitos de sua entrega

e operac¸

ao. Al

em disso, para auxiliar a compreens

ao do funcionamento interno, requer-se

um conjunto de documentos referentes a sua especiﬁcac¸

ao e desenvolvimento.

Adicionalmente, um conjunto de requisitos ligados ao desenvolvimento

do m

odulo criptogr

aﬁco

e deﬁnido, variando dependendo do n

ıvel de certiﬁcac¸

ao. Estes

requisitos visam prover garantia que a implementac¸

ao do m

odulo corresponde com sua

pol

ıtica de seguranc¸a e especiﬁcac¸

ao funcional.

3.2.11 Mitigac¸

ao de Outros Ataques

Esta

area de requisitos visa abranger ataques que n

ao eram conhecidos

durante a escrita da norma FIPS 140-2 ou que ﬁcaram de fora do escopo da mesma. Esses

ataques que o m

odulo n

e suscet

ıvel devem estar descritos na sua pol

ıtica de seguranc¸a.

A maioria dos ataques a um m

odulo criptogr

aﬁco tentam determinar

alguma informac¸

ao referente ao material criptogr

aﬁco armazenado dentro do m

odulo,

tais como: an

alise da tens

ao utilizada durante a gerac¸

ao de chaves e/ou operac¸

oes crip-

togr

aﬁcas, an

alise de tempo de processamento, induc¸

ao para ocorr

encia de erros, entre

outros.

do ingl

es bypass

3.3 Manual de Condutas T

ecnicas 7 (LEA/ITI)

O manual de condutas t

ecnicas 7 (MCT-7)[19], de responsabilidade do

Instituto Nacional de Tecnologia da Informac¸

ao (ITI)[20] em conjunto com os Labo-

rat

orios de Ensaios e Auditoria

(LEA), descreve os requisitos t

ecnicos a serem valida-

dos no processo de homologac¸

ao de um m

odulo de seguranc¸a criptogr

aﬁca no

ambito da

Infra-estrutura de Chaves P

ublicas Brasileira, ICP-Brasil[21].

Por HSM entende-se um servidor ou placa auxiliar criptogr

aﬁca ﬁsica-

mente segura, resistente

a violac¸

ao que fornece funcionalidades criptogr

aﬁcas com capa-

cidade de gerac¸

ao e armazenamento de chaves sim

etricas e assim

etricas voltados essen-

cialmente para utilizac¸

ao em uma Infra-estrutura de Chaves P

ublicas (ICP).

O padr

ao MCT-7 deﬁne tr

es N

ıveis de Seguranc¸a de Homologac¸

(NSH) e dois N

ıveis de Seguranc¸a F

ısica (NSF). O NSH

e baseado na disponibilizac¸

do c

odigo fonte do HSM, onde o NSH 1 n

ao requer dep

osito e an

alise do c

odigo fonte

do HSM, o NSH 2 requer dep

osito e an

alise do c

odigo fonte de componentes espec

ıﬁcos

associados ao dispositivo em homologac¸

ao, enquanto o NSH 3 requer o dep

osito e an

alise

do c

odigo fonte completo associado ao dispositivo em homologac¸

ao.

O NSF 1 requer que o m

odulo tenha mecanismos de seguranc¸a f

ısica

que evidenciam e resistem

a violac¸

ao, enquanto o NSF 2, requer que os mecanismos de

seguranc¸a f

ısica do HSM detectem e respondam

as tentativas de violac¸

ao. O fabricante

do m

odulo, referenciado pela norma como parte interessada (PI), deve especiﬁcar o N

ıvel

de Seguranc¸a F

ısica desejada para homologac¸

ao.

O processo de homologac¸

ao visa a interoperabilidade e operac¸

ao segura

dos servic¸os criptogr

aﬁcos providos por um HSM para uma ICP, analisando a ader

encia

aos requisitos. O escopo da homologac¸

ao n

ao visa avaliar outros servic¸os presentes no

HSM que n

ao sejam

uteis para uso em ICPs, desde que n

ao exista risco desta coexist

encia.

O MCT-7 aborda as 11

areas de atuac¸

ao relacionadas ao projeto e

implementac¸

ao do m

odulo criptogr

aﬁco utilizadas pela FIPS 140-2 (vide sec¸

ao 3.2), al

Entidades formalmente vinculadas ao ITI, aptas a realizar os ensaios exigidos nas avaliac¸

oes de con-

formidade.

de incluir outros quatro temas: algoritmos criptogr

aﬁcos obrigat

orios, gerenciamento, in-

teroperabilidade e restric¸

ao de subst

ancias nocivas.

Apesar da utilizac¸

ao das mesmas

areas de atuac¸

ao, algumas delas sofre-

ram alterac¸

oes (adic¸

ao, remoc¸

ao ou modiﬁcac¸

ao de alguns requisitos) e ser

ao abordados

a seguir, com foco nestas diferenc¸as.

3.3.1 Requisitos de Especiﬁcac¸

Esta

area permanece praticamente a mesma existente no padr

ao FIPS

140-2, diferenciando-se apenas em um dos requisitos. Enquanto a FIPS requer que o

HSM implemente no m

ınimo um algoritmo criptogr

aﬁco aprovado, o MCT-7 apresenta

uma lista de algoritmos obrigat

orias, que inclui:

• DES[22] nos modos de operac¸

ao ECB e CBC. Apenas para uso legado;

• Triple-DES nos modos de operac¸

ao ECB e CBC;

• AES[23] nos modos de operac¸

ao ECB e CBC com tamanho de chaves de 128 bits;

• Assinatura RSA[9, 24] com chaves de 1024 bits no m

ınimo;

• Resumos criptogr

aﬁcos: SHA-1[25] e SHA-256, sendo o primeiro apenas para uso

legado.

em dos obrigat

orios, o MCT-7 recomenda o suporte a outros algorit-

mos criptogr

aﬁcos.

3.3.2 Portas F

ısicas e Interfaces L

ogicas

O MCT-7 deﬁne que as portas f

ısicas e interfaces l

ogicas para a entrada

e sa

ıda de componentes de chaves criptogr

aﬁcas, dados de autenticac¸

ao e PCSs devem ser

ﬁsica e logicamente separados de outras portas e interfaces do HSM, se enquadrando nos

requisitos de n

ıvel 3 e 4 do FIPS 140-2.

3.3.3 Pap

eis, Servic¸os e Mecanismos de Autenticac¸

Esta

area difere em alguns pontos com relac¸

ao aos requisitos deﬁnidos

na FIPS 140-2. Primeiramente, deﬁne-se que o mecanismo de autenticac¸

ao deve ser ba-

seado em papel (referente ao n

ıvel 2 da FIPS 140-2) no NSH 1 e baseado em identidade

nos NSH 2 e NSH 3 (referente aos n

ıveis 3 e 4 da FIPS 140-2).

em disso, apesar de suportar o mesmo conjunto de pap

eis, somente

o papel administrador

e obrigat

orio, devendo receber a responsabilidade dos pap

eis n

existentes. A seguir, apresenta-se o conjunto de servic¸os obrigat

orios para cada um dos

pap

eis:

• papel administrador: inicializac¸

ao do HSM, gerac¸

ao de chaves RSA, sobrescrita de

chaves criptogr

aﬁcas com zero, ﬁnalizac¸

ao do m

odulo, execuc¸

ao de auto-testes e

requisic¸

ao do estado do HSM;

• papel operador: manipulac¸

ao de chaves criptogr

aﬁcas e PCS no HSM, acesso a

algoritmos de resumo e autenticac¸

ao, requisic¸

ao do estado do HSM e gerac¸

ao de

chaves RSA;

• papel de manutenc¸

ao: backup e recuperac¸

ao de chaves, conﬁgurac¸

ao de operado-

res e conﬁgurac¸

ao e controle dos registros do sistema (o processo de auditoria

realizado pelo papel de manutenc¸

ao).

3.3.4 Modelo de Estado Finito

O modelo de estado ﬁnito segue os requisitos especiﬁcados no padr

FIPS 140-2 com a exclus

ao do estado de desvio, que n

e aceito pelo MCT-7.

3.3.5 Seguranc¸a F

ısica

O MCT-7 n

ao faz distinc¸

ao do n

umero de componentes eletr

onicos con-

tidos no HSM como deﬁnido na FIPS 140-2, sendo que o modelo de seguranc¸a f

ısica deve

se enquadrar em uma das seguintes categorias:

• protec¸

ao que evidencia violac¸

ao: referente ao n

ıvel 2 do padr

ao FIPS 140-2 para

odulos criptogr

aﬁcos multi − chipstandalone

• protec¸

ao que resiste a violac¸

ao: referente ao n

ıvel 3 do padr

ao FIPS 140-2 para

odulos criptogr

aﬁcos

multi

−

chipstandal one

• protec¸

ao que detecta e responde

a violac¸

ao: referente ao n

ıvel 4 do padr

ao FIPS

140-2 para m

odulos criptogr

aﬁcos multi − chipstandalone

3.3.6 Ambiente Operacional

O MCT-7 classiﬁca os ambientes operacionais nas tr

es categorias deﬁ-

nidas pela FIPS 140-2, utilizando os requisitos referentes ao n

ıvel 2, sem a obrigatorie-

dade de um sistema operacional com n

ıvel de garantia de avaliac¸

ao 2 (EAL2) do Crit

erio

Comum.

3.3.7 Gerenciamento de Chaves Criptogr

aﬁcas

em de herdar todos os requisitos existentes no padr

ao FIPS 140-2, o

MCT-7 incorpora outros para se adequar as caracter

ısticas da ICP-Brasil. Primeiramente,

requer que a documentac¸

ao especiﬁque os m

etodos utilizados para armazenar chaves se-

cretas, chaves privadas e PCSs que evitem divulgac¸

ao, modiﬁcac¸

ao e substituic¸

ao n

autorizada. O mesmo se aplica para chaves p

ublicas, mas com o objetivo de proteger

contra modiﬁcac¸

ao e substituic¸

ao n

ao autorizadas.

O MCT-7 tamb

em requer que as chaves criptogr

aﬁcas geradas interna-

mente ao HSM possam ser conﬁguradas como export

avel ou n

ao export

avel. Este requi-

sito visa criar compatibilidade com os certiﬁcados digitais do tipo S3, S4, A3 e A4 da

ICP-Brasil. Uma vez conﬁgurada como n

ao export

avel, n

ao deve ser poss

ıvel alter

a-la

para export

avel.

3.3.8 Interfer

encia e Compatibilidade Eletromagn

etica

Esta

area de atuac¸

ao cont

em os mesmo requisitos existentes na FIPS

140-2.

3.3.9 Auto-testes

O MCT-7 utiliza o mesmo conjunto de auto-testes deﬁnidos no padr

FIPS 140-2, com a restric¸

ao de que se o auto-teste de inicializac¸

ao falhar, o HSM est

comprometido e n

ao pode mais ser considerado conﬁ

avel.

3.3.10 Garantia de Projeto

Os requisitos de garantia de projeto s

ao os mesmos encontrados no

padr

ao FIPS 140-2, mudando apenas a relac¸

ao de alguns dos requisitos com o n

ıvel de

seguranc¸a de homologac¸

ao (NSH) desejado.

O NSH 1 requer documentos guias para administradores e operadores,

enquanto o NSH 2, adicionalmente, requer o c

odigo fonte de todos os componentes de

software e ﬁrmware, com coment

arios que esclarec¸am a correspond

encia com os compo-

nentes do m

odulo criptogr

aﬁco.

3.3.11 Mitigac¸

ao de Outros Ataques

Abordado da mesma forma que o padr

ao FIPS 140-2.

3.3.12 Requisitos de Gerenciamento

Esta

area de atuac¸

ao apresenta uma lista de funcionalidades que devem

estar dispon

ıveis aos usu

arios do HSM, para executar operac¸

oes de controle do hardware,

do m

odulo criptogr

aﬁco e das chaves gerenciadas. Cada um dos itens anteriores se rami-

ﬁcam em v

arios requisitos.

O gerenciamento do hardware deve conter procedimentos de gerac¸

de c

opias de seguranc¸a e sua posterior recuperac¸

ao, protec¸

ao contra falta de energia e

falhas de comunicac¸

ao, atualizac¸

ao e validac¸

ao de ﬁrmware e controle de ativac¸

ao de

mecanismos de segredo compartilhado.

O HSM deve dispor de uma interface gr

aﬁca com idioma em portugu

ou ingl

es para seu gerenciamento, incluindo a possibilidade de importar e exportar cha-

ves sim

etricas e assim

etricas, apagar dados contidos no m

odulo (inclusive chaves crip-

togr

aﬁcas), entre outros.

3.3.13 Requisitos de Interoperabilidade

Esta

area avalia o m

odulo do ponto de vista de interoperabilidade,

visando garantir um conjunto m

ınimo de funcionalidades para integrac¸

ao com outras

aplicac¸

oes. O MCT-7 requer que pelo menos uma das seguintes API esteja dispon

ıvel

para o HSM em avaliac¸

ao:

• Microsoft CryptoAPI[26]

• PKCS#11 v.2.11[27]

• JCE

/JCA

• interface pr

opria

• engine OpenSSL (vide sec¸

ao 4.5)

Para cada uma das API, deﬁne-se um conjunto m

ınimo de func¸

oes que

deve estar presente, devendo, quando poss

ıvel, ser compat

ıvel com os sistemas operacio-

nais Microsoft Windows 2000, Linux Kernel 2.4 ou suas vers

oes mais recentes.

3.3.14 Requisitos para restric¸

ao de subst

ancias nocivas

O MCT-7 recomenda que os HSM estejam em conformidade com di-

retivas estabelecidas quanto a restric¸

ao da utilizac¸

ao de subst

ancias nocivas, visando

Extens

ao de criptograﬁa JAVA, do ingl

es Java Cryptography Extension

API de comunicac¸

ao Java, do ingl

es Java Communications API

conjunto de func¸

oes disponibilizadas pelo fabricante do m

odulo, sem seguir um padr

ao conhecido, que

permitir

a a utilizac¸

ao das chaves criptogr

aﬁcas gerenciadas.

preservac¸

ao da sa

ude humana e do meio ambiente. Como refer

encia cita-se o RoHS

[28]

e o WEEE

[29], ambas diretivas da Uni

ao Europ

eia, sendo que a

ultima deﬁne o correto

tratamento, recuperac¸

ao e reciclagem de res

ıduos de materiais eletroeletr

onicos.

3.4 Conclus

As normas de avaliac¸

ao apresentadas nesse cap

ıtulo diferenciam-se

principalmente pelo grau de abrang

encia, onde a FIPS 140-2 certiﬁca qualquer hardware

criptogr

aﬁco, enquanto o MCT-7 restringe-se a HSM voltados para ICPs.

em disso, o MCT-7, nos n

ıveis 2 e 3 de seguranc¸a da homologac¸

ao,

requer o dep

osito de c

odigo fonte, requisito muitas vezes n

ao aprovado pelos fabricantes

dos HSM, por ameac¸ar o segredo industrial.

O MCT-7 se encaixa perfeitamente com os objetivos do HSM do GT

ICPEDU II, j

a que este

ultimo teve seu desenvolvimento direcionado para ICPs e possui

plataforma totalmente aberta.

A aus

encia de elementos que viabilizem um processo de auditoria afe-

tam tanto a FIPS 140-2 quanto o MCT-7. Al

em disso, como o foco deste

ultimo s

as aplicac¸

oes de ICPs, esse comportamento torna o ambiente deﬁciente, j

a que um sis-

tema de auditoria forte

e requisito fundamental para a utilizac¸

ao de cerim

onias que visam

garantir a correta operacionalizac¸

ao de HSM no

ambito de ICPs.

Outro ponto a se considerar

e a falta de requisitos para o estabeleci-

mento de um controle mais restrito no uso de chaves criptogr

aﬁcas, como tamb

em na

criac¸

ao e recuperac¸

ao de c

opias de seguranc¸a dos HSM. A rastreabilidade das mesmas no

ambito de ICPs

e fundamental, j

a que suas ACs e ARs deﬁnem o ponto de conﬁanc¸a de

toda uma hierarquia.

do ingl

es Restriction to the use of Hazardous Substances

do ingl

es Waste from Electrical and Electronic Equipament

Cap

ıtulo 4

OpenSSL

4.1 Introduc¸

O OpenSSL[30]

e uma poderosa e robusta ferramenta para soluc¸

oes

envolvendo criptograﬁa. Desenvolvido na linguagem C sob esforc¸o colaborativo de

odigo aberto, o OpenSSL possui uma aplicac¸

ao de linha de comando para execuc¸

de operac¸

oes criptogr

aﬁcas e uma rica biblioteca, que inclui implementac¸

ao dos dois

principais protocolos de comunicac¸

ao segura: SSL (Secure Socket Layer v3)[31] e TLS

(Transport Layer Security v1)[32].

Atualmente (julho de 2008) na vers

ao 0.9.8h, o OpenSSL foi baseado

na biblioteca SSLeay desenvolvida por Eric A. Young e Tim J. Hudson e

e distribu

ıdo

sob licenc¸a estilo apache, que basicamente signiﬁca que qualquer um

e livre para us

a-la,

comercialmente ou n

ao.

O OpenSSL

e largamente empregado em aplicac¸

oes criptogr

aﬁcas co-

merciais, como no m

odulo de conex

ao segura (mod-ssl) do servidor Web mais utilizado

no mundo, o Apache[33]. Adicionalmente, o OpenSSL possui uma vers

ao certiﬁcada

FIPS 140-2 n

ıvel 1 (vide sec¸

ao 4.6), que mostra a abrang

encia do projeto.

As pr

oximas sec¸

oes descrever

ao as principais funcionalidades e recur-

sos implementados no OpenSSL, incluindo sua aplicac¸

ao de linha de comando para exe-

cutar operac¸

oes criptogr

aﬁcas, a biblioteca de aux

ılio ao desenvolvimento de aplicac¸

oes

e o suporte a engines, que permitem a utilizac¸

ao de outras implementac¸

oes dos algorit-

mos suportados pelo OpenSSL, possibilitando, por exemplo, sua integrac¸

ao a hardware

criptogr

aﬁcos.

4.2 Aplicac¸

ao de Linha de Comando

O pacote do OpenSSL inclui uma aplicac¸

ao de linha de comando que

possibilita a utilizac¸

ao de todas as func¸

oes criptogr

aﬁcas implementadas na biblioteca.

Todas essas func¸

oes podem ser agrupadas em:

• operac¸

oes de criptograﬁa sim

etrica;

• criac¸

ao e manipulac¸

ao de chaves e par

ametros criptogr

aﬁcos de algoritmos as-

sim

etricos;

• operac¸

oes de criptograﬁa assim

etrica;

• c

alculo de mensagens de resumo (hash);

• criac¸

ao de certiﬁcados X.509[10], requisic¸

oes de certiﬁcados (REQ)[34] e lista de

certiﬁcados revogados (LCR)[10];

• testes de servidores e clientes que implementam protocolos SSL/TLS;

• codiﬁcac¸

ao de e-mails assinados e/ou cifrados;

• requisic¸

ao, gerac¸

ao e veriﬁcac¸

ao de carimbos de tempo (implementado na futura

vers

ao 0.9.9 do OpenSSL).

As func¸

oes dispon

ıveis na aplicac¸

ao de linha de comando s

ao imple-

mentadas visando a maior abrang

encia poss

ıvel. Por exemplo, no caso de gerac¸

ao de um

certiﬁcado, seu conte

udo pode ser gravado em formato PEM (Base 64), DER (Bin

ario)

ou NET (um formato obsoleto da Netscape).

O poder de customizac¸

ao das operac¸

oes possibilita o desenvolvimento

de aplicac¸

oes sem utilizac¸

ao da biblioteca e sim chamadas da linha de comando, que pos-

sui seu poder de ac¸

ao aumentado com o suporte a arquivos de conﬁgurac¸

ao (sec¸

ao 4.3.1),

automatizando e padronizando diversas operac¸

oes. Al

em disso, existem comandos que

foram criados especialmente para integrar aplicac¸

oes com o OpenSSL linha de comando,

tais como as func¸

oes que informam se um determinado algoritmo

e suportado.

4.3 Infra-estrutura de Suporte

em de algoritmos criptogr

aﬁcos, o OpenSSL implementa in

umeras

func¸

oes e funcionalidades auxiliares que facilitam o desenvolvimento de aplicac¸

oes reais.

Algumas das facilidades, entre elas a operac¸

ao de n

umeros grandes,

tratamento de erros e abstrac¸

ao de entrada e sa

ıda, ser

ao tratadas separadamente em sub-

sec¸

oes neste cap

ıtulo, apontando suas caracter

ısticas e utilidade. As facilidades imple-

mentadas podem ser

uteis para a aplicac¸

ao de linha de comando e/ou aplicac¸

oes utilizando

a biblioteca OpenSSL.

4.3.1 Arquivos de Conﬁgurac¸

O OpenSSL inclui a capacidade de ler e interpretar arquivos de

conﬁgurac¸

ao em tempo de execuc¸

ao. Com estrutura interna baseada em sec¸

oes, esses

arquivos podem ser utilizados atrav

es da aplicac¸

ao de linha de comando ou pela bibli-

oteca OpenSSL. O item openssl conf

e utilizado pelo OpenSSL para mapear a sec¸

principal (como pode ser visto na tabela 4.1).

Os arquivos de conﬁgurac¸

ao s

ao essenciais no gerenciamento de uma

autoridade certiﬁcadora atrav

es da aplicac¸

ao de linha de comando do OpenSSL, deﬁnindo

o conte

udo dos certiﬁcados e lista de certiﬁcados revogados. Adicionalmente, todas as

extens

oes suportadas ou n

ao pelo OpenSSL podem ser deﬁnidas com a utilizac¸

ao de ar-

quivos de conﬁgurac¸

ao. Para extens

oes n

ao suportadas

e necess

ario deﬁnir sua seq

encia

ASN.1[35] correspondente.

Um processo de carga e utilizac¸

ao de engines (vide sec¸

ao 4.5) tamb

pode ser automatizado utilizando arquivos de conﬁgurac¸

ao, suportando at

e eventuais

par

ametros que podem ser necess

arios em alguns casos. O arquivo de conﬁgurac¸

ao ne-

cess

ario para carga da engine do HSM do GT ICPEDU II pode ser visto na tabela 4.1.

Tabela 4.1: Arquivo de conﬁgurac¸

ao do OpenSSL para carga da engine do ASI-HSM.

1. openssl conf = openssl init

2. [ openssl init ]

3. engines = engine section

4. [ engine section ]

5. openhsmd = openhsmd section

6. [ openhsmd section ]

7. engine id = openhsmd

8. dynamic path = ../engines/engine openhsmd.so

9. ADDRESS CONN = 192.168.1.1

10. PORT CONN = 5001

A API dos arquivos de conﬁgurac¸

ao do OpenSSL pode ser extendida

e utilizada em outras aplicac¸

oes, evitando a implementac¸

ao de um m

odulo de software

com a mesma ﬁnalidade, economizando tempo e minimizando as chances de ocorr

encia

de erros.

4.3.2 Func¸

oes de Callback

O objetivo dessas func¸

oes

e proporcionar ﬂexibilidade e extens

ao das

funcionalidades de uma biblioteca, permitindo aos desenvolvedores implementar o com-

portamento de acordo com a necessidade de sua aplicac¸

ao.

As func¸

oes de callback n

ao s

ao executadas diretamente pela aplicac¸

ao,

ao inv

es disso, seu ponteiro

e passado para outras func¸

oes, de onde elas ser

ao chamadas.

Para isso, as func¸

oes de callback devem seguir o formato previamente deﬁnido pela bibli-

oteca que as utilizam, isto

e, a quantidade e tipos dos argumentos e o tipo da vari

avel de

retorno.

A ﬁgura 4.1 demonstra o funcionamento das func¸

oes de callback, sa-

lientando a indiferenc¸a da biblioteca quanto a operac¸

ao que est

a sendo executada. A

Figura 4.1: Funcionamento das func¸

oes de callback, empregadas no OpenSSL.

biblioteca est

a passando os inteiro 5 e 2 como par

ametro de uma func¸

oes implementada

pela aplicac¸

oes. A execuc¸

ao das linhas 10 e 11 resulta, respectivamente, nos valores 7 e

O OpenSSL emprega func¸

oes de callback em v

arias de suas funciona-

lidades, tal como no processo de gerac¸

ao de n

umeros primos, que, com sua utilizac¸

ao,

pode-se acompanhar cada tentativa do processo de encontrar o n

umero primo apropriado.

Adicionalmente, para algumas funcionalidades da biblioteca OpenSSL,

o emprego dessas func¸

oes

e fundamental, como no suporte a execuc¸

ao multi-thread, que

e o assunto da pr

oxima sub-sec¸

ao.

4.3.3 Suporte Multi-thread

A biblioteca OpenSSL emprega controle de acesso concorrente as estru-

turas consideradas cr

ıticas quando executado em modo multi-thread, protegendo-os com

uso de sem

aforos.

Entretanto, o efetivo uso desse controle ﬁca a cargo da aplicac¸

ao que

est

a utilizando a biblioteca OpenSSL, pois esta deve implementar a func¸

ao que ser

a res-

pons

avel por checar e bloquear o acesso aos recursos. Essa func¸

ao de callback deve ser

conﬁgurada no OpenSSL no in

ıcio da execuc¸

ao da aplicac¸

ao.

O controle de acesso a recursos na biblioteca requer obrigatoriamente a

deﬁnic¸

ao da func¸

ao de callback que ir

a implementar as operac¸

oes de bloqueio e liberac¸

dos sem

aforos. Nas chamadas a func¸

ao de callback solicitando acesso a um recurso

compartilhado, existe a distinc¸

ao de operac¸

oes de somente-leitura das operac¸

oes leitura-

escrita. Fica a cargo da aplicac¸

ao o n

ıvel de controle desejado. A aplicac¸

ao de linha de

comando do OpenSSL implementa uma func¸

ao de callback que trata indiferentemente

operac¸

ao de leitura e escrita, garantindo acesso exclusivo a qualquer um dos casos.

Na sec¸

ao 4.5 ser

a abordado com detalhes o controle de acesso si-

mult

aneo realizado pela biblioteca para gerenciar o suporte as engines.

4.3.4 Matem

atica de Precis

ao Arbitr

aria

A biblioteca OpenSSL possui incorporado um conjunto de func¸

oes ca-

paz de manipular e executar operac¸

oes matem

aticas sobre n

umeros grandes, isto

e, que

ao podem ser representados nas vari

aveis do tipo inteiro de 32 ou 64 bits encontrado nas

plataformas computacionais convencionais.

A manipulac¸

ao de n

umeros grandes

e essencial para a implementac¸

ao,

entre outra, do algoritmo de chaves p

ublicas RSA, considerando que chaves deste algo-

ritmo devem ter um tamanho m

ınimo de seguranc¸a de 1024 bits, como deﬁnido na FIPS

140-2.

O conjunto de func¸

oes implementadas inclui todas operac¸

oes normal-

mente dispon

ıveis sobre vari

aveis do tipo inteiro em linguagens de programac¸

ao em ge-

ral, incluindo operac¸

oes modulares, utilizadas em cifragens e decifragens RSA, al

em da

gerac¸

ao de n

umeros primos, que incorpora os testes conhecidos de primalidade.

Esta funcionalidade

e outro recurso que pode ser usufruido por

aplicac¸

oes utilizando a biblioteca OpenSSL, diminuindo a complexidade de aplicac¸

oes

com necessidades semelhantes.

4.3.5 Tratamento de Erros

O OpenSSL possui um sistema centralizado para tratar erros durante

sua execuc¸

ao, atribuindo identiﬁcadores

unicos para cada parte/m

odulo de sua biblioteca.

Esses identiﬁcadores s

ao utilizados para separar os identiﬁcadores de func¸

oes e erros de

cada m

odulo.

Quando um erro acontece, 5 informac¸

oes referentes ao erro s

ao regis-

tradas:

• o identiﬁcador do m

odulo;

• o identiﬁcador da func¸

ao;

• identiﬁcador do erro;

• nome do arquivo (automaticamente obtido com a macro F ILE da linguagem

C);

• linha na qual o erro foi disparado (automaticamente obtido com a macro LIN E

da linguagem C);

Cada m

odulo

e respons

avel por carregar no sistema o texto correspon-

dente a cada identiﬁcador, tanto de func¸

ao quanto de erro, permitindo a convers

ao dos

erros ocorridos durante a execuc¸

ao do sistema em texto leg

ıvel.

O OpenSSL disponibiliza a func¸

ao ERR load crypto strings para

carregar todos os identiﬁcadores e seus respectivos textos de todos seus m

odulos nativos

de uma s

o vez. Normalmente, esse

e um dos primeiros passos dentro de uma aplicac¸

utilizando a biblioteca OpenSSL.

Na aplicac¸

ao de linha de comando, os erros s

ao impressos ao ﬁnal da

execuc¸

ao de qualquer operac¸

ao que venha a falhar. J

a no caso de aplicac¸

oes utilizando

a biblioteca OpenSSL, as func¸

oes de manipulac¸

ao dos erros precisam ser explicitamente

acionadas.

O sistema de erros do OpenSSL suporta a adic¸

ao de novos m

odulos

de erros, permitindo que bibliotecas e aplicativos o utilizem para gerenciamento de seus

erros, deixando o sistema uniforme. O OpenSSL inclui scripts que vasculham o c

odigo

fonte e geram os arquivos necess

ario para essa integrac¸

ao.

4.3.6 Abstrac¸

ao de Entrada e Sa

ıda

A abstrac¸

ao de entrada e sa

ıda (BIO) do OpenSSL permite a

comunicac¸

ao entre dois pontos de forma transparente, isto

e, sem a manipulac¸

ao de carac-

ter

ısticas inerentes a fonte/destino da informac¸

ao. Al

em disso, camadas podem ser adici-

onadas nesses canais de comunicac¸

ao, provendo funcionaliades extras. No OpenSSL, os

BIOs s

ao agrupados em dois tipos primitivos: comunicac¸

ao e ﬁltro.

Os BIOs de comunicac¸

ao s

ao utilizados na troca de informac¸

ao entre

duas entidades, podendo essas serem arquivos, sockets, mem

oria ou simplesmente um

outro BIO para comunicac¸

ao dentro da pr

opria aplicac¸

ao. O uso de algumas dessas enti-

dades incorporam um outro sub-tipo de BIOs, chamado de descriptor. Este sub-tipo se

aplica a entidades que utilizam descritores de arquivos, como no caso de sockets.

Um exemplo da utilizac¸

ao dos BIOs de comunicac¸

ao seria o processo

de escrita de dados em um arquivo no disco r

ıgido, atrav

es de um BIO arquivo. O mesmo

processo vale para leitura de arquivos.

Os BIOs do tipo ﬁltro s

ao recursos adicionais aos BIOs de comunicac¸

ao,

capazes de processar os dados transferidos, agindo como uma camada extra na

comunicac¸

ao entre dois pontos. O processamento realizado pelo ﬁltro depende da sua

ﬁnalidade, que pode ser:

• conversor base64 ( convers

ao e vice-versa );

• calculo de func¸

oes de resumo;

• criptograﬁa sim

etrica (cifrar e decifrar);

• protocolo SSL;

No caso do exemplo anterior, se os dados a serem escritos no arquivo

precisam ser convertidos em base64, acopla-se o BIO ﬁltro espec

ıﬁco em frente ao BIO

arquivo, de forma que os dados ser

ao escritos no BIO base64 e terminar

ao no arquivo de

destino, com os dados convertidos em base64. N

ao existe limite da quantidade de ﬁltros

que podem ser conectados.

O emprego de ﬁltros deixa o processo simples e uniforme, independente

da quantidade de camadas existentes, onde a sa

ıda de uma camada

e a entrada da pr

oxima,

e atingir o n

o ﬁnal. Cada BIO do tipo ﬁltro realiza uma operac¸

ao em um sentido que

a informac¸

e transferida e a operac¸

ao inversa no sentido oposto, ou seja, voltando no

exemplo do arquivo em base64, tudo que for escrito ser

a convertido em base64, e o que

for lido retornar

a ao formato original. Vale destacar que o processo inverso n

ao se aplica

para a func¸

oes de resumo, devido sua propriedade de irreversibilidade.

A abstrac¸

ao provida pelos BIOs de comunicac¸

ao j

a justiﬁcaria a

exist

encia dos BIOs, entretanto, com a adic¸

ao dos tipos ﬁltros, sua utilidade multiplica-se

de tamanho, agregando in

umeras possibilidades.

E poss

ıvel por exemplo criar um socket

usando BIO e posteriormente adicionar um BIO ssl nas pontas, de forma a estabelecer um

canal seguro de comunicac¸

ao.

A utilizac¸

ao de BIOs est

a difundida em todo c

odigo do OpenSSL, en-

globando todas as func¸

oes de leitura e escrita de arquivos do sistema, tais como o manu-

seio de chaves p

ublicas e privadas.

A abstrac¸

ao de Entrada e Sa

ıda apresentada nesta sec¸

e voltada para

desenvolvedores utilizando a biblioteca OpenSSL, j

a que na aplicac¸

ao de linha de co-

mando, apesar de utiliz

a-los intensamente, esse recurso passa despercebido.

4.4 Documentac¸

Documentac¸

e um dos pontos mais importantes para que uma ferra-

menta, que

e necessariamente voltada para usu

arios em geral, seja facilmente assimilada e

compreendida na sua forma de utilizac¸

ao e operac¸

ao. O OpenSSL, apesar de toda sua ge-

nialidade explicada aqui, peca neste quesito. A falta de documentac¸

ao, principalmente na

biblioteca que permite integrac¸

ao com outros aplicativos, diﬁculta muito sua utilizac¸

ao.

As constantes atualizac¸

oes e gerac¸

ao de novas vers

oes acabam aconte-

cendo sem os devidos cuidados com os materiais auxiliares de aprendizado, fazendo com

que a pouca documentac¸

ao existente ﬁque desatualizada e muitas vezes piorando ainda

mais sua compreens

ao.

O c

odigo fonte acaba se tornando o principal meio de obter conheci-

mento detalhado dos objetivos das func¸

oes e procedimentos, resultando muitas vezes em

mais tempo gasto entendendo a biblioteca do que realmente pensando na soluc¸

ao do pro-

blema. A utilizac¸

ao de outras fontes de documentac¸

ao como livros[36], artigos e lista de

discuss

oes s

ao alternativas.

4.5 Engine

O OpenSSL implementa cada um dos algoritmos criptogr

aﬁcos por ele

suportado, possibilitando que sejam operacionalizados por outras aplicac¸

oes. Entretanto,

em algumas situac¸

oes,

e necess

ario a utilizac¸

ao de outras implementac¸

oes, como no caso

dos aceleradores criptogr

aﬁcos, que implementam os algoritmos em hardware e suportam

grande poder de processamento. Nestes casos, a sa

ıda

e a utilizac¸

ao de engines OpenSSL.

Uma engine OpenSSL

e um m

odulo de software que permite ao seu de-

senvolvedor substituir as implementac¸

oes padr

oes dos algoritmos existentes. As engines

podem implementar um ou mais algoritmos e s

ao classiﬁcadas de est

aticas ou din

amicas.

As engines est

aticas s

ao integradas e compiladas com o c

odigo fonte do

OpenSSL, tornando-as parte do pacote criptogr

aﬁco. Elas s

ao automaticamente carrega-

das sempre que o OpenSSL

e referenciado. Por outro lado, as engines din

amicas podem

ser carregadas em tempo de execuc¸

ao, sem necessitar nenhuma alterac¸

ao na vers

ao ori-

ginal do OpenSSL. Uma engine din

amica

e gerada da mesma forma que uma biblioteca

din

amica, sendo normalmente identiﬁcada pela extens

ao .so no Unix

e .dll no Microsoft

Windows

Internamente, o OpenSSL deﬁne uma engine como uma estrutura cha-

mada EN GIN E, que contem os seguintes campos:

Sistema operacional de software livre.

Sistema operacional da Microsoft Corporation.

• id: identiﬁca unicamente uma engine no OpenSSL. Tanto a aplicac¸

ao de linha de

comando quanto a biblioteca utilizando este campo como refer

encia;

• name: tem somente papel descritivo;

• rsa meth, dsa meth, dh method, ecdsa meth, ecdh meth e rand meth: estru-

tura deﬁnindo os ponteiros das func¸

oes respons

aveis pelo manuseio do algoritmo

em quest

ao (RSA, DSA, DH, ECDSA, ECDH ou func¸

oes de aleatoriedade). Por

exemplo, o campo rand meth cont

em os ponteiros para func¸

oes capazes de gerar

dados rand

omicos e pseudorand

omicos, adicionar entropia, carregar o estado do

gerador, entre outros;

• ciphers e digests: diferentemente dos algoritmos anteriores, onde cada algoritmo

possuia uma estrutura pr

opria, os algoritmo sim

etricos e func¸

oes de resumo pos-

suem o ponteiro para apenas uma func¸

ao cada;

• init e f inish: func¸

oes de inicializac¸

ao e ﬁm da execuc¸

ao da engine. Servem para

a engine criar e preparar as estruturas internas necess

arias para seu funcionamento.

Por exemplo o estabelecimento da conex

ao com um HSM.

• destroy: func¸

ao chamada antes de remover a engine da lista de engines do

OpenSSL. Deve ser utilizada para liberar qualquer tipo de mem

oria alocada, como

por exemplo a descarga de suas mensagens de erros do sistema de erro do OpenSSL;

• ctrl: ponteiro para uma func¸

ao capaz de interpretar os par

ametros necess

arios pela

engine. Por exemplo o enderec¸o IP de um HSM conectado na rede;

• load privkey e load pubkey: func¸

ao para carregar chaves p

ublicas e privadas ge-

renciadas atrav

es da engine. O retorno desta func¸

e uma estrutura EV P P KEY ,

que pode ser utilizada para encapsular todas as chaves assim

etricas suportadas pelo

OpenSSL;

• cmd def ns: deﬁne os comandos aceitos e interpretados por ctrl. Cada co-

mando cont

em um identiﬁcador (que deve iniciar com o valor da constante

EN GIN E CMD BASE, seguindo com ENGINE CMD BASE + 1, ...),

nome do commando, sua descric¸

ao e o tipo do valor de entrada esperado. Os

poss

ıveis tipos de respostas s

ao: num

erico ou texto. Os comandos ainda podem

ao necessitar nenhuma entrada ou at

e mesmo ser marcado para uso interno;

• struct ref e f unct ref : utilizado pelo OpenSSL para controle do n

umero de re-

fer

encias

a estrutura e ao conjunto de func¸

oes de uma engine. Garante a utilizac¸

da engine em v

arias partes do aplicac¸

ao, evitando, por exemplo, a inicializac¸

ao de

uma engine j

a inicializada;

• outros: par

ametros utilizados para controle interno, como prev e next, que mant

uma lista duplamente encadeada das engines dispon

ıveis, ex data, utilizada para

armazenamento de dados referente a engine e f lags, que deﬁne suas caracter

ısticas.

Algumas peculiaridades devem ser levadas em conta no desenvolvi-

mento de uma engine OpenSSL para a utilizac¸

ao de chaves gerenciadas por um HSM.

Primeiramente, o que fazer com a func¸

ao loadprivkey, j

a que n

ao se quer carregar a chave

privada na mem

oria da m

aquina hospedeira, n

ao faria o m

ınimo sentido utilizar uma HSM

para proteger o ciclo de vida de chaves criptogr

aﬁcas e deix

a-la em aberto desta forma.

Uma abordagem comum para resolver esse problema

e retornar a chave p

ublica nas duas

func¸

oes loadprivkey e loadpubkey. Em um primeiro momento pode parecer estranho,

mas isso

e poss

ıvel porque al

em de o OpenSSL utilizar uma

unica estrutura para repre-

sentar chaves p

ublicas e privadas de um mesmo algoritmo, ser

a a engine que ir

a executar

as operac¸

oes sobre essa chave. Portanto, toda vez que uma operac¸

ao com a chave privada

for realizada, a pr

opria engine ser

a chamada e a chave privada correta pode ser identiﬁ-

cada baseado na chave p

ublica, utilizando seus valores p

ublicos (n

umeros primos n e e)

ou atrav

es do identiﬁcador da chave explicitamente armazenado na vari

avel exdata, que

como na engine, existe tamb

em nas estruturas de chaves.

Adicionalmente, a estrutura de chaves criptogr

aﬁcas da biblioteca pos-

sui um atributo chamado engine, que aponta para a engine respons

avel por realizar as

operac¸

oes criptogr

aﬁcas da chave. Portanto, ap

os a carga da chave atr

aves das func¸

oes

l oad privkey e load pubkey, deve-se substituir o valor deste atributo pela engine atual.

Conceitualmente falando, a diferenc¸a entre uma cifragem assim

etrica

e uma assinatura est

a na chave que

e utilizada na operac¸

ao, chave p

ublica no primeiro

caso e chave privada no segundo, e tamb

em na informac¸

ao sobre a qual a ac¸

e rea-

lizada, no

ultimo caso o resultado de uma func¸

ao de resumo. Sabendo disso, o

ultimo

ponto relevante na implementac¸

ao de uma engine est

a na estrutura de operac¸

oes RSA

(RSA M ET HOD). Ela possui basicamente 6 func¸

oes:

• rsa pub enc: cifragem utilizando uma chave p

ublica;

• rsa priv dec: decifragem utilizando uma chave privada;

• rsa priv enc: cifragem utilizando uma chave privada;

• rsa pub dec: decifragem utilizando uma chave p

ublica;

• rsa sign: gerac¸

ao de assinaturas;

• rsa verif y: veriﬁcac¸

ao de assinaturas;

Como pode ser observado, as func¸

oes rsa priv enc e rsa sign pos-

suem a mesma ﬁnalidade de gerac¸

ao de assinaturas, o que acontence com rsa pub dec e

rsa verif y tamb

em. Uma engine n

ao deve implementar estas quatro func¸

oes, e sim es-

colher o conjunto que preferir. O ponto chave aqui

e utilizar o campo f lags da estrutura

das chaves RSA para marcar qual o conjunto de func¸

oes que deve ser acionado. Se a ﬂag

RSA F LAG SIGN V ER estiver conﬁgurada, as func¸

oes rsa sign e rsa verif y ser

utilizadas. As quatro func¸

oes ainda existem por uma quest

ao de compatibilidade com

vers

oes anteriores do OpenSSL, sendo por padr

ao utilizado rsa privenc e rsa pub dec,

apesar de rsa sign e rsa verify serem mais novas.

4.6 OpenSSL FIPS 140-2 n

ıvel 1

O OSSI[37] (Open Source Software Institute

), entidade sem ﬁns lu-

crativos, em conjunto com o n

ucleo de desenvolvimento do OpenSSL preparou e subme-

Instituto de Software de C

odigo Aberto em traduc¸

ao literal

teu a biblioteca do OpenSSL para avaliac¸

ao nos requisitos da FIPS 140-2, alcanc¸ando a

certiﬁcac¸

ao da vers

ao 1.0 do OpenSSL FIPS em marc¸o de 2006[38].

O OpenSSL FIPS 1.0 submetido a certiﬁcac¸

ao cont

em um conjunto li-

mitado de func¸

oes do OpenSSL 0.9.7 e sua utilizac¸

ao por um aplicac¸

ao difere-se um

pouco do usual. O c

odigo do OpenSSL FIPS deve ser compilado para gerar o c

odigo

objeto e esse c

odigo objeto deve ser estaticamente ligado

no processo de compilac¸

do c

odigo fonte da aplicac¸

ao. A biblioteca criptogr

aﬁca do OpenSSL tamb

em deve ser

ligada na aplicac¸

ao, podendo esta ser est

atica ou din

amica.

Os desenvolvedores do OpenSSL FIPS implementaram v

arias t

ecnicas

para veriﬁcac¸

ao de integridade nas v

arias etapas que o m

odulo pode assumir, com che-

cagens autom

aticas do c

odigo fonte durante a compilac¸

ao, no c

odigo objeto durante a

ligac¸

ao e no c

odigo execut

avel quando o modo FIPS do m

odulo

e ativado. Durante a

ativac¸

ao do modo FIPS, atrav

es da func¸

ao F IP S mode set, os auto-testes s

ao iniciados

e todos devem obrigatoriamente passar. Uma vez em modo FIPS, somente operac¸

oes de

algoritmos aprovados podem ser executadas. A tabela 4.2 cont

em os algoritmos crip-

togr

aﬁcos aprovados na vers

ao FIPS do OpenSSL.

Tabela 4.2: Algoritmos Criptogr

aﬁcos Aprovados no OpenSSL FIPS vers

ao 1.1.2

Tipo de Algoritmo Algoritmos

Assim

etrico RSA

Sim

etrico 3DES (nos modos: CBC, CFB8, CFB64, ECB e OFB)

AES de 128, 192 or 256 bits (nos modos CBC, CFB8, CFB128,

ECB e OFB)

HMAC HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-

SHA-384 e HMAC-SHA-512

Func¸

oes de resumo SHA-1, SHA-224, SHA-256, SHA-384 e SHA-512

RNG ANSI X9.31[39]

Em junho de 2006, o certiﬁcado da vers

ao 1.0 foi suspenso, porque

identiﬁcou-se que func¸

oes cr

ıticas n

ao estavam implementadas dentro do per

ımetro de

seguranc¸a. Ap

os as alterac¸

oes necess

arias, submeteu-se uma nova vers

ao, 1.1, mas a

processo de associac¸

ao dos v

arios c

odigos objetos com o objetivo de resolver pend

encias externas,

gerando o c

odigo execut

avel

reativac¸

ao do certiﬁcado nunca ocorreu. A vers

ao foi alterada de 1.1 para 1.1.1 e subme-

tida a um novo processo de certiﬁcac¸

ao.

A vers

ao 1.1.1[40], aprovada em 06/02/2007, foi revogada em

30/11/2007 por dois problemas no gerador de n

umeros aleat

orios: um bug no auto-teste

cont

ınuo e uma vulnerabilidade no processo de inclus

ao de sementes. Uma nova vers

do c

odigo, 1.1.2, com essas deﬁci

encias sanadas, foi novamente submetida a certiﬁcac¸

ao,

por

em, no meio do processo, os requisitos dos auto-testes para operac¸

oes DSA mudou de

512 bits para a utilizac¸

ao de chaves de 1024 bits. Para evitar mais atrasos, o algoritmo

DSA foi retirado do processo de certiﬁcac¸

ao, diminuindo o n

umeros de algoritmos apro-

vados. A alterac¸

ao do auto-teste do DSA de 512 para 1024 bits era realmente simples,

mas signiﬁcaria o rein

ıcio do processo de certiﬁcac¸

ao, uma vez que o c

odigo fonte iria

sofrer alterac¸

oes.

A vers

ao 1.1.2 recebeu a certiﬁcac¸

ao em 6 de fevereiro de 2008[41].

Uma nova vers

ao, 1.2, j

a est

a em processo de desenvolvimento e ser

a baseada na vers

0.9.8 do OpenSSL.

4.7 Conclus

O OpenSSL

e uma ferramenta de criptograﬁa com suporte a um grande

umero de algoritmos criptogr

aﬁcos. Seus v

arios anos de desenvolvimento e testes rea-

lizados por muitos usu

arios ao redor do mundo passam credibilidade quanto a qualidade

dos resultados obtidos. Al

em disso, alguns de seus algoritmos criptogr

aﬁcos fazem parte

do OpenSSL FIPS, que possui certiﬁcac¸

ao FIPS 140-2 n

ıvel 1.

Por outro lado, sua documentac¸

e um tanto deﬁciente, deixando de-

senvolvedores sem muitas alternativas de aux

ılio. As principais fontes de informac¸

oes

acabam sendo seu c

odigo fonte e suas listas de discuss

ao, que est

ao dispon

ıveis na p

agina

do projeto.

As engines OpenSSL permitem a integrac¸

ao de aplicativos com

odulos criptogr

aﬁcos, tornando poss

ıvel a utilizac¸

ao de chaves criptogr

aﬁcas geren-

ciadas em um HSM.

E nessa plataforma que o desenvolvimento do ASI-HSM se baseou,

suprindo o requisito de ser compat

ıvel com o sistema de gerenciamento de certiﬁcado

digitais da ICPEDU.

Cap

ıtulo 5

ASI-HSM

5.1 Introduc¸

O projeto ICPEDU II surgiu da necessidade de se criar um m

odulo de

seguranc¸a criptogr

aﬁca com tecnologia brasileira, de c

odigo aberto e de baixo custo, vol-

tado principalmente para a implantac¸

ao da Infra-estrutura de Chaves P

ublicas para Ensino

e Pesquisa (ICPEDU). O HSM fruto deste projeto

e o ASI-HSM.

O ASI-HSM ser

a descrito neste cap

ıtulo, com apresentac¸

ao de sua ar-

quitetura e os componentes necess

arios para sua operacionalizac¸

ao. O protocolo imple-

mentado internamente para a gest

ao do ciclo de vida de chaves criptogr

aﬁcas

e conhe-

cida como OpenHSM e

e abordado nos cap

ıtulos 6 e 7. Os protocolos e algoritmos

do OpenHSM foram concebidos para serem embarcados em hardware criptogr

aﬁco que

provesse os mecanismos de protec¸

ao conforme estabelece os requisitos apresentados no

Cap

ıtulo 3. A arquitetura do ASI-HSM

e descrita na Sec¸

ao 5.2.

O HSM pode ser visto como um sistema provedor de servic¸os crip-

togr

aﬁcos. Para poder utiliz

a-lo a partir de uma aplicac¸

ao numa m

aquina hospedeira,

necess

ario uma interface de comunicac¸

ao. A interface escolhida para o ASI-HSM foi

a ”engine”do OpenSSL, descrito no Cap

ıtulo 4. A interface do prot

otipo

e descrita na

Sec¸

ao 5.4.

em deste canal de comunicac¸

ao para acesso aos servic¸os, foi proje-

tado um sistema de gest

ao remota do HSM, que

e executado na m

aquina hospedeira, para

realizar a conﬁgurac¸

ao, administrac¸

ao, operac¸

ao e auditoria do material criptogr

aﬁco pro-

tegido pelo HSM e gerenciado pelo OpenHSM. Este sistema

e apresentado na Sec¸

ao 5.3.

5.2 Arquitetura

O ASI-HSM

e composto por uma s

erie de componentes de hardware

e software, que cooperam entre si com o intuito de proteger, gerenciar e monitorar os

recursos e servic¸os dispon

ıveis no mesmo. A ﬁgura 5.1 apresenta uma vis

ao geral da

arquitetura do m

odulo

Figura 5.1: Vis

ao geral da arquitetura do HSM da GT ICPEDU II

Na parte interna ao per

ımetro criptogr

aﬁco, o m

odulo conta com dois

componentes principais: a Unidade de Seguranc¸a e a Unidade Gestora.

editos pela ﬁgura para Juliano Romani

A Unidade de Seguranc¸a (US), dispositivo desenvolvido especiﬁca-

mente para monitorar o funcionamento do m

odulo, conta com uma s

erie de sensores

que visam a detecc¸

ao de qualquer tentativa de violac¸

ao ou risco de comprometimento da

seguranc¸a por inﬂu

encia de fatores externos, sendo qualquer comportamento inesperado

registrado no sistema de registros interno

a US. O m

odulo emprega sensores de tens

ao,

temperatura, luminosidade e detecc¸

ao de intrus

ao f

ısica, sendo o

ultimo provido atrav

es de

uma malha de circuitos que envolve o per

ımetro criptogr

aﬁco. Al

em disso,

e dentro dessa

unidade que ﬁcam o gerador de n

umeros aleat

orios (PNG) e o rel

ogio de alta-estabilidade,

usado no processo de gerac¸

ao dos pares de chaves gerenciados pelo m

odulo e controle de

tempo interno, respectivamente.

A Unidade Gestora (UG) consiste de um conjunto de software/hardware

respons

avel por hospedar as aplicac¸

oes e dados referentes

a execuc¸

ao do m

odulo, como

por exemplo, as ferramentas e bibliotecas que comp

oem o OpenSSL, bem como as chaves

gerenciadas pelo m

odulo.

Operando sobre a UG est

ao as aplicac¸

oes envolvidas na ger

encia do ci-

clo de vida das chaves privadas do HSM (OpenHSMd), bem como a mem

oria persistente

do m

odulo, uma Compact Flash (CF), respons

avel por armazenar os dados relacionados

a conﬁgurac¸

ao do HSM, as chaves sim

etricas e assim

etricas, certiﬁcados, entre outras

informac¸

oes

uteis ao funcionamento do HSM. Ainda na mem

oria ﬂash, encontra-se a

vers

ao customizada do sistema operacional FreeBSD embarcada para gerenciamento da

soluc¸

ao como um todo.

A comunicac¸

ao com o mundo externo est

a restrito a duas portas f

ısicas,

uma porta de rede e uma porta USB. A porta de rede

e utilizada para gerenciamento do

HSM, atrav

es dos aplicativos de administrac¸

ao remota (sec¸

ao 5.3), e para uso das chaves

gerenciadas, atrav

es de uma engine OpenSSL (sec¸

ao 5.4). Na porta USB conecta-se o

leitor de smartcards utilizado nos processos de criac¸

ao e autenticac¸

ao dos usu

arios do

odulo.

5.3 Aplicativos de Administrac¸

ao Remota

O gerenciamento do HSM

e realizado atrav

es de dois aplicativos de

administrac¸

ao remota: interface texto (linha de comando) e interface gr

aﬁca. Ambas tem

o mesmo conjunto de func¸

oes e comandos e se conectam ao HSM atrav

es de um canal

seguro de comunicac¸

ao, t

unel SSL.

A interface texto, uma vez conectada ao HSM, prov

e um ambiente no

mesmo estilo linha de comando do OpenSSL, aonde comandos podem ser executados

com seus respectivos par

ametros e opc¸

oes, sendo que todas as func¸

oes possuem sua

documentac¸

ao de f

acil acesso na pr

opria interface.

E uma forma eﬁciente e eﬁcaz de

obter a informac¸

ao requerida. A ﬁgura 5.2 apresenta um exemplo da interface texto co-

nectada ao HSM.

Figura 5.2: Interface texto para administrac¸

ao remota do HSM do GT ICPEDU II

Por outro lado, a interface gr

aﬁca, desenvolvida em Java

e rica em

detalhes com componentes ativos que se atualizam baseados na conﬁgurac¸

ao atual do

HSM. Outro ponto forte dessa interface

e sua portabilidade. A ﬁgura 5.3 apresenta um

exemplo da interface gr

aﬁca conectada no HSM.

As duas aplicac¸

oes de administrac¸

ao remota do m

odulo s

ao internacio-

nalizadas, suportando atualmente os idiomas ingl

es e portugu

es.

linguagem de programac¸

ao, dispon

ıvel em http://java.sun.com/

Figura 5.3: Interface gr

aﬁca para administrac¸

ao remota do HSM do GT ICPEDU II

5.4 Engine OpenSSL

Um m

odulo criptogr

aﬁco deve prover uma API de integrac¸

ao que per-

mita a uma aplicac¸

ao utilizar suas chaves criptogr

aﬁcas gerenciadas. Essa API pode

seguir um padr

ao j

a estabelecido, como por exemplo PKCS#11, CryptoAPI, Engine

OpenSSL, ou ser uma interface pr

opria do fabricante do HSM.

A escolha da API de integrac¸

ao adequada levou em considerac¸

ao dois

principais fatores: grau de complexidade de implementac¸

ao e o n

umero de aplicativos

afetados. Desta forma, os servic¸os criptogr

aﬁcos do HSM s

ao providos atrav

es de uma

engine OpenSSL, que pode ser carregada de forma est

atica ou din

amica. O m

odulo prov

as seguintes funcionalidades atrav

es desta engine:

• operac¸

oes sobre chaves privadas RSA: permite o uso das chaves criptogr

aﬁcas ge-

renciadas pelos HSM;

• gerador de n

umeros aleat

orios: este servic¸o utiliza o gerador de n

umeros aleat

orios

dispon

ıvel na unidade de seguranc¸a.

5.5 Conclus

Este cap

ıtulo apresentou a arquitetura e os principais componentes do

HSM desenvolvido no projeto ICPEDU II, o ASI-HSM. Este desenvolvimento, que pare-

cia distante devido a falta de documentac¸

ao e publicac¸

oes existente no mundo acad

emico,

por serem normalmente guardadas a sete chaves por empresas comerciais, se mostrou to-

talmente vi

avel e os objetivos do projeto foram alcanc¸ados, sendo concebido utilizando

apenas software livre.

Os pr

oximos dois cap

ıtulos ir

ao descrever em detalhes o protocolo

de gerenciamento do ciclo de vida de chaves criptogr

aﬁcas utilizados no ASI-HSM, o

OpenHSM.

Cap

ıtulo 6

OpenHSM - Operacionalizac¸

O OpenHSM

e um protocolo para gerenciamento completo do ciclo

de vida de chaves criptogr

aﬁcas de HSMs. O foco principal deste protocolo

e suprir

as necessidades encontradas na implantac¸

ao de infra-estruturas de chaves p

ublicas, tais

como rastreabilidades de chaves e com operac¸

oes totalmente audit

aveis.

O gerenciamento do ciclo de vida de chaves criptogr

aﬁcas de forma

segura

e o objetivo de qualquer HSM, sendo que este objetivo pode levar um longo

tempo de maturac¸

ao at

e ser plenamente alcanc¸ado. Sabendo disso, este cap

ıtulo apre-

senta o protocolo do OpenHSM, que foi primeiramente apresentado em uma dissertac¸

de mestrado[4] defendida em 2005 e vem sendo aprimorado em v

arias ocasi

oes, tais como

trabalhos de conclus

ao de curso[3], outras dissertac¸

oes e artigos[5][6]. Apesar disso, o

conjunto destas publicac¸

oes n

ao apresenta de forma coerente todos os sub-protocolos do

OpenHSM.

As mudanc¸as nos sub-protocolos do OpenHSM, al

em de estruturais,

tamb

em ocorreram na forma de sua representac¸

ao, com o objetivo descrev

e-los formal-

mente. A descric¸

ao formal

e o primeiro passo para poder-se realizar a veriﬁcac¸

ao formal

da corretude dos protocolos. As alterac¸

oes e aprimoramentos estruturais s

ao relativos aos

protocolos de criac¸

ao e recuperac¸

ao de c

opias de seguranc¸a do material criptogr

aﬁco, que

ao descritos no Cap

ıtulo 7.

6.1 Aspectos Gerais

Esta sec¸

ao apresenta as deﬁnic¸

oes e caracter

ısticas inerentes aos proto-

colos do OpenHSM, de forma a ajudar na compreens

ao dos mesmos. Al

em disso, dois

sub-protocolos, que tamb

em dar

ao suporte para as pr

oximas sec¸

oes, ser

ao abordados: a

criac¸

ao e a autenticac¸

ao de grupos de usu

arios.

O conjunto de deﬁnic¸

oes e caracter

ısticas utilizadas no protocolo

OpenHSM s

ao:

• Uma vez inicializado, o HSM gera um par de chaves assim

etricas kr

e ku

, pos-

sibilitando a emiss

ao de um certiﬁcado auto-assinado c

. Esta autoridade certiﬁca-

dora interna deﬁne o elemento central de conﬁanc¸a do HSM, a partir do qual todos

os certiﬁcados de seus membros ser

ao gerados;

• O protocolo deﬁne 3 diferentes grupos de usu

arios: administradores, auditores e

operadores;

• Cada tipo de grupo suportado pelo HSM possui um sistema de armazenamento

(DS) diferente. Sendo o dos administradores ADS, operadores ODS e auditores

AudDS. Os dados enviados para esses sistemas s

ao armazenados sem nenhum tipo

adicional de criptograﬁa;

• Cada grupo no HSM possui um identiﬁcador, sendo este

unico em grupos do mesmo

tipo. Entretanto, existe apenas um grupo de administradores v

alido para um dado

momento, com o identiﬁcador ADM sempre apontando para o grupo corrente.

• Todos os grupos s

ao submetidos ao esquema de segredo compartilhado[42], onde

a chave sim

etrica do grupo ks,

e dividida em n partes das quais k s

ao necess

arias

para recuperar ks. Os limiares seguem a seguinte regra: 1 ≤ k ≤ n. Um conjunto

de partes de um segredo

e representado por Ks;

• Durante a criac¸

ao de um grupo no HSM, cada membro recebe um par de chaves

assim

etricas, kr

e ku

, al

em de um certiﬁcado emitido pela AC interna do HSM,

. Esse material

e ent

ao armazenado no smartcard do membro e ser

a utilizado

novamente durante sua autenticac¸

ao;

• Cada parte do segredo compartilhado do grupo, ks

, passa a representar um de seus

membros, sendo sua chave p

ublica utilizada para cifrar sua parte do segredo antes

que este seja armazenado no HSM. Este

e o material que ser

a decifrado durante o

processo de autenticac¸

ao do grupo;

• O sistema de armazenamento de dados n

ao-export

aveis, N XD,

e um sistema de

armazenamento como qualquer outro, diferenciando-se somente porque na criac¸

de uma c

opia de seguranc¸a do HSM, os dados nele contidos n

ao s

ao copiados;

• A interac¸

ao dos membros dos grupos com o HSM

e feito atrav

es de um computador

diretamente conectado, referenciado por hm.

Os protocolos do OpenHSM, dada sua complexidade e quantidade de

passos, ser

ao descritos aqui na forma de algoritmos. Esta mudanc¸a na sua forma de

representac¸

e justiﬁcada pelos coment

arios recebidos nas publicac¸

oes citadas anterior-

mente, garantindo legibilidade e melhor entendimento.

O processo de criac¸

ao de grupos do HSM permanece igual independente

do seu tipo, sendo abordado aqui e referenciado posteriormente quando for necess

ario. A

execuc¸

ao do algoritmo createGroup requer alguns par

ametros, entre eles os dados sobre

o novo grupo, como: identiﬁcador (id) e limiares (k e n), o sistema de armazenamento

referente ao tipo de grupo a ser criado, DS, e por ﬁm a chave privada e o certiﬁcado do

HSM (kr

e c

A execuc¸

ao inicia com a gerac¸

ao da chave sim

etrica do grupo ks no

passo 1. A chave

e ent

ao submetida ao esquema de compartilhando de segredo, utilizando

n como o n

umero total de partes e k o n

umero m

ınimo de partes para reconstruir ks,

resultando no conjuntos de partes da chave Ks.

No passo 3, inicia-se o processo de criac¸

ao dos membros, que deve ser

executado n vezes, at

e que todos os membros do grupo estejam criados. No passo 4, o par

Um sum

ario das descric¸

oes das vari

aveis e func¸

oes est

a dispon

ıvel no ap

endice A

Algoritmo createGroup(DS, id, k, n, c

, kr

)

Cria um grupo utilizando o esquema de compartilhamento de segredo, gerando um

par de chaves (kr

e ku

) e um certiﬁcado (c

) para cada membro do grupo (s

). Os

certiﬁcados dos membros s

ao assinados pela chave privada do HSM kr

. O certiﬁ-

cado de cada membro inclui seu nome e informac¸

oes requisitadas durante o processo

de criac¸

ao dos membros. O token criptogr

aﬁco de cada membro ct

e utilizado para

armazenar seus objetos criados no processo, c

e kr

. A chave sim

etrica do grupo ks,

que foi compartilhada em n partes,

e retornada como resultado do algoritmo.

1: ks ← genSessionKey()

2: Ks ← splitSecret( ks, k, n )

3: for ks

in Ks do

4: (kr

, ku

) ← genKeyPair()

5: id

← load( hm, s

)

6: c

← genCert( id

, ku

, c

, kr

)

7: store( ct

, kr

, c

)

8: eks

← encrypt( ks

, c

)

9: store( DS, id, c

, eks

)

10: end for

11: store( DS, id, k, n )

12: return ks

de chaves do membro

e gerado, kr

e ku

. Na seq

encia, o nome do membro

e solicitado

a m

aquina hospedeira, informac¸

ao que ser

a utilizada para emitir o seu certiﬁcado c

passo 6. Uma vez que o certiﬁcado est

a gerado, kr

, c

e c

pode ser armazenado no token

criptogr

aﬁco do membro.

Continuando, uma das partes do segredo do grupo ks

e cifrada com

o certiﬁcado do membro c

(seu certiﬁcado possui sua chave p

ublica). E ﬁnalmente, no

passo 9, com todos os procedimentos para o membro ﬁnalizados, seus dados s

ao arma-

zenados em DS. Salientando que a chave privada do membro kr

e armazenada,

preservando sua caracter

ıstica principal de privacidade.

No passo 11 os dados referentes ao grupo s

ao armazenados. E ﬁnal-

mente, no passo 12, a chave sim

etrica do grupo

e retornada.

Outro algoritmo que permanece igual independente do tipo (grupo)

e a

autenticac¸

ao de um grupo authenticGroup. O processo requer o sistema de armazena-

mento e o identiﬁcador referentes ao grupo a ser autenticado.

O algoritmo authenticGroup inicia carregando k do grupo identiﬁcado

Algoritmo authenticGroup( DS, id )

Autentica um grupo do HSM identiﬁcado por id no sistema de armazenamento DS.

Os certiﬁcados dos membros c

a serem autenticados s

ao lidos de seus tokens crip-

togr

aﬁcos ct

, identiﬁcando-o e possibilitando a decifragem da parte do segredo do

grupo referente ao membro.

E necess

ario que k membros sejam autenticados para

recuperar o segredo do grupo ks.

1: k ← load( DS, id )

2: for i = 1 to k do

3: c

← load( ct

)

4: eks

← load( DS, id, c

)

5: u ← genSessionKey()

6: euks

← encrypt( u || eks

, c

)

7: eks

← ctDecrypt(ct

, euks

)

8: ks

← decrypt( eks

, u )

9: end for

10: ks ← joinSecret( Ks )

11: return ks

por id do sistema de armazenamento DS. No passo 2, inicia-se a iterac¸

ao para autenticar

os k membros do grupo, k foi deﬁnido no processo de sua criac¸

ao e deﬁne o n

umero

ınimo de membros que precisam ser autenticados para permitir a reconstruc¸

ao do se-

gredo do grupo.

As operac¸

oes entre os passos 2 e 9 ser

ao realizadas k vezes, at

e ser

poss

ıvel recuperar o segredo do grupo. No passo 3 carrega-se do token criptogr

aﬁco do

membro seu certiﬁcado c

, objeto necess

ario para, no passo 4, identiﬁcar no D S a parte

do segredo cifrado do membro eks

Os pr

oximos dois passos, 4 e 5, s

ao necess

arios para evitar o ataque de

replay do Dolev-Yao[43], gerando u e recifrando seu valor concatenado a eks

, resultando

em euks

. Este

ultimo ent

e enviado ao token criptogr

aﬁco do membro para decifragem,

liberado u e ks

. Antes de retorn

a-los ao HSM, o token cifra ks

com u. Como u

conhecido pelo HSM, o valor de ks

e recuperado no passo 8.

Finalmente no passo 10, recupera-se a chave sim

etrica do grupo k s a

partir do conjunto de partes decifradas nos passos anteriores. O algoritmo termina retor-

nando o valor de ks.

6.2 Inicializac¸

ao do HSM e criac¸

ao do grupo de Admi-

nistradores

Este

e o primeiro passo na preparac¸

ao de um ambiente para gerencia-

mento do ciclo de vida de chaves privadas. Este algoritmo ir

a realizar a criac¸

ao da auto-

ridade certiﬁcadora raiz interna e do grupo de administradores do HSM, estabelecendo,

respectivamente, seu ponto de conﬁanc¸a e o grupo respons

avel por suas operarac¸

oes ad-

ministrativas.

O HSM, como apresentado nos aspectos gerais, possui apenas um grupo

de administradores v

alido para um determinado momento no tempo, sendo que esse grupo

pode ser alterado a qualquer momento utilizando o algoritmo changeAdmGroup descrito

na sec¸

ao 6.7.

O algoritmo

e disparado com a especiﬁcac¸

ao dos valores de k e n, res-

pectivamente o n

umero m

ınimo de membros para autenticar o grupo e seu n

umero total

de membros.

Algoritmo createAdm( k, n )

Inicializa o HSM, criando a AC interna que servir

a de ponto de conﬁanc¸a para suas

operac¸

oes. O grupo de administradores tamb

e criado.

1: kr

, ku

← genKeyPair()

2: c

← genSelfSignedCert( kr

, ku

, id )

3: ks

← createGroup( ADS, ADM , k, n, c

, kr

)

4: ekr

← encrypt( kr

, ks

)

5: store( ADS, c

, ekr

)

6: store( CT L, c

)

7: return c

No primeiro passo, o par de chaves assim

etricas do HSM, kr

e ku

e gerado e a partir dele o certiﬁcado auto-assinado do HSM

e emitido. Estes s

ao os

componentes necess

arios para criar o grupo de administradores no passo 3. Como j

explicado anteriormente, a criac¸

ao de um grupo do HSM

e gen

erica e permanece a mesma

para todos os tipos de grupos. A chave sim

etrica do grupo de administradores ks

retornada como resultado. Essa chave

e utilizada para cifrar a chave privada do HSM no

passo 4, gerando ekr

e o passo 4, todos as operac¸

oes necess

arias para a inicializac¸

ao e

criac¸

ao dos administradores foram ﬁnalizadas, restando apenas armazenar todos os com-

ponentes rec

em criados, o que permitir

a a execuc¸

ao da pr

oxima etapa do processo de

tornar o HSM operacional, a criac¸

ao de um grupo de auditores.

Ent

ao, no passo 5 o certiﬁcado do HSM e sua chave privada cifrada

ao armazenados no sistema de armazenamento de administradores e o passo 6 adiciona

o certiﬁcado auto-assinado c

na lista de certiﬁcados conﬁ

aveis CT L, estabelecendo o

ponto de conﬁanc¸a do HSM.

Finalmente, c

e retornado para a m

aquina hospedeira que iniciou a

execuc¸

ao do algoritmo, o que identiﬁca unicamente o HSM.

6.3 Criac¸

ao de um grupo de Auditores

Apesar de n

ao existir restric¸

ao criptogr

aﬁca que impec¸a a criac¸

ao de um

grupo de operadores diretamente ap

os a inicializac¸

ao do HSM, o protocolo do OpenHSM

deﬁne que a criac¸

ao de um grupo de auditores seja obrigatoriamente o segundo passo

para criar um HSM operacional, de forma a garantir que o processo de auditoria possa ser

realizado antes mesmo de uma chave ser criada ou at

e utilizada.

Tratando-se de uma operac¸

ao administrativa, o grupo de administrado-

res do HSM

e autenticado nos primeiros passos do algoritmo, permitindo a reconstruc¸

de sua chave s

ımetrica, possibilitando a decifragem da chave privada do HSM.

Cada grupo de auditores recebe um par de chaves assim

etrica que ser

utilizado para assinar os registros do HSM que ser

ao exportados pelo grupo. Outros pares

de chaves n

ao podem ser associados a um grupo de auditores, como acontece aos grupos

de operadores, mas este

e assunto das pr

oximas sec¸

oes.

O algoritmo requer os valores de k e n para o novo grupo de auditores,

como acontece na criac¸

ao do grupo de administradores, e um identiﬁcador para o grupo

id, sendo que este deve identiﬁcar unicamente o grupo dentro do conjunto de grupos de

auditores.

O algoritmo comec¸a autenticando o grupo de administradores do sis-

Algoritmo createAudGroup(id, k, n)

os a autenticac¸

ao dos administradores do HSM,

e criado um novo grupo de audi-

tores identiﬁcado por id. A chave sim

etrica desse grupo

e submetida ao mecanismo

de compartilhamento de segredo, utilizando os limiares k e n. Adicionalmente, um

par de chaves assim

etricas

e associado ao grupo rec

em criado.

1: ks

← authenticateGroup( ADS, ADM )

2: c

, ekr

← load( ADS )

3: kr

← decrypt( ekr

, ks

)

4: ks

← createGroup( AudDS, id, k, n, c

, kr

)

5: kr

, ku

← genKeyPair()

6: c

← genCert( id, ku

, c

, kr

)

7: ekr

← encrypt( kr

, ks

)

8: store( AudDS, id, c

, ekr

)

9: return c

tema, especiﬁcando o sistema de armazenamento dos administradores ADS e o iden-

tiﬁcador do grupo ADM . Como deﬁnido nas premissas, o HSM possui apenas um

grupo v

alido de administradores para um determinando periodo de tempo e o identiﬁ-

cador ADM sempre aponta para o grupo atual.

O segundo e terceiro passo visam acessar a chave privada do HSM,

carregando-a cifrada de ADS, decifrando em seguida com a chave sim

etrica do admi-

nistradores. Portanto, os tr

es primeiros passos dos algoritmos considerados operac¸

oes

administrativas ser

ao os mesmos, autenticando o grupo de administradores e permitindo

acesso a chave privada do HSM.

No passo 4, o grupo de auditores

e criado utilizando o algoritmo

createGroup previamente deﬁnido, resultando na chave sim

etrica do novo grupo ks

Logo ap

os, um par de chaves criptogr

aﬁcas

e gerado, sendo que um

certiﬁcado utilizando-o ser

a emitido pela AC interna do HSM no passo 6. Este certiﬁ-

cado ser

util para veriﬁcac¸

ao da integridade dos registros exportados do HSM, atrav

do algoritmo abordado na sec¸

ao 6.10. Posteriormente, no passo 7, a chave privada dos

auditores

e cifrada com ks

, garantindo conﬁdencialidade da mesma.

Finalmente, o certiﬁcado e a chave privada cifrada do novo grupo po-

dem ser armazenados no sistema de armazenamento de auditores, identiﬁcados por id, no

passo 8. O certiﬁcado do grupo de auditores

e retornado como resultado da execuc¸

ao do

algoritmo.

6.4 Criac¸

ao de um grupo de Operadores

Os grupos de operadores no protocolo do OpenHSM det

em a responsa-

bilidade de liberac¸

ao para uso das chaves gerenciadas de um HSM, podendo cada grupo

ter nenhuma ou v

arias chaves associadas. Deﬁnido como uma tarefa administrativa, o

processo de criac¸

ao de um grupo de operadores requer a autenticac¸

ao do grupo de admi-

nistradores.

A peculiaridade neste tipo de grupo

e a exist

encia de um link com o

grupo de administradores, habilitando este

ultimo a realizar operac¸

oes sobre um grupo de

operadores. Este link, por exemplo, permite aos administradores do HSM associar novas

chaves ao grupo de operadores como tamb

em desassoci

a-las.

Os par

ametros necess

arios para criar um grupo de operadores s

ao os

mesmos requeridos no criac¸

ao de um grupo de auditores, com o identiﬁcador do novo

grupo id e os limiares para o esquema de segredo compartilhado k e n.

Algoritmo createOperGroup(id, k, n)

Cria um grupo de operadores, autenticando primeiramente o grupo de administrado-

res. O ponto de conﬁanc¸a do novo grupo em relac¸

ao aos administradores

e estabele-

cido.

1: ks

← authenticateGroup( ADS, ADM )

2: c

, ekr

← load( ADS )

3: kr

← decrypt( ekr

, ks

)

4: ks

createGroup( ODS, id, k, n, c

, kr

)

5: ks

o∗

← genSessionKey()

6: ks

← xor( ks

, ks

o∗

)

7: eks

← encrypt( ks

, c

)

8: store( ADS, id, eks

)

9: store( NXD, id, ks

o∗

)

Os tr

es primeiros passos deste algoritmo s

ao exatamente iguais ao pro-

cesso de criac¸

ao de auditores. Tem o objetivo de autenticar o grupo de administradores e

permitir acesso

a chave privada kr

e ao certiﬁcado c

do HSM.

No passo 4, o novo grupo de operadores

e criado, com sua chave

sim

etrica, ks

, sendo retornada como resultado da execuc¸

ao. Essa chave ser

a utilizada

para cifrar as chaves que forem associadas com esse grupo de operadores.

Os passos seguintes, de 5 a 9, servem para criar o ponto de conﬁanc¸a

dos operadores nos administradores, permitindo a realizac¸

ao de operac¸

oes administrativas

sobre os mesmo. Inicia-se com a gerac¸

ao de uma segunda chave sim

etrica para o grupo

de operadores ks

o∗

. No passo 6, realiza-se a operac¸

ao ou-exclusivo (XOR) entre as duas

chaves sim

etricas do grupo de operadores, resultado em ks

. Uma das propriedades da

func¸

ao de XOR

e sua reversibilidade, isto

e, A ⊕B = C e C ⊕ B = A. Portando, se reali-

zar a operac¸

ao ks

o∗

⊕ks

, o resultado ser

a ks

. Desta forma, o grupo de administradores

pode reconstruir ks

tendo acesso apenas a ks

o∗

e ks

No passo 7, o resultado da operac¸

ao XOR ks

e cifrado com a chave

ublica do HSM, garantindo que s

o quem possui acesso a chave privada do HSM, no caso

o grupo de administradores, poder

a ter acesso a mesma. E por ﬁm, os dados sens

ıveis

para futuras execuc¸

oes s

ao armazenadas nos devidos sistemas de armazenamento, passos

8 e 9.

O valor de ks

o∗

e armazenado em um sistema de armazenamento dife-

rente do utilizado para os dados dos grupo de operadores. A utilizac¸

ao do N XD garante

uma caracter

ıstica importante ao protocolo do OpenHSM, a rastreabilidade das chaves

gerenciadas. Durante o procedimento de backup do HSM, coberto no cap

ıtulo 7, o NXD

e copiado, resultando que, uma vez recuperado o backup, N XD permanec¸a vazio.

Sem a exist

encia do ponto de conﬁanc¸a dos operadores em relac¸

ao aos administradores,

ao se pode realizar operac¸

oes administrativas sobre os mesmos.

Por isso que, logo ap

os a recuperac¸

ao do backup, o grupo de adminis-

tradores, juntamente com cada grupo de operadores, dever

ao realizar o procedimento de

re-criac¸

ao do ponto de conﬁanc¸a entre os mesmos (sec¸

ao 6.9). Uma vez obrigat

oria a

intervenc¸

ao do grupo de operadores, garante-se que uma chave gerenciada nunca ser

utilizada ou ter

a seu respons

avel trocado sem pr

evio conhecimento.

6.5 Criac¸

ao de Chave Gerenciada

A criac¸

ao de chaves gerenciadas

e uma das operac¸

oes mais importante

em um HSM e pode ser executada logo ap

os a criac¸

ao do primeiro grupo de operadores.

O grupo de administradores precisa ser autenticado e deve existir o ponto de conﬁanc¸a

entre os administradores e o grupo de operadores que ser

a respons

avel pela nova chave.

As chaves, como acontece nos grupos de operadores e auditores, pos-

suem um identiﬁcador

unico dentro no conjunto de chaves gerenciadas, representado por

. Este identiﬁcador ser

a utilizado posteriormente quando o grupo de operadores car-

regar a chave para uso ou quando uma aplicac¸

ao externa realizar operac¸

ao criptogr

aﬁcas

com a chave.

em do identiﬁcador a ser atribu

ıdo a nova chave, o algoritmo de

criac¸

ao de chaves gerenciadas precisa do identiﬁcador do grupo de operadores que ser

respons

avel pela chave id

e, tamb

em, as caracter

ısticas da nova chave, tais como algo-

ritmo e tamanho.

Algoritmo createManagedKey(id

, key params, id

)

Cria um par de chaves, identiﬁcada por id

, para ser gerenciada pelo HSM. Essa nova

chave ter

a as caracter

ısticas deﬁnidas por key params (algoritmo e tamanho) e ser

associada ao grupo de operadores identiﬁcado por id

1: ks

← authenticateGroup( ADS, ADM )

2: c

, ekr

← load( ADS )

3: kr

← decrypt( ekr

, ks

)

4: eks

← load( ADS, id

)

5: ks

← decrypt( eks

, kr

)

6: ks

o∗

← load( NXD, id

)

7: ks

← xor( ks

, ks

o∗

)

8: kr, ku ← genKeyPair( key

arams )

9: ekr ← encrypt( kr, ks

)

10: store( KDS, id

, ekr, ku, id

)

11: return

O algoritmo inicia autenticando o grupo de administradores, com o ob-

jetivo de obter acesso ao certiﬁcado e chave privada do HSM nos tr

es primeiros passos.

Estes passos j

a foram descritos na criac¸

ao de grupo de auditores (vide sec¸

ao 6.3).

No passo 4, baseado no identiﬁcador do grupo de operadores id

carrega-se o resultado da operac¸

ao XOR cifrada do sistema de armazenamento dos ad-

ministradores. Com a chave privada do HSM j

a aberta, pode-se decifrar eks

para ter

acesso a ks

. Logo ap

os carrega-se a segunda chave sim

etrica do grupo de operadores,

o∗

, identiﬁcado por id

. Lembrando que ks

o∗

estabelece o ponto de conﬁanc¸a entre o

grupo de adminitradores e o grupo de operadores.

No passo 7, se faz uso da propriedade de reversibilidade da operac¸

XOR e recupera-se a chave sim

etrica do grupo de operadores ks

. Esta

e a chave que ser

utilizada no passo 9 para cifrar a nova chave gerenciada. O par de chaves assim

etricas

gerado no passo 8 e ent

ao armazenado no KDS no passo 10, juntamente com id

e id

Finalmente, a chave p

ublica rec

em criada

e retornada como resultado do algoritmo.

6.6 Liberando uma Chave Gerenciada para Uso

O gerenciamento do ciclo de vida de chaves privadas deve permitir

em algum momento a utilizac¸

ao destas chaves. A partir do algoritmo detalhado nesta

sec¸

ao,

e poss

ıvel ao grupo de operadores respons

avel por uma chave liber

a-la para uso

por aplicac¸

oes externas.

O HSM autentica o grupo de operadores respons

avel pela chave,

deixando-a carregada na mem

oria vol

atil do sistema sob uma pol

ıtica de uso explicita-

mente deﬁnida.

Essa pol

ıtica pode ser a quantidade m

axima de usos da chave e/ou um

per

ıodo de tempo determinado. Por exemplo, pode-se carregar uma chave para 5 usos em

um prazo de 5 minutos, sendo que a chave

e descarregada assim que a primeira restric¸

expirar.

O algoritmo para liberac¸

ao de uma chave requer o identiﬁcador da chave

key

e a pol

ıtica sob a qual a chave ir

a operar, policy.

O algoritmo carrega no passo 1 os dados da chave id

key

do sistema de

armazenamento de chaves KDS. Entre os dados carregados est

ao o identiﬁcador do

grupo de operadores respons

avel pela chave, id

oper

, e o par de chaves propriamente dito,

ku e ekr, sendo que a chave privada encontra-se cifrada.

Algoritmo loadManagedKey( id

key

, policy )

Carrega uma chave gerenciada identiﬁcada por id

key

no HSM. Primeiramente, o

grupo de operadores respons

avel pela chave

e autenticado. O par

ametro policy deﬁ-

nir

a a pol

ıtica de uso da chave.

1: ekr, ku, id

oper

← load( KDS, id

key

)

2: ks ← authGroup( ODS, id

oper

)

3: kr ← decrypt( ekr, ks )

4: manageKey( id

key

, kr, ku, policy )

5: return( ku )

No passo 2 autentica-se o grupo de operadores, obtendo-se acesso a sua

chave sim

etrica ks, que ser

a utilizada no passo 3 para decifrar ekr.

A chave privada, kr,

e ent

ao submetida ao controlador de chaves carre-

gadas, deﬁnindo id

key

, a pol

ıtica deﬁnida pelos operadores, ku e kr. Esta chave permane-

cer

a dispon

ıvel enquanto sua pol

ıtica de uso permitir ou o procedimento de descarga da

mesma for acionado.

6.7 Troca do grupo de Administratores

O grupo de administradores de um HSM pode ser trocado utilizando

o algoritmo coberto nesta sec¸

ao. Essa operac¸

ao, como qualquer outra de troca de gru-

pos, deve ser realizada sempre que houver comprometimento do grupo. Considera-se um

grupo comprometido quando o uso do mecanismo de compartilhamento de segredo for

inviabilizado.

As chaves sim

etricas dos grupos s

ao compartilhadas utilizando os limi-

ares k e n, sendo k o n

umero m

ınimo de membros presentes para autenticar o grupo e n o

umero total de membros. Sabendo disso, para um grupo de 5 membros onde 3 precisam

estar presentes, a exist

encia de qualquer 2 membros n

e capaz de recuperar nenhum bit

da chave. Portanto, se dois membros do grupo perderem de alguma forma acesso a seus

token criptogr

aﬁcos, e conseq

uentemente acesso as suas chaves privadas, o grupo ainda

pode ser autenticado, por

em, se mais um tiver problema, o grupo est

a comprometido.

Considerando-se que um HSM s

o possui um grupo de administradores

alido, a sua troca se torna pec¸a fundamental para a continuidade do ciclo de vida das

chaves gerenciadas do HSM, j

a que o grupo de administradores tamb

e utilizado para

recuperac¸

ao das c

opias de seguranc¸a. Este processo autentica o grupo de administradores

atual e requer os limiares k e n que ser

ao utilizados para criac¸

ao do novo grupo.

Algoritmo changeAdmGroup( k, n )

Troca o grupo de administradores de um HSM, autenticando o atual e gerando o

novo. Depois de transferida a administrac¸

ao do HSM, a chave privada do HSM passa

a ser protegida pela chave sim

etrica do novo grupo ks

e os certiﬁcados de todos os

membros do grupo antigo s

ao revogados.

1: ks

← authenticateGroup( ADS, ADM )

2: c

, ekr

← load( ADS )

3: kr

← decrypt( ekr

, ks

)

4: ks

← createGroup( ADS, ADM

, k, n, c

, kh

)

5: ekr

← encrypt( kr

, ks

)

6: store( ADS, ekr

)

7: revokeGroupCerts( ADS, ADM )

8: ADM ← ADM

9: return c

O algoritmo changeAdmGroup inicia como qualquer outra operac¸

administrativa j

a vista at

e aqui, onde os 3 primeiros passos visam autenticar o grupo de

administradores e liberando acesso a chave privada do HSM, kr

No passo 4, o novo grupo de administradores

e criado, referenciado

pelo identiﬁcador tempor

ario ADM

. Esse identiﬁcador ser

a posteriormente atribu

ıdo a

ADM, que sempre aponta para o grupo de administradores corrente do HSM.

A chave privada do HSM

e ent

ao cifrada utilizando a chave sim

etrica

do novo grupo de administradores ks

no passo 5 e logo ap

os armazenada em ADS.

No passo 7, os certiﬁcados de todos os membros do antigo grupo de administradores

ao revogados, garantindo que n

ao ser

ao mais aceitos no HSM. Seguindo,

e atualizado o

identiﬁcador do grupo de administradores, ADM, para apontar para o novo grupo ADM

Finalmente, com o grupo de administradores trocado, o certiﬁcado do

HSM

e retornado no passo 9. Como visto, essa

e uma operac¸

ao cr

ıtica e requer bastante

atenc¸

ao, j

a que um HSM possui apenas um grupo de administradores v

alido. Deve-se

garantir atomicidade na execuc¸

ao dos passos 6, 7 e 8, j

a que se falharem destes pontos, o

HSM possuir

a um grupo de administradores inv

alido.

Uma caracter

ıstica interessante ap

os a execuc¸

ao deste algoritmo

e que,

todas as c

opias de seguranc¸a criadas antes desta execuc¸

ao s

ao apenas recuper

aveis com

a autenticac¸

ao do antigo grupo de administradores do HSM. A troca proposta por este

algoritmo s

o ir

a se reﬂetir em novas c

opias de seguranc¸a criadas. O grupo de auditores

desempenham um papel fundamental neste processo, controlando as atividades do antigo

grupo de administradores em relac¸

ao a recuperac¸

ao de c

opias de seguranc¸a. Alternativa-

mente, os smartcards n

ao mais necess

arios podem ser destru

ıdos.

6.8 Alterando os respons

aveis por uma chave gerenciada

A troca dos respons

aveis de uma chave no HSM n

e uma operac¸

ao cr

ıtica quando a troca de seu grupo de administradores, por

em, t

ao importante quanto.

Isso porque uma vez que o ponto de conﬁanc¸a do grupo atualmente respons

avel e o grupo

que receber

a a responsabilidade existam, os administradores podem realizar a troca.

Esta operac¸

ao pode representar em uma situac¸

ao real, a troca da dire-

toria respons

avel por uma AC em uma instituic¸

ao, permitindo que seus novos membros

passem a ser respons

aveis pelo uso de sua chave privada. Como dito anteriormente, so-

mente o grupo de administradores

e necess

ario para essa troca, desde que os pontos de

conﬁanc¸a existam.

Basicamente, o algoritmo autentica o grupo de administradores e

atrav

es do ponto de conﬁanc¸a recupera a chave sim

etrica dos dois grupos de operado-

res, podendo ent

ao decifrar a chave privada com a chave sim

etrica de um grupo, poste-

riormente cifrando com a do outro. Para iniciar o processo de troca, s

ao necess

arios o

identiﬁcador da chave que ter

a seu grupo respons

avel trocado, id

key

, e o identiﬁcador do

grupo de operadores que se tornar

a seu novo respons

avel, id

O algoritmo changeKeyOwner inicia como qualquer outra operac¸

administrativa j

a vista at

e aqui, onde os 3 primeiros passos visam autenticar o grupo de

administradores e liberando acesso a chave privada do HSM, kr

No passo 4, os dados da chave id

key

ao carregados de KDS, tais como

a chave privada cifrada, ekr, e o identiﬁcador do atual respons

avel pela chave, id

Algorithm changeKeyOwner( id

key

, id

)

Troca o grupo de operadores respons

avel por uma chave gerenciada no HSM.

necess

aria a autenticac¸

ao do grupo de administradores al

em de existir o ponto de

conﬁanc¸a dos dois grupos de operadores envolvidos na operac¸

ao.

1: ks ← authGroup( ADS, ADM )

2: ekr

← load( ADS )

3: kr

← decrypt( ekr

, ks )

4: ekr, id

← load( KDS, id

key

)

5: eks

ao1

← load( ADS, id

)

6: ks

ao1

← decrypt( eks

ao1

, kr

)

7: ks

o1∗

← load( NXD, id

oper1

)

8: ks

← xor( ks

, ks

o1∗

)

9: kr ← decrypt( ekr, ks

)

10: eks

ao2

← load( ADS, id

)

11: ks

ao2

← decrypt( eks

ao2

, kr

)

12: ks

o2∗

← load( NXD, id

oper2

)

13: ks

← xor( ks

, ks

o2∗

)

14: ekr ← encrypt( kr, ks

)

15: store( KDS, id

key

, ekr, id

)

Os passos de 5 a 8, como os passos de 10 a 13, visam recuperar chaves

sim

etricas de grupos de operadores, identiﬁcados por id

e id

respectivamente. Estas

operac¸

oes j

a foram cobertas anteriormente (vide sec¸

ao 6.5). Ao ﬁnal do passo 8, obtem-se

acesso a ks

e pode-se decifrar a chave privada gerenciada no passo 9. E ao ﬁnal do passo

13, obt

em-se acesso a ks

, que

e utilizada no passo 14 para cifrar a chave gerenciada.

Finalmente, a chave kr cifrada pode ser armazenada juntamente com o

identiﬁcador do seu novo respons

avel no passo 15, concluindo o algoritmo de troca do

grupo respons

avel por uma chave gerenciada.

6.9 Criando o ponto de conﬁanc¸a de um grupo de Ope-

radores em relac¸

ao aos Administradores

O ponto de conﬁanc¸a do grupo de operadores em relac¸

ao ao grupo de

administradores garante que operac¸

oes administrativas sejam realizadas sobre o primeiro.

Este ponto de conﬁanc¸a deixa de existir quando os administradores recuperam o backup

de um HSM, estabelecendo outro ambiente operacional.

O algoritmo activatesAdmT asksOverOperGroup autentica o grupo

de administradores e o grupo de operadores a ser ”ativado”, regerando a segunda chave

do grupo de operadores e aplicando a operac¸

ao XOR

a chave principal do grupo. O

idenﬁcador do grupo de operadores

e o

unico requisito para disparar a execuc¸

ao deste

algoritmo.

Algoritmo activatesAdmTasksOverOperGroup( id

oper

)

Estabelece o ponto de conﬁanc¸a de um grupo de operadores identiﬁcado por id

oper

em relac¸

ao ao grupo de administradores. A exist

encia deste ponto possibilita que

ultimo, utilizando a propriedade de reversibilidade do XOR, possa recuperar a

chave sim

etrica do grupo de operadores ks

, permitindo assim, a associac¸

ao e/ou

desassociac¸

ao de chaves gerenciadas.

1: ks

← authGroup( ODS, id

oper

)

2: ks

o∗

← genSessionKey()

3: ks

← xor( ks

, ks

o∗

)

4: c

← load( ADS )

5: eks

← encrypt( ks

, c

)

6: store( ADS, id

oper

, eks

)

7: store( NXD, id

oper

, ks

o∗

)

O algoritmo inicia autenticando o grupo de operadores identiﬁcado por

oper

, obtendo acesso sua chave sim

etrica, ks

. No passo 2, uma nova chave sim

etrica

secund

aria do grupo, ks

o∗

e gerada, permitindo a realizac¸

ao da operac¸

ao XOR no passo

3, que resultar

a em ks

No passo 4, o certiﬁcado do HSM

e carregado do ADS e posterior-

mente utilizado para cifrar ks

, resultado em eks

. Nos passos 6 e 7, os dados gerados

durante a execuc¸

ao do algoritmo, eks

e ks

o∗

, s

ao gravados nos devidos sistemas de

armazenamento, ADS e NXD respectivamente, reestabelecendo o ponto de conﬁanc¸a.

6.10 Exportac¸

ao dos Registros de Atividades

O protocolo do OpenHSM deﬁne que todas as operac¸

oes realizadas em

um HSM devem ser registradas de forma sequencial para posterior an

alise por grupos de

auditores, permitindo que seja reconstru

ıdo toda a trilha das operac¸

oes realizadas.

Apenas grupos de auditores podem exportar os registros de atividades

do HSM, sempre assinados, devendo fazer isso informando seu identiﬁcador id e, opcio-

nalmente, especiﬁcar um per

ıodo de tempo para exportac¸

ao. Se n

ao especiﬁcado, todos

os registros existentes s

ao exportados.

Algoritmo exportLog( id [, rangeDate] )

Permite um grupo de auditores exportar os registros de atividade do HSM assinados,

podendo ou n

ao deﬁnir o per

ıodo de tempo para os mesmos

1: ks ← authGroup( AudDS, id )

2: ekr ← load( AudDS, id )

3: kr ← decrypt( ekr, ks )

4: L ← load( LDS, rangeDate )

5: sL ← sign( L, kr )

6: return( sL )

O algoritmo exportLog inicia autenticando o grupo de auditores iden-

tiﬁcado por id, resultando na sua chave sim

etrica, ks. No passo 2, carrega-se a chave

privada cifrada do grupo, ekr, que, no passo seguinte,

e decifrada, resultando em kr.

No passo 4, o HSM carrega os registros, L, do sistema de armazena-

mento de registros, LDS, respeitando o per

ıodo de tempo especiﬁcado, rangeDate. O

HSM ent

ao assina L para garantir a integridade destes registros. Os registros assinados

ao retornados como resultado do algoritmo.

6.11 Limpeza dos Registros de Atividades

O ciclo de vida de um HSM dura v

arios anos e considerando o fato do

mesmo rodar em ambiente embarcado, com recursos de armazenamento limitado, deﬁniu-

se um operac¸

ao administrativa para apagar os registros do sistema.

Este procedimento de limpeza dos registros de atividades do HSM en-

globa o algoritmo para exportar registros tamb

em, garantindo que qualquer registro que

for apagado do HSM, j

a tenha sido exportado pelo menos uma vez, permitindo assim que

a criac¸

ao da trilha de auditoria cubra todas as operac¸

oes realizadas em todo o tempo de

vida de um HSM.

O algoritmo autentica o grupo de administradores e um grupo de audi-

tores, identiﬁcado por id. Opcionalmente, pode-se informar um per

ıodo de tempo no qual

os registros ser

ao exportados e apagados.

Algoritmo eraseLog( id [, rangeDate] )

Apaga os registros de atividades do HSM, autenticando o grupo de adminitradores e

um grupo de auditores. Este

ultimo, recebe uma c

opia assinada dos registros apaga-

dos.

1: authGroup( ADS, ADM )

2: sL ← exportLog( id, rangeDate )

3: delete( LDS, rangeDate )

4: return( sL )

O algoritmo eraseLog inicia autenticando o grupo de administradores

do HSM no passo 1. Essa autenticac¸

e requirida apenas por quest

ao de seguranc¸a, j

que o conjunto dos registros do sistema

e parte fundamental para o controle do ciclo de

vida das chaves gerenciadas.

No passo 2 executa-se o algoritmo exportLog visto anteriormente,

que ir

a resultar nos registros assinado do HSM, sL, referente ao tempo especiﬁcado,

rangeDate. No passo seguinte, os registros rec

em exportados podem ser apagados. O

HSM retorna sL como resultado da execuc¸

ao.

Os protocolos do OpenHSM abordados at

e aqui descrevem a construc¸

de um ambiente seguro para gerenciamento de chaves criptogr

aﬁcas de um HSM. Por

em,

a continuidade do ciclo de vida das chaves gerenciadas est

a comprometida em caso de

falha de hardware ou de desastres, o que pode causar danos irrepar

aveis a uma infra-

estrutura de chaves p

ublicas. Essa lacuna ser

a coberta na pr

oxima sec¸

ao, que abordar

a a

criac¸

ao e restaurac¸

ao de c

opias de seguranc¸a de um HSM de forma segura e conﬁ

avel.

6.12 Conclus

Este cap

ıtulo apresentou todos os sub-protocolos do OpenHSM usados

na operacionalizac¸

ao de um HSM. Atrav

es deles

e poss

ıvel a realizac¸

ao de dois das prin-

cipais operac¸

oes em um HSM: criac¸

ao e utilizac¸

ao de chaves criptogr

aﬁcas.

Entretanto, duas etapas essencial para o completo ciclo de vida de

chaves criptogr

aﬁcas ainda n

ao foram cobertos, a criac¸

ao e recuperac¸

ao de c

opias de

seguranc¸a (c

opias das chaves gerenciadas). Os sub-protocolos respons

aveis por estas eta-

pas ser

ao abordados no pr

oximo cap

ıtulo.

Cap

ıtulo 7

OpenHSM - C

opias de Seguranc¸a

Os protocolos de criac¸

ao de c

opias de seguranc¸a do conte

udo de um

HSM de forma segura e conﬁ

avel, devem permitir sua posterior recuperac¸

ao, de forma a

restaurar todo o ambiente operacional que existia no momento que a c

opia de seguranc¸a

foi criada.

Figura 7.1: Processo de criac¸

ao de um HSM de backup

A criac¸

ao destas c

opias, como pode ser visto na ﬁgura 7.1, requer a

utilizac¸

ao de um segundo m

odulo, que dever

a ser conﬁgurado como uma unidade de

backup (sec¸

ao 7.1), n

ao podendo ser utilizado para nenhum outro ﬁm, a n

ao ser restaurar

uma c

opia de seguranc¸a de um HSM. Entretanto, uma unidade de backup pode servir de

receptor de backup para v

arios HSM ao mesmo tempo.

os a preparac¸

ao de um HSM para backup, o certiﬁcado c

bkp

deve

ser importado no HSM operacional (sec¸

ao 7.2). Este processo permitir

a que c

opias de

seguranc¸a sejam criadas (sec¸

ao 7.3) para posterior recuperac¸

ao em caso de algum pro-

blema acontecer com o HSM operacional (sec¸

ao 7.4).

Por ﬁm, a sec¸

ao 7.5 discute a quest

ao do controle de ciclo de vida de

ultiplas c

opias da mesma chave criptogr

aﬁca em hardware criptogr

aﬁcos diferentes.

7.1 Preparando um HSM para ser uma unidade de

backup

O primeiro passo para criac¸

ao de c

opias de seguranc¸a de um m

odulo de

seguranc¸a criptogr

aﬁco

e preparar um HSM adicional para ser uma unidade de backup,

sendo que qualquer HSM que n

ao tenha sido inicializado pode ser utilizado neste pro-

cesso.

Nenhuma informac¸

ao dos m

odulos criptogr

aﬁcos ativos

e necess

aria

para a criac¸

ao de uma unidade de backup, que pode ser criado antes mesmo de existir um

HSM operacional.

O algoritmo prepareBkpUnit implementa o protocolo que prepara um

HSM para ser uma unidade de backup, requerendo como par

ametro o identiﬁcador id

bkp

que ser

a utilizado como nome comum do certiﬁcado desta unidade.

Algoritmo prepareBkpUnit( id

bkp

)

Prepara um HSM para ser uma unidade de backup, gerando um par de chaves as-

sim

etricas kr

bkp

e ku

bkp

e emitindo um certiﬁcado auto-assinado a partir deste par

de chaves e o identiﬁcador do HSM id

bkp

passado como par

ametro. O certiﬁcado do

HSM de backup

e exportado como resultado do algoritmo.

1: kr

bkp

, ku

bkp

← genKeyPair()

2: c

bkp

← genSelfSignedCert( kr

bkp

, ku

bkp

, id

bkp

)

3: store( BDS, kr

bkp

, c

bkp

)

4: return c

bkp

O processo de preparac¸

ao de uma unidade de backup inicia com a

criac¸

ao de um par de chaves criptogr

aﬁcas de backup (kr

bkp

e ku

bkp

). No passo 2, um

certiﬁcado auto-assinado c

bkp

e gerado a partir do identiﬁcador id

bkp

e o par de chaves

rec

em criado.

No passo 3, o certiﬁcado e a chave privada de backup s

ao armazenados

no sistema de armazenamento de dados de backup para que possam ser carregados pos-

teriormente no processo de recuperac¸

ao de uma c

opia de seguranc¸a. O algoritmo termina

exportando c

bkp

, que dever

a ser importado nos HSM operacionais para iniciar o processo

de gerac¸

ao de c

opias de seguranc¸a.

A chave privada de backup kr

bkp

e armazenada em texto claro com

protec¸

ao do per

ımetro criptogr

aﬁco do HSM, que

e capaz de detectar, com a utilizac¸

ao de

sensores, e responder a uma tentativa de invas

ao, apagando dados sens

ıveis a seguranc¸a

do m

odulo.

Uma vez preparado para ser um receptor de c

opias de seguranc¸a, o HSM

deve ser armazenado em local seguro, aguardando a necessidade de recuperac¸

ao de um

backup.

7.2 Importando o Certiﬁcado de Backup em HSM Ope-

racional

Como visto na sec¸

ao anterior, a preparac¸

ao de um HSM receptores de

backup inclui a exportac¸

ao de um certiﬁcado. Este certiﬁcado deve ser ent

ao importado

nos HSM operacionais, possibilitando a criac¸

ao de c

opias de seguranc¸a do mesmo.

O processo de importac¸

ao de certiﬁcados de backup em um HSM

simples, mas requer muito cuidado. Por se tratar de um certiﬁcado X.509 auto-assinado,

que pode ser gerado em qualquer lugar, o grupo de administradores deve estar ciente da

sua proced

encia, cabendo aos grupos de auditores a an

alise dos registros de atividades do

HSM, a ﬁm de descobrir eventuais falhas de gerenciamento.

Um HSM pode importar v

arios certiﬁcados de backup, aumentando o

umero de unidades onde uma c

opia de seguranc¸a pode ser recuperada. O algoritmo

importBkpCert implementa o protocolo de importac¸

ao destes certiﬁcados, autenticando

o grupo de administradores do HSM para isso.

Algoritmo importBkpCert( c

bkp

)

Importa o certiﬁcado exportado no processo de criac¸

ao de uma unidade de backup.

O grupo de administrador

e autenticado na execuc¸

ao deste algoritmo.

1: ks ← authenticateGroup( ADS, ADM )

2: ekr

← load( ADS )

3: kr

← decrypt( ekr

, ks )

4: sc

bkp

← sign( c

bkp

, kr

)

5: store( BDS, sc

bkp

)

O algoritmo importBkpCert inicia realizando a autenticac¸

ao do grupo

de adminitradores, possibilitando a liberac¸

ao da chave privada do HSM no passo 3. No

passo 4, o certiﬁcado de backup passado como par

ametro

e reassinado com kr

e poste-

riormente armazenado no sistema de armazenamento de backup.

os a importac¸

ao do primeiro certiﬁcado de backup, c

opias de

seguranc¸a do ambiente operacional do HSM podem ser criadas. Este

e o assunto da

oxima sec¸

ao.

7.3 Backup

A gerac¸

ao de c

opias de seguranc¸a do ambiente operacional de um HSM

e uma atividade essencial para continuidade do ciclo de vida das chaves gerenciadas e

deve ser executada regularmente, j

a que qualquer operac¸

ao executada ap

os a criac¸

ao do

backup ser

a completamente perdida em caso de falha do HSM. As declarac¸

oes de pr

aticas

de certiﬁcac¸

ao das ICPs devem estabelecer a regularidade na qual as c

opias de seguranc¸a

devem ser geradas.

Todas as chaves gerenciadas pelo m

odulo s

ao exportadas de forma ci-

frada, garantindo que, mesmo fora do per

ımetro criptogr

aﬁco do HSM, elas estejam se-

guras, seguindo os requisitos existentes nas normas FIPS PUB 140-2 e MCT-7.

O algoritmo bkpHsm, que implementa o protocolo de criac¸

ao de uma

opia de seguranc¸a de um HSM, autentica o grupo de administradores, por se tratar de

uma operac¸

ao administrativa. Al

em disso, o HSM deve possuir pelo menos um grupo

de auditores, que ser

ao autenticados durante a recuperac¸

ao da c

opia de seguranc¸a, garan-

tindo que n

ao existam c

opias paralelas do HSM sem pr

evio conhecimento da equipe de

auditoria.

Algoritmo bkpHsm()

Cria um c

opia de seguranc¸a de um HSM operacional, autenticando seu grupo de

admistradores. A c

opia de seguranc¸a poder

a ser recuperada em todos as unidades de

backup que tiveram seu certiﬁcado importado no HSM. Lembrando que o sistema de

armazenamento de dados n

ao export

aveis N XD, como o nome j

a diz, n

e copiado.

1: ks ← authenticateGroup( ADS, ADM )

2: ekr

, c

← load( ADS )

3: kr

← decrypt( ekr

, ks )

4: store( BP F , load( CT L ) )

5: store( BP F , load( ADS ) )

6: store( BP F , load( AudDS ) )

7: store( BP F , load( ODS ) )

8: store( BP F , load( KDS ) )

9: store( BP F , load( BDS ) )

10: C

bkp

← load( BDS ) )

11: ks

bkp

← genSessionKey()

12: eBP F ← encrypt( BP F , ks

bkp

)

13: seBP K ← sign( eBP K, kr

)

14: for c

bkp

in C

bkp

15: eks

bkp

← encrypt( ks

bkp

, c

bkp

)

16: end for

17: return seBKP , EKs

bkp

O algoritmo inicia com os tr

es passos comuns para uma operac¸

ao ad-

ministrativa, autenticando os administradores e obtendo acesso a chave privada e o certi-

ﬁcado do HSM, kr

e c

respectivamente.

Nos passos de 4 a 9, todos os dados relevantes ao ambiente operacional

do HSM s

ao copiados para o pacote do backup BP F , incluindo os sistemas de arma-

zenamento de dados dos grupos (ADS, ODS, AudDS), de chaves gerenciadas KDS,

de certiﬁcados conﬁ

aveis CT L e de dados de backup BDS. O

ultimo

e necess

ario por-

que mais de uma certiﬁcado de backup pode ter sido importado no HSM, permitindo que

mesmo ap

os recuperac¸

ao da c

opia de seguranc¸a, novos backups possam ser criados.

O sistema de armazenamento de dados n

ao export

aveis n

e copiado

durante este algoritmo, desabilitando operac¸

oes administrativas sobre chaves gerenciadas

enquanto seu grupo de operadores respons

avel n

ao tenha conhecimento de sua exist

encia.

O BP F ent

ao precisa ser cifrado utilizando todos os certiﬁcados de

backup previamente importados no HSM, permitindo que a c

opia possa ser recuperada

em qualquer um deles. No passo 10, o conjunto de certiﬁcados de backup

e carregado.

Logo ap

os, gera-se uma chave sim

etrica, ks

bkp

, que, no passo 12, ser

a utilizada para cifrar

BP F . O passo 13 visa garantir a integridade do c

opia de seguranc¸a, assinando eBP F

com a chave privada do HSM kr

bkp

Nos passos 14 a 16, realiza-se uma iterac¸

ao por todos os certiﬁcados

de backup existentes dentro do HSM, utilizando cada um deles para cifrar ks

bkp

, que ir

resultar em um conjunto de chaves sim

etricas cifradas com diferentes chaves p

ublicas,

EKs

bkp

O processo de criac¸

ao do backup est

a completo ao ﬁnal do passo 16,

retornando a c

opia de seguranc¸a do ambiente operacional cifrado e assinado e o conjunto

de chaves sim

etricas cifradas pelos certiﬁcados de backup, seBKP e EKs

bkp

respectiva-

mente.

7.4 Recuperac¸

ao do Backup

A recuperac¸

ao de c

opias de seguranc¸a

ultimo passo para permitir o

completo ciclo de vida de chaves criptogr

aﬁcas gerenciadas em um HSM, incluindo os

casos de falhas de hardware ou desastres. Os certiﬁcados de backup existentes na c

opia

de seguranc¸a delimitam o conjunto de unidades de backup que podem ser utilizadas para

recuperac¸

ao.

Esta recuperac¸

ao, al

em de ser um operac¸

ao administrativa, requer a

autenticac¸

ao de um grupo de auditores, permitindo o conhecimento da equipe de auditoria

que uma nova inst

ancia do HSM est

a operacional, diminuindo a carga de responsabilidade

do grupo de administradores.

O algoritmo recoverBkp requer como par

ametros de entrada o identi-

ﬁcador do grupo de auditores que ser

a autenticado durante o processo e os dados retorna-

dos do algoritmo de criac¸

ao do backup, seBKP e EKs

bkp

, respectivamente o pacote de

backup cifrado e assinado e a chave sim

etrica que cifra o pacote de backup cifrada com

cada um dos certiﬁcados de backup importados no HSM.

Algoritmo recoverBkp(seBKP , EKs

bkp

, id

audit

)

Restaura o ambiente operacional de um HSM em um m

odulo previamente preparado

para backup. O grupo de administradores e pelo menos um grupo de auditores s

ao au-

tenticados neste processo, sendo estas autenticac¸

oes somente requeridas por quest

de seguranc¸a, isto

e, n

ao t

em objetivos criptogr

aﬁcos.

1: kr

bkp

← load( BDS )

2: ks

bkp

← decrypt( eks

bkp

, kr

bkp

)

3: BP F ← decrypt( seBP F , ks

bkp

)

4: store( CT L, load( BP F ) )

5: store( ADS, load( BP F ) )

6: c

← load( ADS )

7: verify(seBKP , c

)

8: ks

adm

← authenticateGroup( ADS, ADM )

9: store( AudDS, load( BP F ) )

10: ks

audit

← authenticateGroup( AudDS, id

audit

)

11: store( ODS, load( BP F ) )

12: store( KDS, load( BP F ) )

13: store( BDS, load( BP F ) )

O processo de recuperac¸

ao de backup inicia carregando a chave privada

de backup kr

bkp

do sistema de armazenamento de dados de backup BDS. Logo ap

os, a

chave sim

etrica que cifra o backup, ks

bkp

e decifrada. A chave liberada no passo 2 permite

que o pacote de backup seja decifrado no passo 3.

Os passos 4 e 5 restauram, respectivamente, o sistema de armazena-

mento de certiﬁcados conﬁ

aveis CT L e de administradores ADS. Este

e o conjunto

ınimo de dados necess

ario para veriﬁcar a integridade de seBKP no passo 7 e autenti-

car o grupo de administradores no passo 8.

O passo 9 restaura o sistema de armazenamento de auditores, que per-

mite a autenticac¸

ao do grupo de auditores identiﬁcado por id

audit

no passo 10.

E ﬁnalmente, nos passos 11, 12 e 13, os sistemas de armazenamento

restantes s

ao restaurados, respectivamente, os sistemas de armazenamento de dados de

operadores, chaves e backup.

O ambiente operacional do HSM, uma vez restaurado, ser

a exatamente

igual ao momento em que a c

opia de seguranc¸a foi criada, com excec¸

ao do sistema de ar-

mazenamento de dados n

ao exportados, NXD, que precisa ser recriado com o algoritmo

apresentado na sec¸

ao 6.9.

7.5 Utilizac¸

ao de M

ultiplos Ambientes Operacionais

A medida que o n

umero de inst

ancias de chaves criptogr

aﬁcas operaci-

onais aumenta, maior

e a diﬁculdade para gerenci

a-las, tornando mais complexo tamb

o processo de auditoria, j

a que, esta paralelizac¸

ao das operac¸

oes, difunde os usos de uma

chave criptogr

aﬁca em v

arios ambientes.

Apesar disso, alguns situac¸

oes requerem este tipo de abordagem, isto

e, a criac¸

ao de v

arios ambientes operacionais, com o objetivo de rapidez no processo de

retomada das atividades em caso de falha do ambiente principal ou em ambiente de alta

demanda, com necessidade de balanceamento de carga.

Muitas vezes, a realizac¸

ao de uma cerim

onia implica em custos ﬁnan-

ceiros e/ou log

ısticos elevados em algumas organizac¸

oes, se considerar a quantidade de

pessoas envolvidas e a diﬁculdade de reun

ı-las para uma nova tentativa. Por isso, para

garantir rapidez em caso de falha do ambiente operacional principal, pode-se conﬁgurar

um segundo ambiente id

entico ao primeiro, diminuindo assim os riscos de falha de todo

o processo, evitando que uma nova cerim

onia seja necess

aria.

A criac¸

ao de uma ambiente operacional id

entico pode ser realizado uti-

lizando os mecanismos de criac¸

ao e recuperac¸

ao de c

opias de seguranc¸a do HSM. O novo

HSM, uma vez restaurado, ter

a os mesmos grupos e chaves gerenciadas que existiam no

primeiro. Assim, no caso de uma autoridade certiﬁcadora por exemplo, duas c

opias da

sua chave privada est

ao operacionais, bastando que o grupo de operadores respons

avel a

libere para uso.

Entretando, como forma de diminuir ainda mais os riscos de falhas que

resultem no cancelamento de uma cerim

onia, pode-se criar ambientes totalmente indepen-

dentes, isto

e, com a troca dos grupos de administradores e operadores do m

odulo, sendo

que os novos grupos podem ser compostos dos mesmos membros e possuir a mesma

conﬁgurac¸

ao dos grupos originais. Desta forma,

e poss

ıvel contornar at

e falhas nos smart-

cards dos membros dos grupos. Esta abordagem tamb

em se aplica em casos onde deseja-

se ambientes operacionais paralelos em localizac¸

oes completamente diferentes umas das

outras.

A impot

encia dos grupos de administradores e operadores em relac¸

aos grupos de auditores de um HSM permite que estes

ultimos realizem auditoria de

qualquer uma das inst

ancias dos m

odulos operacionais, desde que tenham sido criados

durante a preparac¸

ao da primeira inst

ancia do HSM. Se novos grupos de auditores forem

criados ap

os a exist

encia de m

ultiplas inst

ancias, estes s

o podem auditar o HSM em que

foram criados e as novas inst

ancias que foram recuperadas de c

opias de seguranc¸a criadas

posteriormente a sua criac¸

ao.

em disso, digamos que um HSM operacional possua um grupo de

administradores, um de operadores, um de auditores e gerencia uma chave criptogr

aﬁca.

O processo de criac¸

ao de c

opias de seguranc¸a deste ambiente requer a autenticac¸

ao do

grupo de administradores. A sua posterior restaurac¸

ao para estabelecimento de um se-

gundo ambiente operacional requer a autenticac¸

ao do grupo de administradores e de pelo

menos um grupo de auditores, portanto, a equipe de auditoria sempre vai saber quando

uma nova inst

ancia do HSM for estabelecida. Nessa nova inst

ancia, a utilizac¸

ao da chave

gerenciada est

a limitada ao grupo de operadores que possui a responsabilidade por seu

uso, j

a que a propriedade de rastreabilidade das chaves gerenciadas do OpenHSM desfaz

o ponto de conﬁanc¸a dos grupos de operadores em relac¸

ao ao grupo de administradores

em todas as c

opias de seguranc¸a recuperadas. Este exemplo procura demostrar todos os

recursos providos pelos protocolos do OpenHSM de modo a estabelecer um controle ri-

goroso sobre o controle do ciclo de vida das chaves gerenciadas, mesmo nos processos de

criac¸

ao e restaurac¸

ao de c

opias de seguranc¸a.

A utilizac¸

ao de m

ultiplos ambientes operacionais tamb

em se aplica no

balanceamento de carga para aplicac¸

oes com alta demanda, se aplicando nestes casos o

uso de ambientes operacionais id

enticos. Um exemplo de aplicabilidade desta arquitetura

e a paralelizac¸

ao da emiss

ao de certiﬁcados e lista de certiﬁcados revogados por uma AC.

7.6 Conclus

O protocolo do OpenHSM, utilizado para o gerenciamento do ciclo de

vida das chaves criptogr

aﬁcas gerenciadas pelo ASI-HSM, foi publicado em eventos in-

ternacionais da

area para apreciac¸

ao do mundo acad

emico, com sua vers

ao mais atual

apresentada nestes dois

ultimos cap

ıtulos, utilizando uma nova forma de representac¸

ao.

Deu-se especial atenc¸

ao aos protocolos de criac¸

ao e recuperac¸

ao de

opias de seguranc¸a do material criptogr

aﬁco, de forma a cobrir as lacunas em caso de

falhas de hardware ou desastres. Al

em disso, extende-se essa funcionalidade de c

opias de

seguranc¸a para o estabelecimento de m

ultiplas inst

ancias de uma chave gerenciada.

Desta forma, tanto o OpenHSM quanto o ASI-HSM s

ao uma realidade

hoje, j

a estando instalado em 7 instituic¸

oes de ensino brasileiras, aonde um projeto piloto

de avaliac¸

ao da ICPEDU est

a em curso.

Cap

ıtulo 8

Conclus

O suporte ao controle do ciclo de vida de m

ultiplas c

opias de uma chave

em m

odulos criptogr

aﬁcos de mercado no contexto de uma infra-estrutura de chaves

ublicas praticamente inexiste e quando existe, o esquema

e propriet

ario e restritivo

mesma fam

ılia de produtos do fabricante. Mesmo assim, o controle

e ineﬁcaz no sentido

de que n

ao se consegue uma forte amarrac¸

ao entre cada uma das c

opias das chaves, o que

diﬁculta sobremaneira a auditoria.

O problema

e maior quanto

e preciso manter as chaves por longo

per

ıodo de tempo, como

e o caso de uma autoridade certiﬁcadora. Normalmente, o tempo

de manutenc¸

ao de uma chave de uma AC Raiz

e superior a 10 anos, o que

e muito maior

que o tempo m

edio esperado de vida

util de um HSM de mercado.

E imperativo, portanto,

a possibilidade de criac¸

ao e recuperac¸

ao de c

opias de seguranc¸a, com total controle, em

equipamento de diferentes fabricantes. Contudo, esta n

e a praxe de mercado.

Foi realizado um estudo das principais normas e recomendac¸

oes naci-

onais e internacionais que regem a construc¸

ao de m

odulos criptogr

aﬁcos. Percebeu-se

que nessas normas, o tratamento de m

ultiplas c

opias do material criptogr

aﬁco

e pouco

explorado. Aproveitou-se tal estudo para avaliar os protocolos do OpenHSM em relac¸

ao requisitos apostos nestas normas.

Este trabalho tem como maior contribuic¸

ao o aprimoramento do

OpenHSM neste contexto, ou seja, como realizar uma c

opia de seguranc¸a das cha-

ves criptogr

aﬁcas, realizar sua restaurac¸

ao e manter a rastreabilidade de cada uma das

opias. Todos os protocolos do OpenHSM foram analisados e onde necess

ario foram

feitas modiﬁcac¸

oes para se alcanc¸ar esta rastreabilidade.

8.1 Resumo das Contribuic¸

oes

O presente trabalho apresentou diversas contribuic¸

oes de car

ater t

ecnico

e te

orico-cient

ıﬁco, atingindo seus objetivos geral e espec

ıﬁcos, tais como os sumarizados

a seguir:

• revisou-se os hardware criptogr

aﬁcos de mercado utilizados no gerenciamento do

ciclo de vida de chaves criptogr

aﬁcas, com

enfase nos smartcards e HSMs;

• detalhou-se da ferramenta criptogr

aﬁca OpenSSL, com a apresentac¸

ao de sua infra-

estrutura de suporte para usu

arios e desenvolvedores, focando-se particularmente no

desenvolvimento de engines, que permitem a integrac¸

ao de aplicativos a hardware

criptogr

aﬁcos;

• analisou-se os requisitos das normas FIPS 140-2 e MCT-7, utilizados na certiﬁcac¸

de HSMs. Esta an

alise identiﬁcou pontos de extrema relev

ancia em relac¸

ao ao uso

de HSMs no

ambito de ICPs que n

ao s

ao cobertos por estas normas, como um

forte sistema de auditoria e um r

ıgido controle das c

opias de seguranc¸a do material

sens

ıvel;

• apresentou-se a arquitetura e as aplicac¸

oes adicionais de um HSM como alvo para o

embarcamento do OpenHSM. Entres estas aplicac¸

oes est

ao as interfaces de geren-

ciamento remoto e a engine que prov

e integrac¸

ao entre o HSM e outros aplicativos;

• revisou-se os protocolos de gerenciamento de chaves criptogr

aﬁcas do OpenHSM,

propondo-se uma nova forma de representac¸

ao. Essa revis

ao detalhou em particular

o esquema de criac¸

ao e recuperac¸

ao de c

opias de seguranc¸a;

• apresentou-se formas de utilizac¸

ao de m

ultiplas inst

ancias de uma chave gerenciada

pelos protocolos do OpenHSM em diferentes ambientes operacionais. Esta abor-

dagem possibilita, entre outras, a r

apida retomada das operac¸

oes em caso de falha

do ambiente operacional principal ou visa suprir as necessidades de ambientes com

alta demanda de processamento;

• publicac¸

ao de dois artigos em eventos internacionais, apresentando os protocolos

de gerenciamento de chaves criptogr

aﬁcas do OpenHSM;

• preparac¸

ao de um artigo de evento introduzindo t

ecnicas iniciais de modelagem e

validac¸

ao de cerim

onias (ainda n

ao submetido);

• preparac¸

ao de um artigo de peri

odico que visa consolidar todo o conhecimento

adquirido no projeto dos protocolos do OpenHSM (ainda n

ao submetido).

8.2 Trabalhos Futuros

areas a se explorar com os protocolos de gerenciamento do ciclo de

vida de chaves criptogr

aﬁcas do OpenHSM s

ao in

umeras, servindo de tema para v

arios

trabalhos futuros.

Uma destas

areas

e o estudo detalhado para modelar e analisar ce-

rim

onias, que desempenham papel fundamental na operacionalizac¸

ao de um HSM, pre-

enchendo lacunas que hardware e software n

ao s

ao capazes de resolver. Adicionalmente,

elas podem ser extendidas, integrando procedimentos de manipulac¸

ao de outros sistemas,

como no caso de uma autoridade certiﬁcadora, onde o software de gest

ao de certiﬁcados

tamb

em requer atenc¸

ao especial.

Outra

area importante de estudo

e a an

alise formal dos protocolos do

OpenHSM, com o intuito de comprovar formalmente a efetividade dos mesmos no geren-

ciamento do ciclo vida das chaves criptogr

aﬁcas gerenciadas em um HSM.

Finalmente, espera-se o aprimoramento dos HSMs comerciais, de

forma que estes passem a suportar funcionalidades de r

ıgido controle de suas c

opias de

seguranc¸a e de utilizac¸

ao de m

ultiplas inst

ancias operacionais da mesma chave.

Refer

encias Bibliogr

aﬁcas

[1] REDE Nacional de Ensino e Pesquisa RNP. Dispon

ıvel em: <http://www.rnp.br/>.

[2] SCHILLER, J. Protecting a Private Key in a CA Context. out. 2000. Dispon

ıvel em:

<http://www.cren.net/crenca/pkirscpages/private key.html>.

[3] SOUZA, T. C. S. Aplicac¸

oes embarcadas para gerenciamento de chaves crip-

togr

aﬁcas. [S.l.], 2005.

[4] MARTINA, J. E. Project of a Hardware Security Module focused on Public Key In-

frastructures and its Applications. Dissertac¸

ao (Mestrado) — Federal University of

Santa Catarina, March 2005.

[5] MARTINA, J. E.; SOUZA, T. C. S. de; CUST

ODIO, R. F. OpenHSM: An open

key life cycle protocol for public key infrastructure’s hardware security modules. In:

LOPEZ, J.; SAMARATI, P.; FERRER, J. L. (Ed.). EuroPKI. [S.l.]: Springer, 2007.

(Lecture Notes in Computer Science, v. 4582), p. 220–235. ISBN 978-3-540-73407-9.

[6] SOUZA, T. C. S. de; MARTINA, J. E.; CUST

ODIO, R. F. Audit and backup

procedures for hardware security modules. In: SEAMONS, K. E.; MCBUR-

NETT, N.; POLK, T. (Ed.). IDtrust ’08: Proceedings of the 7th symposium on

Identity and trust on the Internet. ACM, 2008. (ACM International Conference

Proceeding Series, v. 283), p. 89–97. ISBN 978-1-60558-066-1. Dispon

ıvel em:

<http://doi.acm.org/10.1145/1373290.1373302>.

[7] RANKL, W. W.; EFFING, W. Smart Card Handbook. Third. pub-WILEY:adr: John

Wiley and Sons, Inc., 2004. xxviii + 1120 p. ISBN 0-470-85668-8.

[8] USB 2.0 TECHNICAL WORKING GROUPS. Universal Serial Bus Revision 2.0

speciﬁcation. [S.l.], abr. 2000. Http://www.usb.org/developers/data/usb 20.zip.

[9] RIVEST, R. L.; SHAMIR, A.; ADLEMAN, L. A method for obtaining digital sig-

natures and public-key cryptosystems. Commun. ACM, ACM, New York, NY, USA,

v. 21, n. 2, p. 120–126, 1978. ISSN 0001-0782.

[10] COOPER, D. et al. Internet X.509 Public Key Infrastructure Certiﬁcate and Certiﬁ-

cate Revocation List (CRL) Proﬁle. abr. 2008. Internet RFC 5280.

[11] ISO 7816 - Smart Card Standards Overview. ISO Standards, 1998. Dispon

ıvel em:

<http://www.iso.org/>.

[12] RSA Laboratories. PKCS #15 v1.1: Cryptographic Token Informa-

tion Syntax Standard. pub-RSA:adr, jun. 2000. 81 p. Dispon

ıvel em:

<http://www.rsasecurity.com/rsalabs/pkcs/pkcs-15/index.html>.

[13] LEE, A.; BARKER, E. B.; BARKER, W. C. Guideline for Implementing Crypto-

graphy in the Federal Government. [S.l.], dez. 2005.

[14] MENEZES, A. J.; OORSCHOT, P. C. van; VANSTONE, S. A. Hand-

book of Applied Cryptography. CRC Press, 1997. (CRC Press series on dis-

crete mathematics and its applications). ISBN 0-8493-8523-7. Dispon

ıvel em:

<http://www.cacr.math.uwaterloo.ca/hac/index.html>.

[15] ISO/IEC STANDARD 15408. Common Criteria for Information Tech-

nology Security Evaluation. version 3.1. [S.l.], set. 2006. Dispon

ıvel em:

<http://www.commoncriteriaportal.org/ﬁles/ccﬁles/CCPART1V3.1R1.pdf>.

[16] National Institute of Standards and Technology (NIST). Security Require-

ments for Cryptographic Modules. maio 2001. Federal Information Proces-

sing Standards Publication (FIPS PUB) 140-2. Updated 2002-12-03. Dis-

pon

ıvel em: <http://csrc.nist.gov/publications/ﬁps/ﬁps140-2/ﬁps1402.pdf,

http://csrc.nist.gov/cryptval/140-2.htm>.

[17] National Institute of Standards and Technology (NIST). Security Requirements for

Cryptographic Modules. jan. 1994. Federal Information Processing Standards Publi-

cation (FIPS PUB) 140-1. Dispon

ıvel em: <http://csrc.ncsl.nist.gov/ﬁps/ﬁps1401.pdf,

http://csrc.ncsl.nist.gov/ﬁps/ﬁps1401.htm>.

[18] FEDERAL COMMUNICATIONS COMMISSION. Code of Fede-

ral Regulations, Title 47, Part 15, Subpart B, Unintentional Radia-

tors, Digital Devices, v. 1. http://frwebgate.access.gpo.gov/cgi-bin/get-

cfr.cgi?TITLE=47&PART=15&SECTION=101&YEAR=1998&TYPE=TEXT:

FEDERAL COMMUNICATIONS COMMISSION, 1998.

[19] Instituto Nacional de Tecnologia da Informac¸

ao (ITI). Requisitos, Materiais e

Documentos T

ecnicos para Homologac¸

ao de M

odulos de Seguranc¸a Criptogr

aﬁca

(MSC) no

Ambito da ICP-Brasil. nov. 2007. Manual de Condutas T

ecnicas (MCT)

7. Dispon

ıvel em: <http://www.iti.br/twiki/pub/Homologacao/Documentos/MCT7 -

Vol.I.pdf>.

[20] INSTITUTO Nacional de Tecnologia da Informac¸

ao ITI. Dispon

ıvel em:

<http://www.iti.br/>.

[21] BRASIL. Medida Provis

oria No 2.200-2. 2001. Medida Provis

oria. Dispon

ıvel em:

<http://www.iti.br/twiki/bin/view/Certiﬁcacao/MedidaProvisoria>.

[22] National Institute of Standards and Technology. Data Encryption Standard (DES).

out. 1999. FIPS Publication 46-3.

[23] DAEMEN, J.; RIJMEN, V. Rijndael for AES. In: AES Candidate Conference. [S.l.:

s.n.], 2000. p. 343–348.

[24] RSA Laboratories. PKCS #1 v2.1: RSA Cryptography Standard. pub-RSA:adr,

jun. 2002. 61 p. Dispon

ıvel em: <http://www.rsasecurity.com/rsalabs/pkcs/pkcs-

1/index.html>.

[25] PROCESSING Standards Publication 180-2. fev. 29 2004. Dispon

ıvel em:

<http://citeseer.ist.psu.edu/641912.html; http://csrc.nist.gov/publications/ﬁps/ﬁps180-

2/ﬁps180-2withchangenotice.pdf>.

[26] MICROSOFT CryptoAPI and Cryptographic Service Providers.

[27] RSA. PKCS #11: Cryptographic Token Interface Standard. [S.l.], abr.

1997. Version 2.0. Dispon

ıvel em: <ftp://www.rsa.com/pub/pkcs/ps/pkcs-11.ps,

ftp://www.rsa.com/pub/pkcs/ascii/pkcs-11.asc>.

[28] EUROPEAN UNION. Directive 2002/95/EC of the European Parliamente and of

the Council. [S.l.], jan. 2003.

[29] EUROPEAN UNION. DIRECTIVE 2002/96/EC OF THE EUROPEAN PARLIA-

MENT AND OF THE COUNCIL. [S.l.], jan. 2003.

[30] THE OpenSSL Project. Dispon

ıvel em: <http://www.openssl.org/>.

[31] FREIER, A. O.; KARLTON, P.; KOCHER, P. C. The SSL Protocol — Version 3.0.

nov. 1996. Internet Draft, Transport Layer Security Working Group.

[32] DIERKS, T.; ALLEN, C. The TLS Protocol Version 1.0. nov. 1997. Internet Draft,

TLS working group.

[33] APACHE HTTP Server Project. Dispon

ıvel em: <http://httpd.apache.org/>.

[34] RSA Laboratories. PKCS #10 v1.7: Certiﬁcation Request Syn-

tax Standard. pub-RSA:adr, maio 2000. 10 p. Dispon

ıvel em:

<http://www.rsasecurity.com/rsalabs/pkcs/pkcs-10/index.html>.

[35] GORA, W. ASN.1 - Abstract Syntax Notation One. Bergheim: Datacom-Verlag,

1992. ISBN 3-89238-062-7.

[36] VIEGA, J.; MESSIER, M.; CHANDRA, P. Network Security with OpenSSL:

Cryptography for Secure Communications. pub-ORA:adr: O’Reilly & As-

sociates, Inc., 2002. xiv + 367 p. ISBN 0-596-00270-X. Dispon

ıvel em:

<http://safari.oreilly.com/059600270X; http://www.oreilly.com/catalog/openssl>.

[37] OPEN Source Software Institute. [S.l.]. Dispon

ıvel em: <http://www.oss-

institute.org/>.

[38] AUTHORITIES, F. .-. C. M. V. FIPS 140-2 Validation Certiﬁcate #642.

Marc¸o 2006. Dispon

ıvel em: <http://csrc.nist.gov/groups/STM/cmvp/documents/140-

1/140crt/140crt642.pdf>.

[39] KELLAR, S. S. NIST-Recommended Random Number Generator

Based on ANSI X9.31 Appendix A.2.4 Using the 3-Key Triple DES

and AES Algorithms. pub-NIST:adr, jan. 2005. 4 p. Dispon

ıvel em:

<http://csrc.nist.gov/groups/STM/cavp/documents/rng/931rngext.pdf>.

[40] AUTHORITIES, F. .-. C. M. V. FIPS 140-2 Validation Certiﬁcate #733. Feve-

reiro 2007. Dispon

ıvel em: <http://csrc.nist.gov/groups/STM/cmvp/documents/140-

1/140crt/140crt733.pdf>.

[41] AUTHORITIES, F. .-. C. M. V. FIPS 140-2 Validation Certiﬁcate #918. Feve-

reiro 2008. Dispon

ıvel em: <http://csrc.nist.gov/groups/STM/cmvp/documents/140-

1/140crt/140crt918.pdf>.

[42] SHAMIR, A. How to share a secret. Commun. ACM, ACM Press, New York, NY,

USA, v. 22, n. 11, p. 612–613, 1979. ISSN 0001-0782.

[43] DOLEV, D.; YAO, A. C. On the security of public key protocols. IEEE Transactions

on Information Theory, v. 29, n. 2, p. 198–208, 1983.

endice A

Convenc¸

oes

Esta sec¸

ao apresenta as convenc¸

oes usadas nos cap

ıtulos 6 e 7 para des-

crever os algoritmos que implementam os protocolos do OpenHSM, com a tabela A.1

listando todos os sistemas de armazenamento de dados utilizadas.

Tabela A.1: Sistemas de armazenamento de dados utilizados no OpenHSM

Entidade Descric¸

ADS sistema de armazenamento de dados de administradores

AudDS sistema de armazenamento de dados de auditores

BDS sistema de armazenamento de dados de backup

BP F pacote do backup

CT L lista de Certiﬁcados Conﬁ

aveis

KDS sistema de armazenamento de dados de chaves

LDS sistema de armazenamento de registro de atividades do sistema

NXD sistema de armazenamento de dados n

ao export

aveis

ODS sistema de armazenamento de dados de operadores

Adicionalmente, apresenta-se a descric¸

ao de todas as func¸

oes utilizadas

nos algoritmos dos protocolos do OpenHSM, explicando seu objetivo e seus par

ametros:

ctDecrypt( ct, edata, eu ) Envia para o smartcard ct os valores de edata e eu. Estes

dados ser

ao ent

ao decifrados utilizando a chave privada dentro do smartcard, resul-

tando, respectivamente, em data e u. O valor retornado do smartcard no ﬁnal da

operac¸

ao ser

a data cifrado com u.

decrypt( edata, k ) Decifra edata utilizando a chave criptogr

aﬁca k (sim

etrica ou as-

sim

etrica).

encrypt( data, k ) Cifra data utilizando a chave criptogr

aﬁca k (sim

etrica ou as-

sim

etrica). Se k

e um certiﬁcado, sua chave p

ublica

e extra

ıda e utilizada.

deleteLog( LDS, rangeDate ) Apaga os registros do sistema armazenados em LDS

dentro do periodo de tempo especiﬁcado por rangeDate.

genCert( id, ku, c

, kr

) Emite um certiﬁcado utilizando ku como chave p

ublica e id

como nome comum. c

e kr

ao respectivamente o certiﬁcado e a chave privada

da autoridade certiﬁcadora que emitir

a o novo certiﬁcado.

genKeyPair() Gera um par de chaves assim

etricas.

genSelfSignedCert( kr, ku, id ) Emite um certiﬁcado auto-assinado contendo a chave

ublica ku e o nome comum id. A assinatura

e realizada com a chave privada kr.

genSessionKey() Gera uma chave sim

etrica.

joinSecret( Ks ) Utiliza o conjunto de partes Ks para reconstruc¸

ao do segredo. Entre-

tanto, Ks deve conter o n

umero m

ınimo de partes conﬁguradas durante o compar-

tilhamento.

load ( DS[, id )] Carrega informac¸

oes do sistema de armazenamento DS. (DS tamb

pode representar o computador utilizado na manipulac¸

ao do HSM). Opcional-

mente, pode ser adicionado um identiﬁcador, id, que ir

a restringir o conjunto de

informac¸

oes resultantes.

manageKey( id, kr, ku, policy ) Submete o par de chaves gerenciadas ku e kr, identiﬁ-

cada por id, ao controlador de chaves carregadas, ﬁcando dispon

ıvel para uso por

aplicac¸

oes externas ao HSM. A chave respeitar

a a pol

ıtica de uso pol icy.

revokeGroupCerts( DS, id ) Revoga os certiﬁcados de todos os membros de um grupo

identiﬁcado por id. Os dados dos membros e seus certiﬁcados s

ao carregados de

DS.

sign( data, kr ) Assina os dados contidos em data utilizando a chave privada kr.

splitSecret( ks, k, n ) Compartilha ks utilizando o mecanismo de compartilhamento de

segredo, utilizando os limiares k e n, respectivamente, a quantidade de partes resul-

tantes do compartilhamento e o n

umero m

ınimo de partes necess

arias para recons-

truir ks.

store ( DS, ... ) Armazena todos os dados passados por par

ametro no sistema de arma-

zenamento DS.

xor ( ks1, ks2 ) Realiza a operac¸

ao ou-exclusivo entre o conte

udo de ks1 e ks2.

Livros Grátis
( http://www.livrosgratis.com.br )
 
Milhares de Livros para Download:
 
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas

Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo
 
 