MECANISMO PARA LICENCIAMENTO DE APLICATIVOS

Transcrição

1 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 /2-32

2 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 /2-32

3 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: Membro: Membro: Prof. Marcel Hugo Orientador, FURB Prof. Francisco Adell Péricas, FURB Prof. Sérgio Stringari, FURB Blumenau, 08 de Dezembro de 2004

4 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.

5 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

6 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.

7 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.

8 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.

9 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

10 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 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 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 Figura 51 Integração do aplicativo.net com o módulo de licenciamento Figura 52 Definindo a localização do web service no arquivo de configuração Figura 53 Controle de acesso a um recurso do aplicativo Figura 54 Pastas para o módulo de gerenciamento Figura 55 Configurações do módulo de gerenciamento (Web.config) Figura 56 Definição da senha do administrador (Web.config) Figura 57 Cópia de GerenciamentoWEB para o servidor IIS Figura 58 Definição de Application name para o GerenciadorWEB Figura 59 Licença corrompida Figura 60 Licença transferida para uma máquina não autorizada Figura 61 Licença expirou...107

11 Figura 62 Erro ao ler uma versão falsa de Licenciamento.dll 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

12 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

13 SUMÁRIO 1 INTRODUÇÃO MOTIVAÇÃO OBJETIVOS ORGANIZAÇÃO DO TEXTO PROPRIEDADE INTELECTUAL E MECANISMOS DE PROTEÇÃO DESBLOQUEIO POR SENHA CONSULTADA EM MANUAL VERIFICAÇÃO DE NÚMEROS SERIAIS ATIVAÇÃO ONLINE PROTEÇÃO COM HARDWARE PROTEÇÃO COM IDENTIFICAÇÃO DO HOST LICENCIAMENTO COM ASSINATURA DIGITAL CONSIDERAÇÕES SOBRE LICENCIAMENTO DE SOFTWARE CRIPTOGRAFIA E ASSINATURAS DIGITAIS CRIPTOGRAFIA CRIPTOGRAFIA COM ALGORITMO DE RIJNDAEL ASSINATURAS DIGITAIS CRIPTOGRAFIA DE CHAVES PÚBLICAS FUNÇÕES HASH VISÃO GERAL DO PROCESSO DE ASSINATURA DIGITAL ASSINATURAS DIGITAIS XML TIPOS DE ASSINATURA DIGITAL XML SINTAXE DA ASSINATURA DIGITAL XML Elemento <Signature> Elemento <SignedInfo> Elemento <Reference> ASSINATURA XML NO.NET FRAMEWORK VERIFICAÇÃO DE ASSINATURA XML NO.NET FRAMEWORK TECNOLOGIAS UTILIZADAS MICROSOFT.NET FRAMEWORK CLR LINGUAGEM C# TECNOLOGIA ASP.NET...41

14 4.5 XML FORMAÇÃO CORRETA DO DOCUMENTO CRIAÇÃO DE UM DOCUMENTO XML NO.NET FRAMEWORK ACESSANDO O CONTEÚDO DE UM DOCUMENTO XML SCHEMAS WEB SERVICES CONCEITOS BÁSICOS DE FUNCIONAMENTO UNIVERSAL DESCRIPTION, DISCOVERY AND INTEGRATION (UDDI) WEB SERVICES DESCRIPTION LANGUAGE (WSDL) SIMPLE OBJECT ACCESS PROTOCOL (SOAP) CRIAÇÃO DE UM WEB SERVICE NO.NET CONSUMO DE UM WEB SERVICE NO.NET TRABALHOS CORRELATOS DESENVOLVIMENTO DO SOFTWARE REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO ESPECIFICAÇÃO DIAGRAMA DE CASOS DE USO DESCRIÇÃO DOS CASOS DE USO DIAGRAMAS DE CLASSES Diagramas de classes de análise Diagramas de classes de projeto DIAGRAMAS DE SEQUÊNCIA DIAGRAMA DE ATIVIDADES IMPLEMENTAÇÃO FERRAMENTAS UTILIZADAS IMPLEMENTAÇÃO DAS PRINCIPAIS FUNÇÕES DO SOFTWARE Gravação dos dados pessoais Geração do documento de requisição Obtenção das informações de hardware Armazenamento do documento de requisição Pastas do módulo de gerenciamento Protocolo de acompanhamento Assinatura da licença...81

15 Rejeição da requisição Verificação da licença Chave pública Nível de acesso OPERACIONALIDADE DA IMPLEMENTAÇÃO INTEGRAÇÃO DO MECANISMO COM APLICATIVOS.NET Geração do par de chaves Definição do nível de acesso máximo no módulo de licenciamento Instalação do.net Framework Compilação do módulo de licenciamento Integração com o aplicativo Configuração do web service Obter o nível de acesso Módulo de gerenciamento Cópia das pastas e configuração das permissões Arquivo de configuração Transferência dos arquivos RESULTADOS E DISCUSSÃO CONCLUSÕES EXTENSÕES...111

16 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 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 , 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 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 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º , 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 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 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 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 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 crackers 1 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 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 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 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 Framework 2 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 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 27 Quadro 2 Exemplo de string encriptada 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 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 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 29 <RSAKeyValue> <Modulus>3VwqPnGUgkSsAOZh5cmoq2UfrTSprOUqKYB/vuvWrcQKFM6xgts1u6fL/aiYkwXh6i9TK9C8J Cy9XO5GADfFSRhUlukhL/4/D6406SGa4CvpS+u7l5aLEdvEIyXPgY3Xde+du4QAJ6CeZsK2wz9gEKHMyoDsPqtJeup /ZNDIRi0=</Modulus> <Exponent>AQAB</Exponent> <P>92JKw/bQup50o0je0p7iMSuDsl2u7r7mYfO1GcDDcfkFNJRMANl++mHOBPxRc6HXRec+jgsFfG8ZCno B7xJWkQ==</P> <Q>5RHXE0gfsrmnZIwyLpoYNMHLIA8kaVR7ShlZWrTuklB1yT3oqTY6mUKUUpOx28YaPuFBn6GoA6l+zwX teu5b3q==</q> <DP>MY7uXW2viQM/aIqroNQVijYmbvAXoFp7+rmA2UTloop5gXwH8c+ggXZgeF030Atm/ekCfiA1HCWBhb jfdghfeq==</dp> <DQ>C3JvyAPjqZ/DcK/c1h1XNlO03d5D2IujOZm4sGK4RVGGAU95r/MIzJ3aIaJF0hC9QQUqrVp7tesjbh 8CtfwndQ==</DQ> <InverseQ>rrturwpw6OPd1W1Jshh/5Qf1SPioS0+dPwYFe7zc+Ref8sBqJPU8fRFQuv85A5ewg/gP3mYS majkbukq80awza==</inverseq> <D>y8lDosURwXPTHej6i3/BZjjslpp68o7u59JCyNN5ifOGjG1VAnEo4J+zrsx92ix6NQxod1ftPShrFJj PnPe7CL9Y/q3+KiMOW5T5e5EkT1KbkACygPw5V9w1ojk7w1KRgUsE4hrVu5r6uQKkY+NZ+9rMzlghl1W55fEKHV6Gr IE=</D> </RSAKeyValue> Quadro 5 Exemplo de chave privada RSA <RSAKeyValue> <Modulus>3VwqPnGUgkSsAOZh5cmoq2UfrTSprOUqKYB/vuvWrcQKFM6xgts1u6fL/aiYkwXh6i9TK9C8JC y9xo5gadffsrhulukhl/4/d6406sga4cvps+u7l5aledveiyxpgy3xde+du4qaj6cezsk2wz9gekhmyodspqtjeup/z NDIRi0=</Modulus> <Exponent>AQAB</Exponent> </RSAKeyValue> 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 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.

30 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 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 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 XML 3 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 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 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 33 Figura 2 Tipos de assinatura XML quanto à localização dos dados SINTAXE DA ASSINATURA DIGITAL XML O esqueleto de uma assinatura digital XML está descrito no quadro 7. <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 Quadro 7 Sintaxe da assinatura digital XML 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;

34 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 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 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 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 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 37 Quadro 9 Assinatura de um documento XML no.net 10. O resultado final do processo, que é o documento assinado, pode ser visto no quadro Quadro 10 Documento pedido.xml assinado digitalmente

38 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 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 interrelacionam 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 API 4. 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 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 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 ). O quadro 12 mostra um exemplo de código ASP.NET para apresentação de informações.

42 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 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 SGML 5, que foi estabelecida pelo W3C em 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 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 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 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 45 documento inválido. As regras de formação de um documento XML podem ser encontradas na especificação 6 da tecnologia 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

46 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 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 XPath 7. 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 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 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 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 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 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 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) 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 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 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 53 Quadro 20 Exemplo de envelope SOAP para uma resposta 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 54 Quadro 22 Arquivo web.config para o web service Depois de criados, os arquivos devem ser publicados no servidor web IIS da Microsoft 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 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 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 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 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 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 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 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. Ator Pré-condições Fluxo principal Fluxo de exceção Pós-condições Tabela 1 Caso de uso entrar com dados pessoais Usuário Nenhuma - 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. - Se o digitado for inválido, usuário precisa digitar novamente o ou deixá-lo em branco. Dados pessoais do usuário armazenados no disco

60 60 Ator Pré-condições Fluxo principal Fluxo de exceção Pós-condições Tabela 2 Caso de uso requisitar licença Usuário Nenhuma - 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. - Se não existir conectividade com o web service, exibir mensagem de erro. 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 Ator Pré-condições Fluxo principal Fluxo de exceção Pós-condições Tabela 4 Caso de uso efetuar download da licença Usuário - Requisição de licença enviada; - Licença assinada para a requisição. - 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. - Se houver um erro na transferência, exibir mensagem de erro. Arquivo de licença transferido para o aplicativo

61 61 Ator Pré-condições Fluxo principal Fluxo de exceção Pós-condições Tabela 5 Caso de uso remover licença Usuário Existência de licença para o aplicativo - 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. - Se não houver licença, exibir mensagem de erro. 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 Ator Pré-condições Fluxo principal Fluxo de exceção Pós-condições Tabela 7 Caso de uso expedir licença Administrador Requisição de licença presente no módulo de gerenciamento - 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. - Se não existir a requisição de licença no módulo de gerenciamento, a licença não poderá ser assinada. Licença assinada e disponível para download

62 62 Ator Pré-condições Fluxo principal Fluxo de exceção Pós-condições Tabela 8 Caso de uso rejeitar requisição Administrador Requisição de licença presente no módulo de gerenciamento - 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. - Se não existir a requisição de licença no módulo de gerenciamento, a requisição não poderá ser rejeitada. Requisição de licença rejeitada Ator Pré-condições Fluxo principal Fluxo de exceção Pós-condições Tabela 9 Caso de uso consultar histórico Administrador Nenhuma - 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. Nenhum Relatório sobre o histórico é exibido Ator Pré-condições Fluxo principal Fluxo de exceção Pós-condições Tabela 10 Caso de uso obter nível de acesso Aplicativo licenciado Nenhuma - 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. Nenhum Aplicativo com conhecimento sobre o nível de acesso que a licença instalada permite 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 Diagramas de classes de análise As classes de análise para o módulo de licenciamento podem ser vistas na figura 9.

63 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 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 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 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 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 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 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 68 Figura 14 Diagrama de seqüência para entrar com dados pessoais Figura 15 Diagrama de seqüência para requisitar licença

69 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 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 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 72

73 73 Figura 23 Diagrama de seqüência para obter nível de acesso 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 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 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 IMPLEMENTAÇÃO DAS PRINCIPAIS FUNÇÕES DO SOFTWARE Nesta seção serão abordadas as implementações das principais funções do software 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 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 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 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 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 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 80 Quadro 30 Função responsável por gerar o ID aleatório para a requisição 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 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 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) 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 é enviado ao usuário notificando a disponibilidade de sua licença. O quadro 33 mostra um arquivo de licença assinada.

82 82 Quadro 33 Licença assinada 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 83 Quadro 34 Requisição de licença rejeitada 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 84 Quadro 35 Verificação de um arquivo de licença 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 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. Embutila 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 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 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 86 Aplicativo, contido na solution TCC, apresentada na seção 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 29. Figura 28 Preenchimento dos dados pessoais Neste momento não existe licença e nenhuma requisição foi enviada, como mostra a

87 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 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 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 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 91 Figura 36 Lista de requisições aguardando avaliação Ao clicar no link Gerenciar, a página exibida na figura 37 é mostrada.

92 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 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 , como mostra a figura 39. Figura 39 Notificação enviada por no momento da assinatura

94 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 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 , como mostra a figura 44.

96 96 Figura 44 Notificação enviada por 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 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 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 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 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 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 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 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 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) 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 101 Figura 51 Integração do aplicativo.net com o módulo de licenciamento 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 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 102 O arquivo de configuração deve ser gravado no mesmo diretório onde está o executável do aplicativo 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 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 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 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 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) 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 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 106 Neste ponto está concluída a instalação do módulo de gerenciamento. Para acessá-lo, basta apontar para o arquivo 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 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 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 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 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