desenvolvimento de um driver de dispositivo biom etrico ... · inicialmente o objetivo desse...

Coordenacao de Engenharia da Computacao

Desenvolvimento de um Driver de

Dispositivo Biometrico com Comunicacao

USB

Rafael Casale Abe

Trabalho de formatura apresentado a Faculdade de Engenhariade Sorocaba - FACENS, como parte dos pre-requisitos para aobtencao do tıtulo de Engenheiro da Computacao

Sorocaba/SP

2005

Rafael Casale Abe

Desenvolvimento de um Driver de Dispositivo Biometrico com

Comunicacao USB

Trabalho de formatura apresentado a Faculdade de Engenhariade Sorocaba - FACENS, como parte dos pre-requisitos para aobtencao do tıtulo de Engenheiro da Computacao

Orientador: Eng. Fabio Lopes Caversan

Sorocaba/SP

2005

i

Dedicatoria

Dedico esse trabalho de conclusao de curso ao meu pai Nobuo e minha mae Teresa,

por serem para mim, exemplos de luta e auto-superacao.

“Aprender, Produzir e Divulgar”

ii

Agradecimentos

Gostaria de agradecer imensamente todos aqueles que, direta ou indiretamente, con-

tribuiram para a realizacao desse trabalho:

- A Deus, o criador, por propiciar condicoes para o meu desenvolvimento pessoal,

profissional e academico, por me deixar conhecer o sabor da vitoria apos a luta e me

ensinar muito mais com as derrotas;

- A toda minha famılia, meu pai Nobuo, minha mae Teresa, meus irmaos Flavia e

Rodrigo, meus tios, tias e minha avo, por serem as pessoas que sao, e por me incentivarem

sempre nos projetos de minha vida;

- A minha namorada, Juliana, por ter conseguido me aturar nesse ano;

- Ao meu orientador eng. Fabio Caversan, por me incentivar, acreditar no meu traba-

lho e criar condicoes para o desenvolvimento desse projeto e tambem por me ajudar com

muitas das duvidas sobre TeX;

- Ao hacker Cristiano Rodrigues, que mesmo sem o conhecer pessoalmente, me for-

neceu informacoes valiosas que foram cruciais para o desenvolvimento desse trabalho;

- Aos professores, eng. Edinei Legaspe e eng. Sidney Montebeller, por me ajudarem

a “digerir” numeros hexadecimais e interpreta-los.

- A professora Tiemi Sakata e ao professor Carlos Watanabe, pelo incentivo e ensina-

mentos sobre a ferramenta TeX;

- Ao Marcos Abreu, coordenador de desenvolvimento da Simpress, que salvou o de-

senvolvimento desse projeto, fornecendo recursos tecnologicos, alem do imenso espaco que

me foi aberto, dando-me flexibilidade para conciliar trabalho e esse projeto;

- Aos advogados, prof. Dr. Gilberto e Dra. Luciene Gonzales, por me ajudarem com

materiais sobre criminalıstica e medicina legal, alem de me esclarecerem sobre os efeitos

jurıdicos desse projeto.;

- Aos manos do 3 Divisa, Cesar Rodrigo, Emerson Machado, Jupercio Juliano e Ro-

iii

drigo Pillon, que estavam sempre dispostos a ajudar uns aos outros durante todo o projeto,

alem serem engrenagens importantes para o desenvolvimento das disciplinas durante os

anos de faculdade;

- Aos meus amigos Alexandre Coconesi, Rafael Mosan, Roberto Mosan e Thiago Alves

Siqueira, por serem simplesmente amigos.

- Por fim, a toda comunidade de Software Livre do Brasil e do mundo, por disponibi-

lizarem softwares legais e de alta qualidade, documentacoes tecnicas e muito codigo-fonte

para que eu pudesse aprender com eles.

iv

Sumario

Lista de Figuras viii

Lista de Tabelas x

Resumo xi

Abstract xii

1 Introducao 1

2 Biometria 3

2.1 Datiloscopia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Sistema Vucetich . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.2 Detalhes de Galton . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.3 Idenficacao e Verificacao . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Sistemas biometricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Seguranca da Informacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Sistemas Operacionais 10

3.1 Maquina Extendida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 Componentes de um SO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2.1 Gerenciamento de processos . . . . . . . . . . . . . . . . . . . . . . 11

3.2.1.1 Processos . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2.1.2 Estados de Processos . . . . . . . . . . . . . . . . . . . . . 11

3.2.1.3 Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

v

3.2.1.4 Comunicacao Interprocessos . . . . . . . . . . . . . . . . . 13

3.2.1.5 Condicao de disputa . . . . . . . . . . . . . . . . . . . . . 14

Semaforos . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Mutexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.2 Entrada e Saıda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.2.1 Dispositivos de E/S . . . . . . . . . . . . . . . . . . . . . 14

3.2.2.2 E/S Programada . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.2.3 E/S Orientada a Interrupcao . . . . . . . . . . . . . . . . 16

3.2.3 Sistemas de Arquivos . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.3.1 Arquivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.3.2 Diretorios . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3 Classes de Dispositivos e Modulos . . . . . . . . . . . . . . . . . . . . . . . 19

3.3.1 Drivers de caractere . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.2 Major e Minor Numbers . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.2.1 Metodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Comunicacao USB 23

4.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1.1 Topologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1.2 Host USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1.3 Dispositivos USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1.3.1 Hubs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1.3.2 Funcoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Modelo de Transferencia de Dados . . . . . . . . . . . . . . . . . . . . . . . 26

4.2.1 Protocolo de barramento . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2.1.1 Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2.1.2 Pipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

vi

4.2.2 Tipos de transferencia . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2.2.1 Controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2.2.2 Isocrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2.2.3 Interrupcao . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2.2.4 Bulk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3 URBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5 Desenvolvimento 30

5.1 Requisitos do software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.1.1 Materiais utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2 Projeto BiopodUsbDriver . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2.1 O Dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2.2 Esquema do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2.3 Aquisicao do Protocolo . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.2.4 Biblioteca de Acesso a USB (LibUsb) . . . . . . . . . . . . . . . . . 33

5.2.5 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.2.5.1 Protocolo - Controle . . . . . . . . . . . . . . . . . . . . . 36

5.2.5.2 Protocolo - Configuracao dos Registradores . . . . . . . . 37

5.2.5.3 Protocolo - Requisicao . . . . . . . . . . . . . . . . . . . . 37

5.2.5.4 Protocolo - Dados propriamente ditos . . . . . . . . . . . 38

5.2.5.5 Definicao da imagem . . . . . . . . . . . . . . . . . . . . . 38

5.2.5.6 BiopodUsbDriver . . . . . . . . . . . . . . . . . . . . . . . 39

6 Resultados 41

6.1 Testes e Analise dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . 41

7 Conclusoes 45

vii

Referencias 46

viii

Lista de Figuras

2.1 Elementos basicos de uma impressao digital, retirado de (COSTA, 2001) . . 4

2.2 Classes fundamentais de Vucetich, retirado de Gumz (2002) . . . . . . . . 5

2.3 Detalhes de Galton, retirado de Costa (2001) . . . . . . . . . . . . . . . . . 5

2.4 Pilares da seguranca da informacao, retirado de Siqueira (2004) . . . . . . 9

3.1 Abstracao de uma memoria com varios jobs na memoria . . . . . . . . . . 12

3.2 Diagrama de estados de um processo, adaptado de Silberchatz, Galvin e

Gagne (2002) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3 Processos simples e multi-thread, adaptado de Silberchatz, Galvin e Gagne

(2002) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.4 Estrutura de diretorios hierarquizada, retirado de Sakata (2005) . . . . . . 19

3.5 Arvore de diretorio Unix - Simplificado, adaptado de Bach (1990) . . . . . 19

3.6 Parte do conteudo do diretorio /dev, exibindo os tipos de dispositivos. . . . 21

4.1 Topologia fısica de um subsitema USB, retirado de USB.org (2005) . . . . 24

4.2 Concentrador de pontos de dispositivos, retirado de USB.org (2005) . . . . 25

5.1 Sensor biometrico utilizado no projeto . . . . . . . . . . . . . . . . . . . . 31

5.2 Software Omni Password, aquisitando uma impressao digital . . . . . . . . 32

5.3 Esquema do projeto para obtencao de uma impressao digital . . . . . . . . 33

5.4 Tela SnoopyPro - Sniffer USB . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.5 Comando lsmod, exibindo os modulos carregados em um sistema operacio-

nal Slackware GNU/Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.6 Informacoes de dispositivos montados na estrutura usbfs . . . . . . . . . . 36

5.7 Fluxograma do driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

ix

6.1 Primeiro resultado obtido, imagem formada com o bytes da forma como

eram aquisitados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.2 Imagem com resolucao 90x90 pixels e com sequencia de bytes invertido . . 42

6.3 Teste realizado para verificacao da rotacao da imagem . . . . . . . . . . . . 42

6.4 Primeira imagem de uma impressao digital aquisitada . . . . . . . . . . . . 43

6.5 Impressao digital aquisitada e rotacionada em noventa graus . . . . . . . . 43

6.6 Impressoes digitais aquisitadas utilizando o BiopodUsbDriver . . . . . . . . 43

x

Lista de Tabelas

5.1 Visao macro do protocolo implementado pelo driver . . . . . . . . . . . . . 37

xi

Resumo

Sistemas de identificacao biometrica vem se tornando cada vez mais populares, tantopara questoes de seguranca, como para automacao empresarial. Porem nem todos osfabricantes de dispositivos biometricos disponibilizam drivers para plataformas livre comoo GNU/Linux. Modulos ou drivers de dispositivo sao componentes de software muitoimportantes em sistemas de computadores, pois permitem o acesso ao hardware e porapresentarem uma interface mais simples ao usuario programador.

Esse documento apresenta a teoria utilizada para o desenvolvimento de um drivere detalha a criacao de um modulo de dispositivo de um sensor biometrico que utiliza aporta de comunicacao USB, para a plataforma GNU/Linux. O software desenvolvido elivre esta licenciado sob os termos GNU GPL versao 2.

xii

Abstract

Automatic systems for biometric identification have became most popular every day,for security and even in business automation. Therefore, not all biometric device dri-vers are avaiable for free plataform. Device drivers are software blocks very importantfor computer systems, because they allow hardware acess and offers an interface to theprogrammer.

This document presents a basic theory about device drivers development and describesthe building of a module to an USB biometric sensor for GNU/Linux operating system.As the Linux kernel and whole GNU tools, the software created during this project istotaly free and its under the terms of GNU GPL version 2.

1 Introducao

Em um mundo globalizado e tecnologico, a conectividade entre dispositivos eletronicos,

de pessoas e dispotivos ou simplesmente de pessoas para pessoas, e fator fundamental para

realizacao de diversas tarefas do dia-a-dia, seja no ambiente de trabalho ou domestico.

Diante da necessidade da utilizacao de recursos de informatica acoplados a um meio

seguro para acesso a informacoes confidenciais e integridade de informacoes, e que tecno-

logias baseadas em biometria e seguranca da informacao tem sido desenvolvidas e melho-

radas.

Devido ao grau de competitividade que se estabelece entre empresas de um setor, e

necessario refletir sobre quais metodos uma companhia pode adotar para que tenha um

diferencial comercial entre seus potenciais clientes. A partir dessa reflexao e tentando

visualizar a concorrencia no mercado de informatica, e estrategicamente ruim o desenvol-

vimento/venda de produtos que tenham alta dependencia tecnologica de empresas mono-

polistas e se que negam a deixar esses produtos (software) independente de plataforma ou

sem qualquer compatibilidade. Empresas desenvolvedoras de perifericos de computador

nao fogem a regra da concorrencia, e nao atender uma determinada fatia do mercado,

pode ser fator crucial para a sobrevivencia.

Drivers de dispositivos sao componentes de software responsaveis por permitir o com-

putador interagir com seus perifericos. Sao os drivers de dispositivos que conhecem o

hardware tratado e como ele se comunica com o computador.

Inicialmente o objetivo desse trabalho foi a criacao de um software livre que fosse

capaz de verificar e autenticar pessoas atraves de suas impressoes digitais, para uma

plataforma tambem livre. Como nenhum dos fabricantes de dispositivos biometricos do

mercado disponibilizam drivers para GNU/Linux ou qualquer outra plataforma livre, o

foco do trabalho foi modificado, passando ser o objetivo e motivacao, a criacao de um

driver de dispositivo livre.

No capıtulo 2, sao apresentados os conceitos de biometria e suas aplicacoes, tecnicas

utilizadas na verificacao e identificacao de pessoas usando a datiloscopia.

No capıtulo 3 e feito um estudo de software de interfaceamento e sistemas operacionais,

1

2

explorando conceitos importantes de acesso, controle e interfacemento de dispositivos de

computador, chegando ate o assunto sobre drivers de dispositivos, que e o foco dessa

monografia.

No capıtulo 4 e apresentado uma visao geral da arquitetura do padrao USB e como e

feita a comunicacao entre um dispositivo e um computador atraves dessa porta.

O capıtulo 5 e referente ao processo de desenvolvimento do software prosposto, onde

sao mostradas em detalhes as etapas para a criacao de um driver de dispositivo.

Ja no capıtulo 6, os resultados, tanto positivos como negativos, sao apresentados e e

feita uma analise crıtica destes, podendo se tirar conclusoes fundamentadas em teoria e

pratica.

2 Biometria

Ha tempos o homem estuda o comportamento dos seres vivos e utiliza muito do que

encontra na natureza na melhoria da qualidade de vida da sociedade. Homens ancestrais

sao diferenciados por geologos e historiadores pelo seu porte fısico, caracterısticas da

estrutura ossea e arcada dentaria, ou seja, medidas do corpo.

O termo biometria vem do latim e significa bio: vida; metria: metrica, medida. Ou

seja, e a medida dos seres vivos atraves de suas caracterısticas fısicas. E atraves da

biometria que e possıvel a identificacao unica de pessoas. (DIAS, 2005), (BIOMETRIA-

WIKIPEDIA, )

2.1 Datiloscopia

A datiloscopia e o estudo dos desenhos formados pelas papilas dermicas ao nıvel de

polpas digitais, ou impressoes digitais. Esses desenhos sao formados no perıodo de vida

intra-uterina (perto do sexto mes de gestacao humana) e permanecem inalteradas ate o

final da vida de um indivıduo (GUMZ, 2002), (MARANHaO, 1989).

Conforme Costa (2001), “a palavra datiloscopia ou dactiloscopia e uma palavra de

origem grega e composta dos elementos: daktylos = dedos e skopein = examinar, ou seja,

e a analise dos dedos das maos ou pes”. Pode-se dizer entao que e o estudo biometrico

utilizando os dedos como forma de medicao.

Uma impressao digital e composta basicamente de tres elementos: nucleo, deltas e

linhas. O nucleo e uma formacao das linhas encontrado no centro de uma impressao

digital. Os deltas sao figuras formadas pela juncao de linhas de varios sentidos, fazendo

parecer um triangulo. Deltas sao importantes na classificacao de impressoes digitais, pois

a partir deles e de sua quantidade pode-se dividir um sistema de linhas em diversas classes,

como mostra a figura 2.1 (COSTA, 2001).

A partir dos deltas e possıvel tambem dividir uma impressao digital em varias regioes

(MARANHaO, 1989), (COSTA, 2001):

• Regiao marginal: regiao que representa as formacoes papilares nas margens da im-

3

4

Figura 2.1: Elementos basicos de uma impressao digital, retirado de (COSTA, 2001)

pressao digital.

• Regiao nuclear: regiao central, onde normalmente se encontra o nucleo (na existencia

dele).

• Regiao basilar: regiao abaixo da regiao central e e a base (referencia) de uma im-

pressao digital.

2.1.1 Sistema Vucetich

O argentino Juan Vucetich foi o criador do primeiro sistema de verificacao utilizando

impressoes digitais. Baseando-se nos estudos feitos por Galton e outros, Vucetich dividiu

uma impressao digital em quatro classes fundamentais. Abaixo sao apresentadas as classes

propostas por Vucetich: (MARANHaO, 1989)

• Arco: nao possui regiao nuclear definida. Neste caso, as regioes basilar e maginal se

continuam de um ponto ao outro.

• Presilha externa: regiao nuclear presente, porem marginalizado para a esquerda.

Contem um unico delta e situado a esqueda do observador.

• Presilha interna: regiao nuclear presente, porem marginalizado para a direita. Contem

um unico delta e situado a direita do observador.

• Verticilio: regiao nuclear e bem definida e situada no centro do desenho. Tem

caracterısticas oval, espiral e sinuoso.

5

Essas classes servem apenas para separar as impressoes digitais em grandes grupos e e

baseado no numero de deltas com suas respectivas posicoes, nao sendo possıvel identificar

unicamente uma pessoa. (GUMZ, 2002) E util na area criminalıstica para determinar se,

por exemplo, a impressao digital de um suspeito de um crime faz parte ou nao da classe

de uma impressao digital encontrada no local do crime.

Figura 2.2: Classes fundamentais de Vucetich, retirado de Gumz (2002)

2.1.2 Detalhes de Galton

Segundo Maranhao (1989), “as minucias ou pontos caracterısticos sao resultados de

acidentes apresentados pelas linhas (ou cristas) papilares e representam a garantia de

unicidade em impressoes digitais”. As minucias sao divididas em cinco grupos: cristas

finais, ilhas, bifurcacoes, cruzamentos e esporas. (COSTA, 2001), (GUMZ, 2002)

Uma crista final e uma linha que se interrompe abruptamente. Ja a bifurcacao e uma

linha que da origem a outras duas linhas, separadas por determinada angulacao. Ilhas ou

lagos sao formados por uma bifurcacao que termina convergindo em um mesmo ponto. A

imagem 2.4 ilustra claramente esses pontos (COSTA, 2001), (GUMZ, 2002).

Figura 2.3: Detalhes de Galton, retirado de Costa (2001)

6

As minucias sao elementos identificadores e podem ser utilizadas com certo grau de

confiabilidade, fazendo valer as condicoes impostas pela datiloscopia, tratando-se entao

de uma identificacao (e nao reconhecimento). Segundo Costa (2001), doze pontos encon-

trados em uma impressao digital sao suficientes para que seja feita a identificacao uma

pessoa.

2.1.3 Idenficacao e Verificacao

Segundo Maranhao (1989), “identidade e o conjunto de propriedades ou caracterısticas

que tornam alguem essencialmente diferente de todos os demais, com a quem se assemelhe

ou possa ser confundido”. Baseado nessa afirmacao, pode-se dizer que o termo identidade

e o termo que garante a unicidade de um ser ou um objeto. Diferente do termo reco-

nhecimento, que e uma identificacao sem nenhuma base tecnico-cientıfica (MARANHaO,

1989).

Identificacao diferencia-se terminologicamente de reconhecimento, pelo fato de iden-

tificacao ser um metodo baseado em tecnicas cientıficas e o reconhecimento nao. O re-

conhecimento e dito entao, uma identificacao nao cientıfica. Para que um metodo de

identificacao seja aceito como cientıfico, ou seja, que utilize uma tecnica de identificacao

de base cientıfica, ele precisa atender os requisitos abaixo citados (MARANHaO, 1989) :

• Unicidade, a propriedade ou caracterıstica de alguem ou algo ser unico;

• Imutabilidade, que existe sempre e o que nao muda (imutavel);

• Classificabilidade, indicando que caracterısticas podem ser mensuraveis;

• Praticabilidade, que significa que o metodo venha a ser pratico.

E necessario entao fazer uma analise desses resquisitos em relacao as impressoes di-

gitais como forma de identificacao. O conjunto de figuras (ou minucias) que se formam

em uma impressao digital e unico, ou seja, nao existe dois seres com com as mesmas im-

pressoes digitais no mundo, atendendo assim o requisito da unicidade. Conforme citado,

as impressoes digitais de um ser humano mantem-se naturalmente inalteradas ao longo

de sua vida, sendo valida para o requisito imutabilidade. Como o conjunto de carac-

terısticas das impressoes digitais tambem podem ser medidas, ou seja, o encontro de, no

mınimo, doze pontos caracterısticos em impressoes digitais (ou minucias) e com a mesma

7

localizacao, ja e o suficiente para se identificar uma pessoa, o requisito da classificabili-

dade tambem e atendido. A praticabilidade e um termo que poderia ser substituido por

viabilidade. Tomando um exemplo, um metodo de identificacao atraves da analise do

DNA 1 e teoricamente possıvel, porem nao em termos praticos, pois ter de tirar sangue

ou depositar um fio de cabelo toda vez que for retirar dinheiro de um sistema bancario

seria um tanto quanto desagradavel (COSTA, 2001), (MARANHaO, 1989).

2.2 Sistemas biometricos

A exigencia por aumento de seguranca, a facilidade e a comodidade fizeram com

que os sistemas biometricos automaticos tivessem uma maior aceitacao no mercado nas

ultimas decadas. Alem do intenso uso em criminalıstica, abaixo sao apresentadas algumas

aplicacoes desses sistemas (JuNIOR; JuNIOR, 1979), (MARANHaO, 1989) :

• Comercio eletronico: Seguranca aliado a confiabilidade e o desejo de qualquer

usuario de internet como potencial consumidor. Muitos desses usuarios sentem-se

coagidos em fazer compras pela internet em funcao da falta de seguranca ou da falta

de conhecimento sobre sistemas seguros. E por causa desse receio que empresas de

comercio eletroncio, principalmente B2C2, vem investindo cada vez mais em solucoes

que envolvem sistemas biometricos. (ROMAGNOLI, 2005)

• Acesso fısico: A tecnologia biometrica vem sendo utilizada com maior frequencia

em ambientes que necessitam do controle das pessoas que entram e saem. Para se

ter acesso a uma determinada sala ou area, uma empresa pode optar em utilzar a

biometria ao inves crachas com nıveis de acesso, garantindo dessa forma uma maior

seguranca e minimizando ocorrencias de fraude. (ARAGAKI, 2005)

Existem inumeras aplicacoes que utilizam tecnologia biometria, dos mais variados

tipos. Outras tecnicas alem da datiloscopia podem ser citadas como por exemplo leitura

da ıris, reconhecimento facial e o reconhecimento de voz.

1Sigla inglesa para Acido Desoxirribonucleico2Sigla inglesa que designa relacionamento comercial entre empresas e consumidores

8

2.3 Seguranca da Informacao

A palavra seguranca pode ter diversos significados e esses significados podem ser

abrangentes de pessoa para pessoa, mas basicamente se resume em um sentimento de

conforto perante determinada situacao.

Informacao sempre foi considerado patrimonio importante, seja para uma organizacao

privada, publica ou para um Estado. Preserva-las de outrem que pudesse fazer mal usos,

e tarefa que preocupa empresariados e autoridades (DIAS, 2005).

Com o advento dos computadores e suas interconexoes em rede, permitiu repescti-

vamente a concentracao de informacoes em formato digital e a facilidade em seu acesso.

No sentido contrario, computadores concentradores de informacoes passaram a ser alvo

constante de ataques (DIAS, 2005).

Segundo Siqueira (apud RUSSEL; GANGEMI, 1991), a seguranca da informacao e

baseada nas definicoes dos termos confidencialidade, integridade e na disponibilidade dos

recursos computacionais. Esses tres parametros sao considerados pilares da seguranca da

informacao e estao descritos a seguir (DIAS, 2005), (SIQUEIRA, 2004) :

• Confidencialidade: Protecao da informacao contra acessos nao autorizados.

• Integridade: Preservacao da informacao quanto a alteracoes, violacoes ou des-

truicoes, por ato malicioso ou nao.

• Disponibilidade: Garantia de acesso as informacoes sob demanda e sem atraso.

O nao cumprimento dessa medida quando necessario pode ser tao ruim quanto a

destruicao de um dado.

Sistemas de idenficacao biometrica sao grandes aliados para a mantenibilidade dos

pilares da seguranca da informacao.

9

Figura 2.4: Pilares da seguranca da informacao, retirado de Siqueira (2004)

3 Sistemas Operacionais

Um sistema operacional e um programa de computador que tem como funcao gerenciar

recursos (hardware e software) de um sistema computacional. O seu proposito e prover um

ambiente mais simples e produtivo para o usuario (TANENBAUM, 2003), (SILBERCHATZ;

GALVIN; GAGNE, 2002).

3.1 Maquina Extendida

Computadores sao maquinas eletronicas que utilizam puramente linguagem de maquina.

Essa linguagem e geralmente de difıcil programacao, principalmente para acessos de en-

trada e saıda (E/S), (TANENBAUM, 1992) , (TANENBAUM, 2003). Uma das tarefas

de um sistema operacional e ocultar do usuario programador as entrelinhas de acesso ao

hardware, apresentando uma interface mais simples. Quer dizer entao que o Sistema Ope-

racional estende o hardware do computador para o usuario, como uma maquina virtual

(TANENBAUM, 2003).

3.2 Componentes de um SO

Em um sistema operacional, varios processos concorrentes atendem por diferentes

tarefas quase simultaneamente e cada um desses processos requisitam diversos recursos

do sistema, seja por processamento, memoria, conectividade, ou outros. O kernel (nucleo)

e a parte do sistema operacional responsavel por gerenciar essas requisicoes e essas tarefas

podem ser divididas em cinco partes (RUBINI; CORBET; KROAH-HARTMAN, 2005) :

• Gerenciamento de memoria

• Gerenciamento de processos

• Sistemas de arquivos

• Controle de dispositivos (E/S)

• Rede

10

11

3.2.1 Gerenciamento de processos

Sistemas operacionais modernos possuem recursos extremamente eficientes para su-

prir a necessidade de varios usuarios acessarem o mesmo sistema, assim como ter varios

programas executando diversas tarefas ao “mesmo tempo”. Um dos responsaveis em

manter um sistema multiprogramado, multitarefa e multiusuario com boa performance

e a caracterıstica de gerenciamento de processos (SILBERCHATZ; GALVIN; GAGNE,

2002) , (STALLINGS, 2000).

3.2.1.1 Processos

Um processo pode ser definido como a abstracao de um programa em execucao e que

e acompanhado por variaveis e registradores do sistema (TANENBAUM, 2003).

Computadores modernos tem a capacidade de executar varias tarefas ao mesmo

tempo, isso e devido a caracterıstica do sistema operacional de ser multiprogramado.

Um sistema e considerado multiprogramado, quando ele tem a capacidade de colocar

varias tarefas na memoria e executa-las de forma parcial ou total (TANENBAUM, 2003),

(SAKATA, 2005).

Em sistemas multitarefa, cada tarefa na memoria e executada pela CPU durante um

tempo maximo e entao e alternada por outra tarefa que estava pronta para ser executada,

mesmo que a primeira nao tenha sido concluıda. Quando existe um tempo maximo para

execucao de um processo pela CPU, e necessario a presenca de um escalonador, cuja res-

ponsabilidade e alternar a execucao dos processos entre a CPU e a memoria, baseando-se

nos estados de cada processo (TANENBAUM, 2003), (SILBERCHATZ; GALVIN; GAGNE,

2002).

3.2.1.2 Estados de Processos

Em funcao da caracterıstica de multiprogramacao, aliado a presenca de um esca-

lonador, um processo pode situar-se em diferentes estados, que representa seu grau de

atividade, como mostra a figura 3.2. Os estados que um processo pode ser encontrar sao

os seguintes (SILBERCHATZ; GALVIN; GAGNE, 2002) , (TANENBAUM, 2003) :

• Novo: Processo em estado de criacao.

• Em execucao: As instrucoes do processo estao sendo executadas pela CPU.

12

Figura 3.1: Abstracao de uma memoria com varios jobs na memoria

• Bloqueado: O processo fica incapaz de executar esperando pela ocorrencia de um

evento.

• Pronto: O processo esta pronto para ser executado, aguardando na fila de prontos.

• Finalizado: O processo finalizou sua execucao.

Figura 3.2: Diagrama de estados de um processo, adaptado de Silberchatz, Galvin eGagne (2002)

Os estados dos processos indicam qual sua real situacao e sao importantes para que

o escalonador organize as tarefas a serem executas, assim como sua ordem e prioridade.

13

3.2.1.3 Threads

“Os threads sao entidades escalonadas para a execucao sobre a CPU” (TANENBAUM,

2003). O thread esta sempre contido em um processo e pode ser considerado uma unidade

basica de utilizacao do processador. Processos tradicionais utilizam geralmente apenas

um thread (linha) de controle por vez, porem em determinadas situacoes uma aplicacao

pode necessitar executar diversas tarefas concorrentemente, como se fossem processos

separados. (SILBERCHATZ; GALVIN; GAGNE, 2002)

Cada thread de um processo contem um conjunto de registradores e uma estrutura de

pilha, o que lhes permite trabalhar de forma independente. Dessa forma, varias threads

podem trabalhar concorrentemente, o que e chamado de sistema multi-threaded . A

vantagem de um sistema multi-threaded e permitir que varias execucoes ocorram no mesmo

ambiente do processo, aproveitando-se de recursos utilizados pelo processo em execucao

(enderecamento, arquivos aberto, etc) (TANENBAUM, 2003), (SILBERCHATZ; GALVIN;

GAGNE, 2002).

Figura 3.3: Processos simples e multi-thread, adaptado de Silberchatz, Galvin e Gagne(2002)

3.2.1.4 Comunicacao Interprocessos

E com certa frequencia que processos tem de se comunicar. Essa necessidade de

comunicao deve ocorrer de maneira estruturada e sem interrupcoes. Processos utilizam

14

o mesmo espaco de memoria que outros processos e podem utilizar tambem os mesmos

recursos, por exemplo a leitura de um arquivo. Para evitar acessos multiplos a regioes

crıticas ou evitar acessos multiplos a recursos compartilhados, e preciso fazer uso de

alguma tecnica ou de um modelo de protecao (MITCHELL; OLDHAM; SAMUEL, 2001).

3.2.1.5 Condicao de disputa

Condicao de disputa e a situacao ao qual dois ou mais processos em execucao re-

quisitam acesso (leitura ou escrita) a um determinado recurso compartilhado. Como o

escalonador de processos e o responsavel por determinar qual processo sera utilizado, nao

ha como determinar uma sequencia de execucao, sendo necessario a implementacao de

um algoritmo para evitar imprevistos. Caso nao exista um algoritmo para proteger o

acesso a areas restritas unicamente, o resultado de uma operacao pode nao ser o esperado

(TANENBAUM, 2003).

Semaforos Semaforos sao varaveis-contadores que permitem gerenciar e sincronizar

varios processos ou threads. Trabalha com numeros inteiros nao-negativos e provem uma

abstracao simples, muito util para implementacao de exclusao mutua.

Mutexes O mutex e uma versao simplificada de um semaforo e sao indicados para o

gerenciamento de exclusao mutua para recursos do sistema ou partes de codigo, princi-

palmente em threads implementadas em modo usuario.

3.2.2 Entrada e Saıda

Uma outra tarefa essencial de um sistema operacional e o gerenciamento de dispo-

sitivos de entrada e saıda (E/S). A arquitetura de E/S constitui em uma interface do

computador com o mundo exterior e prove ao sistema operacional informacoes de forma

precisa para que esse efetue as requisicoes de E/S de maneira efetiva (STALLINGS, 2002),

(TANENBAUM, 2003).

3.2.2.1 Dispositivos de E/S

Um dispositivo se comunica com um computador enviando sinais atraves de um meio

fısico. As caracterısticas de um dispositivo de entrada e saıda podem variar muito,

tanto em funcionalidades, protocolos e velocidade de comunicacao. Consequentemente

15

os metodos de acesso e controle tambem sao variados. Os dispositivos de entrada e saıda

podem, de uma maneira geral, ser divididos em duas categorias (TANENBAUM, 2003),

(SILBERCHATZ; GALVIN; GAGNE, 2002), (RUBINI, 2001) :

• Dispositivos de caractere: Dispositivos de caractere sao aqueles que nao pos-

suem uma estrutura definida para transmissao de dados, nao sao enderecaveis e nao

contem operacoes de posicionamento de dados. Ou seja, um dispositivo de carac-

tere envia ou recebe um fluxo de caracteres, nao se importando com uma estrutura

definida de blocos.

• Dispositivos de bloco: Dispositivos de blocos sao aqueles que possuem a capa-

cidade de armazenar os dados em blocos de tamanho fixo, contendo cada qual seu

endereco, e que pode ser lido e/ou escrito independentemente de outro bloco.

Em um sistema computacional, os dispositivos de hardware sao conectados em um

computador atraves de um Controlador de Dispositivo. Uma unidade de E/S e com-

posta por uma parte mecanica e por uma parte eletronica. O controlador de dispositivo e

o componente eletronico do controlador e e responsavel por converter sinais emitidos pelo

dispositivo em um formato mais simples para o sistema operacional. Sao responsaveis

tambem por executarem algum algoritmo de correcao de erros, liberando o conteudo em

buffers para ser copiado para a memoria principal. A realizacao desse trabalho e feita

geralmente por um chip com programas de baixo nıvel. A parte mecanica da unidade de

E/S e o dispositivo propriamente dito (TANENBAUM, 2003).

Para se comunicar com o controlador, o processador necessita ler e escrever em regis-

tradores contidos no proprio controlador. Esses registradores podem ser utilizados tanto

para controle como transferencia de dados. Como alternativa, o controlador de dispositivo

pode fazer uso do recurso de memoria mapeada. Esse recurso permite a CPU mapear

todos os registradores do controlador de dispositivo na memoria. Cada registrador e as-

sociado a um endereco unico ao qual nenhuma memoria esta associada (SILBERCHATZ;

GALVIN; GAGNE, 2002), (TANENBAUM, 2003).

Quando um dispositivo termina sua tarefa, ele gera um sinal de interrupcao no

barramento ao qual esta associado para avisar sua atual situacao. Esse sinal e entao

detectado pelo controlador de dispositivo que toma as devidas atitudes. O controlador,

que e responsavel por gerenciar essas interrupcoes, verifica se existe outro pedido de

interrupcao em atendimento e passa o novo sinal a CPU. Isso faz com que a CPU pare

com a sua atividade atual, salve os registradores atuais na pilha e atenda a requisicao

16

de interrupcao. Ao iniciar o tratamento de interrupcao, a rotina responsavel pelo tal,

informa a controladora de dispositivo que ele esta livre para repassar novas interrupcoes,

escrevendo um valor em uma de suas portas de E/S (TANENBAUM, 2003).

3.2.2.2 E/S Programada

Segundo Tanenbaum (2003), a maneira mais simples de se realizar operacoes de E/S

e utilizar o metodo de E/S Programada (ou polling), ou seja, e deixar com que a CPU

realize todo o trabalho. Esse metodo basea-se em um bloco de instrucoes (ou apenas uma

instrucao) fechado em um laco (for, while, etc), onde sua condicao de parada e o termino

da leitura ou escrita no ou do dispositivo em questao.

Primeiramente o dispositivo e requisitado, caso ele esteja ocupado, e retornado um

sinal do controlador indicando geralmente um erro. Uma vez que o dispositivo esteja

disponıvel, o processo do usuario efetua uma chamada do sistema para que um determi-

nado dado seja lido ou escrito. O sistema operacional normalmente copia uma cadeia de

caracteres do espaco do usuario no espaco do nucleo, caso a operacao seja de escrita, ou

o inverso, caso a operacao seja de leitura. Esse processo facilita o acesso da informacao a

ser lida ou escrita (TANENBAUM, 2003).

No espaco do nucleo, o sistema operacional atualiza espcıficos bits de status que

determinam se um dado foi lido ou escrito. Se o bit de estado ocupado estiver “setado”

(valor 1), o processo de leitura ou escrita aguarda ate que o mesmo esteja “resetado”

(valor 0). O sistema operacional le repeditamente bits de estados ocupado e pronto,

efetuando as operacoes de leitura e escrita ate o fim da cadeia de caracteres, metodo

conhecido tambem como espera ociosa (TANENBAUM, 2003).

Esse metodo pode se tornar ineficiente na tentativa repetida de se encontrar um

dispositivo pronto para o servico, enquanto outro importante processo de CPU permanece

inacabado, ou simplesmente nao atendido (SILBERCHATZ; GALVIN; GAGNE, 2002).

3.2.2.3 E/S Orientada a Interrupcao

Em determinados momentos torna-se mais eficiente organizar o controlador de dispo-

sitivo para que notifique a CPU quando um dispositivo termina o processamento de um

sinal e fica disponıvel para novas requisicoes de E/S, ao inves de fazer a CPU verificar

repetidamente pela finalizacao de um processo de E/S atraves do metodo de espera oci-

osa. O mecanismo que possibilita um dispositivo notificar a CPU quando uma operacao

17

e finalizada, e chamada de interrupcao (SILBERCHATZ; GALVIN; GAGNE, 2002).

De forma analoga ao ıtem 3.2.2.2, apos uma cadeia de caracteres ser escrita no espaco

do nucleo e o primeiro caractere enviado ao dispositivo, a CPU invoca o escalonador de

processos fazendo com que outro processo entre em execucao. O processo que solicitou a

E/S fica no estado bloqueado ate que toda cadeia de caracteres seja processada.

A cada cadeia de caracteres processada pelo dispositivo, e gerado um sinal de in-

terrupcao onde a CPU para o processo atual em execucao, salva seu estado na pilha e

atende ao tratamento de interrupcao do dispositivo. Caso exista mais caracteres a serem

processados pelo dispositivo, o ciclo continua. Caso contrario, o processo de usuario que

requisitou o processamento e desbloqueado (TANENBAUM, 2003).

3.2.3 Sistemas de Arquivos

Um sistema de arquivo e a camada do sistema operacional responsavel por prover me-

canismos de armazenamento e gerenciamento de dados. Entende-se por gerenciamento,

o modo como esses dados sao estruturados, gravados, nomeados e utilizados (SILBER-

CHATZ; GALVIN; GAGNE, 2002), (TANENBAUM, 2003).

3.2.3.1 Arquivo

Um arquivo e a unidade logica basica de armazenamento de dados em dispositivos,

normalmente nao volatil. Cada arquivo contem informacoes estruturadas de acordo com

o seu tipo: arquivos texto, programas executaveis, figuras, vıdeo, som, entre outros (SIL-

BERCHATZ; GALVIN; GAGNE, 2002).

E caracterıstica de um sistema operacional suportar varios tipos de arquivos, e es-

ses podem ser classificados em: arquivos regulares e diretorios, arquivos de caractere e

arquivos de bloco.

Arquivos regulares sao basicamente arquivos texto puro em padrao ASCII1 ou ar-

quivos binarios. Os arquivos de caracteres sao utilizados para modelar dispositivos de

entrada/saıda e os arquivos de bloco para modelar discos ou dispositivos de bloco, pro-

priamente dito (TANENBAUM, 2003).

Os arquivos devem manter tambem informacoes de estados, onde podem variar em

1Sigla para American Standard Code for Information Interchange que e um conjunto de codigos parao computador representar numeros, letras, pontuacao e outros caracteres

18

quantidade, de sistema operacional para sistema operacional, mas sao basicamente os

seguintes:

• Nome: e utilizada pelo usuario para identificar e distinguir diferentes arquivos.

• Numero identificador: E um numero (ou uma sequencia de caracteres alfa-

numericos) que identificam unicamente um arquivo. Essa informacao e utilizada

pelo sistema.

• Localizacao: Essa informacao e um ponteiro para o dispositivo e para a localizacao

do arquivo.

• Tamanho: Contem informacoes do tamanho atual do arquivo.

• Data e hora: Data e hora em que o arquivo foi criado, modificado e acessado.

• Dono: informacoes do usuario que criou o arquivo

3.2.3.2 Diretorios

Diretorios sao estruturas logicas que permitem a organizacao e gerenciamento de ar-

quivos em um sistema de arquivo. Em muitos sistemas operacionais os diretorios sao

simplesmente arquivos. Na verdade sao considerados meta-arquivos, ou seja, sao arquivos

simples que contem informacoes sobre a estrutura de diretorios e subdiretorios pertencen-

tes a ele (TANENBAUM, 2003).

Em sistemas de arquivos modernos, a estrutura de diretorios e geralmente repre-

sentada em forma de arvore hierarquizada, ou seja, podem conter arquivos e tambem

diretorios (subdiretorios), conforme visto na figura 3.4.

Esse tipo de hierarquia e bastante utilizada por permitir um usuario criar tantos

diretorios quanto achar necessario para se organizar. Claro que existe um numero limitado

de arquivos/subdiretorios por diretorio, que nao e inerente apenas ao espaco em disco

utilizado e que tambem varia de sistema de arquivo para sistema de arquivo, (SAKATA,

2005).

O Unix tambem possui uma estrutura de diretorios de forma hierarquizada, conforme

mostra a figura 3.5.

De acordo com Bach (1990), para que um sistema Unix ou GNU/Linux realize uma

operacao de entrada ou saıda, ele necessita utilizar um tipo de arquivo chamado descritor

19

Figura 3.4: Estrutura de diretorios hierarquizada, retirado de Sakata (2005)

/ (root)

/usr /dev /etc /bin /home /boot

Figura 3.5: Arvore de diretorio Unix - Simplificado, adaptado de Bach (1990)

de arquivo. Um descritor de arquivo e um numero inteiro, que esta associado a um arquivo

aberto, sendo que esse arquivo pode ser um dispositivo externo, ou um arquivo no disco,

ou qualquer outro dispositivo fısico/logico que esta sob domınio do SO.

3.3 Classes de Dispositivos e Modulos

Um driver de dispositivo ou simplesmente um modulo e um programa de computador

especıfico, responsavel por controlar determinado dispositivo. Tarefas que necessitam de

abstracao do hadrware ou que geralmente sao chamadas de “baixo nıvel”, sao protegidas

pelo sistema operacional que permite apenas alguns programas especiais de acessa-los. Os

modulos, ou drivers de dispositivo, rodam geralmente no espaco do nucleo (ou espaco

do kernel), quais sao os programas que rodam no domınio do kernel ou nucleo. Enquanto

20

programas de aplicacao rodam no espaco do usuario, que representam os programas

que rodam em uma camada superior a camada do kernel (RUBINI, 1998).

O Unix tem uma maneira de distinguir os diferentes tipos de dispositivos. Cada

modulo e geralmente implementado para cada tipo desses dispositivos. (RUBINI, 1998)

Assim como os dipositivos que sao dividos em categorias, um driver por consequencia

segue tambem as mesmas classificacoes (RUBINI, 1998), (RUBINI, 2001):

• Drivers de bloco

• Drivers de caractere

3.3.1 Drivers de caractere

Driver de caractere e classe de modulos de dispositivos que permitem o controle de

dispositivos de caractere, ou seja, tem como caracterıstica nao possuir uma estrutura

definida para os dados (RUBINI, 1998).

Os drivers de caractere podem suportar requisicoes de E/S de tamanho variavel e sao

suportados pela maioria dos dispostivos. Esses tipos de drivers sao comumente utilizados

por dispositivos que trabalham com transferencias de um byte por vez ou transferencias

que nao exigem um tamanho de pacote de tamanho fixo (TUTORIALS. . . , 2001).

3.3.2 Major e Minor Numbers

Como citado em (PERIM, 2001), em sistemas Unix tudo e considerado um arquivo,

inclusive dispositivos sao montados como arquivos na estrutura de arvore do sistema de

arquivos corrente. Dispositivos de caractere sao acessados utilizando-se nomes e que sao

chamados de arquivos especiais, arquivos de dispositivos ou simplesmente nos (nodos).

Pensando ainda na estrutura de diretorios do Unix esses dispositivos sao convencional-

mente alocados no diretorio /dev e sao representados pela letra c indicando que e um

dispositivo de caractere, ao ponto que a letra b indica que o dispositivo e um dispositivo

de bloco, como visto na figura 3.6 (RUBINI; CORBET; KROAH-HARTMAN, 2005).

Os major numbers sao utilizados para identificar qual driver exato deve ser ser as-

sociado ao dispositivo conectado. Esses numeros de identificacao podem ser alocados

dinamincamente pelo driver ou pode-se definir um numero fixo para o dispositivo no sis-

tema. Logicamente essa nao e a melhor escolha, pois, apesar de sistemas operacionais

21

Figura 3.6: Parte do conteudo do diretorio /dev, exibindo os tipos de dispositivos.

modernos permitirem o compartilhamento de major numbers, ainda existe a possibilidade

de conflito (RUBINI, 1998).

Em contrapartida minor numbers tem como funcao identificar para o kernel exata-

mente qual dispositivo esta sendo referenciado, ou seja, e utilizando minor numbers que

o kernel pode diferenciar dois dispositivos identicos conectados ao computador (RUBINI;

CORBET; KROAH-HARTMAN, 2005).

3.3.2.1 Metodos

Um driver de dispositivo deve fornecer metodos basicos de acesso. Esses metodos sao

na verdade chamadas de sistema simples, com certo nıvel de abstracao do hardware, ou

seja, permite a comunicacao com um dispositivo sem necessariamente conhecer os detalhes

de projeto ou mesmo do protocolo de controle deste. Alguns metodos basico do kernel

Linux estao listados a seguir (BACH, 1990), (RUBINI, 1998):

• Open: o nucleo do sistema utiliza o mesmo metodo para abertura de arquivos

especiais (caractere e bloco) como arquivos regulares. Ao requisitar a abertura de

um dispositivo, o sistema aloca o recurso desejado, obtem o descritor de arquivo e

retorna ao processo do usuario.

• Release: ou metodo Close, e tem como funcao fechar a conexao de um dispositivo

aberto.

• Read e Write: sao metodos para leitura e escrita de dispositivos. Quando invocados

para utilizacao de dispostivos de caractere, esse metodo chama o respectivo metodo

de um driver de dispositivo que tem a real funcao de leitura e escrita.

• ioctl: e uma chamada de sistema que recebe tres argumentos: descritor de arquivo

proveniente de uma chamada open ou creat, comando especıfico do driver de dis-

positivo ao qual esta lidando e por ultimo um argumento para esse comando. Com

22

esse tipo de chamada do sistema, e possıvel executar todos os comandos disponıveis

do dispositivo, utilizando apenas um metodo.

Mais metodos podem ser desenvolvidos, a fim de fornecer maior controle ou mesmo

por necessidades de controle de um hardware mais complexo, variando entao de fabricante

para fabricante. As chamadas ioctl sao uma alternativa para esse tipo de situacao.

4 Comunicacao USB

A sigla USB e um acronimo para Universal Serial Bus ou em portugues, barramento

serial universal. Esse barramento e um padrao de conexao de perifericos e computadores,

que foi originalmente criado para substituir a grande variedade de barramentos existentes

por um unico tipo, alem de permitir que varios perifericos de diferentes fabricantes pu-

dessem interoperar em uma arquitetura aberta. Foi idealizado em 1995 por um grupo de

empresas de tecnologia e quais as motivacoes para criacao do mesmo incluem: (USB.ORG,

2005)

• Conexao de um PC ao telefone

• Facilidade de utilizacao

• Expansao de portas de comunicacao

• Solucao de baixo custo e que suporta altas taxas de tranferencias

Um barramento de dados e o caminho de comunicacao fısico e o acesso entre o pro-

cessador e seus perifericos. “Um barramento padrao juntamente com um conjunto pre-

definido de sinais, temporizadores, conectores provem um meio pelos quais as interfaces

de dispositivos, ou controladores, podem ser facilmente desenvolvidos em um sistema

computacional” (MENDONcA; ZELENOVSKY, 2002).

Ate a especificacao 1.1 do USB, as velocidades de tranferencias podiam variar de

1,5Mbps a 12Mbps, dependendo do dispositivo e do tipo de aplicacao (USB. . . , 2005).

4.1 Arquitetura

A arquitetura de um sistema USB e divida em tres partes basicas. Sao elas:

• Interconxeao USB

• Dispositivos USB

• Host USB

23

24

4.1.1 Topologia

A conexao fısica do USB segue a topologia do tipo estrela, onde um hub USB e o

centro de cada estrela e os dipositivos conectados a ele sao as pontas. Cada conexao entre

um host e um hub ou funcao, ou entre um hub e outro hub, e uma conexao ponto-a-ponto

conforme ilustra a figura 4.1 (USB.ORG, 2005).

Figura 4.1: Topologia fısica de um subsitema USB, retirado de USB.org (2005)

4.1.2 Host USB

Em um sistema USB, existe a presenca de apenas um host, ao qual sua interface com

os dispositivos e referenciada como controladora de host. O host USB e responsavel pela

deteccao de quando um dispositivo e conectado ou desconectado, pelo gerenciamento do

fluxo de controle, pelo gerenciamento do fluxo de dados, por coletar estados e atividades

e ainda suprir energia para dos dispositivos a ele conectados.

25

4.1.3 Dispositivos USB

4.1.3.1 Hubs

Segundo USB.org (2005), os hubs sao elementos chave para a caracterıstica de plug

and play do USB, ou seja, permite que um dispositivo possa ser instalado e automatica-

mente detectado pelo sistema operacional. Hubs sao concentradores de conexao por isso

possibilitam a conexao multipla do USB. Os pontos de conexao sao chamados de portas

e cada hub converte um unico ponto em um multiplo ponto de conexao, conforme pode

ser observado na figura 4.2 (USB. . . , 2005), (USB.ORG, 2005).

Figura 4.2: Concentrador de pontos de dispositivos, retirado de USB.org (2005)

4.1.3.2 Funcoes

Uma funcao e um dispositivo USB que e capaz de receber ou transmitir dados ou

informacoes de controle no barramento. Uma funcao e tipicamente implementada como

um dispositivo separado, com um cabo que o conecta em um hub, porem pacotes fısicos

devem implementar multiplas funcoes e um hub dedicado com apenas um unico cabo.

Isto e conhecido como um dispositivo composto.

Cada funcao contem informacoes de configuracoes que descrevem suas capacidades e

requerimentos de recursos. Antes de uma funcao ser usada, ela precisa ser configurada pelo

host, no qual inclui alocacao de banda e a selecao de opcoes de configuracao (USB.ORG,

2005).

26

4.2 Modelo de Transferencia de Dados

4.2.1 Protocolo de barramento

Toda transacao USB envolve a transferencia de tres pacotes basicos, onde cada transacao

e iniciada pela controladora de host, que envia um pacote contendo o tipo e direcao da

transacao, o endereco do dipositivo e o numero do endpoint. A fonte (host ou dispositivo)

e responsavel por enviar pacotes com informacoes ou mesmo um pacote informando que

nao ha nada a ser transferido, enquanto o destino geralmente responde com um pacote de

handshake1 indicando que a transferencia ocorreu com sucesso. O modelo de tranferencia

entre o fonte e o destino, de um host para um endpoint de um dispositivo, e chamdo de

pipe.

4.2.1.1 Endpoints

Um endpoint e uma porcao unicamente idenfiticavel de um dispositivo USB, que e o

termino do fluxo de comunicacao entre o host e o dispositivo e uma direcao determinada

para fluxo de informacoes. Esse tipo de comunicacao suporta apenas uma direcao (comu-

nicacao simplex ) (USB.ORG, 2005), (RUBINI; CORBET; KROAH-HARTMAN, 2005).

Cada dsipositivo logico USB e composto de uma colecao independente de endpoints

e cada dispositivo logico tambem e unicamente enderecado pelo sistema no momento da

conexao.

4.2.1.2 Pipes

Um pipe USB e uma associacao entre um endpoint de um dispositivo e o software do

lado do host. Os pipes representam a habilidade de trafegar informacoes entre o software

do host via buffer de memoria e um endpoint de um dispositivo. Como descrito na propria

especificacao USB, existem dois modos de comunicacao pipe (USB.ORG, 2005):

• Stream : a informacao trafegada dentro de um pipe nao contem uma estrutura USB

definida;

• Mensagem: ao contrario da comunicao tipo Stream, as mensagens sao informacoes

que trafegam dentro de um pipe com uma estrutura USB definida (USB.ORG, 2005).

1E um termo usado para definir o processo de negociacao de taxas de transmissao de dados entredispositivos.

27

O pipe de mensagem de controle Default Control Pipe e um pipe que consiste de

dois endpoints sendo um deles um endpoint numero zero, que sempre existe em uma

comunicacao, desde a primeira vez que um dispositivo e conectado. Tem como objetivo

fornecer acesso as configuracoes, estados e informacoes de controle do dispositivo em

questaoi (USB.ORG, 2005).

4.2.2 Tipos de transferencia

O USB suporta o intercambio de informacoes funcionais e de controle entre um host

e um dispositivo como um conjunto de conexoes uni ou bi-direcionais. O fluxo de in-

formacoes de uma conexao (pipe) deve ser independente de outra conexao, onde uma

conexao que transfere dados de um host para um dispositivo deve ser diferente da co-

nexao para se transferir dados de um dispositivo para um host. A arquitetura USB pode

ser compreendida por quatro divisoes basicas: fluxo de controle, fluxo de dados Bulk,

fluxo de dados por interrupcao e fluxo de dados isocrono (USB.ORG, 2005).

4.2.2.1 Controle

As transferencias de controle sao usadas pelo software do sistema USB para configu-

rar dispositivos quando esses sao conectados pela primeira vez e ocorre entre o software

cliente e suas funcoes. Esse tipo de transferencia permite o acesso a diferentes partes do

dispositivo. Uma transferencia de controle e composto de uma transacao de Setup que

envia requisicoes de informacoes do host para a funcao, zero ou mais transacoes de dados

enviando as informacoes na direcao indicada pela transacao de Setup, e a transacao de

Status retorna a informacao do estado da funcao para o host. A transacao de Setup re-

torna um flag de “sucesso” indicando que o endpoint completou corretamente a operacao

requisitada (USB.ORG, 2005).

O sistema USB trabalha com o conceito de “rede de melhor esforco” para suportar a

entrega das transferencias de controle entre o host e os dipositivos.

4.2.2.2 Isocrono

Transferencias tipo Isocrona tambem sao designados para grandes quantidades de da-

dos, porem nem sempre a tranferencia e garantida. E chamada de transferencia tolerante

a erro. As caracterısticas importantes de uma transferencia tipo Isocrona sao (USB.ORG,

2005):

28

• Acesso a banda USB com certa latencia.

• Divisoes constantes de informacoes atraves de um pipe de acordo com as informacoes

providas pelo proprio pipe.

• No caso de ocorrencia de falhas, nao e feito o reenvio de um dado.

Os dispositivos USB que geralmente utilizam a conexao isocrona, sao para fins que,

perdas de dados sao de certa forma aceitaveis. Dispositivos em tempo-real sao os mais

comuns, como audio e vıdeo. (RUBINI; CORBET; KROAH-HARTMAN, 2005)

4.2.2.3 Interrupcao

Esse tipo de transferencia e designado para dispositivos que nao necessitam trafegar

grandes quantidades de dados, ou seja, enviam e recebem pequenas quantidades de in-

formacao sem uma frequencia determinada. Duas caracterısticas importantes podem ser

citadas para o tipo de transferencia de interrupcao (USB.ORG, 2005):

• Servico maximo garantido para o pipe.

• Tentativas de retransmissao de tempos em tempos, quando ocorrer falha na entrega.

4.2.2.4 Bulk

Transferencias do tipo Bulk sao designadas para suportar dispositivos que necessi-

tam transferir uma quantidade relativamente grande de dados em tempos altamente

variaveis, sendo possıvel uma transferencia utilizar a largura de banda que estiver dis-

ponıvel (USB.ORG, 2005).

As tranferencias tipo Bulk sao sequenciais e a confibilidade na troca de dados e as-

segurada pelo hardware, utilizando algoritmos de deteccao de erros (CRC2) e invocando

um numero limitado de requisicoes ao hardware. Alem disso, a largura de banda utlizada

por esse tipo de transferencia varia de acordo com a atividade do dispositivo em questao

(USB.ORG, 2005).

Ao requisitar um pipe para transferencia tipo Bulk e provido ao requisitante (USB.ORG,

2005):

• Acesso ao USB na largura de banda disponıvel

2Sigla para Ciclic redundancy check, um algoritmo para deteccao de erros

29

• Retransmissao no caso de falhas ocasionais na entrega devido a erros no barramento

• Garantia na entrega de dados, mas sem garantia de banda ou latencia.

Nao existe uma estrutura definida no fluxo de comunicacao entre bulk pipes.

4.3 URBs

URB e um acronimo para USB Request Block, ou Bloco de Requsicao USB, que nada

mais e do que uma maneira como o Kernel Linux trabalha para se comunicar com todos

os dispositivos USB (RUBINI; CORBET; KROAH-HARTMAN, 2005).

Um URB e usado para enviar ou receber dados de um espefıcico endpoint USB, de

um espefıcio dispositivo USB, de maneira assıncrona. Um driver de dispositivo USB deve

alocar varios URBs para um simples endpoint ou entao reutilizar um URB para diferentes

endpoints, dependendo da necessidade do driver. O ciclo de vida de um URB e descrito

da seguinte forma (RUBINI; CORBET; KROAH-HARTMAN, 2005):

• E criado por um driver de dispositivo;

• E enviado para um especıfico endpoint de um especıfico dispositivo;

• E enviado para nucleo USB (kernel) por um driver de dispositivo;

• E enviado para o especıfico driver controladora de host pelo dispositivo especificado

pelo nucleo USB;

• Processado pelo driver controlador de host que faz a transferencia USB para o

dispositivo;

• Quando a transferencia URB e completada o driver controlador de host notifica o

driver de dispositivo;

5 Desenvolvimento

Sera apresentado nesse capıtulo todas as etapas para o desenvolvimento do driver

para o dispositivo biometrico Biopod, utilizando conceitos fundamentais apresentados

nos capıtulos anteirores, principalmente sobre USB.

5.1 Requisitos do software

O desenvolvimento do projeto aqui proposto, e criar uma camada de software que

seja responsavel por fazer o interfaceamento de uma aplicacao que necessite manipular o

dispositivo biometrico Biopod, sem se preocupar com detalhes de protocolo, para a pla-

taforma GNU/Linux. Essa camada, ou driver, deve ser responsavel em enviar comandos

de configuracao, controle e aquisicao de dados para o dispositivo e retornar os resultados

dessas operacoes, permitindo que outras aplicacoes facam o devido processamento das

informacoes recebidas.

Para exemplificar e tentar comprovar o real funcionamento desse driver, o resultado

esperado da comunicacao entre o computador e o dispositivo deve ser a imagem de uma

impressao digital.

5.1.1 Materiais utilizados

Para o desenvolvimento desse projeto foi necessaria uma gama de recursos de hardware

e software, que sao abaixo descritos:

• Microcomputador IBM/PC x86, 256Mb memoria RAM e host USB;

• Sensor biometrico APC Biopod r©

• Sistema operacional Slackware GNU/Linux kernel serie 2.4;

• Sistema operacional Debian GNU/Linux kernel serie 2.6;

• Sistema operacional Microsoft Windows XP r©

• USB Sniffer SnoopyPro

30

31

• USB Sniffer USB Monitor

• Compilador gcc 3.3.4

• Editor de textos Vi Improved

5.2 Projeto BiopodUsbDriver

5.2.1 O Dispositivo

O dispositivo utilizado para a construcao do driver e o sensor biometrico Biopod do

fabricante APC. Esse dispositivo tem porta de comunicacao USB 1.1 e utiliza uma matriz

de aquisicao de dados e o chip AES3500, ambos do fabricante Authentec, conforme as

especificacoes do datasheet desse fabricante. A figura 5.1 mostra o sensor Biopod.

Figura 5.1: Sensor biometrico utilizado no projeto

O Biopod pode aquisitar imagens de dimensoes por 96x96 pixels 1 e que, segundo o

proprio fabricante, sao suficientes para fazer analise das minucias para identificacao. Seu

sensor e acionado pela temperatura da mao humana, atraves de micro-antenas dispostas

no sensor. Acompanha tambem uma licenca do software OmniPass e e compatıvel com

sistemas operacionais da Microsoft. A figura 5.2 mostra o software aquisitando uma

imagem de uma impressao digital, no Ms-Windows XP.

5.2.2 Esquema do projeto

Como a preocupacao desse trabalho e o desenvolvimento de um driver de dispositivo,

o esquema do projeto e simplesmente ao qual o proprio dispositivo se propoe: facilitar

o acesso ao dispositivo, capturando imagens de impressoes digitais para uma aplicacao

especıfica, como por exemplo autenticacao de um usuario em determinado sistema, uti-

lizando o sistema operacional GNU/Linux. A figura 5.3 mostra a sequencia de eventos

para obtencao de uma imagem de uma impressao digital.

1Unidade basica de uma imagem digital

32

Figura 5.2: Software Omni Password, aquisitando uma impressao digital

5.2.3 Aquisicao do Protocolo

A aquisicao e definicao do protocolo foi a parte do projeto mais complicada e foi

tambem, no decorrer do desenvolvimento, a tarefa mais obscura, ja que a unica fonte de

informacao era o resultado do log feito pelo sniffer 2.

A metodologia adotada foi a engenharia reversa, o qual tem por objetivo extrair

um modelo de construcao de um produto a partir desse produto ja pronto e fechado.

Basicamente sao feitos testes variando-se as entradas e observando as saıdas, tentando

compreender o funcionamento interno dessa “caixa-preta”.

Para analise dos dados foram utilizados dois software capazes de aquisitar todas as

informacoes trafegadas nas portas USB do computador e deixa-las em um formato mais

simples, para que entao fossem analisadas. O procedimento utilizado esta descrito a

seguir:

• O primeiro passo foi verificar o funcionamento do dispositivo em um ambiente onde

se pudesse comprovar seu perfeito funcionamento. Foi utilizando entao, um com-

2Sniffer e um termo para designar um software que “varre” determinada porta de comunicacao docomputador e obtem seu conteudo

33

Figura 5.3: Esquema do projeto para obtencao de uma impressao digital

putador com sistema operacional Ms-Windows XP e nele instalados os drivers e

software fornecidos pelo fabricante.

• O proximo passo foi pesquisar por informacoes que poderiam ser importantes para

o desenvolvimento do driver, como espeficicacoes do firmware e datasheets do chip,

porem nada havia sido encontrado.

• Logo entao foram instalados dois software para aquisicao das informacoes pela porta

USB: SnoopyPro e USB Monitor, ambos para sistemas operacionais Ms-Windows

XP. O primeiro e um software livre licenciado sobre os termos da GNU GPL, e

o segundo e um freeware onde para utilizacao de funcoes adicionais era preciso

de um licenciamento especial. Foram instalados e configurados devidamente e apos

iniciar o software de aquisicao de imagem da impressao digital fabricante (OmniPass

Enrolment), os sniffers iniciaram concomitantemente com o software a aquisicao dos

dados trafegados pela porta USB, gravando essas informacoes em um arquivo texto.

• A partir de entao, foi feita uma profunda analise, tentando separar comandos de

configuracao, protocolo e dados propriamente ditos (imagem), do arquivo gerados

pelos sniffers.

5.2.4 Biblioteca de Acesso a USB (LibUsb)

A LibUsb e uma biblioteca de funcoes que permite o acesso a dispositivos USB de uma

forma mais facil e abstraıda, sendo possıvel criar drivers de dispositivos reais no espaco

do usuario (PROJECT, 2005). As vantagens de criar modulos no espaco do usuario sao:

• Abstracao das chamadas mais complexas do kernel do sistema

34

• Independencia de versao do kernel

• Facilidade no desenvolvimento de novos modulos

A desvantagem e que, nao existindo um modulo dedicado no espaco do nucleo, a cada

novo software a ser desenvolvido deve conter rotinas USB para conexao com dispositivo

em questao (KROAH-HARTMAN, 2001).

Figura 5.4: Tela SnoopyPro - Sniffer USB

5.2.5 Implementacao

Com o protocolo teoricamente definido, foi necessario criar os modulos que iriam

compor o software e estes foram sendo moldados durante o desenvolvimento do projeto,

de acordo com as reais necessidades e na tentativa de sempre utilizar boas praticas de

programacao, que nao foi possıvel fazer em todos os casos.

35

A partir da versao 2.4, o Linux ja possuıa suporte a comunicacao USB, isso inclui mui-

tas das placas controladoras, concentradores e dipositivos propriamente ditos, existentes

no mercados de computadores x86. O modulo que da ao Linux a possibilidade de controlar

dispositivos USB e basicamente um conjunto de drivers USB simples, genericos, invocados

pelos nomes usb.o e usbcore.o, e que sao responsaveis por permitir outros software fazerem

chamadas ao sistema, tornando a comunicacao USB um pouco mais simples. A figura 5.5

mostra os modulos carregados em um sistema operacional Slackware GNU/Linux, atraves

do comando lsmod.

Figura 5.5: Comando lsmod, exibindo os modulos carregados em um sistema operacionalSlackware GNU/Linux

Segundo a especificacao USB, todo dispositivo homolagado pela USB.org deve ter dois

numeros para identificacao unica de um dispositivo: o idProdutc e o idVendor.

O idProduct e o numero que define o modelo do produto, ja o idVendor define o

fabricante. Esses dois numeros sao essenciais para utilizacao de um driver de dispositivo,

ja que sao eles que permitem o sistema operacional saber qual driver carregar no momento

da deteccao de um novo dispositivo conectado ou mesmo o proprio driver certificar-se

que esta lidando com um dispositivo conhecido (RUBINI; CORBET; KROAH-HARTMAN,

2005).

Utilizando um comando do shell do GNU/Linux e possıvel obter mais informacoes

sobre os disposistivos USB que estao conectados a maquina. O comando e o

cat /proc/bus/usb/devices, onde /proc/bus/usb e o subdiretorio que esta montado o usbfs,

conforme ilustra a figura 5.6.

Segundo Kroah-Hartman (2001), o USBFS ou o usbdevfs e a implementacao de um

36

Figura 5.6: Informacoes de dispositivos montados na estrutura usbfs

sistema de arquivos para acesso a dispositivos USB no GNU/Linux. O USBFS mapeia

todos os componentes USB do sistema utilizando as chamadas basicas do kernel para

controle USB e cria uma estrutura de diretorios em local pre-determinado (na versao 2.4

do Linux o diretorio e o /proc/bus/ ) do sistema de arquivos atual. Como no GNU/Linux

tudo e acessado como um arquivo, a partir dessa estrutura de diretorios montada, e

possıvel executar as chamadas basicas de open, close, read e write de um driver carregado

na memoria (RUBINI; CORBET; KROAH-HARTMAN, 2005).

Conforme descrito em Project (2005), a biblioteca LibUsb disponibiliza uma serie de

funcoes para acesso e controle de dispositivos USB. Depois de instalado essa biblioteca e

te-la definido no diretorio dos kernel headers3, e necessario apenas fazer a inclusao do seu

cabecalho.

Apos extrair as informacoes de protocolo do Biopod e preparar o ambiente de desen-

volvimento, e que se deu inicio ao desenvolvimento do driver. Primeiramente, a estrategia

adotada foi a construcao de um modulo no espaco do nucleo (ou espaco do kernel), porem

devido a dificuldades de implementacao e desenvolvimento, adotou-se a estrategia de criar

um driver no espaco do usuario, utilizando a biblioteca LibUsb.

Com a documentacao da biblioteca LibUsb acessıvel, foi criado entao um modulo

simples que basicamente fazia a verificacao do idVendor e idProduct pre-determinado,

com o dispositivo conectado no barramento. Conhecidos entao a localizacao do dispositivo

Biopod no computador, foi feito a abertura (open) e o fechamento (close) de uma conexao

com o dispositivo (a titulo de teste).

5.2.5.1 Protocolo - Controle

Apos a abertura de uma conexao com um dispositivo USB, a primeira atitude a

se tomar foi trocar informacoes com o dispositivo com o intuito de conhecer e ajustar as

3local onde se encontram as definicoes de funcoes e bibliotecas do kernel e do sistema

37

h

Tabela 5.1: Visao macro do protocolo implementado pelo driver

Remessa Tipo de Transferencia Funcao1 control Configuracao inicial2 bulk Configuracao dos registradores3 bulk Deteccao de um dedo4 bulk Requisicao dos dados

configuracoes basicas do mesmo. E nesse momento que e utilizado o Default Control Pipe.

Para esse tipo de situacao, a espeficicacao USB determina a utilizacao de transferencias

de controle, conforme visto no capıtulo 4.

De acordo com informacoes extraıdas do sniffer, os cinco primeiros pacotes trafegados

eram utilizados para o fim de configuracao. Adicionado ao modulo a funcao de envio de

dados de controle e configuracao, como por exemplo configurar o pipe de transferencia.

A tabela 5.2.5.1 mostra, em termos macros, o protocolo inicial para controle do Biopod.

5.2.5.2 Protocolo - Configuracao dos Registradores

Logo apos a troca dos primeiros pacotes, que representam a secao de controle, foi

necessario o envio de uma dezena de outros pacotes que tem por objetivo, a configuracao

dos registradores do chip contido no Biopod. Essa secao e a que contem o maior numero

de pacotes enviados ao dispositivo, porem ocorre apenas uma vez apos a abertura do

dispositivo.

5.2.5.3 Protocolo - Requisicao

Configurados os registradores, foi necessario definir mais tres conjuntos de pacotes de

envio para o dispositivo para que este estivesse pronto para o envio dos dados. A exigencia

do envio desses pacotes sao particulares do dispositivo, que sao definidos pelo conjunto

eletronico que compoe a matriz de aquisicao.

Nesse ponto, a transferencia passa a ser do tipo bulk, pois tanto o endpoint de entrada

como de saıda sao desse tipo, que tambem e definido pelo fabricante.

Quando enviado o primeiro conjunto de pacotes, o dispositivo foi verificado a presenca

de um flag chamado Drive Ring, que e “setado” toda vez que a matriz de aquisicao de

dados identifica a presenca de um dedo. Segundo o datasheet do fabricante, porem de um

38

sensor similar, ao redor da matriz ativa de aquisicao, existem micro-antenas que detectam

a presenca de um dedo atraves de calor (ou inducao) e sao elas as responsaveis por “setar”

ou “resetar” o flag Driver Ring (AUTHENTEC, 2003).

Os outros tres conjuntos de pacotes sao pertinentes a configuracoes especıficas dos

registradores do hardware e sempre retornam um pacote de tamanho 252 bytes quando

as configuracoes sao feitas com sucesso ou retornam um numero negativo quando algum

erro ou inconsistencia ocorre.

5.2.5.4 Protocolo - Dados propriamente ditos

Terminado as etapas de controle e configuracao e requisicao, vem a ultima etapa da

comunicacao, que e a transferencia dos dados alvo (imagem obtida pelo sensor). Essa

informacao e transmitida apos o ultimo pacote de requisicao ter sido enviado e e atendida

apos a chamada read para o dispositivo e retorna blocos de tamanho de 64 bytes (tamanho

do endpoint).

Com a utilizacao da LibUsb, esses blocos de 64 bytes sao armazenados em um unico

buffer e somente no final da mesma e que a biblioteca libera a aquisicao de um pacote

com o tamanho total dos dados transmitidos. Em fim, o Biopod transmite um buffer de

8362 bytes de dados, que representam a imagem de uma impressao digital aquisitada.

5.2.5.5 Definicao da imagem

A ultima parte do projeto foi a definicao do tipo da imagem. Apos o processo de

implementacao do protocolo de comunicacao e aquisicao dos dados, foi preciso descobrir

qual era o tipo da imagem e como era montada. Intuitivamente, a primeira atitude foi

escrever o conteudo inteiro obtido em um arquivo da forma que veio com um cabecalho

simples do tipo PGM 4.

Utililizando o software grafico The Gimp (GIMP, 2005), testes foram feitos na tenta-

tiva de aprender como se comportavam imagens simples e sem compressao. Para os testes

foram criadas imagens extremamente pequenas com tamanhos 1x1 pixel e 2x2 pixels,

utilizando cabecalhos de imagem PGM (Portable Graymap).

Apos incessantes tentativas empıricas e sem sucesso, foi encontrado na internet um

datasheet de um sensor do mesmo fabricante, porem de um produto diferente. Quanto

4PGM - Sigla inglesa para Portable GrayMap que e um formato de arquivo de imagem simples emescala de cinza

39

as definicoes no formato da imagem, foram as sugeridas no datasheet e aplicadas no

programa. Os resultados podem ser vistos na secao de resultados, no capıtulo 6.

5.2.5.6 BiopodUsbDriver

Concluıda a definicao da imagem, o driver pode ser considerado pronto, necessitando

apenas de alguns ajustes de melhoria no desempenho e na qualidade da imagem aquisitada.

Por fim, a figura 5.7 ilustra o fluxo do BiopodUsbDriver.

40

Inicio

Detecçao do dispositivo

Configuraçoes iniciais

Envio comandos paradetecçao um dedo

Dete�ctado?

Envio de comandos de ’handshake’

Aquisiçao dos dados

Montagem e gravaçao daimagem em arquivo

Continua aquisiçao?

Fecha o dispositivo

Fim

SIM

NAO

SIM

NAO

Figura 5.7: Fluxograma do driver

6 Resultados

Ao longo de todo o processo de desenvolvimento foram sendo feitos diversos testes e

coletados seus respectivos resultados, tanto bons como ruins, para que fosse possıvel fazer

uma analise crıtica e chegar a possıveis conclusoes.

O resultado final e um driver de dispositivo que trabalha no espaco do usuario, que

pode aquisitar imagens do sensor biometrico APC Biopod, com chip AES 3500 integrado,

em formato nao compactado de um byte por pixel.

6.1 Testes e Analise dos Resultados

Antes da definicao correta da imagem, foram feitos diversos testes com o objetivo de

exibir uma impressao digital que era aquisitada atraves do driver. Foi constatado que,

apos o protocolo, um pacote de 8632 bytes era enviado pela porta USB, onde imaginava-

se ser os bytes decorrentes de uma impressao digital fornecida pelo sensor. A primeira

tentativa foi escrever um arquivo com esses bytes, da forma como eles eram enviados, com

um cabecalho simples, tipo PGM. A figura 6.1 mostra o primeiro resultado obtido.

Figura 6.1: Primeiro resultado obtido, imagem formada com o bytes da forma como eramaquisitados

Com esse resultado negativo, outras tentativas foram feitas, porem sem nenhum re-

sultado coerente. As tentativas foram basicamente trocar a ordem de escrita no arquivo

em relacao aos dados aquisitados do sensor. A figura 6.2 mostra a imagem montada, in-

vertendo a sequencia de bytes recebidos e escritos e a definicao do tamanho no cabecalho.

Para tentar descobrir qual sentido a matriz de aquisicao do Biopod realiaza a varredura

para obtencao da imagem, testes foram feitos colocando a ponta do dedos em uma das

extremidades e comparado a imagem formada pelo programa.

41

42

Figura 6.2: Imagem com resolucao 90x90 pixels e com sequencia de bytes invertido

(a) Posicionamento dodedo na parte lateral dosensor

(b) Imagem aquisitadacom o dedo na lateral dosensor

Figura 6.3: Teste realizado para verificacao da rotacao da imagem

Nesse ponto foi possıvel identificar a rotacao da imagem enviada pelo sensor, que e

de 90 graus no sentido horario.

Imaginava-se entao, que o problema poderia ser em funcao da definicao do tamanho

da imagem, ou seja, forcando um cabecalho de 64x64 pixels em uma imagem de qualquer

outra dimensao, poderia ser suficiente para que a imagem ficasse distorcida a ponto de

se tornar irreconhecıvel. Foram testadas varias dimensoes dentre o range possıvel. Mais

testes foram feitos sem nenhum resultado positivo.

Com esse problema em mente, a alternativa restante foi procurar por informacoes

sobre o chip que compunha o dispositivo, e que pudesse esclarecer como era montada

a imagem. Foi encontrado entao um datasheet de outro sensor biometrico, porem do

mesmo fabricante. Baseado nesse documento, as informacoes de dados transmitidos do

sensor para o computador eram dividos em seis linhas de noventa e seis colunas, com

dezesseis bytes cada linha. Foi ainda descoberto que para cada pixel era enviado um byte

de dado e qual formato tambem era especıfico.

43

Implementando um algorıtmo para o tratamento desses bytes, de acordo com as es-

pecificacoes disponıveis, foi entao possıvel exibir uma imagem de uma impressao digital,

como mostra a figura 6.4.

Figura 6.4: Primeira imagem de uma impressao digital aquisitada

Ficou obivo, a partir da primeira aquisicao que a imagem resultante estava com uma

rotacao de 90 e que foi facilmente resolvido, utilizando a tecnica de transposicao de ma-

trizes, como resultado mostra a figura 6.5.

Figura 6.5: Impressao digital aquisitada e rotacionada em noventa graus

Outros testes foram feitos para verificacao e certificacao do funcionamento do driver.

As imagens 6.6(a), 6.6(b) e 6.6(c) mostram o resultado satisfatorio.

(a) Impressao di-gital aquisitada dodedo indicador es-querdo

(b) Impressao di-gital aquisitada dodedo indicador di-reito

(c) Impressao di-gital aquisitada dodedo medio direito

Figura 6.6: Impressoes digitais aquisitadas utilizando o BiopodUsbDriver

44

As imagens aquisitadas pelo software BiopodUsbDriver, foram comparadas com as

imagens exibidas pelo software fornecido pelo fabricante, e os resultados foram parecidos.

Baseando-se nesses resultados, pode-se concluir que o BiopodUsbDriver e capaz de

fornecer informacoes suficientes para a utilizacao em uma aplicacao de reconhecimento de

padroes de impressao digital, em plataforma GNU/Linux.

7 Conclusoes

Com a pluralizacao de sistemas operacionais alternativos no mercado, tornando o mo-

nopolio nesse segmento uma ficcao, obrigara empresas de hardware a repensarem sobre

publico-alvo que pretendem atingir, se quiserem se manter competitivos e nao limitados

a apenas uma tecnologia. Sendo isso fator decisivo para essas companhias, o desenvolvi-

mento de drivers de dispositivos, consequentemente, tera tambem de ser reavaliado.

Ate que o amadurecimento, tanto das empresas, como do mercado, venha a suceder,

o desenvolvimento de classes de modulos para dispositivos continuara a ser tarefa ardua

para os desenvolvedores de aplicacao que dependam de um equipamento especıfico e que

utilizam SOs alternativos.

Esse projeto vem mostrar a importancia dos drivers de dispositivos e quais as pos-

sibilidades de criacao para sistemas GNU/Linux. Contribui tambem, de forma significa-

tiva para a comunidade Software Livre, aumentando o numero de dispositivos suportado

em um sistema operacional GNU/Linux, alem de abrir novas possibilidades de imple-

mentacoes futuras utilizando esse driver como recurso.

Para projetos futuros, fica a possibilidade de se portar esse driver para o espaco do

nucleo, poder adicionar algoritmos de pre-processamento na imagem aquisitada, utiliza-lo

para enfim realizar uma identificacao biometrica de usuarios de um sistema e ate integrar

um sistema de identificacao automatica utilizando o Biopod com modulos de autenticacao

do GNU/Linux, como o PAM (Password Authentication Module).

45

Referencias

ARAGAKI, B. Biometria. 2005. Disponıvel em:<http://tecnologia.uol.com.br/especiais/ultnot/2005/07/21/ult2888u71.jhtm>.

AUTHENTEC. Product Specification for the AFS8600 Fingerprint Sensor.Melbourne: Authenteci, Inc, 2003.

BACH, M. J. The Design of the Unix Operating System. New Jersey: Prentice-Hall,1990.

BIOMETRIA-WIKIPEDIA. Disponıvel em: <http://pt.wikipedia.org/wiki/Biometria>.Acesso em: 03 de maio de 2005.

COSTA, S. M. F. Classificacao e verificacao de impressoes digitais. 2001.

DIAS, C. Seguranca e Auditoria da Tecnologia da Informacao. Rio de Janeiro:Axcell Books, 2005.

GIMP, T. The GNU Image Manipulation Program. 2005. Disponıvel em:<http://www.gimp.org>.

GUMZ, R. A. Prototipo de um sistema de identificacao de minucias em impressoesdigitais utilizando redes neurais artificiais feedforward multicamada. 2002.

JuNIOR, A. A.; JuNIOR, J. B. de Oliveira e C. Licoes de Meldicina Legal. 16. ed.Sao Paulo: Editora Nacional, 1979.

KROAH-HARTMAN, G. Writing a Real Driver - In User Space. 2001. Disponıvelem: <http://www.linuxjournal.com/node/7466/>.

MARANHaO, O. R. Curso Basico de Medicina Legal. 4. ed. Sao Paulo: EditoraRevista dos Tribunais, 1989.

MENDONcA, A.; ZELENOVSKY, R. PC: Um Guia Pratico de Hardware eInterfaceamento. 3. ed. Rio de Janeiro: MZ Editora, 2002.

MITCHELL, M.; OLDHAM, J.; SAMUEL, A. Advanced Linux Programming. 1.ed. [S.l.]: New Riders, 2001.

PERIM, F. Tutorial de sockets. 2001. Disponıvel em:<http://olinux.uol.com.br/artigos/370/1.html>.

PROJECT, L. LibUsb Project Documentation. 2005. Disponıvel em:<http://libusb.sourceforge.net/documentation.html>.

46

47

ROMAGNOLI, G. dos S. Biometria: Voce e sua senha. 2005. Disponıvel em:<http://www.serpro.gov.br/publicacao/tematec/2002/ttec61>.

RUBINI, A. Linux Device Drivers. 1. ed. Sebastopol: O’Reilly, 1998.

RUBINI, A. Linux Device Drivers. 1. ed. Sebastopol: O’Reilly, 2001.

RUBINI, A.; CORBET, J.; KROAH-HARTMAN, G. Linux Device Drivers. 3. ed.Sebastopol: O’Reilly, 2005.

RUSSEL, D.; GANGEMI, G. T. Computer Security Basics. Sebastopol: O’Reillyiand Associates, 1991.

SAKATA, T. C. Sistemas de Arquivo. 2005. Disponıvel em:<http://www.li.facens.br/ tiemi/so/aula11-sarq.pdf>.

SILBERCHATZ, A.; GALVIN, P. B.; GAGNE, G. Operating Systems Concepts. 6.ed. Nova Iorque: Jonh Willey & Sons, Inc., 2002.

SIQUEIRA, T. A. Acme! honeynet de 2a geracao: Implementacao de novas tecnologias.UNESP, 2004.

STALLINGS, W. Operating Systems. 4. ed. New Jersey: Prentice Hall, 2000.

STALLINGS, W. Arquitetura e Organizacao de Computadores. 5. ed. Sao Paulo:Prentice Hall, 2002.

TANENBAUM, A. Sistemas Operacionais Modernos. 2. ed. Sao Paulo: PearsonPrentice Hall, 2003.

TANENBAUM, A. S. Organizacao Estruturada de Computadores. 3. ed. Rio deJaneiro: Prentice Hall, 1992.

TUTORIALS on Device Drivers. 2001. Disponıvel em:<http://www.rt.db.erau.edu/experiments/drivers/fundamentals.html>.

USB 2.0. 2005. Disponıvel em: <http://www.infowester.com/usb20.php>.

USB.ORG. USB Spec. 1.1. 2005. Disponıvel em:<http://www.usb.org/developers/docs/usbspec.zip>.

desenvolvimento de um driver de dispositivo biom etrico ... · inicialmente o objetivo desse...

Documents