Coordenao de Engenharia da Computao ca ca

Desenvolvimento de um Driver de Dispositivo Biomtrico com Comunicao e ca USB

Rafael Casale Abe

Trabalho de formatura apresentado a Faculdade de Engenharia ` de Sorocaba - FACENS, como parte dos pr-requisitos para a e obtenao do t c tulo de Engenheiro da Computaao c

Sorocaba/SP 2005

Rafael Casale Abe

Desenvolvimento de um Driver de Dispositivo Biomtrico com e Comunicao USB ca

Trabalho de formatura apresentado a Faculdade de Engenharia ` de Sorocaba - FACENS, como parte dos pr-requisitos para a e obtenao do t c tulo de Engenheiro da Computaao c

Orientador: Eng. Fabio Lopes Caversan

Sorocaba/SP 2005

Dedicatria o
Dedico esse trabalho de concluso de curso ao meu pai Nobuo e minha me Teresa, a a por serem para mim, exemplos de luta e auto-superaao. c

Aprender, Produzir e Divulgar

ii

Agradecimentos
Gostaria de agradecer imensamente todos aqueles que, direta ou indiretamente, contribuiram para a realizaao desse trabalho: c ` - A Deus, o criador, por propiciar condioes para o meu desenvolvimento pessoal, c prossional e acadmico, por me deixar conhecer o sabor da vitria aps a luta e me e o o ensinar muito mais com as derrotas; ` - A toda minha fam lia, meu pai Nobuo, minha me Teresa, meus irmos Flvia e a a a Rodrigo, meus tios, tias e minha av, por serem as pessoas que so, e por me incentivarem o a sempre nos projetos de minha vida; ` - A minha namorada, Juliana, por ter conseguido me aturar nesse ano; - Ao meu orientador eng. Fbio Caversan, por me incentivar, acreditar no meu trabaa lho e criar condioes para o desenvolvimento desse projeto e tambm por me ajudar com c e muitas das d vidas sobre TeX; u - Ao hacker Cristiano Rodrigues, que mesmo sem o conhecer pessoalmente, me forneceu informaoes valiosas que foram cruciais para o desenvolvimento desse trabalho; c - Aos professores, eng. Edinei Legaspe e eng. Sidney Montebeller, por me ajudarem a digerir n meros hexadecimais e interpret-los. u a - A professora Tiemi Sakata e ao professor Carlos Watanabe, pelo incentivo e ensinamentos sobre a ferramenta TeX; - Ao Marcos Abreu, coordenador de desenvolvimento da Simpress, que salvou o desenvolvimento desse projeto, fornecendo recursos tecnolgicos, alm do imenso espao que o e c me foi aberto, dando-me exibilidade 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, alm de me esclarecerem sobre os efeitos e jur dicos desse projeto.; - Aos manos do 3 Divisa, Cesar Rodrigo, Emerson Machado, Juprcio Juliano e Roe

iii

drigo Pillon, que estavam sempre dispostos a ajudar uns aos outros durante todo o projeto, alm serem engrenagens importantes para o desenvolvimento das disciplinas durante os e anos de faculdade; - Aos meus amigos Alexandre Coconesi, Rafael Mosan, Roberto Mosan e Thiago Alves Siqueira, por serem simplesmente amigos. - Por m, a toda comunidade de Software Livre do Brasil e do mundo, por disponibilizarem softwares legais e de alta qualidade, documentaoes tcnicas e muito cdigo-fonte c e o para que eu pudesse aprender com eles.

iv

Sumrio a

Lista de Figuras Lista de Tabelas Resumo Abstract 1 Introduo ca 2 Biometria 2.1 Datiloscopia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 2.1.2 2.1.3 Sistema Vucetich . . . . . . . . . . . . . . . . . . . . . . . . . . . . Detalhes de Galton . . . . . . . . . . . . . . . . . . . . . . . . . . . Idencaao e Vericaao . . . . . . . . . . . . . . . . . . . . . . . . c c

viii x xi xii 1 3 3 4 5 6 7 8 10

2.2 Sistemas biomtricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e 2.3 Segurana da Informaao . . . . . . . . . . . . . . . . . . . . . . . . . . . . c c 3 Sistemas Operacionais

3.1 Mquina Extendida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 a 3.2 Componentes de um SO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1 Gerenciamento de processos . . . . . . . . . . . . . . . . . . . . . . 11 3.2.1.1 3.2.1.2 3.2.1.3 Processos . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Estados de Processos . . . . . . . . . . . . . . . . . . . . . 11 Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2.1.4 3.2.1.5

Comunicaao Interprocessos . . . . . . . . . . . . . . . . . 13 c Condiao de disputa . . . . . . . . . . . . . . . . . . . . . 14 c Semforos . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 a Mutexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.2

Entrada e Sa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 da 3.2.2.1 3.2.2.2 3.2.2.3 Dispositivos de E/S . . . . . . . . . . . . . . . . . . . . . 14 E/S Programada . . . . . . . . . . . . . . . . . . . . . . . 16 E/S Orientada a Interrupao . . . . . . . . . . . . . . . . 16 ` c

3.2.3

Sistemas de Arquivos . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2.3.1 3.2.3.2 Arquivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Diretrios . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 o

3.3 Classes de Dispositivos e Mdulos . . . . . . . . . . . . . . . . . . . . . . . 19 o 3.3.1 3.3.2 Drivers de caractere . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Major e Minor Numbers . . . . . . . . . . . . . . . . . . . . . . . . 20 3.3.2.1 Mtodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 e 23

4 Comunicao USB ca

4.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.1.1 4.1.2 4.1.3 Topologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Host USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Dispositivos USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.1.3.1 4.1.3.2 Hubs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Funoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 c

4.2 Modelo de Transferncia de Dados . . . . . . . . . . . . . . . . . . . . . . . 26 e 4.2.1 Protocolo de barramento . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2.1.1 4.2.1.2 Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Pipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

vi

4.2.2

Tipos de transferncia . . . . . . . . . . . . . . . . . . . . . . . . . 27 e 4.2.2.1 4.2.2.2 4.2.2.3 4.2.2.4 Controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Iscrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 o Interrupao . . . . . . . . . . . . . . . . . . . . . . . . . . 28 c Bulk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3 URBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5 Desenvolvimento 30

5.1 Requisitos do software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.1.1 Materiais utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2 Projeto BiopodUsbDriver 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5

O Dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Esquema do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Aquisiao do Protocolo . . . . . . . . . . . . . . . . . . . . . . . . . 32 c Biblioteca de Acesso a USB (LibUsb) . . . . . . . . . . . . . . . . . 33 Implementaao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 c 5.2.5.1 5.2.5.2 5.2.5.3 5.2.5.4 5.2.5.5 5.2.5.6 Protocolo - Controle . . . . . . . . . . . . . . . . . . . . . 36 Protocolo - Conguraao dos Registradores . . . . . . . . 37 c Protocolo - Requisiao . . . . . . . . . . . . . . . . . . . . 37 c Protocolo - Dados propriamente ditos . . . . . . . . . . . 38

Deniao da imagem . . . . . . . . . . . . . . . . . . . . . 38 c BiopodUsbDriver . . . . . . . . . . . . . . . . . . . . . . . 39 41

6 Resultados

6.1 Testes e Anlise dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . 41 a 7 Concluses o 45

vii

Referncias e

46

viii

Lista de Figuras
2.1 Elementos bsicos de uma impresso digital, retirado de (COSTA, 2001) . . a a 2.2 Classes fundamentais de Vucetich, retirado de Gumz (2002) . . . . . . . . 4 5 5 9

2.3 Detalhes de Galton, retirado de Costa (2001) . . . . . . . . . . . . . . . . . 2.4 Pilares da segurana da informaao, retirado de Siqueira (2004) . . . . . . c c

3.1 Abstraao de uma memria com vrios jobs na memria . . . . . . . . . . 12 c o a o 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 diretrios hierarquizada, retirado de Sakata (2005) . . . . . . 19 o 3.5 Arvore de diretrio Unix - Simplicado, adaptado de Bach (1990) . . . . . 19 o 3.6 Parte do conte do do diretrio /dev, exibindo os tipos de dispositivos. . . . 21 u o 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 biomtrico utilizado no projeto . . . . . . . . . . . . . . . . . . . . 31 e 5.2 Software Omni Password, aquisitando uma impresso digital . . . . . . . . 32 a 5.3 Esquema do projeto para obtenao de uma impresso digital . . . . . . . . 33 c a 5.4 Tela SnoopyPro - Snier USB . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.5 Comando lsmod, exibindo os mdulos carregados em um sistema operacioo nal Slackware GNU/Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.6 Informaoes de dispositivos montados na estrutura usbfs . . . . . . . . . . 36 c 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 resoluao 90x90 pixels e com seq encia de bytes invertido . . 42 c u 6.3 Teste realizado para vericaao da rotaao da imagem . . . . . . . . . . . . 42 c c 6.4 Primeira imagem de uma impresso digital aquisitada . . . . . . . . . . . . 43 a 6.5 Impresso digital aquisitada e rotacionada em noventa graus . . . . . . . . 43 a 6.6 Impresses digitais aquisitadas utilizando o BiopodUsbDriver . . . . . . . . 43 o

Lista de Tabelas
5.1 Viso macro do protocolo implementado pelo driver . . . . . . . . . . . . . 37 a

xi

Resumo
Sistemas de identicaao biomtrica vm se tornando cada vez mais populares, tanto c e e para questes de segurana, como para automaao empresarial. Porm nem todos os o c c e fabricantes de dispositivos biomtricos disponibilizam drivers para plataformas livre como e o GNU/Linux. Mdulos ou drivers de dispositivo so componentes de software muito o a importantes em sistemas de computadores, pois permitem o acesso ao hardware e por apresentarem uma interface mais simples ao usurio programador. a Esse documento apresenta a teoria utilizada para o desenvolvimento de um driver e detalha a criaao de um mdulo de dispositivo de um sensor biomtrico que utiliza a c o e porta de comunicaao USB, para a plataforma GNU/Linux. O software desenvolvido c e livre est licenciado sob os termos GNU GPL verso 2. a a

xii

Abstract
Automatic systems for biometric identication have became most popular every day, for security and even in business automation. Therefore, not all biometric device drivers are avaiable for free plataform. Device drivers are software blocks very important for computer systems, because they allow hardware acess and oers an interface to the programmer. This document presents a basic theory about device drivers development and describes the 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 is totaly free and its under the terms of GNU GPL version 2.

Introduo ca
Em um mundo globalizado e tecnolgico, a conectividade entre dispositivos eletrnicos, o o

de pessoas e dispotivos ou simplesmente de pessoas para pessoas, fator fundamental para e realizaao de diversas tarefas do dia-a-dia, seja no ambiente de trabalho ou domstico. c e Diante da necessidade da utilizaao de recursos de informtica acoplados a um meio c a seguro para acesso a informaoes condenciais e integridade de informaoes, que tecno` c c e logias baseadas em biometria e segurana da informaao tm sido desenvolvidas e melhoc c e radas. Devido ao grau de competitividade que se estabelece entre empresas de um setor, e necessrio reetir sobre quais mtodos uma companhia pode adotar para que tenha um a e diferencial comercial entre seus potenciais clientes. A partir dessa reexo e tentando a visualizar a concorrncia no mercado de informtica, estrategicamente ruim o desenvole a e vimento/venda de produtos que tenham alta dependncia tecnolgica de empresas monoe o polistas e se que negam a deixar esses produtos (software) independente de plataforma ou sem qualquer compatibilidade. Empresas desenvolvedoras de perifricos de computador e no fogem a regra da concorrncia, e no atender uma determinada fatia do mercado, a ` e a pode ser fator crucial para a sobrevivncia. e Drivers de dispositivos so componentes de software responsveis por permitir o coma a putador interagir com seus perifricos. So os drivers de dispositivos que conhecem o e a hardware tratado e como ele se comunica com o computador. Inicialmente o objetivo desse trabalho foi a criaao de um software livre que fosse c capaz de vericar e autenticar pessoas atravs de suas impresses digitais, para uma e o plataforma tambm livre. Como nenhum dos fabricantes de dispositivos biomtricos do e e mercado disponibilizam drivers para GNU/Linux ou qualquer outra plataforma livre, o foco do trabalho foi modicado, passando ser o objetivo e motivaao, a criaao de um c c driver de dispositivo livre. No cap tulo 2, so apresentados os conceitos de biometria e suas aplicaoes, tcnicas a c e utilizadas na vericaao e identicaao de pessoas usando a datiloscopia. c c No cap tulo 3 feito um estudo de software de interfaceamento e sistemas operacionais, e

explorando conceitos importantes de acesso, controle e interfacemento de dispositivos de computador, chegando at o assunto sobre drivers de dispositivos, que o foco dessa e e monograa. No cap tulo 4 apresentado uma viso geral da arquitetura do padro USB e como e a a e feita a comunicaao entre um dispositivo e um computador atravs dessa porta. c e O cap tulo 5 referente ao processo de desenvolvimento do software prosposto, onde e so mostradas em detalhes as etapas para a criaao de um driver de dispositivo. a c J no cap a tulo 6, os resultados, tanto positivos como negativos, so apresentados e a e feita uma anlise cr a tica destes, podendo se tirar concluses fundamentadas em teoria e o prtica. a

Biometria
H tempos o homem estuda o comportamento dos seres vivos e utiliza muito do que a

encontra na natureza na melhoria da qualidade de vida da sociedade. Homens ancestrais so diferenciados por gelogos e historiadores pelo seu porte f a o sico, caracter sticas da estrutura ossea e arcada dentria, ou seja, medidas do corpo. a O termo biometria vem do latim e signica bio: vida; metria: mtrica, medida. Ou e seja, a medida dos seres vivos atravs de suas caracter e e sticas f sicas. E atravs da e biometria que poss a identicaao unica de pessoas. (DIAS, 2005), (BIOMETRIAe vel c
WIKIPEDIA, )

2.1

Datiloscopia

A datiloscopia o estudo dos desenhos formados pelas papilas drmicas ao n de e e vel polpas digitais, ou impresses digitais. Esses desenhos so formados no per o a odo de vida intra-uterina (perto do sexto ms de gestaao humana) e permanecem inalteradas at o e c e nal da vida de um indiv duo (GUMZ, 2002), (MARANHO, 1989). a Conforme Costa (2001), a palavra datiloscopia ou dactiloscopia uma palavra de e origem grega e composta dos elementos: daktylos = dedos e skopein = examinar, ou seja, a anlise dos dedos das mos ou ps. Pode-se dizer ento que o estudo biomtrico e a a e a e e utilizando os dedos como forma de mediao. c Uma impresso digital composta basicamente de trs elementos: n cleo, deltas e a e e u linhas. O n cleo uma formaao das linhas encontrado no centro de uma impresso u e c a digital. Os deltas so guras formadas pela junao de linhas de vrios sentidos, fazendo a c a parecer um tringulo. Deltas so importantes na classicaao de impresses digitais, pois a a c o a partir deles e de sua quantidade pode-se dividir um sistema de linhas em diversas classes, como mostra a gura 2.1 (COSTA, 2001). A partir dos deltas poss tambm dividir uma impresso digital em vrias regies e vel e a a o (MARANHO, 1989), (COSTA, 2001): a Regio marginal: regio que representa as formaoes papilares nas margens da ima a c 3

Figura 2.1: Elementos bsicos de uma impresso digital, retirado de (COSTA, 2001) a a presso digital. a Regio nuclear: regio central, onde normalmente se encontra o n cleo (na existncia a a u e dele). Regio basilar: regio abaixo da regio central e a base (referncia) de uma ima a a e e presso digital. a

2.1.1

Sistema Vucetich

O argentino Juan Vucetich foi o criador do primeiro sistema de vericaao utilizando c impresses digitais. Baseando-se nos estudos feitos por Galton e outros, Vucetich dividiu o uma impresso digital em quatro classes fundamentais. Abaixo so apresentadas as classes a a propostas por Vucetich: (MARANHO, 1989) a Arco: no possui regio nuclear denida. Neste caso, as regies basilar e maginal se a a o continuam de um ponto ao outro. Presilha externa: regio nuclear presente, porm marginalizado para a esquerda. a e Contm um unico delta e situado a esqueda do observador. e Presilha interna: regio nuclear presente, porm marginalizado para a direita. Contm a e e um unico delta e situado a direita do observador. Verticilio: regio nuclear bem denida e situada no centro do desenho. Tem a e caracter sticas oval, espiral e sinuoso.

Essas classes servem apenas para separar as impresses digitais em grandes grupos e o e baseado no n mero de deltas com suas respectivas posioes, no sendo poss identicar u c a vel unicamente uma pessoa. (GUMZ, 2002) E util na area criminal stica para determinar se, por exemplo, a impresso digital de um suspeito de um crime faz parte ou no da classe a a de uma impresso digital encontrada no local do crime. a

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

2.1.2

Detalhes de Galton

Segundo Maranho (1989), as min cias ou pontos caracter a u sticos so resultados de a acidentes apresentados pelas linhas (ou cristas) papilares e representam a garantia de unicidade em impresses digitais. As min cias so divididas em cinco grupos: cristas o u a nais, ilhas, bifurcaoes, cruzamentos e esporas. (COSTA, 2001), (GUMZ, 2002) c Uma crista nal uma linha que se interrompe abruptamente. J a bifurcaao uma e a c e linha que d origem a outras duas linhas, separadas por determinada angulaao. Ilhas ou a c lagos so formados por uma bifurcaao que termina convergindo em um mesmo ponto. A a c imagem 2.4 ilustra claramente esses pontos (COSTA, 2001), (GUMZ, 2002).

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

As min cias so elementos identicadores e podem ser utilizadas com certo grau de u a conabilidade, fazendo valer as condioes impostas pela datiloscopia, tratando-se ento c a de uma identicaao (e no reconhecimento). Segundo Costa (2001), doze pontos enconc a trados em uma impresso digital so sucientes para que seja feita a identicaao uma a a c pessoa.

2.1.3

Idencao e Vericao ca ca

Segundo Maranho (1989), identidade o conjunto de propriedades ou caracter a e sticas que tornam algum essencialmente diferente de todos os demais, com a quem se assemelhe e ou possa ser confundido. Baseado nessa armaao, pode-se dizer que o termo identidade c o termo que garante a unicidade de um ser ou um objeto. Diferente do termo recoe nhecimento, que uma identicaao sem nenhuma base tcnico-cient e c e ca (MARANHO, a 1989). Identicaao diferencia-se terminologicamente de reconhecimento, pelo fato de idenc ticaao ser um mtodo baseado em tcnicas cient c e e cas e o reconhecimento no. O rea conhecimento dito ento, uma identicaao no cient e a c a ca. Para que um mtodo de e identicaao seja aceito como cient c co, ou seja, que utilize uma tcnica de identicaao e c de base cient ca, ele precisa atender os requisitos abaixo citados (MARANHO, 1989) : a Unicidade, a propriedade ou caracter stica de algum ou algo ser unico; e Imutabilidade, que existe sempre e o que no muda (imutvel); a a Classicabilidade, indicando que caracter sticas podem ser mensurveis; a Praticabilidade, que signica que o mtodo venha a ser prtico. e a E necessrio ento fazer uma anlise desses resquisitos em relaao as impresses dia a a c o gitais como forma de identicaao. O conjunto de guras (ou min cias) que se formam c u em uma impresso digital unico, ou seja, no existe dois seres com com as mesmas ima e a presses digitais no mundo, atendendo assim o requisito da unicidade. Conforme citado, o as impresses digitais de um ser humano mantm-se naturalmente inalteradas ao longo o e de sua vida, sendo vlida para o requisito imutabilidade. Como o conjunto de caraca ter sticas das impresses digitais tambm podem ser medidas, ou seja, o encontro de, no o e m nimo, doze pontos caracter sticos em impresses digitais (ou min cias) e com a mesma o u

localizaao, j o suciente para se identicar uma pessoa, o requisito da classicabilic a e dade tambm atendido. A praticabilidade um termo que poderia ser substituido por e e e viabilidade. Tomando um exemplo, um mtodo de identicaao atravs da anlise do e c e a DNA
1

teoricamente poss e vel, porm no em termos prticos, pois ter de tirar sangue e a a

ou depositar um o de cabelo toda vez que for retirar dinheiro de um sistema bancrio a seria um tanto quanto desagradvel (COSTA, 2001), (MARANHO, 1989). a a

2.2

Sistemas biomtricos e

A exigncia por aumento de segurana, a facilidade e a comodidade zeram com e c que os sistemas biomtricos automticos tivessem uma maior aceitaao no mercado nas e a c ultimas dcadas. Alm do intenso uso em criminal e e stica, abaixo so apresentadas algumas a aplicaoes desses sistemas (JNIOR; JNIOR, 1979), (MARANHO, 1989) : c u u a Comrcio eletrnico: e o Segurana aliado a conabilidade o desejo de qualquer c ` e

usurio de internet como potencial consumidor. Muitos desses usurios sentem-se a a coagidos em fazer compras pela internet em funao da falta de segurana ou da falta c c de conhecimento sobre sistemas seguros. E por causa desse receio que empresas de comrcio eletrncio, principalmente B2C2 , vem investindo cada vez mais em soluoes e o c que envolvem sistemas biomtricos. (ROMAGNOLI, 2005) e Acesso f sico: A tecnologia biomtrica vem sendo utilizada com maior freqncia e ue 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 invs crachs com n e a veis de acesso, garantindo dessa forma uma maior segurana e minimizando ocorrncias de fraude. (ARAGAKI, 2005) c e Existem in meras aplicaoes que utilizam tecnologia biomtria, dos mais variados u c e tipos. Outras tcnicas alm da datiloscopia podem ser citadas como por exemplo leitura e e da ris, reconhecimento facial e o reconhecimento de voz.
1 2

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

2.3

Segurana da Informao c ca

A palavra segurana pode ter diversos signicados e esses signicados podem ser c abrangentes de pessoa para pessoa, mas basicamente se resume em um sentimento de conforto perante determinada situaao. c Informaao sempre foi considerado patrimnio importante, seja para uma organizaao c o c privada, p blica ou para um Estado. Preserv-las de outrem que pudesse fazer mal usos, u a tarefa que preocupa empresariados e autoridades (DIAS, 2005). e Com o advento dos computadores e suas interconexes em rede, permitiu repesctio vamente a concentraao de informaoes em formato digital e a facilidade em seu acesso. c c No sentido contrrio, computadores concentradores de informaoes passaram a ser alvo a c constante de ataques (DIAS, 2005). Segundo Siqueira (apud RUSSEL; GANGEMI, 1991), a segurana da informaao c c e baseada nas denioes dos termos condencialidade, integridade e na disponibilidade dos c recursos computacionais. Esses trs parmetros so considerados pilares da segurana da e a a c informaao e esto descritos a seguir (DIAS, 2005), (SIQUEIRA, 2004) : c a Condencialidade: Proteao da informaao contra acessos no autorizados. c c a Integridade: Preservaao da informaao quanto a alteraoes, violaoes ou desc c c c

truioes, por ato malicioso ou no. c a Disponibilidade: Garantia de acesso as informaoes sob demanda e sem atraso. c O no cumprimento dessa medida quando necessrio pode ser to ruim quanto a a a a destruiao de um dado. c Sistemas de idencaao biomtrica so grandes aliados para a mantenibilidade dos c e a pilares da segurana da informaao. c c

Figura 2.4: Pilares da segurana da informaao, retirado de Siqueira (2004) c c

Sistemas Operacionais
Um sistema operacional um programa de computador que tem como funao gerenciar e c

recursos (hardware e software) de um sistema computacional. O seu propsito prover um o e ambiente mais simples e produtivo para o usurio (TANENBAUM, 2003), (SILBERCHATZ; a
GALVIN; GAGNE, 2002).

3.1

Mquina Extendida a

Computadores so mquinas eletrnicas que utilizam puramente linguagem de mquina. a a o a Essa linguagem geralmente de dif programaao, principalmente para acessos de ene cil c trada e sa (E/S), (TANENBAUM, 1992) , (TANENBAUM, 2003). Uma das tarefas da de um sistema operacional ocultar do usurio programador as entrelinhas de acesso ao e a hardware, apresentando uma interface mais simples. Quer dizer ento que o Sistema Opea racional estende o hardware do computador para o usurio, como uma mquina virtual a a (TANENBAUM, 2003).

3.2

Componentes de um SO

Em um sistema operacional, vrios processos concorrentes atendem por diferentes a tarefas quase simultaneamente e cada um desses processos requisitam diversos recursos do sistema, seja por processamento, memria, conectividade, ou outros. O kernel (n cleo) o u a parte do sistema operacional responsvel por gerenciar essas requisioes e essas tarefas e a c podem ser divididas em cinco partes (RUBINI; CORBET; KROAH-HARTMAN, 2005) : Gerenciamento de memria o 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 ecientes para suprir a necessidade de vrios usurios acessarem o mesmo sistema, assim como ter vrios a a a programas executando diversas tarefas ao mesmo tempo. Um dos responsveis em a manter um sistema multiprogramado, multitarefa e multiusurio com boa performance a a caracter e stica de gerenciamento de processos (SILBERCHATZ; GALVIN; GAGNE, 2002) , (STALLINGS, 2000). 3.2.1.1 Processos

Um processo pode ser denido como a abstraao de um programa em execuao e que c c acompanhado por variveis e registradores do sistema (TANENBAUM, 2003). e a Computadores modernos tm a capacidade de executar vrias tarefas ao mesmo e a tempo, isso devido a caracter e stica do sistema operacional de ser multiprogramado. Um sistema considerado multiprogramado, quando ele tem a capacidade de colocar e vrias tarefas na memria e execut-las de forma parcial ou total (TANENBAUM, 2003), a o a (SAKATA, 2005). Em sistemas multitarefa, cada tarefa na memria executada pela CPU durante um o e tempo mximo e ento alternada por outra tarefa que estava pronta para ser executada, a a e mesmo que a primeira no tenha sido conclu a da. Quando existe um tempo mximo para a execuao de um processo pela CPU, necessrio a presena de um escalonador, cuja resc e a c ponsabilidade alternar a execuao dos processos entre a CPU e a memria, baseando-se e c o nos estados de cada processo (TANENBAUM, 2003), (SILBERCHATZ; GALVIN; GAGNE, 2002). 3.2.1.2 Estados de Processos

Em funao da caracter c stica de multiprogramaao, aliado a presena de um escac c lonador, um processo pode situar-se em diferentes estados, que representa seu grau de atividade, como mostra a gura 3.2. Os estados que um processo pode ser encontrar so a os seguintes (SILBERCHATZ; GALVIN; GAGNE, 2002) , (TANENBAUM, 2003) : Novo: Processo em estado de criaao. c Em execuo: As instruoes do processo esto sendo executadas pela CPU. ca c a

12

Figura 3.1: Abstraao de uma memria com vrios jobs na memria c o a o Bloqueado: O processo ca incapaz de executar esperando pela ocorrncia de um e evento. Pronto: O processo est pronto para ser executado, aguardando na la de prontos. a Finalizado: O processo nalizou sua execuao. c

Figura 3.2: Diagrama de estados de um processo, adaptado de Silberchatz, Galvin e Gagne (2002) Os estados dos processos indicam qual sua real situaao e so importantes para que c a o escalonador organize as tarefas a serem executas, assim como sua ordem e prioridade.

13

3.2.1.3

Threads

Os threads so entidades escalonadas para a execuao sobre a CPU (TANENBAUM, a c 2003). O thread est sempre contido em um processo e pode ser considerado uma unidade a bsica de utilizaao do processador. Processos tradicionais utilizam geralmente apenas a c um thread (linha) de controle por vez, porm em determinadas situaoes uma aplicaao e c c pode necessitar executar diversas tarefas concorrentemente, como se fossem processos separados. (SILBERCHATZ; GALVIN; GAGNE, 2002) Cada thread de um processo contm um conjunto de registradores e uma estrutura de e pilha, o que lhes permite trabalhar de forma independente. Dessa forma, vrias threads a podem trabalhar concorrentemente, o que chamado de sistema multi-threaded . A e vantagem de um sistema multi-threaded permitir que vrias execuoes ocorram no mesmo e a c ambiente do processo, aproveitando-se de recursos utilizados pelo processo em execuao c (endereamento, arquivos aberto, etc) (TANENBAUM, 2003), (SILBERCHATZ; GALVIN; c
GAGNE, 2002).

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

3.2.1.4

Comunicao Interprocessos ca

E com certa freqncia que processos tm de se comunicar. Essa necessidade de ue e comuniao deve ocorrer de maneira estruturada e sem interrupoes. Processos utilizam c c

14

o mesmo espao de memria que outros processos e podem utilizar tambm os mesmos c o e recursos, por exemplo a leitura de um arquivo. Para evitar acessos m ltiplos a regies u ` o cr ticas ou evitar acessos m ltiplos a recursos compartilhados, preciso fazer uso de u e alguma tcnica ou de um modelo de proteao (MITCHELL; OLDHAM; SAMUEL, 2001). e c 3.2.1.5 Condio de disputa ca

Condiao de disputa a situaao ao qual dois ou mais processos em execuao rec e c c quisitam acesso (leitura ou escrita) a um determinado recurso compartilhado. Como o escalonador de processos o responsvel por determinar qual processo ser utilizado, no e a a a h como determinar uma seqncia de execuao, sendo necessrio a implementaao de a ue c a c um algoritmo para evitar imprevistos. Caso no exista um algoritmo para proteger o a acesso a areas restritas unicamente, o resultado de uma operaao pode no ser o esperado c a (TANENBAUM, 2003).

Semforos a

Semforos so varveis-contadores que permitem gerenciar e sincronizar a a a

vrios processos ou threads. Trabalha com n meros inteiros no-negativos e provm uma a u a e abstraao simples, muito util para implementaao de excluso m tua. c c a u

Mutexes

O mutex uma verso simplicada de um semforo e so indicados para o e a a a

gerenciamento de excluso m tua para recursos do sistema ou partes de cdigo, princia u o palmente em threads implementadas em modo usurio. a

3.2.2

Entrada e Sa da

Uma outra tarefa essencial de um sistema operacional o gerenciamento de dispoe sitivos de entrada e sa (E/S). A arquitetura de E/S constitui em uma interface do da computador com o mundo exterior e prov ao sistema operacional informaoes de forma e c precisa para que esse efetue as requisioes de E/S de maneira efetiva (STALLINGS, 2002), c (TANENBAUM, 2003). 3.2.2.1 Dispositivos de E/S

Um dispositivo se comunica com um computador enviando sinais atravs de um meio e f sico. As caracter sticas de um dispositivo de entrada e sa podem variar muito, da tanto em funcionalidades, protocolos e velocidade de comunicaao. Conseq entemente c u

15

os mtodos de acesso e controle tambm so variados. Os dispositivos de entrada e sa e e a 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 so aqueles que no posa a suem uma estrutura denida para transmisso de dados, no so endereaveis e no a a a c a contm operaoes de posicionamento de dados. Ou seja, um dispositivo de carace c tere envia ou recebe um uxo de caracteres, no se importando com uma estrutura a denida de blocos. Dispositivos de bloco: Dispositivos de blocos so aqueles que possuem a capaa cidade de armazenar os dados em blocos de tamanho xo, contendo cada qual seu endereo, e que pode ser lido e/ou escrito independentemente de outro bloco. c Em um sistema computacional, os dispositivos de hardware so conectados em um a computador atravs de um Controlador de Dispositivo. Uma unidade de E/S come e posta por uma parte mecnica e por uma parte eletrnica. O controlador de dispositivo a o e o componente eletrnico do controlador e responsvel por converter sinais emitidos pelo o e a dispositivo em um formato mais simples para o sistema operacional. So responsveis a a tambm por executarem algum algoritmo de correao de erros, liberando o conte do em e c u buers para ser copiado para a memria principal. A realizaao desse trabalho feita o c e geralmente por um chip com programas de baixo n vel. A parte mecnica da unidade de a E/S o dispositivo propriamente dito (TANENBAUM, 2003). e Para se comunicar com o controlador, o processador necessita ler e escrever em registradores contidos no prprio controlador. Esses registradores podem ser utilizados tanto o para controle como transferncia de dados. Como alternativa, o controlador de dispositivo e pode fazer uso do recurso de memria mapeada. Esse recurso permite a CPU mapear o todos os registradores do controlador de dispositivo na memria. Cada registrador aso e sociado a um endereo unico ao qual nenhuma memria est associada (SILBERCHATZ; c o a
GALVIN; GAGNE, 2002), (TANENBAUM, 2003).

Quando um dispositivo termina sua tarefa, ele gera um sinal de interrupo no ca barramento ao qual est associado para avisar sua atual situaao. Esse sinal ento a c e a detectado pelo controlador de dispositivo que toma as devidas atitudes. O controlador, que responsvel por gerenciar essas interrupoes, verica se existe outro pedido de e a c interrupao em atendimento e passa o novo sinal a CPU. Isso faz com que a CPU pare c ` com a sua atividade atual, salve os registradores atuais na pilha e atenda a requisiao c

16

de interrupao. Ao iniciar o tratamento de interrupao, a rotina responsvel pelo tal, c c a informa a controladora de dispositivo que ele est livre para repassar novas interrupoes, a c 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 operaoes de E/S c utilizar o mtodo de E/S Programada (ou polling), ou seja, deixar com que a CPU e e e realize todo o trabalho. Esse mtodo basea-se em um bloco de instruoes (ou apenas uma e c instruao) fechado em um lao (for, while, etc), onde sua condiao de parada o trmino c c c e e da leitura ou escrita no ou do dispositivo em questo. a Primeiramente o dispositivo requisitado, caso ele esteja ocupado, retornado um e e sinal do controlador indicando geralmente um erro. Uma vez que o dispositivo esteja dispon vel, o processo do usurio efetua uma chamada do sistema para que um determia nado dado seja lido ou escrito. O sistema operacional normalmente copia uma cadeia de caracteres do espao do usurio no espao do n cleo, caso a operaao seja de escrita, ou c a c u c o inverso, caso a operaao seja de leitura. Esse processo facilita o acesso da informaao a c c ser lida ou escrita (TANENBAUM, 2003). No espao do n cleo, o sistema operacional atualiza espc c u cos 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 at que o mesmo esteja resetado e (valor 0). O sistema operacional l repeditamente bits de estados ocupado e pronto, e efetuando as operaoes de leitura e escrita at o m da cadeia de caracteres, mtodo c e e conhecido tambm como espera ociosa (TANENBAUM, 2003). e Esse mtodo pode se tornar ineciente na tentativa repetida de se encontrar um e dispositivo pronto para o servio, enquanto outro importante processo de CPU permanece c inacabado, ou simplesmente no atendido (SILBERCHATZ; GALVIN; GAGNE, 2002). a 3.2.2.3 E/S Orientada ` Interrupo a ca

Em determinados momentos torna-se mais eciente organizar o controlador de dispositivo para que notique a CPU quando um dispositivo termina o processamento de um sinal e ca dispon para novas requisioes de E/S, ao invs de fazer a CPU vericar vel c e repetidamente pela nalizaao de um processo de E/S atravs do mtodo de espera ocic e e osa. O mecanismo que possibilita um dispositivo noticar a CPU quando uma operaao c

17

nalizada, chamada de interrupo (SILBERCHATZ; GALVIN; GAGNE, 2002). e e ca De forma anloga ao a tem 3.2.2.2, aps uma cadeia de caracteres ser escrita no espao o c do n cleo e o primeiro caractere enviado ao dispositivo, a CPU invoca o escalonador de u processos fazendo com que outro processo entre em execuao. O processo que solicitou a c E/S ca no estado bloqueado at que toda cadeia de caracteres seja processada. e A cada cadeia de caracteres processada pelo dispositivo, gerado um sinal de ine terrupao onde a CPU pra o processo atual em execuao, salva seu estado na pilha e c a c atende ao tratamento de interrupao do dispositivo. Caso exista mais caracteres a serem c processados pelo dispositivo, o ciclo continua. Caso contrrio, o processo de usurio que a a requisitou o processamento desbloqueado (TANENBAUM, 2003). e

3.2.3

Sistemas de Arquivos

Um sistema de arquivo a camada do sistema operacional responsvel por prover mee a canismos de armazenamento e gerenciamento de dados. Entende-se por gerenciamento, o modo como esses dados so estruturados, gravados, nomeados e utilizados (SILBERa
CHATZ; GALVIN; GAGNE, 2002), (TANENBAUM, 2003).

3.2.3.1

Arquivo

Um arquivo a unidade lgica bsica de armazenamento de dados em dispositivos, e o a normalmente no voltil. Cada arquivo contm informaoes estruturadas de acordo com a a e c o seu tipo: arquivos texto, programas executveis, guras, v a deo, som, entre outros (SILBERCHATZ; GALVIN; GAGNE, 2002).

E caracter stica de um sistema operacional suportar vrios tipos de arquivos, e esa ses podem ser classicados em: arquivos regulares e diretrios, arquivos de caractere e o arquivos de bloco. Arquivos regulares so basicamente arquivos texto puro em padro ASCII 1 ou ara a quivos binrios. Os arquivos de caracteres so utilizados para modelar dispositivos de a a entrada/sa e os arquivos de bloco para modelar discos ou dispositivos de bloco, proda priamente dito (TANENBAUM, 2003). Os arquivos devem manter tambm informaoes de estados, onde podem variar em e c
Sigla para American Standard Code for Information Interchange que um conjunto de cdigos para e o o computador representar nmeros, letras, pontuaao e outros caracteres u c
1

18

quantidade, de sistema operacional para sistema operacional, mas so basicamente os a seguintes: Nome: utilizada pelo usurio para identicar e disting ir diferentes arquivos. e a u Nmero identicador: E um n mero (ou uma seqncia de caracteres alfau u ue numricos) que identicam unicamente um arquivo. Essa informaao utilizada e c e pelo sistema. Localizao: Essa informaao um ponteiro para o dispositivo e para a localizaao ca c e c do arquivo. Tamanho: Contm informaoes do tamanho atual do arquivo. e c Data e hora: Data e hora em que o arquivo foi criado, modicado e acessado. Dono: informaoes do usurio que criou o arquivo c a 3.2.3.2 Diretrios o

Diretrios so estruturas lgicas que permitem a organizaao e gerenciamento de aro a o c quivos em um sistema de arquivo. Em muitos sistemas operacionais os diretrios so o a simplesmente arquivos. Na verdade so considerados meta-arquivos, ou seja, so arquivos a a simples que contm informaoes sobre a estrutura de diretrios e subdiretrios pertencene c o o tes a ele (TANENBAUM, 2003). Em sistemas de arquivos modernos, a estrutura de diretrios geralmente repreo e sentada em forma de arvore hierarquizada, ou seja, podem conter arquivos e tambm e diretrios (subdiretrios), conforme visto na gura 3.4. o o Esse tipo de hierarquia bastante utilizada por permitir um usurio criar tantos e a diretrios quanto achar necessrio para se organizar. Claro que existe um n mero limitado o a u de arquivos/subdiretrios por diretrio, que no inerente apenas ao espao em disco o o a e c utilizado e que tambm varia de sistema de arquivo para sistema de arquivo, (SAKATA, e 2005). O Unix tambm possui uma estrutura de diretrios de forma hierarquizada, conforme e o mostra a gura 3.5. De acordo com Bach (1990), para que um sistema Unix ou GNU/Linux realize uma operaao de entrada ou sa ele necessita utilizar um tipo de arquivo chamado descritor c da,

19

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

/ (root)

/usr

/dev

/etc

/bin

/home

/boot

Figura 3.5: Arvore de diretrio Unix - Simplicado, adaptado de Bach (1990) o de arquivo. Um descritor de arquivo um n mero inteiro, que est associado a um arquivo e u a aberto, sendo que esse arquivo pode ser um dispositivo externo, ou um arquivo no disco, ou qualquer outro dispositivo f sico/lgico que est sob dom o a nio do SO.

3.3

Classes de Dispositivos e Mdulos o

Um driver de dispositivo ou simplesmente um mdulo um programa de computador o e espec co, responsvel por controlar determinado dispositivo. Tarefas que necessitam de a abstraao do hadrware ou que geralmente so chamadas de baixo n c a vel, so protegidas a pelo sistema operacional que permite apenas alguns programas especiais de acess-los. Os a mdulos, ou drivers de dispositivo, rodam geralmente no espao do ncleo (ou espao o c u c do kernel ), quais so os programas que rodam no dom do kernel ou n cleo. Enquanto a nio u

20

programas de aplicaao rodam no espao do usurio, que representam os programas c c a que rodam em uma camada superior a camada do kernel (RUBINI, 1998). ` O Unix tem uma maneira de disting ir os diferentes tipos de dispositivos. Cada u mdulo geralmente implementado para cada tipo desses dispositivos. (RUBINI, 1998) o e Assim como os dipositivos que so dividos em categorias, um driver por conseqncia a ue segue tambm as mesmas classicaoes (RUBINI, 1998), (RUBINI, 2001): e c Drivers de bloco Drivers de caractere

3.3.1

Drivers de caractere

Driver de caractere classe de mdulos de dispositivos que permitem o controle de e o dispositivos de caractere, ou seja, tem como caracter stica no possuir uma estrutura a denida para os dados (RUBINI, 1998). Os drivers de caractere podem suportar requisioes de E/S de tamanho varivel e so c a a suportados pela maioria dos dispostivos. Esses tipos de drivers so comumente utilizados a por dispositivos que trabalham com transferncias de um byte por vez ou transferncias e e que no exigem um tamanho de pacote de tamanho xo (TUTORIALS. . . , 2001). a

3.3.2

Major e Minor Numbers

Como citado em (PERIM, 2001), em sistemas Unix tudo considerado um arquivo, e inclusive dispositivos so montados como arquivos na estrutura de arvore do sistema de a arquivos corrente. Dispositivos de caractere so acessados utilizando-se nomes e que so a a chamados de arquivos especiais, arquivos de dispositivos ou simplesmente ns (nodos). o Pensando ainda na estrutura de diretrios do Unix esses dispositivos so convencionalo a mente alocados no diretrio /dev e so representados pela letra c indicando que um o a e dispositivo de caractere, ao ponto que a letra b indica que o dispositivo um dispositivo e de bloco, como visto na gura 3.6 (RUBINI; CORBET; KROAH-HARTMAN, 2005). Os major numbers so utilizados para identicar qual driver exato deve ser ser asa sociado ao dispositivo conectado. Esses n meros de identicaao podem ser alocados u c dinamincamente pelo driver ou pode-se denir um n mero xo para o dispositivo no sisu tema. Logicamente essa no a melhor escolha, pois, apesar de sistemas operacionais a e

21

Figura 3.6: Parte do conte do do diretrio /dev, exibindo os tipos de dispositivos. u o modernos permitirem o compartilhamento de major numbers, ainda existe a possibilidade de conito (RUBINI, 1998). Em contrapartida minor numbers tem como funao identicar para o kernel exatac mente qual dispositivo est sendo referenciado, ou seja, utilizando minor numbers que a e o kernel pode diferenciar dois dispositivos idnticos conectados ao computador (RUBINI; e
CORBET; KROAH-HARTMAN, 2005).

3.3.2.1

Mtodos e

Um driver de dispositivo deve fornecer mtodos bsicos de acesso. Esses mtodos so e a e a na verdade chamadas de sistema simples, com certo n de abstraao do hardware, ou vel c seja, permite a comunicaao com um dispositivo sem necessariamente conhecer os detalhes c de projeto ou mesmo do protocolo de controle deste. Alguns mtodos bsico do kernel e a Linux esto listados a seguir (BACH, 1990), (RUBINI, 1998): a Open: o n cleo do sistema utiliza o mesmo mtodo para abertura de arquivos u e especiais (caractere e bloco) como arquivos regulares. Ao requisitar a abertura de um dispositivo, o sistema aloca o recurso desejado, obtm o descritor de arquivo e e retorna ao processo do usurio. a Release: ou mtodo Close, e tem como funao fechar a conexo de um dispositivo e c a aberto. Read e Write: so mtodos para leitura e escrita de dispositivos. Quando invocados a e para utilizaao de dispostivos de caractere, esse mtodo chama o respectivo mtodo c e e de um driver de dispositivo que tem a real funao de leitura e escrita. c ioctl: uma chamada de sistema que recebe trs argumentos: descritor de arquivo e e proveniente de uma chamada open ou creat, comando espec co do driver de dispositivo ao qual est lidando e por ultimo um argumento para esse comando. Com a

22

esse tipo de chamada do sistema, poss executar todos os comandos dispon e vel veis do dispositivo, utilizando apenas um mtodo. e Mais mtodos podem ser desenvolvidos, a m de fornecer maior controle ou mesmo e por necessidades de controle de um hardware mais complexo, variando ento de fabricante a para fabricante. As chamadas ioctl so uma alternativa para esse tipo de situaao. a c

Comunicao USB ca
A sigla USB um acrnimo para Universal Serial Bus ou em portugus, barramento e o e

serial universal. Esse barramento um padro de conexo de perifricos e computadores, e a a e que foi originalmente criado para substituir a grande variedade de barramentos existentes por um unico tipo, alm de permitir que vrios perifricos de diferentes fabricantes pu e a e dessem interoperar em uma arquitetura aberta. Foi idealizado em 1995 por um grupo de empresas de tecnologia e quais as motivaoes para criaao do mesmo incluem: (USB.ORG, c c 2005) Conexo de um PC ao telefone a Facilidade de utilizaao c Expanso de portas de comunicaao a c Soluao de baixo custo e que suporta altas taxas de tranferncias c e Um barramento de dados o caminho de comunicaao f e c sico e o acesso entre o processador e seus perifricos. Um barramento padro juntamente com um conjunto pre a e denido de sinais, temporizadores, conectores provm um meio pelos quais as interfaces e de dispositivos, ou controladores, podem ser facilmente desenvolvidos em um sistema computacional (MENDONA; ZELENOVSKY, 2002). c At a especicaao 1.1 do USB, as velocidades de tranferncias podiam variar de e c e 1,5Mbps a 12Mbps, dependendo do dispositivo e do tipo de aplicaao (USB. . . , 2005). c

4.1

Arquitetura

A arquitetura de um sistema USB divida em trs partes bsicas. So elas: e e a a Interconxeo USB a Dispositivos USB Host USB 23

24

4.1.1

Topologia

A conexo f a sica do USB segue a topologia do tipo estrela, onde um hub USB o e centro de cada estrela e os dipositivos conectados a ele so as pontas. Cada conexo entre a a um host e um hub ou funao, ou entre um hub e outro hub, uma conexo ponto-a-ponto c e a conforme ilustra a gura 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 presena de apenas um host, ao qual sua interface com c os dispositivos referenciada como controladora de host. O host USB responsvel pela e e a detecao de quando um dispositivo conectado ou desconectado, pelo gerenciamento do c e uxo de controle, pelo gerenciamento do uxo de dados, por coletar estados e atividades e ainda suprir energia para dos dispositivos a ele conectados.

25

4.1.3
4.1.3.1

Dispositivos USB
Hubs

Segundo USB.org (2005), os hubs so elementos chave para a caracter a stica de plug and play do USB, ou seja, permite que um dispositivo possa ser instalado e automaticamente detectado pelo sistema operacional. Hubs so concentradores de conexo por isso a a possibilitam a conexo m ltipla do USB. Os pontos de conexo so chamados de portas a u a a e cada hub converte um unico ponto em um m ltiplo ponto de conexo, conforme pode u a ser observado na gura 4.2 (USB. . . , 2005), (USB.ORG, 2005).

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

4.1.3.2

Funoes c

Uma funao um dispositivo USB que capaz de receber ou transmitir dados ou c e e informaoes de controle no barramento. Uma funao tipicamente implementada como c c e um dispositivo separado, com um cabo que o conecta em um hub, porm pacotes f e sicos devem implementar m ltiplas funoes e um hub dedicado com apenas um unico cabo. u c Isto conhecido como um dispositivo composto. e Cada funao contm informaoes de conguraoes que descrevem suas capacidades e c e c c requerimentos de recursos. Antes de uma funao ser usada, ela precisa ser congurada pelo c host, no qual inclui alocaao de banda e a seleao de opoes de conguraao (USB.ORG, c c c c 2005).

26

4.2
4.2.1

Modelo de Transferncia de Dados e

Protocolo de barramento

Toda transaao USB envolve a transferncia de trs pacotes bsicos, onde cada transaao c e e a c iniciada pela controladora de host, que envia um pacote contendo o tipo e direao da e c transaao, o endereo do dipositivo e o n mero do endpoint. A fonte (host ou dispositivo) c c u responsvel por enviar pacotes com informaoes ou mesmo um pacote informando que e a c no h nada a ser transferido, enquanto o destino geralmente responde com um pacote de a a handshake 1 indicando que a transferncia ocorreu com sucesso. O modelo de tranferncia e e entre o fonte e o destino, de um host para um endpoint de um dispositivo, chamdo de e pipe. 4.2.1.1 Endpoints

Um endpoint uma porao unicamente identicvel de um dispositivo USB, que o e c a e trmino do uxo de comunicaao entre o host e o dispositivo e uma direao determinada e c c para uxo de informaoes. Esse tipo de comunicaao suporta apenas uma direao (comuc c c nicaao simplex ) (USB.ORG, 2005), (RUBINI; CORBET; KROAH-HARTMAN, 2005). c Cada dsipositivo lgico USB composto de uma coleao independente de endpoints o e c e cada dispositivo lgico tambm unicamente endereado pelo sistema no momento da o e e c conexo. a 4.2.1.2 Pipes

Um pipe USB uma associaao entre um endpoint de um dispositivo e o software do e c lado do host. Os pipes representam a habilidade de trafegar informaoes entre o software c do host via buer de memria e um endpoint de um dispositivo. Como descrito na prpria o o especicaao USB, existem dois modos de comunicaao pipe (USB.ORG, 2005): c c Stream: a informaao trafegada dentro de um pipe no contm uma estrutura USB c a e denida; Mensagem: ao contrrio da comuniao tipo Stream, as mensagens so informaoes a c a c que trafegam dentro de um pipe com uma estrutura USB denida (USB.ORG, 2005).
E um termo usado para denir o processo de negociaao de taxas de transmisso de dados entre c a dispositivos.
1

27

O pipe de mensagem de controle Default Control Pipe um pipe que consiste de e dois endpoints sendo um deles um endpoint n mero zero, que sempre existe em uma u comunicaao, desde a primeira vez que um dispositivo conectado. Tem como objetivo c e fornecer acesso as conguraoes, estados e informaoes de controle do dispositivo em ` c c questoi (USB.ORG, 2005). a

4.2.2

Tipos de transferncia e

O USB suporta o intercmbio de informaoes funcionais e de controle entre um host a c e um dispositivo como um conjunto de conexes uni ou bi-direcionais. O uxo de ino formaoes de uma conexo (pipe) deve ser independente de outra conexo, onde uma c a a conexo que transfere dados de um host para um dispositivo deve ser diferente da coa nexo para se transferir dados de um dispositivo para um host. A arquitetura USB pode a ser compreendida por quatro divises bsicas: uxo de controle, uxo de dados Bulk, o a uxo de dados por interrupao e uxo de dados iscrono (USB.ORG, 2005). c o 4.2.2.1 Controle

As transferncias de controle so usadas pelo software do sistema USB para congue a rar dispositivos quando esses so conectados pela primeira vez e ocorre entre o software a cliente e suas funoes. Esse tipo de transferncia permite o acesso a diferentes partes do c e dispositivo. Uma transferncia de controle composto de uma transaao de Setup que e e c envia requisioes de informaoes do host para a funao, zero ou mais transaoes de dados c c c c enviando as informaoes na direao indicada pela transaao de Setup, e a transaao de c c c c Status retorna a informaao do estado da funao para o host. A transaao de Setup rec c c torna um ag de sucesso indicando que o endpoint completou corretamente a operaao c requisitada (USB.ORG, 2005). O sistema USB trabalha com o conceito de rede de melhor esforo para suportar a c entrega das transferncias de controle entre o host e os dipositivos. e 4.2.2.2 Iscrono o

Transferncias tipo Iscrona tambm so designados para grandes quantidades de dae o e a dos, porm nem sempre a tranferncia garantida. E chamada de transferncia tolerante e e e e a erro. As caracter sticas importantes de uma transferncia tipo Iscrona so (USB.ORG, e o a 2005):

28

Acesso a banda USB com certa latncia. e Divises constantes de informaoes atravs de um pipe de acordo com as informaoes o c e c providas pelo prprio pipe. o No caso de ocorrncia de falhas, no feito o reenvio de um dado. e a e Os dispositivos USB que geralmente utilizam a conexo iscrona, so para ns que, a o a perdas de dados so de certa forma aceitveis. Dispositivos em tempo-real so os mais a a a comuns, como audio e v deo. (RUBINI; CORBET; KROAH-HARTMAN, 2005) 4.2.2.3 Interrupo ca

Esse tipo de transferncia designado para dispositivos que no necessitam trafegar e e a grandes quantidades de dados, ou seja, enviam e recebem pequenas quantidades de informaao sem uma freqncia determinada. Duas caracter c ue sticas importantes podem ser citadas para o tipo de transferncia de interrupao (USB.ORG, 2005): e c Servio mximo garantido para o pipe. c a Tentativas de retransmisso de tempos em tempos, quando ocorrer falha na entrega. a 4.2.2.4 Bulk

Transferncias do tipo Bulk so designadas para suportar dispositivos que necessie a tam transferir uma quantidade relativamente grande de dados em tempos altamente variveis, sendo poss a vel uma transferncia utilizar a largura de banda que estiver dise pon (USB.ORG, 2005). vel As tranferncias tipo Bulk so seq enciais e a conbilidade na troca de dados ase a u e segurada pelo hardware, utilizando algoritmos de detecao de erros (CRC2 ) e invocando c um n mero limitado de requisioes ao hardware. Alm disso, a largura de banda utlizada u c e por esse tipo de transferncia varia de acordo com a atividade do dispositivo em questo e a (USB.ORG, 2005). Ao requisitar um pipe para transferncia tipo Bulk provido ao requisitante (USB.ORG, e e 2005): Acesso ao USB na largura de banda dispon vel
2

Sigla para Ciclic redundancy check, um algoritmo para detecao de erros c

29

Retransmisso no caso de falhas ocasionais na entrega devido a erros no barramento a Garantia na entrega de dados, mas sem garantia de banda ou latncia. e No existe uma estrutura denida no uxo de comunicaao entre bulk pipes. a c

4.3

URBs

URB um acrnimo para USB Request Block, ou Bloco de Requsiao USB, que nada e o c mais do que uma maneira como o Kernel Linux trabalha para se comunicar com todos e os dispositivos USB (RUBINI; CORBET; KROAH-HARTMAN, 2005). Um URB usado para enviar ou receber dados de um espef e cico endpoint USB, de um espef dispositivo USB, de maneira ass cio ncrona. Um driver de dispositivo USB deve alocar vrios URBs para um simples endpoint ou ento reutilizar um URB para diferentes a a endpoints, dependendo da necessidade do driver. O ciclo de vida de um URB descrito e da seguinte forma (RUBINI; CORBET; KROAH-HARTMAN, 2005): E criado por um driver de dispositivo; E enviado para um espec co endpoint de um espec co dispositivo; E enviado para n cleo USB (kernel ) por um driver de dispositivo; u E enviado para o espec co driver controladora de host pelo dispositivo especicado pelo n cleo USB; u Processado pelo driver controlador de host que faz a transferncia USB para o e dispositivo; Quando a transferncia URB completada o driver controlador de host notica o e e driver de dispositivo;

Desenvolvimento
Ser apresentado nesse cap a tulo todas as etapas para o desenvolvimento do driver

para o dispositivo biomtrico Biopod, utilizando conceitos fundamentais apresentados e nos cap tulos anteirores, principalmente sobre USB.

5.1

Requisitos do software

O desenvolvimento do projeto aqui proposto, criar uma camada de software que e seja responsvel por fazer o interfaceamento de uma aplicaao que necessite manipular o a c dispositivo biomtrico Biopod, sem se preocupar com detalhes de protocolo, para a plae taforma GNU/Linux. Essa camada, ou driver, deve ser responsvel em enviar comandos a de conguraao, controle e aquisiao de dados para o dispositivo e retornar os resultados c c dessas operaoes, permitindo que outras aplicaoes faam o devido processamento das c c c informaoes recebidas. c Para exemplicar e tentar comprovar o real funcionamento desse driver, o resultado esperado da comunicaao entre o computador e o dispositivo deve ser a imagem de uma c impresso digital. a

5.1.1

Materiais utilizados

Para o desenvolvimento desse projeto foi necessria uma gama de recursos de hardware a e software, que so abaixo descritos: a Microcomputador IBM/PC x86, 256Mb memria RAM e host USB; o Sensor biomtrico APC Biopod e
r

Sistema operacional Slackware GNU/Linux kernel srie 2.4; e Sistema operacional Debian GNU/Linux kernel srie 2.6; e Sistema operacional Microsoft Windows XP USB Snier SnoopyPro 30
r

31

USB Snier USB Monitor Compilador gcc 3.3.4 Editor de textos Vi Improved

5.2
5.2.1

Projeto BiopodUsbDriver
O Dispositivo

O dispositivo utilizado para a construao do driver o sensor biomtrico Biopod do c e e fabricante APC. Esse dispositivo tem porta de comunicaao USB 1.1 e utiliza uma matriz c de aquisiao de dados e o chip AES3500, ambos do fabricante Authentec, conforme as c especicaoes do datasheet desse fabricante. A gura 5.1 mostra o sensor Biopod. c

Figura 5.1: Sensor biomtrico utilizado no projeto e O Biopod pode aquisitar imagens de dimenses por 96x96 pixels 1 e que, segundo o o prprio fabricante, so sucientes para fazer anlise das min cias para identicaao. Seu o a a u c sensor acionado pela temperatura da mo humana, atravs de micro-antenas dispostas e a e no sensor. Acompanha tambm uma licena do software OmniPass e compat com e c e vel sistemas operacionais da Microsoft. A gura 5.2 mostra o software aquisitando uma imagem de uma impresso digital, no Ms-Windows XP. a

5.2.2

Esquema do projeto

Como a preocupaao desse trabalho o desenvolvimento de um driver de dispositivo, c e o esquema do projeto simplesmente ao qual o prprio dispositivo se prope: facilitar e o o o acesso ao dispositivo, capturando imagens de impresses digitais para uma aplicaao o c espec ca, como por exemplo autenticaao de um usurio em determinado sistema, utic a lizando o sistema operacional GNU/Linux. A gura 5.3 mostra a sequncia de eventos e para obtenao de uma imagem de uma impresso digital. c a
1

Unidade bsica de uma imagem digital a

32

Figura 5.2: Software Omni Password, aquisitando uma impresso digital a

5.2.3

Aquisio do Protocolo ca

A aquisiao e deniao do protocolo foi a parte do projeto mais complicada e foi c c tambm, no decorrer do desenvolvimento, a tarefa mais obscura, j que a unica fonte de e a informaao era o resultado do log feito pelo snier 2 . c A metodologia adotada foi a engenharia reversa, o qual tem por objetivo extrair um modelo de construao de um produto a partir desse produto j pronto e fechado. c a Basicamente so feitos testes variando-se as entradas e observando as sa a das, tentando compreender o funcionamento interno dessa caixa-preta. Para anlise dos dados foram utilizados dois software capazes de aquisitar todas as a informaoes trafegadas nas portas USB do computador e deixa-ls em um formato mais c a simples, para que ento fossem analisadas. O procedimento utilizado est descrito a a a seguir: O primeiro passo foi vericar o funcionamento do dispositivo em um ambiente onde se pudesse comprovar seu perfeito funcionamento. Foi utilizando ento, um coma
Snier um termo para designar um software que varre determinada porta de comunicaao do e c computador e obtm seu contedo e u
2

33

Figura 5.3: Esquema do projeto para obtenao de uma impresso digital c a putador com sistema operacional Ms-Windows XP e nele instalados os drivers e software fornecidos pelo fabricante. O prximo passo foi pesquisar por informaoes que poderiam ser importantes para o c o desenvolvimento do driver, como especicaoes do rmware e datasheets do chip, c porm nada havia sido encontrado. e Logo ento foram instalados dois software para aquisiao das informaoes pela porta a c c USB: SnoopyPro e USB Monitor, ambos para sistemas operacionais Ms-Windows XP. O primeiro um software livre licenciado sobre os termos da GNU GPL, e e o segundo um freeware onde para utilizaao de funoes adicionais era preciso e c c de um licenciamento especial. Foram instalados e congurados devidamente e aps o iniciar o software de aquisiao de imagem da impresso digital fabricante (OmniPass c a Enrolment), os sniers iniciaram concomitantemente com o software a aquisiao dos c dados trafegados pela porta USB, gravando essas informaoes em um arquivo texto. c A partir de ento, foi feita uma profunda anlise, tentando separar comandos de a a conguraao, protocolo e dados propriamente ditos (imagem), do arquivo gerados c pelos sniers.

5.2.4

Biblioteca de Acesso a USB (LibUsb)

A LibUsb uma biblioteca de funoes que permite o acesso a dispositivos USB de uma e c forma mais fcil e abstra a da, sendo poss criar drivers de dispositivos reais no espao vel c do usurio (PROJECT, 2005). As vantagens de criar mdulos no espao do usurio so: a o c a a Abstraao das chamadas mais complexas do kernel do sistema c

34

Independncia de verso do kernel e a Facilidade no desenvolvimento de novos mdulos o A desvantagem que, no existindo um mdulo dedicado no espao do n cleo, a cada e a o c u novo software a ser desenvolvido deve conter rotinas USB para conexo com dispositivo a em questo (KROAH-HARTMAN, 2001). a

Figura 5.4: Tela SnoopyPro - Snier USB

5.2.5

Implementao ca

Com o protocolo teoricamente denido, foi necessrio criar os mdulos que iriam a o 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 prticas de a programaao, que no foi poss fazer em todos os casos. c a vel

35

A partir da verso 2.4, o Linux j possu suporte a comunicaao USB, isso inclui muia a a c tas das placas controladoras, concentradores e dipositivos propriamente ditos, existentes no mercados de computadores x86. O mdulo que d ao Linux a possibilidade de controlar o a dispositivos USB basicamente um conjunto de drivers USB simples, genricos, invocados e e pelos nomes usb.o e usbcore.o, e que so responsveis por permitir outros software fazerem a a chamadas ao sistema, tornando a comunicaao USB um pouco mais simples. A gura 5.5 c mostra os mdulos carregados em um sistema operacional Slackware GNU/Linux, atravs o e do comando lsmod.

Figura 5.5: Comando lsmod, exibindo os mdulos carregados em um sistema operacional o Slackware GNU/Linux Segundo a especicaao USB, todo dispositivo homolagado pela USB.org deve ter dois c n meros para identicaao unica de um dispositivo: o idProdutc e o idVendor. u c O idProduct o n mero que dene o modelo do produto, j o idVendor dene o e u a fabricante. Esses dois n meros so essenciais para utilizaao de um driver de dispositivo, u a c j que so eles que permitem o sistema operacional saber qual driver carregar no momento a a da detecao de um novo dispositivo conectado ou mesmo o prprio driver certicar-se c o que est lidando com um dispositivo conhecido (RUBINI; CORBET; KROAH-HARTMAN, a 2005). Utilizando um comando do shell do GNU/Linux poss obter mais informaoes e vel c sobre os disposistivos USB que esto conectados a mquina. O comando o a ` a e cat /proc/bus/usb/devices, onde /proc/bus/usb o subdiretrio que est montado o usbfs, e o a conforme ilustra a gura 5.6. Segundo Kroah-Hartman (2001), o USBFS ou o usbdevfs a implementaao de um e c

36

Figura 5.6: Informaoes de dispositivos montados na estrutura usbfs c sistema de arquivos para acesso a dispositivos USB no GNU/Linux. O USBFS mapeia ` todos os componentes USB do sistema utilizando as chamadas bsicas do kernel para a controle USB e cria uma estrutura de diretrios em local pr-determinado (na verso 2.4 o e a do Linux o diretrio o /proc/bus/ ) do sistema de arquivos atual. Como no GNU/Linux o e tudo acessado como um arquivo, a partir dessa estrutura de diretrios montada, e o e poss executar as chamadas bsicas de open, close, read e write de um driver carregado vel a na memria (RUBINI; CORBET; KROAH-HARTMAN, 2005). o Conforme descrito em Project (2005), a biblioteca LibUsb disponibiliza uma srie de e funoes para acesso e controle de dispositivos USB. Depois de instalado essa biblioteca e c t-la denido no diretrio dos kernel headers 3 , necessrio apenas fazer a incluso do seu e o e a a cabealho. c Aps extrair as informaoes de protocolo do Biopod e preparar o ambiente de deseno c volvimento, que se deu inicio ao desenvolvimento do driver. Primeiramente, a estratgia e e adotada foi a construao de um mdulo no espao do n cleo (ou espao do kernel ), porm c o c u c e devido a diculdades de implementaao e desenvolvimento, adotou-se a estratgia de criar c e um driver no espao do usurio, utilizando a biblioteca LibUsb. c a Com a documentaao da biblioteca LibUsb acess c vel, foi criado ento um mdulo a o simples que basicamente fazia a vericaao do idVendor e idProduct pr-determinado, c e com o dispositivo conectado no barramento. Conhecidos ento a localizaao do dispositivo a c Biopod no computador, foi feito a abertura (open) e o fechamento (close) de uma conexo a com o dispositivo (` titulo de teste). a 5.2.5.1 Protocolo - Controle

Aps a abertura de uma conexo com um dispositivo USB, a primeira atitude a o a se tomar foi trocar informaoes com o dispositivo com o intuito de conhecer e ajustar as c
3

local onde se encontram as denioes de funoes e bibliotecas do kernel e do sistema c c

37

h Tabela 5.1: Viso macro do protocolo implementado pelo driver a Remessa Tipo de Transferncia e Funo ca 1 control Conguraao inicial c 2 bulk Conguraao dos registradores c 3 bulk Detecao de um dedo c 4 bulk Requisiao dos dados c

conguraoes bsicas do mesmo. E nesse momento que utilizado o Default Control Pipe. c a e Para esse tipo de situaao, a especicaao USB determina a utilizaao de transferncias c c c e de controle, conforme visto no cap tulo 4. De acordo com informaoes extra c das do snier, os cinco primeiros pacotes trafegados eram utilizados para o m de conguraao. Adicionado ao mdulo a funao de envio de c o c dados de controle e conguraao, como por exemplo congurar o pipe de transferncia. c e A tabela 5.2.5.1 mostra, em termos macros, o protocolo inicial para controle do Biopod. 5.2.5.2 Protocolo - Congurao dos Registradores ca

Logo aps a troca dos primeiros pacotes, que representam a seao de controle, foi o c necessrio o envio de uma dezena de outros pacotes que tem por objetivo, a conguraao a c dos registradores do chip contido no Biopod. Essa seao a que contm o maior n mero c e e u de pacotes enviados ao dispositivo, porm ocorre apenas uma vez aps a abertura do e o dispositivo. 5.2.5.3 Protocolo - Requisio ca

Congurados os registradores, foi necessrio denir mais trs conjuntos de pacotes de a e envio para o dispositivo para que este estivesse pronto para o envio dos dados. A exigncia e do envio desses pacotes so particulares do dispositivo, que so denidos pelo conjunto a a eletrnico que compe a matriz de aquisiao. o o c Nesse ponto, a transferncia passa a ser do tipo bulk, pois tanto o endpoint de entrada e como de sa so desse tipo, que tambm denido pelo fabricante. da a e e Quando enviado o primeiro conjunto de pacotes, o dispositivo foi vericado a presena c de um ag chamado Drive Ring, que setado toda vez que a matriz de aquisiao de e c dados identica a presena de um dedo. Segundo o datasheet do fabricante, porm de um c e

38

sensor similar, ao redor da matriz ativa de aquisiao, existem micro-antenas que detectam c a presena de um dedo atravs de calor (ou induao) e so elas as responsveis por setar c e c a a ou resetar o ag Driver Ring (AUTHENTEC, 2003). Os outros trs conjuntos de pacotes so pertinentes a conguraoes espec e a c cas dos registradores do hardware e sempre retornam um pacote de tamanho 252 bytes quando as conguraoes so feitas com sucesso ou retornam um n mero negativo quando algum c a u erro ou inconsistncia ocorre. e 5.2.5.4 Protocolo - Dados propriamente ditos

Terminado as etapas de controle e conguraao e requisiao, vem a ultima etapa da c c comunicaao, que a transferncia dos dados alvo (imagem obtida pelo sensor). Essa c e e informaao transmitida aps o ultimo pacote de requisiao ter sido enviado e atendida c e o c e aps a chamada read para o dispositivo e retorna blocos de tamanho de 64 bytes (tamanho o do endpoint). Com a utilizaao da LibUsb, esses blocos de 64 bytes so armazenados em um unico c a buer e somente no nal da mesma que a biblioteca libera a aquisiao de um pacote e c com o tamanho total dos dados transmitidos. Em m, o Biopod transmite um buer de 8362 bytes de dados, que representam a imagem de uma impresso digital aquisitada. a 5.2.5.5 Denio da imagem ca

A ultima parte do projeto foi a deniao do tipo da imagem. Aps o processo de c o implementaao do protocolo de comunicaao e aquisiao dos dados, foi preciso descobrir c c c qual era o tipo da imagem e como era montada. Intuitivamente, a primeira atitude foi escrever o conte do inteiro obtido em um arquivo da forma que veio com um cabealho u c simples do tipo PGM 4 . Utililizando o software grco The Gimp (GIMP, 2005), testes foram feitos na tentaa tiva de aprender como se comportavam imagens simples e sem compresso. Para os testes a foram criadas imagens extremamente pequenas com tamanhos 1x1 pixel e 2x2 pixels, utilizando cabealhos de imagem PGM (Portable Graymap). c Aps incessantes tentativas emp o ricas e sem sucesso, foi encontrado na internet um datasheet de um sensor do mesmo fabricante, porm de um produto diferente. Quanto e
PGM - Sigla inglesa para Portable GrayMap que um formato de arquivo de imagem simples em e escala de cinza
4

39

as denioes no formato da imagem, foram as sugeridas no datasheet e aplicadas no c programa. Os resultados podem ser vistos na seao de resultados, no cap c tulo 6. 5.2.5.6 BiopodUsbDriver

Conclu a deniao da imagem, o driver pode ser considerado pronto, necessitando da c apenas de alguns ajustes de melhoria no desempenho e na qualidade da imagem aquisitada. Por m, a gura 5.7 ilustra o uxo do BiopodUsbDriver.

40

Inicio

Detecao do dispositivo

Configuraoes iniciais

Envio comandos para detecao um dedo

Dete ctado?

NAO

SIM
Envio de comandos de handshake

Aquisiao dos dados

Montagem e gravaao da imagem em arquivo

SIM

Continua aquisiao?

NAO
Fecha o dispositivo

Fim

Figura 5.7: Fluxograma do driver

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 fazer vel uma anlise cr a tica e chegar a poss veis concluses. o O resultado nal um driver de dispositivo que trabalha no espao do usurio, que e c a pode aquisitar imagens do sensor biomtrico APC Biopod, com chip AES 3500 integrado, e em formato no compactado de um byte por pixel. a

6.1

Testes e Anlise dos Resultados a

Antes da deniao correta da imagem, foram feitos diversos testes com o objetivo de c exibir uma impresso digital que era aquisitada atravs do driver. Foi constatado que, a e aps o protocolo, um pacote de 8632 bytes era enviado pela porta USB, onde imaginavao se ser os bytes decorrentes de uma impresso digital fornecida pelo sensor. A primeira a tentativa foi escrever um arquivo com esses bytes, da forma como eles eram enviados, com um cabealho simples, tipo PGM. A gura 6.1 mostra o primeiro resultado obtido. c

Figura 6.1: Primeiro resultado obtido, imagem formada com o bytes da forma como eram aquisitados Com esse resultado negativo, outras tentativas foram feitas, porm sem nenhum ree sultado coerente. As tentativas foram basicamente trocar a ordem de escrita no arquivo em relaao aos dados aquisitados do sensor. A gura 6.2 mostra a imagem montada, inc vertendo a seq encia de bytes recebidos e escritos e a deniao do tamanho no cabealho. u c c Para tentar descobrir qual sentido a matriz de aquisiao do Biopod realiaza a varredura c para obtenao da imagem, testes foram feitos colocando a ponta do dedos em uma das c extremidades e comparado a imagem formada pelo programa. `

41

42

Figura 6.2: Imagem com resoluao 90x90 pixels e com seq encia de bytes invertido c u

(a) Posicionamento do dedo na parte lateral do sensor

(b) Imagem aquisitada com o dedo na lateral do sensor

Figura 6.3: Teste realizado para vericaao da rotaao da imagem c c Nesse ponto foi poss identicar a rotaao da imagem enviada pelo sensor, que vel c e de 90 graus no sentido horrio. a Imaginava-se ento, que o problema poderia ser em funao da deniao do tamanho a c c da imagem, ou seja, forando um cabealho de 64x64 pixels em uma imagem de qualquer c c outra dimenso, poderia ser suciente para que a imagem casse distorcida a ponto de a se tornar irreconhec vel. Foram testadas vrias dimenses dentre o range poss a o vel. Mais testes foram feitos sem nenhum resultado positivo. Com esse problema em mente, a alternativa restante foi procurar por informaoes c sobre o chip que compunha o dispositivo, e que pudesse esclarecer como era montada a imagem. Foi encontrado ento um datasheet de outro sensor biomtrico, porm do a e e mesmo fabricante. Baseado nesse documento, as informaoes de dados transmitidos do c 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 tambm era espec e co.

43

Implementando um algor tmo para o tratamento desses bytes, de acordo com as especicaoes dispon c veis, foi ento poss exibir uma imagem de uma impresso digital, a vel a como mostra a gura 6.4.

Figura 6.4: Primeira imagem de uma impresso digital aquisitada a Ficou obivo, a partir da primeira aquisiao que a imagem resultante estava com uma c rotaao de 90 e que foi facilmente resolvido, utilizando a tcnica de transposiao de mac e c trizes, como resultado mostra a gura 6.5.

Figura 6.5: Impresso digital aquisitada e rotacionada em noventa graus a Outros testes foram feitos para vericaao e certicaao do funcionamento do driver. c c As imagens 6.6(a), 6.6(b) e 6.6(c) mostram o resultado satisfatrio. o

(a) Impresso dia gital aquisitada do dedo indicador esquerdo

(b) Impresso dia gital aquisitada do dedo indicador direito

(c) Impresso dia gital aquisitada do dedo mdio direito e

Figura 6.6: Impresses digitais aquisitadas utilizando o BiopodUsbDriver o

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 capaz de e fornecer informaoes sucientes para a utilizaao em uma aplicaao de reconhecimento de c c c padres de impresso digital, em plataforma GNU/Linux. o a

Concluses o
Com a pluralizaao de sistemas operacionais alternativos no mercado, tornando o moc

noplio nesse segmento uma cao, obrigar empresas de hardware a repensarem sobre o c a p blico-alvo que pretendem atingir, se quiserem se manter competitivos e no limitados u a a apenas uma tecnologia. Sendo isso fator decisivo para essas companhias, o desenvolvimento de drivers de dispositivos, conseq entemente, ter tambm de ser reavaliado. u a e At que o amadurecimento, tanto das empresas, como do mercado, venha a suceder, e o desenvolvimento de classes de mdulos para dispositivos continuar a ser tarefa ardua o a para os desenvolvedores de aplicaao que dependam de um equipamento espec c co e que utilizam SOs alternativos. Esse projeto vem mostrar a importncia dos drivers de dispositivos e quais as posa sibilidades de criaao para sistemas GNU/Linux. Contribui tambm, de forma signicac e tiva para a comunidade Software Livre, aumentando o n mero de dispositivos suportado u em um sistema operacional GNU/Linux, alm de abrir novas possibilidades de implee mentaoes futuras utilizando esse driver como recurso. c Para projetos futuros, ca a possibilidade de se portar esse driver para o espao do c n cleo, poder adicionar algoritmos de pr-processamento na imagem aquisitada, utiliz-lo u e a para enm realizar uma identicaao biomtrica de usurios de um sistema e at integrar c e a e um sistema de identicaao automtica utilizando o Biopod com mdulos de autenticaao c a o c do GNU/Linux, como o PAM (Password Authentication Module).

45

Referncias e
ARAGAKI, B. Biometria. 2005. Dispon vel em: <http://tecnologia.uol.com.br/especiais/ultnot/2005/07/21/ult2888u71.jhtm>. AUTHENTEC. Product Specication 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 em: <http://pt.wikipedia.org/wiki/Biometria>. vel Acesso em: 03 de maio de 2005. COSTA, S. M. F. Classicaao e vericaao de impresses digitais. 2001. c c o DIAS, C. Segurana e Auditoria da Tecnologia da Informao. Rio de Janeiro: c ca Axcell Books, 2005. GIMP, T. The GNU Image Manipulation Program. 2005. Dispon vel em: <http://www.gimp.org>. GUMZ, R. A. Prottipo de um sistema de identicaao de min cias em impresses o c u o digitais utilizando redes neurais articiais feedforward multicamada. 2002. J NIOR, A. A.; J NIOR, J. B. de Oliveira e C. Lioes de Meldicina Legal. 16. ed. u u c So Paulo: Editora Nacional, 1979. a KROAH-HARTMAN, G. Writing a Real Driver - In User Space. 2001. Dispon vel em: <http://www.linuxjournal.com/node/7466/>. MARANHO, O. R. Curso Bsico de Medicina Legal. 4. ed. So Paulo: Editora a a a Revista dos Tribunais, 1989. MENDONA, A.; ZELENOVSKY, R. PC: Um Guia Prtico de Hardware e c a Interfaceamento. 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: Voc sua senha. 2005. Dispon em: e e vel <http://www.serpro.gov.br/publicacao/tematec/2002/ttec61>. RUBINI, A. Linux Device Drivers. 1. ed. Sebastopol: OReilly, 1998. RUBINI, A. Linux Device Drivers. 1. ed. Sebastopol: OReilly, 2001. RUBINI, A.; CORBET, J.; KROAH-HARTMAN, G. Linux Device Drivers. 3. ed. Sebastopol: OReilly, 2005. RUSSEL, D.; GANGEMI, G. T. Computer Security Basics. Sebastopol: OReillyi and 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 geraao: Implementaao de novas tecnologias. c c UNESP, 2004. STALLINGS, W. Operating Systems. 4. ed. New Jersey: Prentice Hall, 2000. STALLINGS, W. Arquitetura e Organizao de Computadores. 5. ed. So Paulo: ca a Prentice Hall, 2002. TANENBAUM, A. Sistemas Operacionais Modernos. 2. ed. So Paulo: Pearson a Prentice Hall, 2003. TANENBAUM, A. S. Organizao Estruturada de Computadores. 3. ed. Rio de ca Janeiro: 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 em: <http://www.infowester.com/usb20.php>. vel USB.ORG. USB Spec. 1.1. 2005. Dispon vel em: <http://www.usb.org/developers/docs/usbspec.zip>.