Embed Size (px)
Citation preview
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIAS DA COMPUTAÇÃO – BACHARELADO
MECANISMO PARA LICENCIAMENTO DE APLICATIVOS
MICROSOFT .NET BASEADO EM ASSINATURA DIGITAL
XML
LEONARDO CHAGAS D’IPPOLITO
BLUMENAU 2004
2004/2-32
LEONARDO CHAGAS D’IPPOLITO
MECANISMO PARA LICENCIAMENTO DE APLICATIVOS
MICROSOFT .NET BASEADO EM ASSINATURA DIGITAL
XML
Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Ciências da Computação — Bacharelado.
Prof. Marcel Hugo - Orientador
BLUMENAU 2004
2004/2-32
MECANISMO PARA LICENCIAMENTO DE APLICATIVOS
MICROSOFT .NET BASEADO EM ASSINATURA DIGITAL
XML
Por
LEONARDO CHAGAS D’IPPOLITO
Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por:
______________________________________________________ Presidente: Prof. Marcel Hugo – Orientador, FURB
______________________________________________________ Membro: Prof. Francisco Adell Péricas, FURB
______________________________________________________ Membro: Prof. Sérgio Stringari, FURB
Blumenau, 08 de Dezembro de 2004
Dedico este trabalho aos meus pais, Francisco José Memoria D’Ippolito e Cristina Maria Chagas D’Ippolito, pelo apoio e incentivo recebidos durante os últimos 25 anos.
“Aprendi muitas coisas com Ivan Lessa. Lição número 1: não escreva. Lição número 2: se realmente tiver de escrever, trate o resto da humanidade aos tapas e pontapés.”
Diogo Mainardi
AGRADECIMENTOS
Agradeço à minha namorada Samantha Sabel, que durante os dias em que estive
fazendo este trabalho, preparou para mim diversas xícaras de café e chá verde, que me
mantiveram acordado. Sou imensamente grato pelo seu carinho.
RESUMO
A pirataria de software é um problema freqüente para as empresas que desenvolvem programas de computador. Este trabalho descreve a especificação e implementação de um mecanismo para gerenciar licenças de aplicativos Microsoft .NET. O mecanismo tem como objetivo principal impedir a utilização ilegal do aplicativo que está sendo comercializado ou distribuído. Ele está dividido em dois módulos: o primeiro, de licenciamento, é uma biblioteca a ser integrada ao aplicativo .NET, responsável por enviar requisições de licenças à empresa desenvolvedora e também fazer o controle de acesso aos recursos do software; o segundo é o módulo de gerenciamento, uma aplicação ASP.NET, para que o administrador da empresa desenvolvedora possa expedir ou rejeitar os pedidos de licenças para o aplicativo, através de qualquer navegador da Internet. O mecanismo desenvolvido é capaz de amarrar as licenças de software a uma máquina específica, com a checagem de identificadores de hardware. A segurança é implementada com a tecnologia de assinatura digital XML e a comunicação entre os módulos ocorre através de um web service.
Palavras Chaves: Pirataria de Software; Proteção Contra Cópias; Assinatura Digital; XML.
ABSTRACT
Software piracy is a frequent problem to companies that develop computer programs. This work describes the specification and implementation of a mechanism to manage software licenses for Microsoft .NET applications. The main objective of this mechanism is to prevent illegal use of the application that is being commercialized or distributed. It is divided in two modules: the first one, called licensing module, is a library to be integrated with the .NET application. This module is responsible for sending license requests to the company that developed the software, and also to control the access to software resources. The second is the management module, an ASP.NET application, where the company administrator will be able to approve or reject license requests through any web browser. The licensing mechanism is capable of tying license files to specific computer machines, by checking hardware identifiers. Security is implemented with XML digital signature and communication between modules is made by a web service.
Keywords: Software Piracy; Copy Protection; Digital Signatures; XML.
LISTA DE ILUSTRAÇÕES
Quadro 1 – Encriptando uma mensagem no .NET com Rijndael ............................................26 Quadro 2 – Exemplo de string encriptada ................................................................................27 Quadro 3 – Algoritmo RSA para geração do par de chaves criptográficas..............................28 Quadro 4 – Geração de chaves RSA no .NET..........................................................................28 Quadro 5 – Exemplo de chave privada RSA............................................................................29 Quadro 6 – Exemplo de chave pública RSA ............................................................................29 Figura 1 – Visão geral do processo de assinatura digital .........................................................30 Figura 2 – Tipos de assinatura XML quanto à localização dos dados .....................................33 Quadro 7 – Sintaxe da assinatura digital XML ........................................................................33 Quadro 8 – Exemplo do documento que será assinado (pedido.xml) ......................................36 Quadro 9 – Assinatura de um documento XML no .NET........................................................37 Quadro 10 – Documento pedido.xml assinado digitalmente....................................................37 Quadro 11 – Verificação de assinatura digital XML no .NET.................................................38 Figura 3 – Compilação em diferentes linguagens no Microsoft .NET.....................................40 Quadro 12 – Página de apresentação ASP.NET (exemplo.aspx).............................................42 Quadro 13 – Página de código ASP.NET (exemplo.aspx.cs) ..................................................42 Quadro 14 – Criação de um documento XML através da classe XmlTextWriter....................45 Quadro 15 – Documento XML criado com a classe XmlTextWriter.......................................46 Quadro 16 – Acessando informação em um documento XML................................................46 Quadro 17 – Exemplo de schema XML ...................................................................................48 Quadro 18 – Validação de documento XML contra o seu schema ..........................................49 Figura 4 – Visão geral de funcionamento de um web service..................................................51 Quadro 19 – Exemplo de envelope SOAP para uma requisição ..............................................52 Quadro 20 – Exemplo de envelope SOAP para uma resposta .................................................53 Quadro 21 – Exemplo de web service (ServicoDeHora.asmx) ................................................53 Quadro 22 – Arquivo web.config para o web service ..............................................................54 Quadro 23 – Aplicação para consumir o web service (TesteConsumo.cs) ..............................54 Figura 5 – Criando a classe proxy para um web service ..........................................................55 Figura 6 – Compilação e execução de um cliente de web service ...........................................55 Figura 7 – Visão geral do software...........................................................................................57 Figura 8 – Diagrama de casos de uso .......................................................................................59 Figura 9 – Diagrama de classes de análise para o módulo de licenciamento...........................63 Figura 10 – Diagrama de classes de análise para o módulo de gerenciamento........................64 Figura 11 – Diagrama de classes de projeto para o módulo de licenciamento.........................65 Figura 12 – Diagrama de classes de projeto para o módulo de gerenciamento (administrador)
..........................................................................................................................................66 Figura 13 – Diagrama de classes de projeto para o módulo de gerenciamento (público)........67 Figura 14 – Diagrama de seqüência para “entrar com dados pessoais” ...................................68 Figura 15 – Diagrama de seqüência para “requisitar licença”..................................................68 Figura 16 – Diagrama de seqüência para “acompanhar situação da requisição enviada”........69 Figura 17 – Diagrama de seqüência para “efetuar download de licença” ................................69 Figura 18 – Diagrama de seqüência para “remover licença” ...................................................70 Figura 19 – Diagrama de seqüência para “remover protocolo de acompanhamento de
requisição” ........................................................................................................................70 Figura 20 – Diagrama de seqüência para “expedir licença”.....................................................71 Figura 21 – Diagrama de seqüência para “rejeitar requisição” ................................................71 Figura 22 – Diagrama de seqüência para “consultar histórico” ...............................................72 Figura 23 – Diagrama de seqüência para “obter nível de acesso”............................................73
Figura 24 – Diagrama de atividades .........................................................................................74 Figura 25 – Solution do Visual Studio para o software desenvolvido .....................................75 Quadro 24 – Obtendo o diretório de execução do módulo de licenciamento...........................76 Quadro 25 – Exemplo de documento de requisição de licença................................................76 Quadro 26 – Acessando informações do disco via platform interop........................................77 Quadro 27 – Método que verifica um documento de requisição recebido pelo web service ...78 Quadro 28 – Inclusão de informações e gravação do documento de requisição......................78 Quadro 29 – Documento de requisição recebido com sucesso pelo web service ....................79 Quadro 30 – Função responsável por gerar o ID aleatório para a requisição...........................80 Quadro 31 – Obtenção do ID da requisição enviada ................................................................81 Quadro 32 – Protocolo de acompanhamento da requisição (requisicaoEmEspera.xml)..........81 Quadro 33 – Licença assinada ..................................................................................................82 Quadro 34 – Requisição de licença rejeitada............................................................................83 Quadro 35 – Verificação de um arquivo de licença .................................................................84 Figura 26 – Chave pública embutida no assembly Licenciamento.dll .....................................85 Figura 27 – Tela principal do aplicativo licenciado .................................................................86 Figura 28 – Preenchimento dos dados pessoais........................................................................86 Figura 29 – Situação inicial do módulo de licenciamento........................................................87 Figura 30 – Tentativa de acesso aos recursos sem uma licença válida ....................................87 Figura 31 – Formulário de parâmetros da requisição ...............................................................88 Figura 32 – Dados do protocolo de acompanhamento da requisição .......................................88 Figura 33 – Mensagem de que a requisição está sendo avaliada pelo administrador ..............89 Figura 34 – Acesso às funções administrativas no módulo de gerenciamento (login) ............89 Figura 35 – Menu do administrador no módulo de gerenciamento..........................................90 Figura 36 – Lista de requisições aguardando avaliação ...........................................................91 Figura 37 – Gerenciamento de uma requisição ........................................................................92 Figura 38 – Nível de acesso e tempo de uso concedidos a uma licença...................................93 Figura 39 – Notificação enviada por email no momento da assinatura....................................93 Figura 40 – Mensagem de licença disponível ..........................................................................94 Figura 41 – Licença transferida para o aplicativo ....................................................................94 Figura 42 – Acesso às funções do aplicativo depois de transferida a licença ..........................95 Figura 43 – Definição do motivo da rejeição de uma requisição .............................................95 Figura 44 – Notificação enviada por email no momento da rejeição da requisição.................96 Figura 45 – Mensagem de que a requisição de licença foi rejeitada pelo administrador .........96 Figura 46 – Utilitário para geração do par de chaves RSA ......................................................97 Figura 47 – Geração das chaves para assinatura do assembly Licenciamento.dll ...................98 Figura 48 – Configuração do nível de acesso máximo em Licenciamento.cs..........................98 Figura 49 – Inclusão do compilador C# no path do sistema operacional.................................99 Figura 50 – Compilação do módulo de licenciamento ...........................................................100 Figura 51 – Integração do aplicativo .NET com o módulo de licenciamento ........................101 Figura 52 – Definindo a localização do web service no arquivo de configuração.................101 Figura 53 – Controle de acesso a um recurso do aplicativo ...................................................102 Figura 54 – Pastas para o módulo de gerenciamento .............................................................103 Figura 55 – Configurações do módulo de gerenciamento (Web.config) ...............................104 Figura 56 – Definição da senha do administrador (Web.config) ...........................................104 Figura 57 – Cópia de GerenciamentoWEB para o servidor IIS .............................................105 Figura 58 – Definição de Application name para o GerenciadorWEB ..................................105 Figura 59 – Licença corrompida.............................................................................................106 Figura 60 – Licença transferida para uma máquina não autorizada .......................................106 Figura 61 – Licença expirou...................................................................................................107
Figura 62 – Erro ao ler uma versão falsa de Licenciamento.dll .............................................108
LISTA DE TABELAS
Tabela 1 – Caso de uso “entrar com dados pessoais”...............................................................59 Tabela 2 – Caso de uso “requisitar licença” .............................................................................60 Tabela 3 – Caso de uso “acompanhar situação da requisição enviada” ...................................60 Tabela 4 – Caso de uso “efetuar download da licença” ...........................................................60 Tabela 5 – Caso de uso “remover licença”...............................................................................61 Tabela 6 – Caso de uso “remover protocolo de acompanhamento de requisição”...................61 Tabela 7 – Caso de uso “expedir licença” ................................................................................61 Tabela 8 – Caso de uso “rejeitar requisição”............................................................................62 Tabela 9 – Caso de uso “consultar histórico”...........................................................................62 Tabela 10 – Caso de uso “obter nível de acesso” .....................................................................62
LISTA DE SIGLAS
API – Application Program Interface
ASP – Active Server Pages
BIOS – Basic Input/Output System
CLR – Common Language Runtime
DCOM – Distributed Component Object Model
ECMA – European Computer Manufacturers Association
GIF – Graphics Interchange Format
HTML – Hypertext Markup Language
HTTP – Hypertext Transfer Protocol
IIS – Internet Information Services
IL – Intermediate Language
JVM – Java Virtual Machine
MAC – Media Access Control
MD5 – Message Digest 5
NTFS – NT File System
PE – Portable Executable
PGP – Pretty Good Privacy
PIB – Produto Interno Bruto
PKCS #7 – Public-Key Cryptography Standards #7
RF – Requisito Funcional
RMI – Remote Method Invocation
RNF – Requisito Não Funcional
SGML – Standard Generalized Markup Language
SHA – Secure Hash Algorithm
SOAP – Simple Object Access Protocol
SSL – Secure Sockets Layer
UDDI – Universal Description, Discovery and Integration
URI – Uniform Resource Identifier
USB – Universal Serial Bus
W3C – World Wide Web Consortium
WSDL – Web Services Description Language
XML – Extensible Markup Language
SUMÁRIO
1 INTRODUÇÃO..................................................................................................................16
1.1 MOTIVAÇÃO...................................................................................................................17
1.2 OBJETIVOS......................................................................................................................17
1.3 ORGANIZAÇÃO DO TEXTO.........................................................................................18
2 PROPRIEDADE INTELECTUAL E MECANISMOS DE PROTEÇÃO ...................19
2.1 DESBLOQUEIO POR SENHA CONSULTADA EM MANUAL ..................................19
2.2 VERIFICAÇÃO DE NÚMEROS SERIAIS .....................................................................20
2.3 ATIVAÇÃO ONLINE ......................................................................................................21
2.4 PROTEÇÃO COM HARDWARE....................................................................................21
2.5 PROTEÇÃO COM IDENTIFICAÇÃO DO HOST..........................................................22
2.6 LICENCIAMENTO COM ASSINATURA DIGITAL.....................................................23
2.7 CONSIDERAÇÕES SOBRE LICENCIAMENTO DE SOFTWARE .............................23
3 CRIPTOGRAFIA E ASSINATURAS DIGITAIS..........................................................25
3.1 CRIPTOGRAFIA..............................................................................................................25
3.1.1 CRIPTOGRAFIA COM ALGORITMO DE RIJNDAEL ..............................................25
3.1.2 ASSINATURAS DIGITAIS...........................................................................................27
3.1.3 CRIPTOGRAFIA DE CHAVES PÚBLICAS................................................................27
3.1.4 FUNÇÕES HASH...........................................................................................................29
3.1.5 VISÃO GERAL DO PROCESSO DE ASSINATURA DIGITAL ................................30
3.2 ASSINATURAS DIGITAIS XML ...................................................................................31
3.2.1 TIPOS DE ASSINATURA DIGITAL XML..................................................................32
3.2.2 SINTAXE DA ASSINATURA DIGITAL XML ...........................................................33
3.2.2.1 Elemento <Signature> ..................................................................................................33
3.2.2.2 Elemento <SignedInfo>................................................................................................34
3.2.2.3 Elemento <Reference> .................................................................................................35
3.2.3 ASSINATURA XML NO .NET FRAMEWORK..........................................................35
3.2.4 VERIFICAÇÃO DE ASSINATURA XML NO .NET FRAMEWORK........................38
4 TECNOLOGIAS UTILIZADAS......................................................................................39
4.1 MICROSOFT .NET FRAMEWORK ...............................................................................39
4.2 CLR ...................................................................................................................................39
4.3 LINGUAGEM C# .............................................................................................................41
4.4 TECNOLOGIA ASP.NET ................................................................................................41
4.5 XML ..................................................................................................................................43
4.5.1 FORMAÇÃO CORRETA DO DOCUMENTO .............................................................44
4.5.2 CRIAÇÃO DE UM DOCUMENTO XML NO .NET FRAMEWORK.........................45
4.5.3 ACESSANDO O CONTEÚDO DE UM DOCUMENTO XML....................................46
4.6 SCHEMAS ........................................................................................................................47
4.7 WEB SERVICES ..............................................................................................................50
4.7.1 CONCEITOS BÁSICOS DE FUNCIONAMENTO ......................................................50
4.7.2 UNIVERSAL DESCRIPTION, DISCOVERY AND INTEGRATION (UDDI)...........51
4.7.3 WEB SERVICES DESCRIPTION LANGUAGE (WSDL)...........................................51
4.7.4 SIMPLE OBJECT ACCESS PROTOCOL (SOAP).......................................................52
4.7.5 CRIAÇÃO DE UM WEB SERVICE NO .NET.............................................................53
4.7.6 CONSUMO DE UM WEB SERVICE NO .NET...........................................................54
4.8 TRABALHOS CORRELATOS........................................................................................55
5 DESENVOLVIMENTO DO SOFTWARE.....................................................................57
5.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO.......................57
5.2 ESPECIFICAÇÃO ............................................................................................................58
5.2.1 DIAGRAMA DE CASOS DE USO ...............................................................................59
5.2.2 DESCRIÇÃO DOS CASOS DE USO............................................................................59
5.2.3 DIAGRAMAS DE CLASSES ........................................................................................62
5.2.3.1 Diagramas de classes de análise ...................................................................................62
5.2.3.2 Diagramas de classes de projeto ...................................................................................65
5.2.4 DIAGRAMAS DE SEQUÊNCIA ..................................................................................67
5.2.5 DIAGRAMA DE ATIVIDADES ...................................................................................73
5.3 IMPLEMENTAÇÃO ........................................................................................................74
5.3.1 FERRAMENTAS UTILIZADAS...................................................................................75
5.3.2 IMPLEMENTAÇÃO DAS PRINCIPAIS FUNÇÕES DO SOFTWARE......................75
5.3.2.1 Gravação dos dados pessoais........................................................................................75
5.3.2.2 Geração do documento de requisição ...........................................................................76
5.3.2.3 Obtenção das informações de hardware .......................................................................77
5.3.2.4 Armazenamento do documento de requisição ..............................................................78
5.3.2.5 Pastas do módulo de gerenciamento.............................................................................80
5.3.2.6 Protocolo de acompanhamento.....................................................................................80
5.3.2.7 Assinatura da licença ....................................................................................................81
5.3.2.8 Rejeição da requisição ..................................................................................................82
5.3.2.9 Verificação da licença...................................................................................................83
5.3.2.10 Chave pública ........................................................................................................84
5.3.2.11 Nível de acesso ......................................................................................................85
5.3.3 OPERACIONALIDADE DA IMPLEMENTAÇÃO......................................................85
5.3.4 INTEGRAÇÃO DO MECANISMO COM APLICATIVOS .NET ...............................96
5.3.4.1 Geração do par de chaves .............................................................................................97
5.3.4.2 Definição do nível de acesso máximo no módulo de licenciamento............................98
5.3.4.3 Instalação do .NET Framework ....................................................................................99
5.3.4.4 Compilação do módulo de licenciamento.....................................................................99
5.3.4.5 Integração com o aplicativo........................................................................................100
5.3.4.6 Configuração do web service......................................................................................101
5.3.4.7 Obter o nível de acesso ...............................................................................................102
5.3.4.8 Módulo de gerenciamento ..........................................................................................102
5.3.4.9 Cópia das pastas e configuração das permissões ........................................................103
5.3.4.10 Arquivo de configuração .....................................................................................103
5.3.4.11 Transferência dos arquivos ..................................................................................104
5.4 RESULTADOS E DISCUSSÃO ....................................................................................106
6 CONCLUSÕES................................................................................................................110
6.1 EXTENSÕES ..................................................................................................................111
16
1 INTRODUÇÃO
Os programas de computador são uma das mais valiosas tecnologias na era da
informação. A produção de software exige conhecimento técnico e um grande volume de
investimentos. Pela sua importância e alcance, movimenta bilhões de dólares em negócios e
emprega muitos profissionais.
Devido à facilidade de se copiar programas hoje em dia, com a popularização dos
gravadores de CD e DVD e do acesso rápido à Internet, o uso ilegal de aplicativos tem
crescido bastante. De acordo com a Associação Brasileira das Empresas de Software (2004), a
pirataria de software é a prática de reproduzir ilegalmente um programa de computador sem a
autorização expressa do titular da obra. Pode-se compreender também a expressão pirataria de
software como sendo a utilização de um programa de computador sem a sua devida licença de
uso.
A necessidade de se proteger aplicativos contra cópias ilegais nunca foi tão forte.
Segundo Folha de São Paulo (2003), 56% dos aplicativos utilizados atualmente no Brasil são
piratas. De acordo com especialistas, a contribuição da indústria de tecnologia com o PIB de
um país é inversamente proporcional ao índice de pirataria que o país possui.
O uso ilegal de aplicativos desestimula a economia de um estado, uma vez que os
produtores de tecnologia não têm o retorno merecido do investimento que realizaram e, em
conseqüência disso, menos empregos são gerados. Observa-se também que a prática da
pirataria impede que os próprios autores de software invistam na melhoria dos programas,
devido ao menor rendimento obtido a partir do trabalho realizado, resultando em uma
evolução mais lenta daquele segmento tecnológico.
Para minimizar o prejuízo com a pirataria, um mecanismo seguro de licenciamento é
de grande importância para as empresas que comercializam software. O gerenciamento
eletrônico de licenças fornece uma camada de controle digital para os aspectos de utilização
do software. A adoção de um mecanismo dessa natureza representa, para a empresa ou
instituição envolvida, uma maneira de reduzir ou dificultar a pirataria do seu produto.
Para que seja possível atingir um bom nível de proteção em um mecanismo de
gerenciamento eletrônico de licenças, é necessário recorrer a algum recurso tecnológico capaz
de proteger a concessão de uso que uma determinada empresa fornece para os usuários do seu
17
software. Por exemplo, se esta concessão estiver na forma de um arquivo de licença, é preciso
ter a garantia de que a licença foi realmente construída e transmitida pelo provedor do
software, e também de que ela não foi alterada por intermediários.
Com base no exposto, desenvolveu-se um mecanismo para gerenciamento eletrônico
de licenças de software, visando contribuir com a diminuição da pirataria. O XML foi usado
como tecnologia de apoio no mecanismo desenvolvido, por ser adequado às necessidades de
manipulação das informações nos arquivos de licença, por estar preparado para a tecnologia
de assinatura digital, pela grande disponibilidade de ferramentas e bibliotecas voltadas a essa
tecnologia, além do baixo custo envolvido na sua utilização.
1.1 MOTIVAÇÃO
Segundo Almeida (2004), a redução dos índices de pirataria acelera o crescimento do
mercado de tecnologia. Com crescimento projetado para 34% - entre 2001 e 2006 -, o
segmento poderia crescer quinze pontos percentuais mais rápido, ou seja, 49%, caso ocorresse
a redução de dez pontos percentuais no índice médio de pirataria mundial.
Dentre as possíveis medidas a serem adotadas visando dificultar a prática da pirataria,
o gerenciamento eletrônico de licenças é um dos instrumentos mais importantes para a
empresa ou instituição que deseja ter um controle maior sobre a utilização dos seus produtos.
1.2 OBJETIVOS
O objetivo deste trabalho consiste em desenvolver um mecanismo de software para
gerenciamento de licenças de aplicativos Microsoft .NET, utilizando o padrão de assinatura
digital XML recomendado pelo W3C.
Os objetivos específicos do trabalho são:
a) disponibilizar um componente de licenciamento que possa ser facilmente integrado
a aplicativos existentes que necessitam de controle de utilização;
b) disponibilizar um módulo de gerenciamento em forma de aplicação web, para que
o administrador da empresa ou instituição que provê o software possa expedir ou
rejeitar os pedidos de licenças através da Internet.
18
1.3 ORGANIZAÇÃO DO TEXTO
Este trabalho está dividido em seis capítulos. O primeiro capítulo trata da introdução e
objetivos do trabalho. O segundo, terceiro e quarto capítulos abordam a fundamentação
teórica das tecnologias envolvidas. O quinto capítulo trata do desenvolvimento e
implementação do software. O sexto capítulo finaliza o trabalho com a conclusão.
19
2 PROPRIEDADE INTELECTUAL E MECANISMOS DE PROTEÇÃO
Como a proposta deste trabalho é desenvolver um instrumento técnico para contribuir
com o combate à pirataria de software, convém descrever algumas definições preliminares
sobre o assunto. A lei brasileira nº. 9.609, de Fevereiro de 1998, traz a definição de um
programa de computador.
[...] Programa de computador é a expressão de um conjunto organizado de instruções em linguagem natural ou codificada, contida em suporte físico de qualquer natureza, de emprego necessário em máquinas automáticas de tratamento da informação, dispositivos, instrumentos ou equipamentos periféricos, baseados em técnica digital ou análoga, para fazê-los funcionar de modo e para fins determinados. [...] (BRASIL, 1998)
No texto da mesma lei, no capítulo cinco, que trata das infrações e penalidades, está
estipulada a pena de seis meses a dois anos de detenção, além de multa, para quem viola os
direitos autorais de um programa de computador.
As empresas de software instaladas no Brasil dispõem de recursos legais suficientes
para proteger a sua produção intelectual e a comercialização dos seus produtos. Entretanto,
observa-se que a fiscalização neste campo não é suficiente para garantir que os softwares
sejam majoritariamente legalizados, nas empresas, instituições e domicílios. Daí a
importância de se implementar algum mecanismo técnico que possa permitir ou bloquear o
uso dos aplicativos, de acordo com as regras definidas pelo seu produtor.
De acordo com Wikipedia (2004), a proteção contra cópia é uma medida de proteção
técnica desenvolvida para evitar a duplicação de material protegido por direito autoral. Ao
longo da história da comercialização do software, foram desenvolvidas algumas técnicas para
evitar a prática das cópias ilegais.
2.1 DESBLOQUEIO POR SENHA CONSULTADA EM MANUAL
No início da década de noventa a maioria dos jogos que foram lançados para o sistema
MS-DOS utilizava um mecanismo de proteção contra cópias relativamente simples. Para que
o jogo pudesse iniciar, era solicitado ao usuário que digitasse uma palavra que estava escrita
em uma determinada página e parágrafo do manual impresso que acompanhava o produto. O
jogo então verificava se a palavra digitada estava correta, para permitir ou negar o acesso.
Como o manual do usuário era o mesmo para todas as cópias vendidas do jogo, o
mecanismo poderia ser facilmente quebrado bastando uma fotocópia daquele manual.
20
Naquela época era possível observar cópias piratas dos jogos que vinham acompanhadas de
uma única folha impressa com todas as possibilidades de página e parágrafo que o jogo
poderia perguntar, seguidas da palavra de acesso que deveria ser digitada. Nem mesmo uma
cópia completa do manual era necessária para burlar o mecanismo.
Além de ineficiente no seu objetivo, que era impedir as cópias ilegais, o mecanismo
era visto como um problema para o usuário pagante, que precisava consultar o manual do
jogo todas as vezes que tinha vontade de jogar. Se o jogo fosse reiniciado três vezes naquele
período, o manual precisaria ser consultado três vezes. Outra situação que representava um
transtorno neste mecanismo de proteção era a perda do manual. Em muitos casos a solicitação
de uma segunda via junto ao fabricante era um processo demorado.
2.2 VERIFICAÇÃO DE NÚMEROS SERIAIS
Hoje em dia muitos aplicativos possuem mecanismos de proteção que são baseados em
uma chave de verificação única. Ou seja, possuem um determinado algoritmo matemático,
que fica embutido no código do aplicativo, capaz de gerar e verificar números seriais. No
momento da instalação (ou qualquer outro momento), o usuário é solicitado a digitar o
número serial que recebeu do fabricante, que é em seguida avaliado por esse algoritmo. Se a
verificação for bem sucedida, o aplicativo é liberado para o usuário.
Esse mecanismo possui algumas vantagens em relação ao de consulta de manual
descrito anteriormente:
a) não possibilita uma listagem completa dos números seriais que o algoritmo
reconhece como válido, a não ser que se tenha acesso ao próprio algoritmo;
b) o fabricante pode mudar o algoritmo matemático em diferentes versões do
aplicativo, evitando que números seriais que foram ilegalmente compartilhados
continuem a ser usados na versão seguinte;
c) é possível associar um número serial a um determinado registro de usuário,
permitindo algum tipo de rastreamento caso um número serial seja transferido para
uma cópia pirata.
Todavia, esse mecanismo de proteção não consegue impedir que o número serial de
um usuário autorizado seja usado por outro não-autorizado, em uma mesma versão do
21
aplicativo. Um único número serial pode ser usado por n pessoas, sem que o provedor do
software consiga impedir ou sequer tenha conhecimento dessa prática.
2.3 ATIVAÇÃO ONLINE
Existem alguns sistemas que adotam o mecanismo de números seriais descrito
anteriormente, com a diferença de uma etapa adicional: a validação online. Isto é, o aplicativo
precisa enviar para uma central de ativação na Internet o seu número serial, que é testado
quanto à sua validade.
A vantagem desse mecanismo é que o provedor do software consegue identificar
números seriais que não foram legitimamente expedidos, ou que foram indevidamente
compartilhados ou roubados, e construir uma lista negra com esses números. Dessa forma, o
produtor pode negar acesso aos números seriais que fazem parte dessa lista, sem que para isso
precise emitir uma nova versão do aplicativo, com um novo algoritmo de verificação.
A desvantagem dessa abordagem de proteção é que ocasionalmente usuários pagantes
do aplicativo podem ter sua instalação ou utilização negada, caso adquiram um produto com
número serial que tenha sido usado por um pirata e adicionado à lista negra. Um mecanismo
de proteção contra cópias que impede que um legítimo comprador faça uso do produto
adquirido deve ser visto com cautela.
2.4 PROTEÇÃO COM HARDWARE
Alguns sistemas adotam a proteção por hardware, que funciona através da verificação,
por parte do aplicativo, da presença de dispositivos que encaixam em uma porta de entrada do
computador (por exemplo, a porta serial, paralela ou USB), e são fornecidos pelo fabricante
no momento da compra do software. Esses dispositivos contêm as informações de ativação do
produto.
A proteção por hardware proporciona um bom grau de segurança, devido à dificuldade
de se duplicar o dispositivo, mas também representa um custo extra para quem vende o
produto. Portanto, não é muito usado por pequenos desenvolvedores, mas sim em grandes
soluções de software, que envolvem alto custo e tecnologia de ponta.
Outra desvantagem que pode ser observada é que, caso a ativação por hardware se
tornasse uma medida popular pelos diversos fabricantes de software, um usuário que tivesse
22
cinco ou seis aplicativos executando ao mesmo tempo no seu micro, protegidos por esse
mecanismo, teria problemas de ordem física no seu computador. Seria inviável ou até
impossível ter que encaixar tantas peças de hardware ao mesmo tempo para ativar os
programas.
2.5 PROTEÇÃO COM IDENTIFICAÇÃO DO HOST
Uma técnica usada por diversas soluções anti-pirataria é a identificação do hardware
que executa o aplicativo. O reconhecimento dos componentes físicos permite com que as
licenças possam ser expedidas para uma máquina específica, de forma que, caso a licença seja
transferida para outra máquina, não será reconhecida como válida.
Entretanto, não foi observado ainda um componente de hardware que seja totalmente
confiável para ser usado como identificação única da máquina. Quando foi lançado o
processador Pentium III, seu fabricante Intel disponibilizou um recurso chamado CPU serial
number, uma identificação única atribuída ao processador, que poderia ser acessada por uma
API do sistema operacional.
Com esse fato, surgiram discussões em torno da questão da privacidade, o que levou os
fabricantes de BIOS a colocarem uma opção que permitiu habilitar ou desabilitar esse recurso
nas placas-mãe. De acordo com a Intel (2002), somente os processadores Pentium III,
Pentium III Xeon e Mobile Pentium III possuem o recurso de identificação única. Nenhuma
outra versão do Pentium, inclusive as posteriores, recebeu essa característica.
Os componentes de hardware mais comumente usados para identificação são:
a) adaptador de rede, por possuir o endereço MAC, que deve ser único na rede;
b) número serial da partição ou volume, que é atribuído no momento da formatação;
c) identificação descritiva do processador, que inclui fabricante, modelo, revisão e
freqüência.
É possível obter descrições de diversos componentes de hardware. Nenhum deles,
sozinho, é capaz de identificar unicamente uma máquina. Porém, uma combinação de
elementos de identificação proporciona uma segurança relativamente boa na distinção de um
host.
23
É importante observar que o licenciamento amarrado ao hardware pode trazer
problemas caso a máquina tenha os componentes substituídos, por motivo de defeito ou
upgrade. Caso a técnica seja implementada, é interessante que também seja disponibilizado
um meio eficiente para renovação das licenças, visando situações em que o hardware precisar
ser trocado.
2.6 LICENCIAMENTO COM ASSINATURA DIGITAL
Dois fatores importantes em licenciamento de aplicativos são a autenticidade e a
integridade do arquivo de licença. A autenticidade diz respeito à origem da licença. No
contexto do licenciamento de software, uma licença autêntica é aquela construída pelo
fornecedor do software a ser licenciado.
A integridade está relacionada com as informações que a licença contém. É preciso
haver garantia de que as informações presentes em um arquivo de licença são realmente
aquelas inseridas pelo fornecedor do software e de que não houve modificação dessas
informações depois que a licença foi expedida.
Uma tecnologia capaz de satisfazer as necessidades de autenticidade e integridade no
licenciamento de softwares (assim como em outros campos) é a assinatura digital. Se o
fornecedor do software assinar digitalmente a licença que está expedindo, será possível ter a
certeza, no momento em que o aplicativo licenciado estiver processando aquela licença, de
que se trata de um arquivo que veio realmente do fornecedor do software, e de que ele não foi
modificado até aquele momento.
2.7 CONSIDERAÇÕES SOBRE LICENCIAMENTO DE SOFTWARE
Assim como outras discussões no território da segurança da informação, os
mecanismos para evitar a prática da pirataria de software fazem parte do popularmente
chamado “jogo de gato e rato”. As soluções surgem e logo em seguida grupos de crackers1
direcionam esforços para burlar o mecanismo. Ocorre um aperfeiçoamento das soluções para,
em algum tempo, serem quebradas novamente. E assim o ciclo segue.
1 Cracker é uma pessoa que explora brechas de segurança e inutiliza sistemas de proteção contra pirataria em programas de computador
24
É praticamente impossível elaborar um mecanismo para gerenciamento de licenças que
dê garantia total de proteção. O que se procura fazer é dificultar, dentro das limitações de
orçamento e tecnologia disponíveis, as cópias ocasionais do software.
Para o objetivo de redução da pirataria, além dos mecanismos de gerenciamento de
licença, outras medidas podem ser adotadas em paralelo, como a proteção contra cópia física
da mídia em que o produto é distribuído. Existem algumas técnicas para esta finalidade. Por
exemplo, para dificultar a cópia de um CD-ROM, pode ser adotada a gravação de dados em
sub-canais, ou ainda uma tecnologia comercial como o Macrovision SafeDisc
(MACROVISION, 2004).
Em todo caso, Seebach (2003) alerta para que se tenha cautela na implementação de
mecanismos de proteção. No seu artigo entitulado “The point is to be able to use the software
you purchase” (“o propósito é poder usar o software que você comprou”), ele cita que existem
produtos no mercado que foram tão bem protegidos, que trazem freqüentes problemas para os
seus usuários. No artigo ele defende a importância de se equilibrar proteção contra cópia e
qualidade na usabilidade.
25
3 CRIPTOGRAFIA E ASSINATURAS DIGITAIS
Neste capítulo serão abordadas as áreas de criptografia e assinaturas digitais, que
promovem a segurança do mecanismo proposto.
3.1 CRIPTOGRAFIA
Segundo RSA Laboratories (2000), a criptografia é a preocupação em tornar uma
comunicação privada. Encriptar significa transformar uma mensagem em dados que são
praticamente impossíveis de serem compreendidos sem um conhecimento específico (uma
chave de criptografia). Desencriptar é o processo inverso, ou seja, a transformação dos dados
encriptados de volta para uma forma compreensível.
Uma chave de criptografia é a informação secreta capaz de encriptar e desencriptar
informações. Existem duas categorias principais de sistemas de criptografia:
a) de chave secreta ou simétrica, onde a mesma chave é usada para encriptar e
desencriptar uma mensagem;
b) de chaves públicas ou assimétrica, onde uma chave é usada para encriptar uma
mensagem, e outra (relacionada à primeira), para desencriptá-la.
3.1.1 CRIPTOGRAFIA COM ALGORITMO DE RIJNDAEL
De acordo com SearchSecurity (2003), o algoritmo de Rijndael é um algoritmo recente
de criptografia simétrica, que foi escolhido pelo United States National Institute of Standards
and Technology (NIST), a partir de uma lista de mais de 15 submissões, como o algoritmo
padrão para criptografia avançada.
O algoritmo de Rijndael suporta chaves criptográficas de 128, 192 e 256 bits. Ele
recebe o texto original e, através de transformações utilizando a chave criptográfica, produz o
texto encriptado. Por ser um algoritmo de criptografia simétrica de duas vias, o texto
encriptado pode ser convertido de volta para o texto original, através de transformações
utilizando a mesma chave criptográfica.
No .NET Framework2 existe uma classe que fornece a implementação do algoritmo de
Rijndael, chamada System.Security.Cryptography.RijndaelManaged. Para usar esta
implementação, devem ser especificados o vetor de inicialização (atributo IV da classe), que é 2 Abordado em maiores detalhes no capítulo 4
26
uma string qualquer de exatos 16 bytes, e uma chave criptográfica (atributo Key da classe).
Estas informações podem ser geradas aleatoriamente através dos métodos GenerateIV e
GenerateKey. Para encriptar ou desencriptar uma mensagem deve-se criar um objeto de
criptografia através dos métodos CreateEncryptor ou CreateDecryptor. Estes objetos são
criados com base no vetor de inicialização e chave que foram gerados. Um objeto da classe
System.Security.Cryptography.CryptoStream é necessário para realizar a escrita ou leitura dos
dados encriptados. Esta escrita ou leitura é feita sempre através de um objeto do tipo
System.IO.MemoryStream. Um exemplo de como pode ser encriptada uma string no .NET
pode ser visto nos quadros 1 e 2.
Quadro 1 – Encriptando uma mensagem no .NET com Rijndael
27
Quadro 2 – Exemplo de string encriptada
3.1.2 ASSINATURAS DIGITAIS
No campo da criptografia, as assinaturas digitais são uma forma de autenticar
informação digital. São usadas quando existe a necessidade de se confiar na origem de uma
determinada informação e de se ter uma garantia de que esta não foi corrompida.
Segundo PGPI (1999), uma assinatura digital tem o mesmo propósito que uma
assinatura escrita à mão. Entretanto, a assinatura escrita à mão é fácil de ser falsificada. Uma
assinatura digital é superior a uma assinatura escrita à mão por ser praticamente impossível de
ser falsificada. Além disso, a assinatura digital atesta o conteúdo da informação, assim como a
identidade de quem a assinou.
3.1.3 CRIPTOGRAFIA DE CHAVES PÚBLICAS
A assinatura digital é um serviço possibilitado pela criptografia de chaves públicas (em
inglês é conhecida como public key cryptography), que tem como fundamento a criptografia
com o uso de um par de chaves, uma pública e outra privada. É também chamada de
criptografia assimétrica.
Um algoritmo muito popular para assinaturas digitais é o RSA, sigla que representa as
iniciais de seus criadores: Ronald L. Rivest, Adi Shamir e Leonard M. Adleman. O quadro 3
descreve o algoritmo RSA que é usado para a geração do par de chaves criptográficas.
28
Quadro 3 – Algoritmo RSA para geração do par de chaves criptográficas
No .NET Framework estas chaves podem ser geradas através da classe
System.Security.Cryptography.RSA, como demonstrado no quadro 4.
Quadro 4 – Geração de chaves RSA no .NET
As chaves são exportadas para o disco no formato XML, de acordo com os caminhos e
nomes especificados na classe auxiliar StreamWriter. Os quadros 5 e 6 mostram exemplos de
chaves privada e pública geradas pela classe RSA do .NET.
29
Quadro 5 – Exemplo de chave privada RSA
Quadro 6 – Exemplo de chave pública RSA
Hissam (2001) coloca que a relação matemática entre o par de chaves permite uma
regra geral: qualquer mensagem encriptada com uma das chaves do par pode ser
desencriptada com sucesso somente com a contraparte daquela chave. Encriptar uma
informação com a chave pública significa que somente a chave privada poderá desencriptá-la.
O contrário também é verdadeiro, encriptar uma informação com a chave privada significa
que somente a chave pública poderá desencriptá-la.
3.1.4 FUNÇÕES HASH
Uma função hash é uma função matemática que recebe um texto qualquer de entrada e
retorna uma string de tamanho fixo, que representa aquela entrada. As funções hash mais
conhecidas são a MD5 e SHA. Uma função hash também pode ser chamada de message
digest.
Esta função é considerada uma criptografia de via única, isto é, pode-se calcular o hash
de qualquer mensagem, mas deste resultado gerado, é impossível fazer o caminho inverso e
chegar à mensagem original.
<RSAKeyValue> <Modulus>3VwqPnGUgkSsAOZh5cmoq2UfrTSprOUqKYB/vuvWrcQKFM6xgts1u6fL/aiYkwXh6i9TK9C8JCy9XO5GADfFSRhUlukhL/4/D6406SGa4CvpS+u7l5aLEdvEIyXPgY3Xde+du4QAJ6CeZsK2wz9gEKHMyoDsPqtJeup/ZNDIRi0=</Modulus> <Exponent>AQAB</Exponent> <P>92JKw/bQup50o0je0p7iMSuDsl2u7r7mYfO1GcDDcfkFNJRMANl++mHOBPxRc6HXRec+jgsFfG8ZCnoB7xJWkQ==</P> <Q>5RHXE0gfsrmnZIwyLpoYNMHLIA8kaVR7ShlZWrTuklB1yT3oqTY6mUKUUpOx28YaPuFBn6GoA6l+zwXteU5b3Q==</Q> <DP>MY7uXW2viQM/aIqroNQVijYmbvAXoFp7+rmA2UTloop5gXwH8c+ggXZgeF030Atm/ekCfiA1HCWBhbjFdGhfEQ==</DP> <DQ>C3JvyAPjqZ/DcK/c1h1XNlO03d5D2IujOZm4sGK4RVGGAU95r/MIzJ3aIaJF0hC9QQUqrVp7tesjbh8CtfwndQ==</DQ> <InverseQ>rrturwpw6OPd1W1Jshh/5Qf1SPioS0+dPwYFe7zc+Ref8sBqJPU8fRFQuv85A5ewg/gP3mYSmajkbUkq80AWZA==</InverseQ> <D>y8lDosURwXPTHej6i3/BZjjslpp68o7u59JCyNN5ifOGjG1VAnEo4J+zrsx92ix6NQxod1ftPShrFJjPnPe7CL9Y/q3+KiMOW5T5e5EkT1KbkACygPw5V9w1ojk7w1KRgUsE4hrVu5r6uQKkY+NZ+9rMzlghl1W55fEKHV6GrIE=</D> </RSAKeyValue>
<RSAKeyValue> <Modulus>3VwqPnGUgkSsAOZh5cmoq2UfrTSprOUqKYB/vuvWrcQKFM6xgts1u6fL/aiYkwXh6i9TK9C8JCy9XO5GADfFSRhUlukhL/4/D6406SGa4CvpS+u7l5aLEdvEIyXPgY3Xde+du4QAJ6CeZsK2wz9gEKHMyoDsPqtJeup/ZNDIRi0=</Modulus> <Exponent>AQAB</Exponent> </RSAKeyValue>
30
As funções hash são frequentemente utilizadas no processo de assinatura digital. A
utilidade de uma função hash na assinatura digital está relacionada com a performance. A
função hash permite que apenas um pequeno trecho (o resultado do hash), que representa de
forma fiel o documento inteiro, seja encriptado e enviado ao destinatário que verificará a
assinatura. Sem utilizar uma função hash, a mensagem original inteira precisaria ser
encriptada e transferida, junto com a mensagem original, para o seu destinatário.
3.1.5 VISÃO GERAL DO PROCESSO DE ASSINATURA DIGITAL
A figura 1 ilustra as etapas que ocorrem no processo de assinatura digital, envio e
verificação de um documento.
Figura 1 – Visão geral do processo de assinatura digital
Nas etapas iniciais ocorre o cálculo do hash da mensagem original e a sua encriptação
com a chave privada do remetente. A mensagem original e o hash encriptado são então
enviados ao destinatário.
Nesse momento, o destinatário desencripta o hash com a chave pública do remetente.
Depois, um novo cálculo de hash da mensagem enviada é realizado. Esse hash calculado é
comparado ao hash que foi recebido do remetente (e desencriptado com a sua chave pública),
para verificar a validade da assinatura.
31
Caso a mensagem tenha sido enviada por outra origem (o hash enviado foi encriptado
com outra chave privada), ao desencriptar o hash com a chave pública do verdadeiro
remetente, o destinatário teria um valor de hash incompatível com o conteúdo da mensagem
recebida, o que o levaria a concluir que a assinatura não é válida.
Caso a mensagem tenha sido enviada pelo remetente autêntico, mas tido o seu
conteúdo modificado no meio do caminho, a comparação do hash recebido com um novo
hash calculado iria falhar, o que também levaria à conclusão de que a assinatura não é válida.
Dessa forma, na assinatura digital tem-se ao mesmo tempo uma garantia de origem e
de integridade dos dados da mensagem.
3.2 ASSINATURAS DIGITAIS XML
Com o crescimento da adoção do XML3 pelas diversas entidades presentes na Internet,
surgiu a necessidade de se ter autenticidade e confiabilidade no intercâmbio dos documentos
que trafegam nesse formato.
As tecnologias de segurança mais comuns nos sistemas atuais não são suficientes para
proteger determinadas operações de negócios que são realizadas na rede. Simon et al (2001)
lembra o exemplo do protocolo SSL, que fornece segurança no transporte de um documento
entre um navegador de Internet e um servidor web. O protocolo oferece um túnel seguro por
onde a informação trafega. Todavia, nenhum nível de proteção é oferecido no momento em
que o documento chega ao host de destino. A partir deste ponto, o documento fica vulnerável
a modificações. A segurança, neste caso, existe apenas durante o transporte.
Uma solução encontrada para esse tipo de problema consiste no uso de assinaturas
digitais, que são capazes de associar um conjunto de dados a uma chave. Eastlake e Niles
(2003, cap. 10.1) citam o motivo de alguns padrões de assinaturas consolidados não
conseguirem se ajustar bem ao universo do XML. Segundo eles, tecnologias como o PKCS #7
e PGP possuem um formato binário, com sintaxe própria. Caso seja necessário anexar uma
assinatura desse tipo em um documento XML, é preciso converter o formato binário em
caracteres imprimíveis, por meio de uma técnica como base-64 ou outra.
3 Abordado em maiores detalhes no capítulo 4
32
Segundo Dournaee (2002, p. 109), tem-se outra limitação nos mecanismos de
assinatura digital externos ao XML: a aplicação que deseja assinar um documento precisa
enviar, para aquela que irá receber e verificar a assinatura, informações adicionais a respeito
da assinatura digital, como por exemplo, o algoritmo que foi usado.
Para sistemas que trabalham com XML, é importante que a assinatura digital esteja em
conformidade com a sintaxe XML. Somente desta forma será possível usar ferramentas para
manipular partes dessa assinatura, referenciar outras estruturas XML com o objetivo de
assinar fragmentos de outros documentos, localizar e fazer verificações no elemento da
assinatura e fazer uso de ferramentas para exibi-la.
Para satisfazer a demanda por assinatura digital em documentos XML, foi
desenvolvido um padrão próprio que está descrito no documento de recomendação formal
XML-Signature Syntax and Processing Recomendation, de Fevereiro de 2002 (WORLD
WIDE WEB CONSORTIUM, 2002). A principal característica da assinatura digital XML é
que o objeto da assinatura possui a sintaxe XML e está em total harmonia com esta
tecnologia.
3.2.1 TIPOS DE ASSINATURA DIGITAL XML
Observam-se três possibilidades para a localização dos dados que estão recebendo a
assinatura digital XML:
a) enveloping signature: os dados estão dentro do elemento de assinatura digital;
b) enveloped signature: os dados englobam o elemento de assinatura digital;
c) detached signature: os dados estão desconectados do elemento de assinatura
digital. Podem estar no mesmo documento físico ou em qualquer outro local.
A figura 2 ilustra as três possibilidades de posicionamento da assinatura digital XML.
33
Figura 2 – Tipos de assinatura XML quanto à localização dos dados
3.2.2 SINTAXE DA ASSINATURA DIGITAL XML
O esqueleto de uma assinatura digital XML está descrito no quadro 7.
Quadro 7 – Sintaxe da assinatura digital XML
3.2.2.1 Elemento <Signature>
Engloba todo o conjunto de informações a respeito da assinatura digital. Contém os
seguintes elementos:
a) <SignedInfo>: o elemento mais complexo da assinatura. Contém uma referência a
cada objeto de dados que está sendo assinado e abrange todas as informações
necessárias à assinatura;
<Signature> <SignedInfo> <CanonicalizationMethod> <SignatureMethod> (<Reference (URI=)?> (<Transforms>)? <DigestMethod> <DigestValue> </Reference>)+ </SignedInfo> <SignatureValue> (<KeyInfo>)? (<Object>)* </Signature> * zero ou mais ocorrências + uma ou mais ocorrências ? zero ou uma ocorrência
34
b) <SignatureValue>: o valor binário da assinatura, calculado sobre o elemento
<SignedInfo> usando o <SignatureMethod> especificado e a chave fornecida. Esse
valor é convertido em texto através de base-64;
c) <KeyInfo>: opcional. Contém informações sobre a chave a ser usada para validar a
assinatura, que pode ser o conteúdo direto da chave ou um certificado X.509. Pode
ainda conter informações indiretas de obtenção da chave, como o local onde a
chave está armazenada. O elemento é opcional porque as informações sobre a
chave podem vir de forma separada do elemento de assinatura digital XML;
d) <Object>: opcional. Um elemento que pode conter informações arbitrárias
referentes aos dados que foram assinados. Por exemplo, se um tipo binário foi
assinado o elemento <Object> poderia conter o seu MimeType, que descreve a
natureza do conteúdo binário (imagem, página HTML, etc.). O elemento <Object>
fica à disposição do desenvolvedor da aplicação para qualquer tipo de informação
que deseje incluir dentro do elemento da assinatura digital XML. Este elemento
também pode conter os dados que devem ser assinados, quando é usado o tipo de
assinatura enveloping signature.
3.2.2.2 Elemento <SignedInfo>
O elemento <SignedInfo> contém uma seqüência dos seguintes elementos:
a) <CanonicalizationMethod>: contém um identificador para o método usado na
canonicalização. Diz respeito a como será feita a conversão do elemento
<SignedInfo> em uma seqüência de bits, para que a assinatura seja realizada neste
resultado binário. A canonicalização quer dizer obter um significado único (forma
canônica) para um conjunto de dados que pode ter vários tipos de representações;
b) <SignatureMethod>: contém um identificador do algoritmo que é aplicado, com a
respectiva chave de assinatura, ao elemento <SignedInfo> canonicalizado,
produzindo como resultado o elemento <SignatureValue>;
c) <Reference>: este elemento indica os dados a serem assinados. Os dados podem
ser de qualquer tipo (XML, HTML, GIF, etc.). Pelo menos uma ocorrência do
elemento <Reference> deve existir, sendo que ele pode se repetir por diversas vezes
no elemento <SignedInfo>.
35
3.2.2.3 Elemento <Reference>
Para cada elemento <Reference> presente em <SignedInfo> tem-se as seguintes
informações:
a) atributo URI (uniform resource identifier): opcional. Se presente traz uma
referência aos dados que devem ser assinados. Pode não existir porque os dados a
serem assinados podem ser determinados no contexto da aplicação;
b) <Transforms>: opcional. Provê um mecanismo para realizar um processamento dos
dados a serem assinados antes de ser calculado o seu digest. Por exemplo, pode-se
querer extrair um subconjunto dos dados, caso esse subconjunto seja a única parte
que se deseja assinar;
c) <DigestMethod>: identifica o algoritmo para calcular o digest dos dados;
d) <DigestValue>: contém o resultado do cálculo realizado pelo algoritmo
especificado no elemento <DigestMethod>, codificado em base-64.
3.2.3 ASSINATURA XML NO .NET FRAMEWORK
O .NET Framework contém um conjunto de classes para criação e verificação de
assinaturas digitais XML, conforme o padrão recomendado pelo W3C. Essas classes
pertencem ao namespace System.Security.Cryptography.Xml.
Para exemplificar a utilização de assinaturas digitais XML no .NET, suponha-se o
seguinte exemplo: uma empresa que vende livros na Internet deseja enviar um documento
XML que contém o registro de um determinado pedido para outra empresa. Esse documento
XML precisa ser assinado digitalmente, por razões de segurança. O documento deste
hipotético pedido pode ser visto no quadro 8.
36
Quadro 8 – Exemplo do documento que será assinado (pedido.xml)
O quadro 9 ilustra o procedimento da assinatura. O primeiro passo é carregar o
documento em um objeto da classe XmlDocument e criar um objeto do tipo SignedXml para
ele (parte A). Depois, deve-se definir a chave que assinará o documento. A chave pode ser
lida de um arquivo XML no disco (parte B). A etapa seguinte consiste na criação de uma
referência aos dados que serão assinados (parte C).
Uma referência com o atributo URI vazio significa uma referência ao documento
inteiro. Como essa será uma assinatura do tipo enveloped signature, validar o documento
inteiro resultará numa assinatura inválida, porque o valor do próprio node de assinatura será
equivocadamente incluído no documento. Portanto, deve-se adicionar um Transform para
fazer com que apenas o conjunto de dados do pedido da livraria virtual seja processado no
cálculo da assinatura, deixando de fora a própria assinatura. O Transform adicionado, nesse
caso, é o XmlDsigEnvelopedSignatureTransform, para assinaturas do tipo enveloped
signature.
O cálculo da assinatura pode ser realizado, através do método ComputeSignature. A
assinatura é calculada e adicionada ao documento original. Depois, o arquivo é gravado no
disco com o nome de pedido_assinado.xml (parte D).
37
Quadro 9 – Assinatura de um documento XML no .NET
O resultado final do processo, que é o documento assinado, pode ser visto no quadro
10.
Quadro 10 – Documento pedido.xml assinado digitalmente
38
3.2.4 VERIFICAÇÃO DE ASSINATURA XML NO .NET FRAMEWORK
Para verificar uma assinatura digital XML no .NET é necessário fazer o carregamento
do documento assinado em um objeto do tipo XmlDocument. Depois, é preciso carregar o
elemento <Signature> em um objeto do tipo SignedXml e obter a chave pública que irá
verificar o documento. Por último, o método CheckSignature da classe SignedXml é o
responsável por fazer a verificação da assinatura digital. O quadro 11 exemplifica o
procedimento.
Quadro 11 – Verificação de assinatura digital XML no .NET
39
4 TECNOLOGIAS UTILIZADAS
Neste capítulo serão abordadas as ferramentas e técnicas que estão envolvidas na
construção do mecanismo proposto.
4.1 MICROSOFT .NET FRAMEWORK
Um framework pode ser compreendido como um conjunto de classes que se inter-
relacionam por meio de heranças e especializações e tem como finalidade permitir um design
de reutilização na construção de um software. Os desenvolvedores fazem uso das classes de
um framework para criar as partes de um sistema.
O .NET Framework disponibiliza uma nova interface de programação para os serviços
de API do Windows e integra um número de tecnologias que surgiram no final da década de
noventa (LAM; THAI, 2003, cap. 1).
Em julho de 2000 foi anunciado pela Microsoft o lançamento das primeiras
ferramentas de desenvolvimento para o .NET Framework. Nos últimos quatro anos foi
possível observar a adoção desta tecnologia por diversas empresas que trabalham com
desenvolvimento de sistemas.
O .NET Framework está sendo alvo de intenso investimento por parte do seu
fabricante. A próxima versão do Windows, que hoje tem o codinome de Longhorn, terá
grande parte da sua API em código gerenciado do .NET Framework. De acordo com Otey
(2004), isso acontecerá por meio do WinFX, a API do Longhorn que essencialmente
substituirá a Win32 API4.
Um dos maiores objetivos no desenvolvimento do .NET Framework foi integrar os
sistemas existentes ao ambiente da Internet. Por esse motivo, a plataforma oferece bons
recursos para criação de aplicações na Internet e web services.
4.2 CLR
O principal componente do .NET Framework é o Common Language Runtime (CLR).
O CLR gerencia e executa o código que foi escrito em uma linguagem .NET. O CLR está para
a plataforma .NET assim como a Java Virtual Machine (JVM) está para a plataforma Java.
4 Conjunto de funções do sistema operacional Windows utilizado nos últimos dez anos.
40
Segundo Richter (2002, cap. 1), a Microsoft está dando suporte a diversas linguagens
que tem como alvo o código intermediário (IL) do CLR: C++, C#, Visual Basic e J#. Ainda
segundo o mesmo autor, outras empresas estão disponibilizando compiladores para o CLR,
nas mais diversas linguagens: Alice, APL, COBOL, Component Pascal, Eiffel, Fortran,
Haskell, Mercury, ML, Mondrian, Oberon, Perl, Python, RPG, Scheme e Smalltalk.
No .NET Framework, independente da linguagem e do compilador utilizado, o
resultado é sempre o mesmo: um módulo gerenciado, também conhecido como assembly
.NET. Este módulo é composto por:
a) um portable executable (PE): padrão para os arquivos executáveis no ambiente
Windows desde a versão NT;
b) CLR header: cabeçalho que contém informações sobre o módulo gerenciado;
c) Metadata: tabelas que descrevem tipos e dados definidos ou referenciados pelo
código fonte;
d) intermediate language (IL): o código intermediário que é produzido por um
compilador da plataforma Microsoft .NET.
A figura 3 traz uma ilustração de como programas escritos em diferentes linguagens
resultam em uma mesma categoria de módulo gerenciado na plataforma .NET.
Figura 3 – Compilação em diferentes linguagens no Microsoft .NET
41
A plataforma .NET, além de ser disponibilizada pela Microsoft, também está sendo
implementada em um projeto de código aberto. O projeto chama-se Mono (MONO
PROJECT, 2004), e permite que aplicativos .NET sejam executados em sistemas operacionais
Linux e Unix.
4.3 LINGUAGEM C#
O C# (pronunciado como Csharp) é uma linguagem de programação orientada a
objetos desenvolvida pela Microsoft. A linguagem C# é bastante similar à linguagem Java, e
surgiu com o advento da plataforma Microsoft .NET.
A linguagem C# é uma especificação aberta, certificada pelo ECMA (MSDN, 2004a),
que pode ser consultada livremente através da Internet. Ela possui uma sintaxe baseada na
linguagem C, e foi desenvolvida com o objetivo de combinar as possibilidades de
programação da linguagem C++ com a simplicidade da linguagem Visual Basic.
4.4 TECNOLOGIA ASP.NET
Um dos componentes mais importantes do .NET Framework é a tecnologia ASP.NET,
evolução do ASP, para desenvolvimento de aplicações para Internet. O ASP.NET permite a
construção de páginas dinâmicas e suporta todas as linguagens que compilam para a IL do
.NET Framework.
Uma aplicação ASP.NET executa sobre o servidor web IIS. O ASP.NET dá suporte ao
modelo de desenvolvimento chamado code behind, onde existe separação entre a interface
visual (apresentação) e a implementação (regras de negócio) de uma página da aplicação.
Um arquivo de code behind, também conhecido como uma “classe code behind”, é um
arquivo contendo código .NET gerenciado (como VB.NET ou C#) que define uma classe
herdada por uma página ASP.NET, web service ou arquivo de aplicação (DUTHIE;
MACDONNALD, 2003, cap. 2.3.6).
O quadro 12 mostra um exemplo de código ASP.NET para apresentação de
informações.
42
Quadro 12 – Página de apresentação ASP.NET (exemplo.aspx)
A primeira linha do documento indica a linguagem que será utilizada no arquivo de
code behind. A diretiva Inherits diz o nome da classe code behind que fornece o código para
as regras de negócio e processamento da página.
Cada controle ASP.NET, como <asp:textbox> e <asp:button> é processado no
servidor web no momento da requisição da página. O servidor web verifica qual o navegador
que fez a solicitação e monta dinamicamente a página com o código HTML compatível com
aquele navegador. Cada controle ASP.NET é mapeado para um componente HTML. Por
exemplo, o <asp:textbox> é convertido em um <input type=”text”>.
No quadro 13 pode-se observar o arquivo de code behind para o código de
apresentação exposto no quadro 12.
Quadro 13 – Página de código ASP.NET (exemplo.aspx.cs)
43
No exemplo ilustrado, o processamento da informação ocorrido quando o usuário clica
no botão do formulário HTML acontece no módulo compilado do arquivo de code behind.
Dessa forma, pode-se dizer que o ASP.NET não é apenas uma linguagem de
interpretação e processamento de scripts, mas uma plataforma que executa aplicações que são
compiladas da mesma forma que aplicações que executam fora de um navegador de Internet.
4.5 XML
A tecnologia XML é uma especificação aberta para marcação de documentos, derivada
do padrão SGML5, que foi estabelecida pelo W3C em 1996. O XML define uma sintaxe
genérica para a inserção de caracteres e símbolos em um conjunto de dados, de forma a dar
significado à informação.
Ray (2003), no prefácio de seu livro, escreve um bom exemplo da importância de uma
tecnologia de marcação. Ele conta que um grupo de cientistas solicitou à NASA algumas
informações sobre o solo de Marte, de um conjunto de dados que vieram de uma sonda
enviada ao planeta em 1976. Ao longo dos anos, essa sonda coletou diversos tipos de
informações, incluindo as amostras do solo, e as enviou para a Terra.
[...] A princípio seria uma tarefa simples recuperar os dados do microfilme e publicá-los em CD-ROM [para disponibilizá-los aos cientistas]. Não havia nenhuma dificuldade em relação a isso. Entretanto, era necessário separar os dados relevantes sobre o solo marciano dos outros dados coletados pela sonda. Nesse momento surgiu o problema. Como eles iriam extrair o fragmento específico de informação, referente às leituras do solo, do enorme conjunto de dados, que foram coletados? Todas as medições enviadas pela sonda foram armazenadas diretamente, numa única cadeia de dados seqüenciais. Procurar nesse grande conjunto de dados seria uma tarefa custosa e demorada. Percebeu-se que apesar de toda a informação necessária estar presente, ela acabou se tornando inútil, devido ao árduo trabalho para decifrá-la. [...] (RAY, 2003, prefácio)
A tecnologia XML propõe-se a solucionar esse tipo de problema, permitindo com que
a informação seja marcada e devidamente identificada. Também possui recursos para a
especificação de modelos de documentos de qualquer natureza.
Entre os objetivos principais do XML está a capacidade de enviar, receber e processar
informações na Internet de forma padronizada. É atualmente bastante utilizado em aplicativos
de comércio eletrônico, transações online, compartilhamento de informação entre sistemas
que rodam em plataformas heterogêneas, criação de novas linguagens de representação, web 5 International Organization for Standardization (ISO) 8879
44
services, entre outros. Em qualquer situação onde ocorra a necessidade de armazenar,
interpretar e/ou transferir informações, o XML pode vir a ser útil.
4.5.1 FORMAÇÃO CORRETA DO DOCUMENTO
Um documento XML considerado corretamente formado é um documento que
obedece às regras da especificação XML. Segundo Harold (2004), existem mais de cem
diferentes regras que devem ser respeitadas na composição de um documento XML.
Por exemplo, uma das regras diz que o nome do elemento deve ser escrito
imediatamente depois do caractere ‘<’ na tag de início do elemento. Considerando essa
diretriz, o elemento <descrição> seria válido, enquanto o elemento < descrição> não seria.
Outra regra diz que para toda tag de início deve existir uma tag de fim do elemento. Se um
elemento foi aberto com <data> deve obrigatoriamente ser fechado com </data>.
Apesar de a linguagem XML permitir a criação de tantos diferentes elementos e
atributos quantos forem necessários, esses elementos e atributos, bem como o conteúdo e o
documento que os contém, devem todos obedecer a determinadas regras para que sejam
considerados corretamente formados. Se um documento XML não está corretamente formado,
qualquer tentativa de lê-lo ou processá-lo irá falhar (HAROLD, 2004).
No HTML, que é uma especificação também derivada do SGML, observa-se que os
navegadores e interpretadores tentam corrigir ou ignorar um erro de formação no documento,
quando este ocorre. Por exemplo, se uma tag <p> foi aberta em uma página HTML, e depois
outra tag <p> foi aberta sem que a primeira tivesse sido fechada com </p>, o navegador não
irá se recusar a apresentar a página, mas ajustará a página e a exibirá da melhor forma que
conseguir. Esse tipo de abordagem traz inconsistências entre navegadores, que podem assumir
comportamentos diferentes diante de uma mesma característica de má formação de um
documento HTML.
A especificação XML, ao contrário, não permite que um parser corrija um erro de
formação em um documento, nem tente compreender o documento ignorando o erro. Ao
encontrar um erro de formação, o parser deverá reportá-lo imediatamente e considerar o
45
documento inválido. As regras de formação de um documento XML podem ser encontradas
na especificação6 da tecnologia.
4.5.2 CRIAÇÃO DE UM DOCUMENTO XML NO .NET FRAMEWORK
As classes para manipulação de XML no .NET Framework estão contidas no
namespace System.Xml. Uma das maneiras de se criar um documento XML é através da
classe XmlTextWriter. Um exemplo pode ser visto no quadro 14.
Quadro 14 – Criação de um documento XML através da classe XmlTextWriter
Os objetos do tipo StringBuilder e StringWriter servem para armazenar o conteúdo do
documento XML em uma cadeia de caracteres do tipo string, que poderá ser impressa na tela.
O XmlTextWriter também poderia receber como argumento, no seu construtor, um caminho e
nome de arquivo no disco, para que o conteúdo fosse armazenado de forma permanente.
A propriedade Formatting do objeto de tipo XmlTextWriter permite que seja
configurada a identação do documento, isto é, que o seu conteúdo seja armazenado com um
espaçamento lógico entre os elementos e a margem esquerda da página.
6 http://www.w3.org/TR/2000/REC-xml-20001006
46
O método WriteStartDocument inclui a declaração XML na primeira linha do
documento. O método WriteStartElement inclui uma tag de início de elemento. O método
WriteEndElement faz o fechamento da tag que foi aberta. O método WriteElementString
escreve um elemento completo no documento, que contém uma string em seu conteúdo. Esse
método já adiciona ambas as tags de abertura e fechamento do elemento. O método
WriteAttributeString adiciona um atributo a um elemento XML com seu respectivo valor. O
método Close encerra a criação do documento.
O código exposto anteriormente produz um documento XML que está representado no
quadro 15.
Quadro 15 – Documento XML criado com a classe XmlTextWriter
4.5.3 ACESSANDO O CONTEÚDO DE UM DOCUMENTO XML
Existem classes no .NET Framework que possibilitam a leitura de um documento
XML sequencialmente, do início ao fim, passando por todos os seus nós. Um exemplo é a
classe XmlReader.
No mecanismo construído nesse trabalho, o acesso à informação em documentos XML
foi feito de forma direta, selecionando nós específicos do documento através de expressões
XPath7. O quadro 16 exemplifica como acessar o elemento titulo do documento criado
anteriormente.
Quadro 16 – Acessando informação em um documento XML
7 XPath é uma linguagem que descreve uma maneira de localizar itens em um documento XML utilizando uma sintaxe de endereçamento baseada no caminho da estrutura lógica e hierárquica do documento.
47
No exemplo, um objeto do tipo XmlDocument é construído. Em seguida, através do
método LoadXml, é obtido o conteúdo completo de uma string que contém os dados XML (no
caso, informações sobre um livro). Uma outra string é instanciada para armazenar o título do
livro. Através do método SelectSingleNode e uma expressão XPath o elemento /livro/titulo é
selecionado. A string titulo recebe então o texto que está contido nesse elemento, e depois é
impressa na saída padrão.
4.6 SCHEMAS
O XML permite a criação de formatos próprios para armazenar e compartilhar
informações. Por exemplo, com o XML é possível representar uma partitura musical, um
mapa geográfico ou um contrato comercial. Com essa flexibilidade, surgem problemas: como
estabelecer uma declaração formal da estrutura desses documentos XML? Quais são as regras
de formação que um determinado documento possui? O que o documento deve ou não deve
conter? Os desenvolvedores precisam ter esse conhecimento para que as aplicações possam
ser construídas.
A linguagem de schema XML é uma formalização das restrições, expressadas como
regras ou modelo de estrutura, que se aplica a uma classe de documentos XML. Em muitos
casos, schemas servem como uma ferramenta de desenho, estabelecendo uma moldura sobre
onde as implementações podem ser construídas. (VLIST, 2002, cap. 1.1)
Segundo Gulbransen (2001), a melhor maneira de compreender um schema XML é
observá-lo como uma gramática. Da mesma forma que a gramática de uma língua define
regras de concordância, nomes e verbos, o schema XML representa esse conjunto de regras e
restrições para um documento XML.
O uso mais comum de schemas XML é para a validação de documentos. Quando um
documento XML é recebido por um sistema, antes de importar ou processar os dados contidos
no documento, é importante que ele seja verificado contra o seu schema, para ter certeza de
que ele obedece ao padrão esperado.
O schema XML é bastante útil no que diz respeito à interoperabilidade entre diferentes
sistemas. Quando dois sistemas distintos precisam trocar informações, eles necessitam de uma
língua e formato comuns, para que o intercâmbio possa ocorrer. Nesse caso, é possível definir
um schema XML para as informações a serem trocadas, que funcionará como um contrato
48
estabelecido entre as partes. Dessa forma, tem-se uma formalização da estrutura que essas
informações devem conter.
O próprio formato XML é usado para descrever um schema XML. Um exemplo de
schema, que formaliza a estrutura de um hipotético tipo “carta”, pode ser visto no quadro 17.
Quadro 17 – Exemplo de schema XML
Para fazer a validação de um documento XML contra o seu schema utilizando as
classes do .NET Framework, pode ser usada a classe XmlValidatingReader, como está
exemplificado no quadro 18.
49
Quadro 18 – Validação de documento XML contra o seu schema
No exemplo existem dois métodos principais, o ManipuladorErros e o
ValidaDocumentoXML. O segundo método deve receber como parâmetros o documento XML
a ser avaliado e o schema que será usado, ambos em formato string. Os objetos do tipo
StringReader e XmlTextReader são usados para a leitura seqüencial do documento XML.
O objeto do tipo XmlValidatingReader é o responsável principal por analisar o
documento XML. Sua propriedade ValidationType é definida para a validação com schema. O
objeto possui um manipulador de evento chamado ValidationEventHandler, que irá disparar
um método quando o analisador encontrar um erro no documento XML. No exemplo, o
método ManipuladorErros é adicionado a esse manipulador de eventos.
É iniciada a análise do documento XML com chamadas sucessivas do método Read do
objeto instanciado de XmlValidatingReader. A cada chamada do método Read é lido o
50
próximo nó do documento XML. Caso um erro seja encontrado, o método ManipuladorErros
é executado. No código demonstrado, caso o erro seja do tipo warning, a análise do
documento continua. Caso contrário, uma exceção é lançada.
4.7 WEB SERVICES
Web services podem ser descritos como qualquer funcionalidade que é acessível a
partir da Internet, geralmente (mas não necessariamente) usando uma ou mais mensagens
XML no protocolo de comunicação (SCRIBNER; STIVER, 2001, cap. 1).
O web service usa na Internet os conceitos de desenvolvimento baseado em
componentes. Da mesma forma que componentes, os web services são funcionalidades
empacotadas (“caixa preta”), publicadas em um servidor web, que podem ser utilizadas (ou
“consumidas”, no jargão da tecnologia) sem a preocupação de como foi feita a sua
implementação.
Diferentemente do modelo de componentes, os web services não são acessados através
de protocolos específicos como DCOM ou RMI, mas sim através do protocolo HTTP, o
mesmo utilizado pelos navegadores de Internet. Para o formato dos dados, é freqüente o uso
do XML. Para a troca de mensagens, é prática comum a utilização de envelopes do protocolo
SOAP.
Pode-se observar o uso de web services em diferentes tipos de aplicações, como por
exemplo:
a) em provedores de dados, que disponibilizam informações como índices da bolsa de
valores ou a previsão meteorológica de um determinado local;
b) em integrações entre negócios (business-to-business), como em um hotel que
disponibiliza uma interface do módulo de reservas do seu sistema para as
companhias de turismo;
c) na integração entre sistemas de plataformas heterogêneas.
4.7.1 CONCEITOS BÁSICOS DE FUNCIONAMENTO
A visão geral do funcionamento de um web service é a de que existe um serviço a ser
publicado, um servidor que publica o serviço e um interessado em usá-lo. A figura 4 ilustra o
processo.
51
Figura 4 – Visão geral de funcionamento de um web service
O provedor do serviço é o responsável por hospedar a funcionalidade a ser publicada
na rede. Ele também faz a publicação do serviço e da semântica da sua interface em um
servidor de registros, para que o serviço possa ser localizado. Em algum momento, um
interessado em usar o serviço fará a sua busca no servidor de registros. Depois de localizado,
o requerente irá amarrar o serviço, através do provedor onde o serviço está hospedado, e fazer
uso das suas funcionalidades. Esse processo é conhecido pela terminologia publish, find and
bind (publicar, encontrar e amarrar).
4.7.2 UNIVERSAL DESCRIPTION, DISCOVERY AND INTEGRATION (UDDI)
O UDDI é um diretório baseado na Internet que permite com que interessados
publiquem o registro de seus web services e também possam encontrar os serviços que estão
procurando. Pode-se fazer uma analogia com o catálogo de páginas amarelas, que lista os
serviços comerciais que existem em uma cidade.
4.7.3 WEB SERVICES DESCRIPTION LANGUAGE (WSDL)
De acordo com Srinivas (2001), o WSDL é uma linguagem para descrever as
capacidades de um web service. O WSDL é parte integrante do UDDI. Ele especifica onde o
serviço está hospedado, as operações (ou métodos) que o serviço expõe, e os seus tipos de
dados. É através de um documento WSDL que um web service será localizado e amarrado à
aplicação que deseja consumi-lo.
52
4.7.4 SIMPLE OBJECT ACCESS PROTOCOL (SOAP)
De acordo com Scribner e Stiver (2001, cap. 1), para resumir o protocolo SOAP em
uma única palavra, “empacotamento” seria a descrição mais adequada. Muitos
desenvolvedores criaram abordagens proprietárias para a troca de mensagens XML entre
sistemas. O SOAP basicamente define uma maneira padrão (mas possivelmente extensível) de
empacotar informação em XML, de forma que ambos os lados da conexão possam entender
como abrir esse pacote.
A chamada de um método publicado em um web service e a resposta recebida são
encapsuladas em um envelope SOAP. O modelo de objeto SOAP é composto por três partes:
a) SOAP Envelope: forma o elemento raiz do documento e encapsula os dois
próximos elementos;
b) SOAP Header: é uma parte opcional do modelo de objeto SOAP que carrega
informações necessárias que não estão presentes na assinatura do método, como por
exemplo, informação sobre a chave pública de criptografia, informação de sessão e
informação de autenticação;
c) SOAP Body: o elemento mais importante, que carrega o método e seus parâmetros,
armazenados como XML.
Um exemplo de envelope SOAP em uma requisição pode ser visto no quadro 19.
Quadro 19 – Exemplo de envelope SOAP para uma requisição
O envelope mostra como deve ser feito o empacotamento da chamada ao método
verificarSituacao publicado em um web service. O método recebe um argumento, de nome id
e tipo string. Ao ser acionado, o método processa a chamada e responde, com sua resposta
empacotada em outro envelope SOAP, como ilustra o quadro 20.
53
Quadro 20 – Exemplo de envelope SOAP para uma resposta
4.7.5 CRIAÇÃO DE UM WEB SERVICE NO .NET
Um web service no .NET possui a extensão .asmx. Para criar o web service, basta criar
uma classe que herda da classe System.Web.Services.WebService. O quadro 21 exemplifica
como um web service que fornece a hora atual pode ser criado no .NET.
Quadro 21 – Exemplo de web service (ServicoDeHora.asmx)
O atributo [WebMethod] antes de um método identifica que ele será exposto
publicamente, e poderá ser consumido por clientes do web service.
Além de criar o arquivo principal (ServicoDeHora.asmx), é necessário criar um
arquivo chamado web.config com um mínimo de informações de configuração da página (web
service) que será publicada. O conteúdo do web.config deve ser algo semelhante ao descrito
no quadro 22.
54
Quadro 22 – Arquivo web.config para o web service
Depois de criados, os arquivos devem ser publicados no servidor web IIS da Microsoft.
4.7.6 CONSUMO DE UM WEB SERVICE NO .NET
Para consumir um web service no .NET, uma classe proxy deve ser criada. A classe
proxy é o middleware, isto é, o intermediário entre o aplicativo cliente e o web service que
será consumido. O quadro 23 mostra uma aplicação de console em .NET consumindo o web
service ServicoDeHora.asmx criado anteriormente.
Quadro 23 – Aplicação para consumir o web service (TesteConsumo.cs)
A criação da classe proxy pode ser feita com o utilitário wsdl.exe que acompanha o
.NET Framework. A figura 5 ilustra o procedimento.
55
Figura 5 – Criando a classe proxy para um web service
O utilitário wsdl.exe deve receber como parâmetro a localidade exata em que se
encontra o arquivo .asmx do web service na rede e deve poder acessá-lo. O resultado será a
classe proxy gerada. Depois que a classe proxy estiver disponível, basta compilar e executar
os arquivos, como mostra a figura 6.
Figura 6 – Compilação e execução de um cliente de web service
No código fonte do aplicativo TesteConsumo.cs, que é cliente do web service, todas as
chamadas de métodos do web service são feitas de forma transparente, da mesma forma que
seriam chamados se a classe ServicoDeHora fosse uma classe local.
A classe proxy gerada pelo wsdl.exe é a responsável por requisitar, através de um
envelope SOAP, a informação ao web service. E também, ao receber a resposta empacotada
em outro envelope SOAP, retornar o resultado à aplicação.
Com o ambiente de desenvolvimento Visual Studio da Microsoft, a criação e consumo
de web services é facilitada por meio de assistentes que a ferramenta oferece.
4.8 TRABALHOS CORRELATOS
Em pesquisa realizada, foram encontrados três sistemas disponíveis no mercado que
são correlatos a este trabalho, relacionados a seguir:
a) Sentinel LM (RAINBOW TECHNOLOGIES, 2004);
56
b) SLockPK (CRYPTO CENTRAL, 2003);
c) XHEO|Licensing (XHEO INC, 2004).
Sentinel LM é um sistema comercial para gerenciamento eletrônico de licenças e
distribuição de softwares. Ele permite com que as licenças de software sejam gerenciadas de
forma centralizada na rede do cliente, e pode trabalhar com identificadores únicos de
hardware para verificar quais as máquinas que estão autorizadas a executar o aplicativo.
SLockPK é outro produto comercial que permite que desenvolvedores possam fazer a
proteção contra cópia do software com que trabalham. O sistema é baseado na criptografia de
chaves públicas RSA e foi desenvolvido para aplicativos dos ambientes Delphi e C++
Builder.
XHEO|Licensing é uma solução comercial para licenciamento de aplicativos
especialmente focada na plataforma .NET. O sistema trabalha com assinaturas digitais e
possui integração automática com o ambiente de desenvolvimento Visual Studio da Microsoft.
Também foi encontrado o artigo Using XML Digital Signatures for Application
Licensing (STEWART, 2003). Nele, o autor disserta sobre a tecnologia de assinatura digital
XML e fornece exemplos de como as ferramentas do Microsoft .NET Framework podem ser
usadas na área de licenciamento de aplicativos.
57
5 DESENVOLVIMENTO DO SOFTWARE
Neste capítulo será detalhado o desenvolvimento do mecanismo proposto. O software
é formado por três partes principais, ilustradas na figura 7 e descritas a seguir:
a) o módulo de licenciamento, um componente para ser integrado ao aplicativo que se
deseja fazer o controle de licenciamento;
b) o módulo de gerenciamento, uma página ASP.NET por onde o administrador da
instituição que detém o software pode gerenciar as requisições de licenças que são
enviadas;
c) um web service, responsável pela comunicação entre o aplicativo licenciado e o
sistema de gerenciamento de licenças, na instituição desenvolvedora do software.
Figura 7 – Visão geral do software
As seções a seguir descrevem os requisitos, especificação e implementação do
software. Em seguida é apresentada a operacionalidade da implementação e os resultados
obtidos.
5.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO
O mecanismo de proteção deverá satisfazer os seguintes requisitos funcionais (RF) e
requisitos não funcionais (RNF) relacionados abaixo:
a) permitir que requisições de licenças sejam enviadas, através da internet, do
aplicativo licenciado para a empresa que o desenvolveu (RF);
b) embutir, na requisição de licença, informações sobre o hardware do host que enviou
o pedido de licença, para fins de amarrar uma licença a uma determinada máquina,
evitando que a licença seja transferida de uma máquina autorizada para uma
máquina não autorizada (RF);
c) permitir que seja especificado, no momento da requisição da licença, o nível de
58
acesso e tempo de uso desejados para o aplicativo (RF);
d) permitir acompanhar a situação do pedido de licença (em avaliação, aprovado ou
rejeitado), a partir do aplicativo licenciado (RF);
e) permitir a transferência do arquivo de licença (download), da empresa que provê o
software para o aplicativo licenciado (RF);
f) permitir que o administrador da empresa que desenvolveu o aplicativo possa assinar
uma licença para um pedido enviado, especificando o nível de acesso e tempo de
uso concedidos (RF);
g) permitir que o administrador da empresa que desenvolveu o aplicativo possa rejeitar
um pedido de licença, especificando o motivo da rejeição (RF);
h) enviar um email para o requerente da licença, informando da expedição da licença
ou rejeição do pedido, quando estes ocorrerem (RF);
i) permitir que o administrador da empresa que desenvolveu o aplicativo possa
consultar relatórios sobre o histórico dos pedidos de licenças (RF);
j) verificar, no módulo de licenciamento, os arquivos de licença, no que diz respeito a
autenticidade, integridade dos dados, data de expiração e o hardware onde o
aplicativo está sendo executado (RF);
k) retornar, do módulo de licenciamento ao aplicativo licenciado, informações sobre a
presença e validade da licença, bem como o nível de acesso que a licença autoriza
no aplicativo (RF);
l) permitir descartar licenças e acompanhamentos de requisição, no aplicativo
licenciado (RF);
m) permitir uma fácil integração do mecanismo de licenciamento com aplicativos
existentes da plataforma .NET (RNF);
n) gerenciar os aspectos de segurança envolvidos para que o mecanismo de
licenciamento não seja quebrado (RNF).
5.2 ESPECIFICAÇÃO
A especificação do mecanismo proposto é apresentada através de diagrama de casos de
uso, descrição dos casos de uso, diagramas de classes, diagramas de seqüência e diagrama de
atividades. Estes diagramas são definidos pela Unified Modeling Language (UML).
59
5.2.1 DIAGRAMA DE CASOS DE USO
O diagrama de casos de uso para o software proposto pode ser visto na figura 8.
Figura 8 – Diagrama de casos de uso
5.2.2 DESCRIÇÃO DOS CASOS DE USO
A seguir serão detalhados os casos de uso especificados na figura 7. As descrições para
os casos de uso podem ser vistas nas tabelas de 1 a 10.
Tabela 1 – Caso de uso “entrar com dados pessoais” Ator Usuário Pré-condições Nenhuma Fluxo principal - Usuário acessa o menu de licenciamento e escolhe a opção “dados
pessoais”; - Usuário digita os seus dados; - Gravar os dados em um arquivo no disco.
Fluxo de exceção - Se o email digitado for inválido, usuário precisa digitar novamente o email ou deixá-lo em branco.
Pós-condições Dados pessoais do usuário armazenados no disco
60
Tabela 2 – Caso de uso “requisitar licença” Ator Usuário Pré-condições Nenhuma Fluxo principal - Usuário acessa o menu de licenciamento e escolhe a opção “enviar
requisição pela rede”; - Se uma licença já foi requisitada anteriormente (existe protocolo de acompanhamento), perguntar se deseja desconsiderar a licença antiga e enviar uma nova; - Exibir formulário de parâmetros da requisição, para obter o nível de acesso e tempo de uso desejados; - Enviar a requisição da licença pela rede.
Fluxo de exceção - Se não existir conectividade com o web service, exibir mensagem de erro.
Pós-condições Requisição de licença enviada para a empresa fabricante do software
Tabela 3 – Caso de uso “acompanhar situação da requisição enviada” Ator Usuário Pré-condições Existência de um protocolo de acompanhamento de requisição Fluxo principal - Usuário acessa o menu de licenciamento e escolhe a opção
“verificar situação da requisição enviada”; - Consultar no web service a situação da licença; - Exibir mensagem com a situação; - Se a licença estiver disponível, exibir opção para fazer download da licença.
Fluxo de exceção - Se não existir um protocolo de acompanhamento de requisição, exibir mensagem de erro.
Pós-condições Situação da licença consultada
Tabela 4 – Caso de uso “efetuar download da licença” Ator Usuário Pré-condições - Requisição de licença enviada;
- Licença assinada para a requisição. Fluxo principal - Usuário acessa o menu de licenciamento e escolhe a opção
“verificar situação da requisição enviada”; - Consultar no web service a situação da licença; - Exibir mensagem com a situação “licença disponível”; - Exibir opção para fazer download da licença; - Transferir a licença para o aplicativo.
Fluxo de exceção - Se houver um erro na transferência, exibir mensagem de erro. Pós-condições Arquivo de licença transferido para o aplicativo
61
Tabela 5 – Caso de uso “remover licença” Ator Usuário Pré-condições Existência de licença para o aplicativo Fluxo principal - Usuário acessa o menu de licenciamento e escolhe a opção
“remover licença”; - Verificar a existência da licença; - Remover a licença.
Fluxo de exceção - Se não houver licença, exibir mensagem de erro. Pós-condições Arquivo de licença removido do aplicativo
Tabela 6 – Caso de uso “remover protocolo de acompanhamento de requisição” Ator Usuário Pré-condições Existência de protocolo de acompanhamento de requisição Fluxo principal - Usuário acessa o menu de licenciamento e escolhe a opção
“remover acompanhamento de requisição”; - Verificar a existência do protocolo de acompanhamento; - Remover o protocolo de acompanhamento.
Fluxo de exceção - Se não houver protocolo de acompanhamento, exibir mensagem de erro.
Pós-condições Protocolo de acompanhamento de requisição removido
Tabela 7 – Caso de uso “expedir licença” Ator Administrador Pré-condições Requisição de licença presente no módulo de gerenciamento Fluxo principal - Administrador acessa interface web e escolhe a opção “requisições
aguardando avaliação”; - Administrador escolhe a opção “assinar licença” para uma determinada requisição que aguarda avaliação; - Administrador entra com o nível de acesso e tempo de uso concedidos; - Assinar a licença.
Fluxo de exceção - Se não existir a requisição de licença no módulo de gerenciamento, a licença não poderá ser assinada.
Pós-condições Licença assinada e disponível para download
62
Tabela 8 – Caso de uso “rejeitar requisição” Ator Administrador Pré-condições Requisição de licença presente no módulo de gerenciamento Fluxo principal - Administrador acessa interface web e escolhe a opção “requisições
aguardando avaliação”; - Administrador escolhe a opção “rejeitar requisição” para uma determinada requisição que aguarda avaliação; - Administrador entra com o motivo da rejeição; - Rejeitar requisição.
Fluxo de exceção - Se não existir a requisição de licença no módulo de gerenciamento, a requisição não poderá ser rejeitada.
Pós-condições Requisição de licença rejeitada
Tabela 9 – Caso de uso “consultar histórico” Ator Administrador Pré-condições Nenhuma Fluxo principal - Administrador acessa interface web e escolhe a opção “consultar
histórico”; - Administrador escolhe a categoria de histórico que deseja consultar (licenças expedidas ou requisições rejeitadas); - Exibir relatório sobre o histórico selecionado.
Fluxo de exceção Nenhum Pós-condições Relatório sobre o histórico é exibido
Tabela 10 – Caso de uso “obter nível de acesso” Ator Aplicativo licenciado Pré-condições Nenhuma Fluxo principal - Aplicativo acessa o objeto de licenciamento e chama o método
obterNivelDeAcesso; - Retornar o nível de acesso para a licença instalada ou um valor específico (-1) caso não exista licença válida.
Fluxo de exceção Nenhum Pós-condições Aplicativo com conhecimento sobre o nível de acesso que a licença
instalada permite
5.2.3 DIAGRAMAS DE CLASSES
Nesta seção serão especificados os diagramas de classes. Os diagramas foram
divididos em diagramas de análise e diagramas de projeto.
5.2.3.1 Diagramas de classes de análise
As classes de análise para o módulo de licenciamento podem ser vistas na figura 9.
63
Figura 9 – Diagrama de classes de análise para o módulo de licenciamento
A classe Licenciamento é a que realiza as principais funções relativas ao licenciamento
do aplicativo. A classe Hardware fornece métodos para obter informações do hardware onde
o aplicativo está sendo executado. A classe Criptografia disponibiliza métodos para encriptar
64
e desencriptar strings, recurso usado para ocultar as informações de hardware no documento
de requisição de licença. A classe Gerenciador é uma classe proxy para comunicação com o
web service. A classe AplicativoLicenciado representa o aplicativo que está fazendo uso do
mecanismo de gerenciamento de licenças proposto.
As classes de análise para o módulo de gerenciamento podem ser vistas na figura 10.
Figura 10 – Diagrama de classes de análise para o módulo de gerenciamento
65
A classe Requisicao implementa as principais funções relativas ao módulo de
gerenciamento. Esta classe faz uso da classe RegistroTabelaRequisicoes, para construir
tabelas de requisições nas páginas ASP.NET. A classe AnalisadorRequisicao é responsável
por validar um documento de requisição contra um schema XML, para saber se a requisição
de licença enviada está em conformidade com o padrão estabelecido. A classe Gerenciador é
a implementação do web service para comunicação entre o aplicativo licenciado e o módulo
de gerenciamento.
5.2.3.2 Diagramas de classes de projeto
As classes de projeto para o módulo de licenciamento podem ser vistas na figura 11.
Figura 11 – Diagrama de classes de projeto para o módulo de licenciamento
Estas classes representam uma interface gráfica para interação com o usuário.
66
As classes de projeto para o módulo de gerenciamento, relativas às funções do
administrador (expedir licença, rejeitar requisição, consultar histórico, etc.), podem ser vistas
na figura 12.
Figura 12 – Diagrama de classes de projeto para o módulo de gerenciamento (administrador)
67
As classes de projeto para o módulo de gerenciamento, relativas às funções públicas
(enviar requisição de licença, verificar a situação de uma requisição, etc.), podem ser vistas na
figura 13.
Figura 13 – Diagrama de classes de projeto para o módulo de gerenciamento (público)
As classes representadas nas figuras 12 e 13 são do tipo code behind, que possuem a
lógica e processamento associados às páginas de apresentação ASP.NET. As classes code
behind permitem que a apresentação fique separada do código em um sistema ASP.NET.
5.2.4 DIAGRAMAS DE SEQUÊNCIA
A seguir serão descritos os diagramas de seqüência para os casos de uso do software.
Os diagramas podem ser vistos nas figuras de 14 a 23.
68
Figura 14 – Diagrama de seqüência para “entrar com dados pessoais”
Figura 15 – Diagrama de seqüência para “requisitar licença”
69
Figura 16 – Diagrama de seqüência para “acompanhar situação da requisição enviada”
Figura 17 – Diagrama de seqüência para “efetuar download de licença”
70
Figura 18 – Diagrama de seqüência para “remover licença”
Figura 19 – Diagrama de seqüência para “remover protocolo de acompanhamento de requisição”
71
Figura 20 – Diagrama de seqüência para “expedir licença”
Figura 21 – Diagrama de seqüência para “rejeitar requisição”
72
Figura 22 – Diagrama de seqüência para “consultar histórico”
73
Figura 23 – Diagrama de seqüência para “obter nível de acesso”
5.2.5 DIAGRAMA DE ATIVIDADES
O diagrama de atividades descreve o processo de envio de uma requisição de licença,
as ações que o administrador pode tomar quanto à requisição enviada e à verificação da
situação de uma licença por parte do usuário. O diagrama pode ser visto na figura 24.
74
Figura 24 – Diagrama de atividades
5.3 IMPLEMENTAÇÃO
Esta seção abordará a implementação do mecanismo proposto. Serão descritas as
ferramentas utilizadas e as principais funções do software.
75
5.3.1 FERRAMENTAS UTILIZADAS
O mecanismo de proteção foi desenvolvido com a ferramenta Visual Studio .NET 2003
da Microsoft. Foi criada uma solution chamada TCC contendo quatro projetos principais. A
ilustração da solution pode ser vista na figura 25.
Figura 25 – Solution do Visual Studio para o software desenvolvido
O projeto Aplicativo representa o aplicativo que se deseja proteger contra cópias
ilegais. Ele é um exemplo que foi criado para exemplificar o funcionamento do mecanismo.
Este aplicativo-exemplo possui três funções simples, para que possam ser testados os níveis
de acesso e a validade da licença. O projeto GerenciadorWEB contém as páginas ASP.NET
que fazem parte do módulo de gerenciamento. Este projeto também contém a implementação
do web service, para a comunicação entre os módulos do software. O projeto Licenciamento
contém as classes relativas ao módulo de licenciamento. Foi criado um pequeno projeto
chamado GeradorChaves, que auxilia na criação do par de chaves criptográficas (etapa
necessária para integrar o mecanismo a um aplicativo .NET existente).
Para os casos de uso, diagramas de classes e diagramas de seqüência foi usada a
ferramenta Microsoft Visio. O diagrama de atividades foi feito com a ferramenta SmartDraw.
5.3.2 IMPLEMENTAÇÃO DAS PRINCIPAIS FUNÇÕES DO SOFTWARE
Nesta seção serão abordadas as implementações das principais funções do software.
5.3.2.1 Gravação dos dados pessoais
Os dados pessoais do usuário são gravados no diretório onde executa a DLL de
licenciamento, em formato XML. Estes dados são automaticamente recuperados quando um
76
objeto Licenciamento é instanciado. O diretório de execução é obtido através do namespace
System.Reflection, como mostra o quadro 24.
Quadro 24 – Obtendo o diretório de execução do módulo de licenciamento
5.3.2.2 Geração do documento de requisição
Para gerar o documento de requisição, o usuário deve entrar com o nível de acesso e
tempo de uso desejados para o aplicativo. Depois que essas informações são passadas para o
objeto de licenciamento, é gerado o documento de requisição. O documento contém as
informações pessoais do requerente, os parâmetros de utilização do software e três
identificadores de hardware encriptados. Um exemplo de documento de requisição de licença
pode ser visto no quadro 25.
Quadro 25 – Exemplo de documento de requisição de licença
Os três identificadores de hardware significam, respectivamente, os endereços MAC
(concatenados) das placas de rede ethernet instaladas, o número serial do volume/partição do
drive C e a identificação do processador instalado na máquina. Os identificadores de
hardware são encriptados através da classe Criptografia, que utiliza o algoritmo Rijndael,
disponível no namespace System.Security.Cryptography do .NET Framework.
77
5.3.2.3 Obtenção das informações de hardware
As informações de hardware presentes no documento de requisição são obtidas através
de chamadas de código nativo do sistema operacional. Por meio de uma técnica chamada
platform interop, é possível, a partir de uma aplicação .NET gerenciada, acessar funções da
Win32 API.
No mecanismo proposto, para obter as informações da placa de rede, a função
GetAdaptersInfo é usada. Para a identificação do disco, a função GetVolumeInformation é
usada. A identificação do processador da máquina é obtida com a função GetSystemInfo. O
quando 26 exemplifica a técnica de platform interop com os métodos responsáveis por
retornar o volume serial do HD, a partir da função GetVolumeInformation.
Quadro 26 – Acessando informações do disco via platform interop
78
5.3.2.4 Armazenamento do documento de requisição
Depois que o documento de requisição é gerado, é instanciada uma classe proxy para o
web service. Então é chamado o método receberReq do web service, que recebe como
parâmetro o documento XML da requisição convertido em formato string. O web service
recebe a requisição e a analisa contra um schema para verificar se está dentro do padrão
esperado. O quadro 27 mostra o método que faz essa verificação.
Quadro 27 – Método que verifica um documento de requisição recebido pelo web service
Se a verificação for bem sucedida, o web service irá incluir no documento de
requisição informações sobre o seu recebimento e sobre a sua situação. Depois, o documento
é gravado na pasta destinada às requisições que aguardam avaliação, no host que executa o
módulo de gerenciamento. O procedimento pode ser visto no quadro 28.
Quadro 28 – Inclusão de informações e gravação do documento de requisição
O quadro 29 mostra um documento de requisição que foi recebido e armazenado com
sucesso pelo web service.
79
Quadro 29 – Documento de requisição recebido com sucesso pelo web service
Em relação ao documento gerado inicialmente no módulo de licenciamento, foram
adicionados pelo web service os nodes recebimento e situacao. O node recebimento contém o
ID da requisição, o endereço IP de quem enviou o documento e a data e hora de envio. O node
situacao contem a situação da requisição (inicialmente “em avaliação”).
Caso seja assinada uma licença para a requisição ou ela seja rejeitada, o node situacao
será atualizado. A data e hora deste node são relativas à assinatura ou rejeição da requisição.
O node situacao também pode conter o motivo da rejeição (fornecido pelo administrador),
caso ela tenha sido rejeitada.
No momento do recebimento da requisição é atribuído ao documento um ID gerado
aleatoriamente (idRequisicao), que identifica uma requisição de forma única e serve para que
o usuário acompanhe a sua situação. O ID possui o formato “LnLnLnLnLnLnLn”, onde “L”
representa uma letra maiúscula e “n” representa um dígito entre 0 e 9. O quadro 30 mostra a
função responsável por gerar este ID.
80
Quadro 30 – Função responsável por gerar o ID aleatório para a requisição
5.3.2.5 Pastas do módulo de gerenciamento
O módulo de gerenciamento faz o armazenamento das requisições, licenças, chaves
criptográficas e arquivo de schema no próprio disco do host que o executa. É criada uma
estrutura de pastas para armazenar essas informações.
A raiz dessa estrutura é uma pasta chamada Gerenciamento. Dentro dela existe a pasta
chave, que contém a chave privada que assina as licenças de software. A pasta licenca, outra
subpasta de Gerenciamento, contém as licenças assinadas e que estão disponíveis para
download. A pasta requisicoes, também dentro de Gerenciamento, contém as requisições de
licenças que foram enviadas. Esta pasta é subdividida em uma pasta que armazena as
requisições que aguardam a avaliação do administrador (emEspera), uma pasta que armazena
as requisições que foram rejeitadas (rejeitadas) e uma pasta para armazenamento temporário
(tempWeb). A pasta schema, localizada dentro da raiz Gerenciamento, contém o arquivo de
schema XML usado na validação das requisições.
5.3.2.6 Protocolo de acompanhamento
O método que inclui as informações de recebimento na requisição enviada tem como
variável de retorno o ID que foi gerado aleatoriamente. O web service retorna este ID para o
aplicativo que enviou a requisição, para fins de acompanhamento. O quadro 31 mostra o
código relativo a esta parte, no módulo de licenciamento.
81
Quadro 31 – Obtenção do ID da requisição enviada
Depois de receber o ID do web service o aplicativo chama o método
registrarIdRequisicao, responsável por gravar no seu diretório o protocolo de
acompanhamento da requisição, que é um arquivo XML. O quadro 32 mostra um exemplo
deste protocolo de acompanhamento.
Quadro 32 – Protocolo de acompanhamento da requisição (requisicaoEmEspera.xml)
5.3.2.7 Assinatura da licença
Quando o administrador decide assinar uma licença para uma requisição enviada, o
módulo de gerenciamento solicita o nível de acesso e tempo de uso concedidos àquela
requisição. Depois, os nodes nivelDeAcesso e tempoDeLicenca (desejados) são removidos e
nos seus lugares são adicionados os nodes nivelDeAcessoConcedido e dataDeExpiracao.
Em seguida é atualizada a situação da requisição para “licenca assinada” e a data e
hora da assinatura são registrados na licença. Depois o cálculo da assinatura digital é realizado
e também anexado no documento. Finalmente, um email é enviado ao usuário notificando a
disponibilidade de sua licença. O quadro 33 mostra um arquivo de licença assinada.
82
Quadro 33 – Licença assinada
5.3.2.8 Rejeição da requisição
Quando o administrador decide rejeitar uma requisição de licença ele deve informar o
motivo da rejeição. Depois que isso é feito, o node situacao é atualizado para “rejeitada”,
constando também a data e hora da rejeição e o motivo fornecido pelo administrador. O
quadro 34 mostra um arquivo de requisição rejeitada.
83
Quadro 34 – Requisição de licença rejeitada
5.3.2.9 Verificação da licença
A verificação de uma licença, no módulo de licenciamento, acontece através das
seguintes etapas: a verificação da assinatura digital contida na licença, checagem dos
identificadores de hardware e checagem da data de expiração da licença. A licença só é
considerada válida se as três verificações forem bem sucedidas.
O quadro 35 mostra as etapas de verificação da licença, no módulo de licenciamento.
84
Quadro 35 – Verificação de um arquivo de licença
5.3.2.10 Chave pública
A verificação da assinatura digital de uma licença é feita com a chave pública da
empresa desenvolvedora do software (que assina as licenças com a sua chave privada). Essa
chave pública, em formato de um arquivo XML, fica embutida no assembly do módulo de
licenciamento. Isto é, o arquivo XML da chave pública fica armazenado dentro do próprio
arquivo Licenciamento.dll.
Caso a chave pública fosse escrita no corpo do arquivo de licença ou enviada em um
arquivo XML acessível pelo usuário, ocorreria uma falha de segurança. Isto porque qualquer
pessoa não autorizada poderia assinar licenças com a sua chave privada e substituir a chave
pública da empresa desenvolvedora pela sua chave pública, o que levaria o módulo de
85
licenciamento a considerar válidas assinaturas de fontes não autênticas. Portanto, para que
haja segurança, a chave pública da empresa desenvolvedora não pode ser modificada. Embuti-
la no assembly é uma maneira de preservá-la.
Para embutir a chave pública no assembly, foi usado o ambiente de desenvolvimento
Visual Studio. Para realizar esse procedimento é preciso adicionar a chave pública no projeto
e depois configurar nas suas propriedades a opção embedded resource. Esta opção faz com
que o arquivo XML da chave pública seja incorporado ao assembly Licenciamento.dll. A
figura 26 faz uma ilustração desta etapa.
Figura 26 – Chave pública embutida no assembly Licenciamento.dll
5.3.2.11 Nível de acesso
Uma das mais importantes comunicações entre o aplicativo e o módulo de
licenciamento é quando o aplicativo deseja saber qual o nível de acesso que o usuário possui,
de acordo com o arquivo de licença. O nível de acesso é um número inteiro. É baseado neste
nível de acesso que o aplicativo vai permitir ou bloquear o uso dos seus recursos.
Se existir uma licença válida o nível de acesso retornado é aquele que foi concedido
pelo administrador no momento da assinatura da licença (node nivelDeAcessoConcedido).
Caso não exista licença ou a licença esteja inválida, é retornado o valor -1 para o aplicativo.
5.3.3 OPERACIONALIDADE DA IMPLEMENTAÇÃO
Nesta seção é apresentado o funcionamento do mecanismo desenvolvido. Para isto,
será realizado um estudo de caso que consiste em um aplicativo .NET que irá integrar o
mecanismo de licenciamento proposto. O aplicativo utilizado será aquele do projeto
86
Aplicativo, contido na solution TCC, apresentada na seção 5.3.1. A figura 27 mostra a tela
principal do aplicativo.
Figura 27 – Tela principal do aplicativo licenciado
O aplicativo possui três recursos simples: a exibição da frase hello world em várias
línguas, a exibição da hora atual e a geração de um número aleatório. No estudo de caso estas
funções necessitam, respectivamente, de níveis de acesso 1, 2 e 3.
O primeiro passo que o usuário deve tomar é preencher os seus dados pessoais. Para
isso o usuário acessa o menu Licenciamento e escolhe a opção Dados pessoais. A ilustração
desta etapa pode ser vista na figura 28.
Figura 28 – Preenchimento dos dados pessoais
Neste momento não existe licença e nenhuma requisição foi enviada, como mostra a
figura 29.
87
Figura 29 – Situação inicial do módulo de licenciamento
Qualquer tentativa de acesso aos recursos do sistema, que necessitam de pelo menos o
nível de acesso 1, resultará em uma mensagem de acesso negado. A figura 30 ilustra esse
caso.
Figura 30 – Tentativa de acesso aos recursos sem uma licença válida
Nesse momento o usuário pode enviar uma requisição de licença à empresa
proprietária do software. Para isso ele acessa o menu Licenciamento e nas opções da
88
requisição escolhe enviar requisição pela rede. Será exibido o formulário de parâmetros da
requisição, onde o usuário deve entrar com o nível de acesso e tempo de uso desejados, como
mostra a figura 31.
Figura 31 – Formulário de parâmetros da requisição
Ao clicar no botão Ok a requisição de licença é enviada através do web service. Um
protocolo de acompanhamento é gravado no disco, com o ID retornado pelo web service. A
figura 32 mostra os dados do protocolo de acompanhamento da requisição.
Figura 32 – Dados do protocolo de acompanhamento da requisição
89
Nesse momento a requisição está aguardando avaliação no módulo de gerenciamento,
na empresa proprietária do software. O usuário pode acompanhar a situação da sua requisição
acessando o menu de Licenciamento e escolhendo a opção verificar situação da requisição
enviada. Caso seja acessada neste ponto, será exibida a mensagem da figura 33.
Figura 33 – Mensagem de que a requisição está sendo avaliada pelo administrador
O administrador faz o gerenciamento das licenças através de uma interface web. Para
acessar as funções administrativas o administrador precisa digitar a senha de acesso, como
mostra a figura 34.
Figura 34 – Acesso às funções administrativas no módulo de gerenciamento (login)
90
Depois de fazer a autenticação, o administrador escolhe uma opção do menu. Para
gerenciar as requisições deve ser acessada a opção Requisições aguardando avaliação, como
mostra a figura 35.
Figura 35 – Menu do administrador no módulo de gerenciamento
Quando esta opção for acessada serão listadas as requisições enviadas que aguardam
avaliação, em ordem cronológica. Para assinar uma licença ou rejeitar a requisição, o
administrador deve clicar no link Gerenciar da requisição. A lista de requisições para esta
opção do menu pode ser vista na figura 36.
91
Figura 36 – Lista de requisições aguardando avaliação
Ao clicar no link Gerenciar, a página exibida na figura 37 é mostrada.
92
Figura 37 – Gerenciamento de uma requisição
Ao clicar no botão Assinar licença, o administrador deve informar o nível de acesso e
tempo de uso concedidos. Os valores iniciais do formulário são aqueles que o usuário
requisitou. Esta etapa está ilustrada na figura 38.
93
Figura 38 – Nível de acesso e tempo de uso concedidos a uma licença
Ao clicar no botão Assinar será realizada a assinatura da licença, que ficará disponível
para download. Quando uma licença é assinada o usuário é notificado por email, como mostra
a figura 39.
Figura 39 – Notificação enviada por email no momento da assinatura
94
A partir desse momento, quando o usuário verificar a situação da sua licença, no menu
de licenciamento do seu aplicativo, será exibida a mensagem de que a licença está disponível,
e que ele pode fazer o seu download. A figura 40 mostra essa mensagem.
Figura 40 – Mensagem de licença disponível
Ao clicar no botão Sim, a licença será transferida para o aplicativo e será removido o
protocolo de acompanhamento da requisição que estava gravado. Os dados da licença serão
exibidos no painel de licenciamento, como pode ser visto na figura 41.
Figura 41 – Licença transferida para o aplicativo
Agora que existe uma licença no aplicativo as funções do programa podem ser
acessadas. Com nível de acesso 2 o usuário do estudo de caso pode acessar as funções Hello
World e Mostrar hora. A função Gerar número requer nível de acesso 3 e não pode ser
95
acessada com essa licença. Caso seja acessada será exibida uma mensagem de erro. A figura
42 mostra o acesso às funções do programa.
Figura 42 – Acesso às funções do aplicativo depois de transferida a licença
Caso o administrador desejasse rejeitar uma licença ele deveria selecionar o botão
Rejeitar, no gerenciamento da licença. Depois, deveria especificar o motivo da rejeição. A
figura 43 mostra a interface correspondente a este procedimento.
Figura 43 – Definição do motivo da rejeição de uma requisição
Depois de clicado o botão Rejeitar, o usuário seria notificado da rejeição por email,
como mostra a figura 44.
96
Figura 44 – Notificação enviada por email no momento da rejeição da requisição
Ao verificar a situação da sua requisição de licença no aplicativo, o usuário também
seria informado da rejeição da sua requisição, como é mostrado na figura 45.
Figura 45 – Mensagem de que a requisição de licença foi rejeitada pelo administrador
5.3.4 INTEGRAÇÃO DO MECANISMO COM APLICATIVOS .NET
Para que o mecanismo de licenciamento proposto seja integrado com um aplicativo
.NET, é necessário o cumprimento de algumas etapas, que serão descritas nesta seção. Para
realizar a integração, será considerada a pasta Integracao, presente na mídia que acompanha
97
este trabalho. Esta pasta contém as subpastas Licenciamento, GerenciadorWEB,
GeradorChaves e Gerenciamento. O primeiro passo é copiar todo o conteúdo da pasta
Integracao para um espaço no disco, de modo que seus arquivos possam ser modificados.
5.3.4.1 Geração do par de chaves
É importante que seja gerado um novo par de chaves criptográficas RSA para cada
aplicativo que integrará o mecanismo. O utilitário GeradorChaves, disponibilizado na pasta
Integracao\GeradorChaves, possibilita a geração destas chaves. A figura 46 mostra a tela do
utilitário.
Figura 46 – Utilitário para geração do par de chaves RSA
A chave pública deve ter o nome chavePublica.xml e a chave privada deve ter o nome
chavePrivada.xml. Para este exemplo, o diretório de gravação das chaves será o C:\Temp.
Depois de criadas as chaves para a assinatura e verificação das licenças, deve ser
criado o par de chaves para a assinatura do assembly Licenciamento.dll. Assinar um assembly
.NET significa dar a ele um strong name (em português, nome forte). Isto significa que o
assembly será identificado não apenas pelo nome que possui, mas também por uma assinatura
digital gerada e anexada a ele pelo compilador .NET. Quando um assembly é assinado com
um strong name, qualquer tentativa de substituí-lo por uma versão falsa (com o mesmo nome
e um conteúdo diferente) irá falhar. Ou seja, o aplicativo que faz uso do Licenciamento.dll
reconhecerá apenas a versão autêntica da biblioteca, aquela que foi usada na compilação
original.
O arquivo que contém as chaves para assinatura do assembly não possui o formato
XML, mas um formato binário com extensão .snk. Ele é gerado pela ferramenta sn.exe, que
acompanha o Visual Studio .NET. Na pasta Integracao\GeradorChaves foi disponibilizado
um script chamado gerarChaves_Assembly.bat que pode ser usado para gerar o arquivo
98
chavesAssembly.snk. Para este exemplo, o diretório de gravação do arquivo será o C:\Temp. A
figura 47 mostra o script sendo executado para gerar as chaves de assinatura do assembly.
Figura 47 – Geração das chaves para assinatura do assembly Licenciamento.dll
A chave para assinatura de um assembly é normalmente especificada no arquivo
AssemblyInfo.cs, através do atributo [assembly:AssemblyKeyFileAttribute("...")], que deve
conter o caminho e nome para o arquivo .snk. Para este exemplo, o arquivo AssemblyInfo.cs
do módulo de licenciamento já encontra-se configurado para procurar o arquivo
chavesAssembly.snk no diretório C:\Temp.
5.3.4.2 Definição do nível de acesso máximo no módulo de licenciamento
O formulário de obtenção dos parâmetros da requisição possui um controle do tipo
System.Windows.Forms.ComboBox, que contém uma lista de níveis de acesso para o usuário
selecionar aquele que deseja. As opções de seleção da lista são números inteiros que vão de 1
até o nível máximo. O nível de acesso máximo deve ser configurado no arquivo
Licenciamento.cs, por meio de um editor de textos comum. Este arquivo está na pasta
Integracao\Licenciamento. Para configurar o nível de acesso máximo, basta atribuir um valor
inteiro à variável _NivelDeAcessoMaximo e depois salvar o arquivo. O procedimento pode ser
visto na figura 48.
Figura 48 – Configuração do nível de acesso máximo em Licenciamento.cs
99
5.3.4.3 Instalação do .NET Framework
É preciso certificar-se de que o .NET Framework está instalado na máquina. Ele pode
ser baixado gratuitamente no site da Microsoft (MSDN, 2004b). O .NET Framework
acompanha um compilador C# que opera por linha de comando, chamado csc.exe.
5.3.4.4 Compilação do módulo de licenciamento
Uma compilação do módulo de licenciamento se faz necessária, pois a configuração de
nível de acesso máximo e a chave pública precisam estar dentro do assembly que será gerado.
Caso estas informações sejam colocadas fora do assembly, elas podem ser facilmente
alteradas, comprometendo a segurança do software.
Nesta etapa é necessário copiar todos os arquivos com extensão .cs da pasta
Integracao\Licenciamento para a pasta temporária C:\Temp, que armazena as chaves geradas.
Em seguida, é necessário abrir um prompt de comando e incluir o compilador C# no path do
sistema operacional. O compilador está no diretório onde foi instalado o Microsoft .NET
Framework. A figura 49 mostra um exemplo desta etapa.
Figura 49 – Inclusão do compilador C# no path do sistema operacional
Depois é preciso fazer a compilação através deste prompt de comando que foi aberto.
No diretório C:\Temp devem estar os arquivos da pasta Integracao\Licenciamento, o arquivo
chavePublica.xml e o arquivo chavesAssembly.snk. A compilação deve incluir
chavePublica.xml como embedded resource do arquivo Licenciamento.dll. A figura 50 mostra
a sintaxe necessária para este objetivo.
100
Figura 50 – Compilação do módulo de licenciamento
O resultado da compilação é o arquivo Licenciamento.dll, o módulo de licenciamento
que será integrado ao aplicativo .NET. Este assembly irá conter a chave pública para
verificação das licenças e estará assinado digitalmente (strong name).
5.3.4.5 Integração com o aplicativo
A integração com o aplicativo é feita adicionando-se uma referência no projeto do
aplicativo ao arquivo Licenciamento.dll, para que o linker encontre a biblioteca e para que a
compilação do aplicativo junto com o módulo de licenciamento possa ocorrer.
No código do aplicativo deve ser instanciado um objeto do tipo Licenciamento em um
escopo de variável que tenha visibilidade durante a vida do aplicativo. Por exemplo, o objeto
de licenciamento pode ser um atributo do formulário principal do aplicativo.
O mecanismo de licenciamento oferece uma interface gráfica através da classe
FormLicenciamento. Um objeto desta classe pode ser associado a um determinado menu do
aplicativo, para que as opções de licenciamento sejam acessadas pelo usuário. O construtor da
classe FormLicenciamento deve receber o objeto de licenciamento como parâmetro. A figura
51 mostra um exemplo de código para esta etapa.
101
Figura 51 – Integração do aplicativo .NET com o módulo de licenciamento
5.3.4.6 Configuração do web service
A localização do web service na rede deve ser definida em um arquivo de configuração
para o aplicativo. Este arquivo de configuração deve ser criado (ou alterado, caso já exista)
por meio de um editor de textos comum. Ele deve ter o nome no formato
MeuAplicativo.exe.config, onde MeuAplicativo.exe é o executável do aplicativo. A figura 52
mostra o conteúdo que o arquivo de configuração deve possuir.
Figura 52 – Definindo a localização do web service no arquivo de configuração
Na figura, o atributo value da chave de configuração contém o endereço IP 192.168.0.6
para o web service, que por sua vez está em um diretório do servidor web chamado
GerenciadorWEB e possui um nome de arquivo Gerenciador.asmx. Estes valores devem ser
alterados para conter a localização do web service na rede em que será instalado o módulo de
gerenciamento. O valor da chave Licenciamento.GerenciadorWEB.Gerenciador não deve ser
alterado no arquivo de configuração, apenas o seu atributo value.
102
O arquivo de configuração deve ser gravado no mesmo diretório onde está o
executável do aplicativo.
5.3.4.7 Obter o nível de acesso
Para fazer o controle de permissão ou bloqueio de utilização dos recursos no
aplicativo, deve-se incluir, nos métodos que contém esses recursos, verificações do nível de
acesso retornado pelo objeto de licenciamento. A figura 53 mostra um exemplo de código
para uma determinada função chamada Calcular, associada ao clique de um botão no
formulário principal.
Figura 53 – Controle de acesso a um recurso do aplicativo
O objeto de licenciamento traz uma mensagem padrão de acesso negado, que pode ser
obtida através da propriedade mensagemAcessoNegado.
Neste ponto está encerrada a integração do aplicativo .NET com o módulo de
licenciamento. Aconselha-se que o aplicativo .NET também seja assinado com um strong
name. Para isto deve-se configurar a propriedade
[assembly:AssemblyKeyFileAttribute(@"C:\Temp\chavesAssembly.snk")] no arquivo
AssemblyInfo.cs do aplicativo, antes da compilação ser realizada. Caso esse arquivo não
exista, ele deve ser criado.
5.3.4.8 Módulo de gerenciamento
O módulo de gerenciamento deve ser hospedado por uma máquina que tenha o
servidor web IIS e o .NET Framework instalados. É importante que o .NET Framework tenha
sido instalado depois do servidor IIS no sistema operacional. Caso contrário, alguns ajustes
são necessários (MICROSOFT, 2004).
103
5.3.4.9 Cópia das pastas e configuração das permissões
A primeira etapa para instalação do módulo de gerenciamento é cópia da pasta
Integracao\Gerenciamento para o disco local da máquina que hospeda o módulo. A estrutura
destas pastas pode ser vista na figura 54.
Figura 54 – Pastas para o módulo de gerenciamento
Depois de copiadas as pastas, deve-se conceder permissões NTFS para elas, com o
objetivo de permitir que a aplicação ASP.NET possa acessá-las. Para isto o usuário ASPNET
deve receber a permissão de controle total na raiz Gerenciamento e em todas as suas
subpastas.
A chave privada, gerada anteriormente e armazenada em C:\Temp, deve ser copiada
para a pasta chave desta estrutura. A pasta schema deve conter o arquivo de schema XML
para a validação das requisições. As outras pastas devem estar vazias.
5.3.4.10 Arquivo de configuração
Nesta etapa algumas configurações precisam ser feitas no arquivo Web.config. Este
arquivo está contido na pasta Integracao\GerenciadorWEB e pode ser editado por qualquer
editor de textos. A figura 55 mostra a primeira parte das configurações que devem ser
definidas.
104
Figura 55 – Configurações do módulo de gerenciamento (Web.config)
Todos os atributos value devem ser alterados para refletir os dados da empresa que está
instalando o sistema e os caminhos das pastas que foram criadas. A chave
nivelDeAcessoMaximo deve ser igual a que foi configurada no módulo de licenciamento.
A segunda parte da configuração consiste na definição de um nome de usuário e senha
para o administrador de licenças. Estas informações também devem ser especificadas no
arquivo Web.config, como mostra a figura 56.
Figura 56 – Definição da senha do administrador (Web.config)
5.3.4.11 Transferência dos arquivos
Neste ponto, a pasta Integracao\GerenciadorWEB, que contém o módulo de
gerenciamento, deve ser copiada inteiramente para dentro da pasta raiz do servidor web. A
figura 57 mostra esta etapa.
105
Figura 57 – Cópia de GerenciamentoWEB para o servidor IIS
A pasta raiz do servidor web, no exemplo, é a C:\Inetpub\wwwroot. Depois da cópia,
nas propriedades do diretório GerenciadorWEB do Internet Services Manager (painel de
configurações do servidor IIS), deve-se definir um Application name para a aplicação web.
Para isso é preciso clicar em Create e depois em Ok. O procedimento pode ser visto na figura
58.
Figura 58 – Definição de Application name para o GerenciadorWEB
106
Neste ponto está concluída a instalação do módulo de gerenciamento. Para acessá-lo,
basta apontar para o arquivo http://nome_do_host/GerenciadorWEB/index.aspx no navegador
da Internet.
5.4 RESULTADOS E DISCUSSÃO
Nos testes realizados com o software observou-se um resultado satisfatório. O
comportamento do mecanismo atende aos requisitos funcionais especificados na seção 5.1.
Ele permitiu o acesso aos recursos quando uma licença válida era encontrada no aplicativo e
negou o acesso quando não existia licença ou quando a mesma estava inválida. Foi possível
identificar este comportamento no estudo de caso realizado na seção 5.3.3.
A tentativa de corromper um arquivo de licença (por exemplo, aumentando o nível de
acesso no node nivelDeAcessoConcedido) foi detectada corretamente pelo mecanismo
desenvolvido, que acusou a invalidade da licença. A figura 59 mostra essa situação.
Figura 59 – Licença corrompida
Quando foi testada a transferência do arquivo de licença para uma máquina não
autorizada, a licença foi considerada inválida, devido à falha na verificação dos
identificadores de hardware. Essa situação pode ser vista na figura 60.
Figura 60 – Licença transferida para uma máquina não autorizada
107
Outro teste realizado foi o avanço do calendário do sistema operacional, que ocasionou
corretamente a expiração da licença. Essa situação é mostrada na figura 61.
Figura 61 – Licença expirou
Foi possível observar no mecanismo de licenciamento a facilidade na requisição e
download das licenças. Isto foi possível devido à comunicação direta, através do web service,
do módulo de licenciamento com o módulo de gerenciamento.
O mecanismo de licenciamento demonstrou confiabilidade em relação à falsificação de
licenças. Esta situação é muito difícil de acontecer, pois para que uma licença seja falsificada,
é necessário o acesso à chave privada da empresa proprietária do software. Se esta chave
estiver bem protegida, a falsificação de licenças torna-se praticamente impossível.
O requisito não funcional identificado pela letra m (seção 5.1), que diz respeito à
facilidade de integração do mecanismo a um aplicativo .NET, foi atendido de forma
satisfatória. O roteiro exposto na seção 5.3.4 descreve todos os passos necessários para que
este objetivo seja alcançado.
O requisito não funcional identificado pela letra n (seção 5.1), que diz respeito aos
aspectos de segurança do mecanismo de proteção, foi atendido parcialmente. Desde o
momento da concepção do mecanismo, uma vulnerabilidade de segurança foi percebida.
Como o módulo de licenciamento está escrito em C# e é compilado para a plataforma .NET,
tem-se como resultado final um assembly composto por código intermediário, que é
compilado para código nativo somente no momento da execução.
É possível observar a existência de algumas ferramentas, como a Microsoft ILDASM
(distribuída gratuitamente com o .NET Framework), capazes de exibir ou extrair o código
intermediário contido em um assembly .NET. Outras ferramentas, como a Microsoft ILASM,
são capazes de gerar um assembly .NET a partir de código intermediário. Considerando estas
108
ferramentas, é perfeitamente possível a descompilação, modificação e recompilação de um
programa compilado para a plataforma .NET.
Neste caso, uma possibilidade de ataque seria a modificação do módulo de
licenciamento, para que ele retornasse um valor fixo de nível de acesso, independente da
verificação da licença. Outra possibilidade seria a substituição da chave pública que está
embutida no assembly por outra não autêntica.
Esta deficiência não é específica ao mecanismo de gerenciamento de licenças
desenvolvido neste trabalho, mas sim uma característica geral dos assembly .NET. Em outras
linguagens que também trabalham com código intermediário, como Java e Python, o
problema existe igualmente.
A assinatura do assembly Licenciamento.dll ajuda a superar este problema até certo
ponto. Caso o aplicativo licenciado seja compilado com uma versão assinada digitalmente do
assembly Licenciamneto.dll (isto é, com um strong name), qualquer versão modificada pelo
procedimento de descompilação não seria reconhecida como autêntica, por faltar a assinatura
digital que o aplicativo licenciado espera encontrar. A figura 62 mostra o erro encontrado ao
tentar executar uma versão falsa do assembly Licenciamento.dll.
Figura 62 – Erro ao ler uma versão falsa de Licenciamento.dll
Entretanto, como o aplicativo licenciado é também um aplicativo .NET, o processo de
descompilação, modificação e recompilação também poderia ser empregado a este aplicativo.
Assim, um ataque ainda mais simples poderia ser realizado, como a modificação do aplicativo
com o objetivo de remover os pontos de verificação da licença no acesso aos recursos.
Não foram observadas técnicas de fácil implementação para evitar esse tipo de
problema. Na Internet podem ser encontradas ferramentas comerciais que impedem o
109
processo de modificação e descompilação de um assembly .NET, conhecidas como
obfuscators e protetores de código. Um exemplo seriam as ferramentas Salamander .NET
Obfuscator (REMOTESOFT, 2004a) e Salamander .NET Protector (REMOTESOFT,
2004b).
A segurança de assembly .NET é uma discussão importante e correlata a este trabalho.
Caso o aplicativo licenciado seja bem protegido, através das técnicas empregadas pelas
ferramentas citadas, o mecanismo de licenciamento pode ser considerado de bom nível de
segurança.
Foi percebido um outro tipo de vulnerabilidade no mecanismo de proteção, que tem
relação com a verificação da data de expiração da licença. Para realizar a verificação, o
módulo de licenciamento obtém a data atual do sistema operacional e a compara com a data
especificada no arquivo de licença. Caso a data do sistema operacional seja posterior à data do
arquivo, a licença é considerada vencida. Entretanto, se o usuário do aplicativo mantiver a
data do sistema operacional sempre anterior àquela do arquivo de licenças, de forma
proposital, a licença nunca irá expirar. Não foi observada nenhuma técnica que pudesse
impedir esse procedimento.
110
6 CONCLUSÕES
Este trabalho aborda o problema da pirataria de software e descreve como as empresas
que desenvolvem aplicativos podem, através de um recurso técnico, diminuir as cópias ilegais
dos seus produtos.
O mecanismo de licenciamento foi construído com dois módulos principais sobre a
plataforma Microsoft .NET. O mecanismo possui uma interface amigável e pode ser
facilmente integrado a aplicativos .NET que necessitem gerenciar as suas licenças. É
permitido que a empresa especifique diferentes níveis de acesso para os recursos do aplicativo
que está licenciando, e também a definição de uma data de expiração para a licença.
Foram atendidos todos os requisitos funcionais especificados, bem como o requisito
não funcional que diz respeito à facilidade de integração. Foram descritas as razões pelas
quais um dos requisitos não funcionais, sobre segurança, foi atendido parcialmente, e
sugestões foram apontadas para que este objetivo possa ser alcançado.
A tecnologia XML foi usada para o armazenamento dos dados, o que possibilitou que
o mecanismo de proteção funcionasse sem a necessidade de um servidor de banco de dados na
rede. O XML facilitou o acesso e manipulação das informações armazenadas, de modo que
ele também permitiu especificar um padrão formal para o documento de requisição enviado,
através de um schema XML.
O módulo de licenciamento acessa funções da API do Windows (platform invoke) para
obter informações de identificação do hardware que executa o módulo, o que possibilita
amarrar uma licença de software a uma determinada máquina. Estas informações são
ocultadas no arquivo de requisição de licença e na própria licença, através do algoritmo de
criptografia simétrica Rijndael.
O módulo de gerenciamento foi construído com a tecnologia ASP.NET, permitindo
que o administrador da empresa possa fazer o gerenciamento das licenças de qualquer micro
conectado na rede, através de um navegador. O ASP.NET possibilitou que o módulo de
gerenciamento, uma aplicação para a Internet, fosse desenvolvido sobre o paradigma de
orientação a objetos, utilizando uma linguagem compilada.
111
A comunicação entre os módulos ocorre através de um web service, baseado em SOAP
e XML. Estas tecnologias abstraem a implementação de um protocolo específico de
comunicação, que seria necessário, por exemplo, caso o software utilizasse o protocolo TCP
com sockets. Outra interessante vantagem na utilização de um web service é que ele permite
facilmente a adaptação do mecanismo de proteção para trabalhar sobre plataformas
heterogêneas (por exemplo, o módulo de gerenciamento em um host Windows e o módulo de
licenciamento em um host Linux). O web service também possibilita que os dados trafeguem
sobre o protocolo HTTP, que usualmente não sofre restrições de firewalls.
A segurança do mecanismo é feita através da assinatura digital XML, que é baseada na
criptografia de chaves públicas RSA. O entendimento desta tecnologia é de grande valor, não
só para o mecanismo de licenciamento deste trabalho, mas porque permite acrescentar
recursos de segurança em uma variedade de aplicações que trabalham com XML na Internet.
Os maiores desafios no desenvolvimento do mecanismo de licenciamento estiveram
relacionados ao próprio aprendizado e integração das diferentes tecnologias envolvidas.
6.1 EXTENSÕES
Nesta seção são apresentadas sugestões de extensões e modificações para este trabalho,
que estão descritas a seguir:
a) desenvolver um módulo de gerenciamento central de licenças, com o objetivo de
permitir que uma empresa adquira x licenças para uso simultâneo do aplicativo
licenciado e este módulo gerencie uma fila de utilização dessas licenças para os
vários hosts de uma rede;
b) adicionar um componente de hardware (dispositivo para porta serial, paralela ou
USB) no mecanismo de licenciamento, com o objetivo de fornecer uma camada
adicional de segurança;
c) elaborar técnicas para impedir que o código do assembly .NET seja visualizado,
modificado ou descompilado;
d) desenvolver um módulo para gerenciamento de atualizações, com o objetivo de
permitir o alerta e download de novas atualizações do aplicativo de forma segura;
e) adaptar o software para funcionamento em outras plataformas, por exemplo, Java
ou Win32 nativo.
112
REFERÊNCIAS BIBLIOGRÁFICAS
ALMEIDA, André de. Estudo da BSA afirma que 1,5 milhão de empregos seriam gerados no mundo com a redução da pirataria. [S.l], 2004. Disponível em: <http://global.bsa.org/brazil/press/newsreleases/2003-04-02.1884.phtml>. Acesso em: 19 nov. 2004.
ASSOCIAÇÃO BRASILEIRA DAS EMPRESAS DE SOFTWARE. Antipirataria. São Paulo, 2004. Disponível em: <http://www.abes.org.br/antipira/vocesaap.htm>. Acesso em: 19 nov. 2004.
BRASIL. Ministério da Ciência e Tecnologia. Lei nº 9609. Brasília-DF, 1998. Disponível em: <http://www.mct.gov.br/legis/leis/9609_98.htm>. Acesso em: 19 nov. 2004.
CRYPTO CENTRAL. SLockPK. [S.l], 2003. Disponível em: <http://www.crypto-central.com/slock/index.html>. Acesso em: 19 nov. 2004.
DOURNAEE, Blake. XML security. Emeryville: McGrawl-Hill, 2002.
DUTHIE, G. Andrew; MACDONALD, Matthew. ASP.NET in a nutshell. 2. ed. Sebastopol: O'Reilly, 2003.
EASTLAKE, Donald E.; NILES, Kitty. Secure XML: the new syntax for signatures and encryption, Boston: Addison Wesley, 2002.
FOLHA DE SÃO PAULO. Queda de 10% na pirataria poderia gerar 13 mil empregos no Brasil. São Paulo, 2003. Disponível em: <http://www1.folha.uol.com.br/folha/informatica/ult124u12623.shtml>. Acesso em: 19 nov. 2004.
GULBRANSEN, David. Special edition using XML schema. Indianapolis: Que Publishing, 2001.
HAROLD, Elliotte Rusty. Well-formed XML. [S.l.], 2004. Disponível em: <http://www.developer.com/tech/article.php/10923_797861_1>. Acesso em: 19 nov. 2004.
HISSAM, Scott A. Public key cryptography: software technology roadmap. [S.l.], 2001. Disponível em: <http://www.sei.cmu.edu/str/descriptions/publickey_body.html>. Acesso em: 19 nov. 2004.
INTEL. Support for the processor serial number feature. [S.l.], 2002. Disponível em: <http://www.intel.com/support/processors/pentium4/sb/CS-001641-prd483.htm>. Acesso em: 19 nov. 2004.
LAM, Hoang; THAI, Thuan. .NET framework essentials. 3. ed. Sebastopol: O'Reilly, 2003.
MACROVISION. SafeDisc advanced. Santa Clara, 2004. Disponível em: <http://www.macrovision.com/company/directions/index.shtml>. Acesso em: 19 nov 2004.
113
MICROSOFT. How to repair IIS mapping after you remove and reinstall IIS. Redmond, 2004. Disponível em: <http://support.microsoft.com/default.aspx?scid=kb;en-us;306005>. Acesso em: 19 nov 2004.
MONO PROJECT. Mono. [S.l], 2004. Disponível em: <http://www.mono-project.com>. Acesso em: 19 nov 2004.
MSDN. ECMA standardization. Redmond, 2004a. Disponível em: <http://msdn.microsoft.com/net/ecma/>. Acesso em: 19 nov 2004.
MSDN. Get the .NET framework 1.1. Redmond, 2004b. Disponível em: <http://msdn.microsoft.com/netframework/downloads/framework1_1/>. Acesso em: 19 nov 2004.
OTEY, Michael. New features in longhorn: WinFS, Avalon, and Indigo lead the pack. [S.l.], 2004. Disponível em: <http://www.winnetmag.com/Windows/Article/ArticleID/41986/41986.html>. Acesso em: 19 nov. 2004.
PGPI. How PGP works. [S.l.], 1999. Disponível em: <http://www.pgpi.org/doc/pgpintro/>. Acesso em: 19 nov. 2004.
RAINBOW TECHNOLOGIES. Sentinel LM. [S.l.], 2004. Disponível em: <http://www.rainbow.com/products/sentinel/sentinellm.asp>. Acesso em: 19 nov. 2004.
RAY, Erik T. Learning XML. 2. ed. Sebastopol: O'Reilly, 2003.
REMOTESOFT. Salamander .NET obfuscator. California, 2004a. Disponível em: <http://www.remotesoft.com/salamander/obfuscator.html>. Acesso em: 19 nov 2004.
REMOTESOFT. Salamander .NET protector. California, 2004b. Disponível em: <http://www.remotesoft.com/salamander/protector.html>. Acesso em: 19 nov 2004.
RICHTER, Jeffrey. Applied Microsoft .NET framework programming. Redmond: Microsoft Press, 2002.
RSA LABORATORIES. RSA laboratories frequently asked questions about today's cryptography, version 4.1. [S.l.], 2000. Disponível em: <http://www.rsasecurity.com/rsalabs/node.asp?id=2157>. Acesso em: 19 nov. 2004.
SCRIBNER, Kenn; STIVER, Mark C. Applied SOAP: implementing .NET XML web services. Indianapolis: Sams Publishing, 2001.
SEARCHSECURITY. Rijndael. [S.l.], 2003. Disponível em: <http://searchsecurity.techtarget.com/sDefinition/0,,sid14_gci523541,00.html>. Acesso em: 19 nov. 2004.
SEEBACH, Peter. The point is to be able to use the software you purchase. [S.l.], 2003. Disponível em: <http://www-106.ibm.com/developerworks/web/library/wa-cranky29.html>. Acesso em: 19 nov. 2004.
114
SIMON, Ed et al. An introduction to XML digital signatures. [S.l.], 2001. Disponível em: <http://www.xml.com/pub/a/2001/08/08/xmldsig.html>. Acesso em: 19 nov. 2004.
SRINIVAS, Davanum. What is WSDL?, [S.l.], 2001. Disponível em: <http://jguru.com/faq/view.jsp?EID=559994>. Acesso em: 19 nov. 2004.
STEWART, Heath. Using XML digital signatures for application licensing. [S.l.], 2003 Disponível em: <http://www.codeproject.com/dotnet/xmldsiglic.asp>. Acesso em: 19 nov. 2004.
VLIST, Eric van der. XML schema. Sebastopol: O'Reilly, 2002.
WIKIPEDIA. Copy prevention. [S.l.], 2004. Disponível em: <http://en.wikipedia.org/wiki/Copy_protection>. Acesso em: 19 nov. 2004.
WORLD WIDE WEB CONSORTIUM. XML-signature syntax and processing. [S.l.], 2002. Disponível em: <http://www.w3.org/TR/xmldsig-core/>. Acesso em: 19 nov. 2004.
XHEO INC. XHEO|Licesing. Temecula, 2004. Disponível em: <http://www.xheo.com/products/enterprise/licensing/default.aspx>. Acesso em: 19 nov. 2004.
