A geração da assinatura

UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA
CURSO DE CIÊNCIAS DA COMPUTAÇÃO
Dispositivo móvel para geração de
assinaturas digitais curtas
Andrey Morais Brüggemann
0313203-0
Florianópolis – SC
2007/1
Sumário
Introdução.......................................................................................................3
Objetivo ..........................................................................................................5
Assinatura Digital ............................................................................................6
A geração da assinatura..............................................................................7
A verificação da assinatura .........................................................................8
Digital Signature Algorithm..............................................................................9
Geração da assinatura ................................................................................9
Verificação da assinatura .......................................................................... 11
Secure Hash Standard ..................................................................................12
Advanced Encryption Standard .....................................................................13
Java2 Micro Edition ......................................................................................14
Configuração.............................................................................................15
Connected Limited Device Configuration ...............................................15
Connected Device Configuration ...........................................................16
Perfil..........................................................................................................16
Referências Bibliográficas ................................................................................................................. 17
Introdução
Normalmente, para se poder acessar este tipo de sistema, deve ser que fornecidos
um nome de usuário cadastrado no sistema e a senha associada a este usuário, para se
poder autenticar no sistema e então utilizá-lo. O nome de usuário normalmente é de
acesso público, ou seja, qualquer outra pessoa além do dono pode saber, enquanto que a
senha deve ser de conhecimento apenas de seu dono. Uma vez verificada a
concordância entre a senha e o nome de usuário, fornecidos, obtém-se acesso ao
sistema.
Nesta autenticação, tem-se um fator de autenticação, a senha. Somente ela
garante que quem esta entrando no sistema com um dado nome de usuário é realmente o
dono deste nome, ou seja, é a senha que garante a identidade do usuário. Esta
segurança pode ser facilmente quebrada, bastando que alguém veja um outro digitando
sua senha e a grave, ou capture o envio da senha pela rede e a leia, para poder entrar no
sistema fingindo ser o verdadeiro dono da senha, já que o nome de usuário e público e
pode ser facilmente obtido.
Apesar da insegurança que se tem quando apenas a senha é utilizada, esta é
muitas vezes suficiente, principalmente em sistemas em que poucas informações do
usuário são manipuladas. Porém há sistemas em que a segurança na autenticação é
primordial, ou seja, deve-se ter certeza de que quem está realizando as operações no
sistema é realmente a pessoa autenticada, pois praticamente toda informação manipulada
é confidencial. Como exemplo de situação onde a segurança na troca de informação é
primordial, pode-se citar as transações bancárias.
Um outro problema está no caminho de troca de informações. Ao menos que se
garanta a privacidade do caminho que se utiliza para trocar as informações, ou seja, que
ninguém compartilha deste caminho além do usuário e o sistema, toda informação
trocada entre o usuário e o sistema pode ser capturada no meio do envio, e então ser
alterada e enviada ao destino. O problema de interceptação uma informação trocada está,
não somente em se poder ler esta informação, mas também em se poder alterá-la em
envia-la ao destino. Isso se agrava ainda mais com o uso da internet como meio de
transmissão, o acesso à rede é público.
A fim de resolver o problema de interceptação, surgiram as tecnologias de chaves,
como chaves simétricas e chaves assimétricas, e também de cifragem de dados. Ainda,
devido a fragilidade do uso de apenas a senha como fator de autenticação, como,
assinatura digital e certificado digital, que se utilizam da tecnologia de chaves
assimétricas. É possível, inclusive, que mais de um destes fatores passa ser utilizado ao
mesmo tempo.
Objetivo
Implementar um dispositivo móvel de autenticação, utilizando assinatura digital
curta de 32 bits, baseada no Digital Signature Algorithm (DSA), usando JAVA 2 Micro
Edition (J2ME) como plataforma de desenvolvimento e tendo o celular como hardware de
execução. O dispositivo deverá suportar:

Geração dos parâmetros do DSA.

Geração de assinatura curta, usando algoritmo DSA adaptado.

Cifragem e decifragem, usando AES.

Armazenamento dos parâmetros do DSA.
Assinatura Digital
Normalmente para se demonstrar a aceitação do conteúdo de um documento, por
exemplo um contrato, tem-se que escrever uma assinatura sobre este documento. A
assinatura de um indivíduo é única, dependente da caligrafia de cada um. Como a
assinatura está presente nos documentos de identificação, alguém com posse, por
exemplo, da carteira de identidade de quem assinou o documento, pode conferir a
autenticidade da assinatura. Da mesma forma, se a assinatura de uma certa pessoa está
presente em um documento, ela não pode negar que assinou, salvo os casos em que há
falsificação.
A assinatura digital é uma forma de autenticação análoga a assinatura manuscrita
de um indivíduo, utilizada para assinar mensagens, estas podendo ser tanto mensagens
de e-mail propriamente ditas quanto arquivos. Basicamente , uma assinatura digital nada
mais é do que uma seqüência de dígitos binários, gerada por um algoritmo
computacional.
A assinatura digital proporciona características de segurança tais como:

Autenticação: o receptor da mensagem pode confirmar a identidade do signatário.

Integridade: o receptor pode verificar se a mensagem recebida é a mesma enviada
pelo signatário, ou seja, se ela foi ou não alterada durante o envio.

Não-repúdio: tendo assinado uma mensagem, o signatário não pode negar que
realizou a assinatura.
Os esquemas de assinatura digital normalmente são compostos dois processos,
uma para a geração da assinatura e outro para a verificação da mesma, ambos
envolvendo algoritmos de cifragem assimétrica e hash.
A geração da assinatura
Para gerar uma assinatura primeiramente o remetente obtém o código hash da
mensagem a ser enviada. Este código é obtido através de uma algoritmo de hash, o qual
retorna uma saída de tamanho fixo e pequeno, para qualquer que seja a mensagem de
entrada.
Então, o hash calculado é cifrado usando a chave privada do remetente, a qual
deve ter sido previamente gerada.
Este hash, agora cifrado, é a assinatura digital
propriamente dita. O rementente da mensagem, o qual gerou a assinatura passa a ser
chamado signatário.
Por fim, a assinatura digital é enviada juntamente com a mensagem original para
para o destinatário, que pode assim verificar a autenticidade do remetente bem como a
integridade da mensagem que recebeu.
A verificação da assinatura
Figura 1.: Processo de geração da assinatura
Para que seja possível que o destinatário verifique ele deve ter recebido
previamente a chave pública do signatário da mensagem. Normalmente este envio é feito
através de certificados digitais, para que haja uma garantia de que a chave pública
recebida é realmente do remetente, signatário da mensagem.
Tendo a chave pública, a assinatura a mensagem recebidos, o destinatário decifra
a assinatura digital, obtendo o possível código hash da mensagem. Depois, da mesma
forma que acontece no processo de geração, é calculado o código hash da mensagem
recebida.
Por fim, os dois códigos hash obtidos são comparados. Se iguais, então a
assinatura e a mensagem são consideradas válidas, caso contrário, inválidas. A
invalidade por ocorrer por diversos motivos, como corrupção da informação durante o
envio ou tentativa de ataque malicioso.
Figura 2: Processo de verificação da assinatura
Digital Signature Algorithm
O Digital Signature Algorithm (DSA) é um algoritmo de assinatura digital proposto
pelo NIST (National Institute of Standards and Technology)
como integrante de seu
padrão para assinaturas digitais, o Digital Signature Standard (DSS), em agosto de 1991.
Ele foi publicado em maio de 1994, na FIPS-186 (Federal Information Processing
Standard). Em 1998, foi publicada a FIPS-186-1, que adicionou o algoritmo rDSA (Digital
Signatures Using Reversible Public Key Cryptography ) , especificado pelo ANSI X9.31.
Posteriomente, em 1999, uma nova alteração foi feita e publicada na FIPS-186-2, a qual
adicionou o algoritmo ECDSA (Elliptic Curve Digital Signature Algorithm), definido pelo
ANSI X9.62.
O algoritmo das utiliza chaves de tamanho entre 512 e 1024 bits, porém esta
limitação está para ser mudada através de uma nova revisão do NIST, a FIPS-186-3, que
está em fase de rascunho. Esta nova publicação estabelece tamanhos de chave como
2048 e 3072 bits.
Geração da assinatura
O primeiro passo do algoritmo é a geração dos parâmetros, chamados parâmetros
de domínio. Antes da geração dos parâmetros algumas decisões devem ser tomadas:

Escolher um algoritmo de hash H. No DSS original o algoritmo SHA-1 é utilizado
por padrão, porém como surgiram algoritmos de hash mais avançados, pode-se
utilizá-los, bastando truncar a saída para o mesmo tamanho da saída do SHA-1.

Escolher o tamanho L da chave a ser utilizada. Segundo o padrão original, o
tamanho deve ser um múltiplo de 64, entre 512 e 1024. Com a definição da FIPS196-3, esta tamanho poderá ser maior.
Tomadas as decisões, deve-se gerar os seguintes parâmetros:

p: um primo de tamanho L.

q: um primo divisor de p-1, com número de bits igual a saída da função hash
escolhida.

g: um número calculado pela fórmula g = h(p-1)/q mod p, onde h é qualquer número
menor que p-1 e h(p-1)/q mod p > 1

x: um inteiro aleatório, tal que 0 < x < q.

y: calculado pela fórmua y = gx mod p.

k: um inteiro aleatório, tal que 0 < k < q. Este parâmetro deve ser único por
mensagem.
Os parâmetros p, q, g são públicos. O parâmetros y é a chave pública e x a chave
privada. O parâmetro k é secreto e deve ser gerado novamente a cada geração de
assinatura.
A geração da assinatura para uma mensagem M consiste no cálculo de dois
números r e s tal que:

r = (gk mod p ) mod q

s = (k-1(H(M)+xr)) mod q. H(M) representa a saída da função hash H tendo como
entrada a mensagem M.

Se r = 0 ou s = 0, então o parâmetro k deve ser gerado novamente e r e s devem
ser calculados de novo.
A assinatura resultante é a união dos parâmetros r e s. Como r tem 160 bits e s
também, então a assinatura gerada possui 320 bits.
Os números k e r, bem como k-1, poderiam ser pré-calculados, pois não dependem
da mensagem a ser assinada, acelerando desta forma a geração da assinatura.
Verificação da assinatura
Para poder verificar a assinatura, o verificador deve possuir os parâmetros p, q, g e
a chave pública do signatário. Isto pode ser feito de forma segura através de um
certificado digital, assinado por alguém confiável.
Sendo M1, r1 e s1 as informações recebidas pelo verificador, a verificação da
assinatura ocorre da seguinte maneira.

São verificadas as condições 0 < r1 < q e 0 < s1 < q . Se uma das condições não
for satisfeita, então a assinatura é considerada inválida. Caso contrário
prosseguem os seguintes passos:

Calcula w = (s1)-1 mod q

Calcula u1 = (H(M1)*w) mod q

Calcula u2 = (r1*w) mod q

Calcula v = ((gu1*yu2) mod p) mod q
Se v = r1 a assinatura é válida. Caso contrário, inválida.Secure
Hash
Standard
O Secure Hash Standard (SHS) é um padrão adotado pelo NIST que especifica um
conjunto de algoritmos de função de hash, chamados de Secure Hash Algorithm (SHA). A
primeira publicação do padrão, o FIPS-180-1, continha apenas o algoritmo SHA-1.
O algoritmo SHA-1 suporta entradas de tamanho até 264 bits, retorna um hash com
tamanho fixo de 160 bits. Este algoritmo foi criado especialmente para servir o das e teve
como base o MD4. O uso do SHA-1 no DSA se faz necessário para aumentar o
desempenho do algoritmo, já que assinar o hash da mensagem é muito mais rápido que
assinar a mensagem em si, pois o tamanho do hash é muito menor.
Em 2002, foi lançada a FIPS-180-2, pelo NIST, adicionando um novo conjunto de
algoritmos ao padrão, os quais ficaram conhecidos como família SHA-2. Três novos
algoritmos foram adicionados nesta publicação, sendo eles o SHA-256, SHA-384 e SHA512, grando códigos hash de 256, 384 e 512 bits, respectivamente. Depois, em 2004, um
novo algoritmo foi acrescentado, o SHA-224, que gera saídas de 224 bits. A criação de
novos algoritmos se fez necessária para compatibilizar com os novos algoritmos
criptográficos que surgiram.
Foi divulgado, em 2005, um ataque ao SHA-1 que diminuiria o esforço em
aproximadamente 269 operações para encontrar uma colisão, ou seja, duas mensagens
gerando o mesmo hash, sendo que o requerido para o SHA-1 ser considerado seguro
eram 280 operações. Desde então o NIST tem recomendado a troca do SHA-1 por algum
algoritmo da família SHA-2.
Segundo a FIPS-180-2 CHANGE NOTICE 1, em casos onde é necessário um hash
de menor que saída de um algoritmo SHA-2, pode- truncar a saída algoritmo tomando os
bits mais à esquerda como hash.
Advanced Encryption Standard
Em 1997, o NIST iniciou sua procura por um novo algoritmo de cifragem simétrica,
que service como substituto do DES (Data Encryption Standard). O DES era
recomendado pela instituição desde 1977, publicado na FIPS PUB 46, mas acabou sendo
considerado inseguro devido aos vários anúncios de ataques realizados sobre ele.
Um dos substitutos propostos foi o algoritmo Rijndael, criado por Joan Daemen e
Vincent Rijmen. Este algoritmo usa uma rede de permutação e substituição em lugar da
rede de Feistel, como ocorria no DES. Isto o tornava mais rápido e simples de ser
implementado. O Rijndael aceita diversos tamanhos de chave e bloco, podendo ser
qualquer múltiplo de 32, entre 128 e 256.
Após algumas modificações, o Rijndael, foi publicado em 2001, na FIPS-197, como
um novo padrão para cifragem simétrica, com o nome de Advanced Encryption Standard
(AES). O AES suporta chaves de 128, 192 ou 256 bits e blocos de 128bits, ao contrário
do Rijndael original, que aceitava um maior número de tamanhos diferentes, tanto para a
chave quanto para o bloco.
Java2 Micro Edition
O Java2 Micro Edition (J2ME), é uma variação da plataforma Java surgida em
1999, como uma iniciativa da empresa Motorola, que uni-se a Sun para produzir uma
plataforma que promovesse portabilidade às suas aplicações de celulares. Mais que
somente a celulares, a plataforma J2ME visa atender qualquer dispositivo com recursos
limitados de processamento, memória e rede, tais como PDAs (Personal Digital
Assistants) , set-top-boxes, utilizados nos sistemas de TV digital, e celulares.
Diferente dos outros padrões, como J2SE e J2EE, os quais se dedicam a
equipamentos com capacidades semelhantes, o J2ME tem de atender as mais variadas
configurações de hardware, as quais na maioria das vezes não podem ter sua capacidade
estendida, como o que ocorre com os computadores pessoais.
Devido a isto o J2ME não possui uma única distribuição e sim várias subdivisões
destinadas a atender um conjunto específico de dispositivos. Estas subdivisões ocorrem
em dois níveis diferentes: a configuração, num nível mais baixo ou básico, e o perfil.
Figura 3: Arquitetura do J2ME
Configuração
A divisão por configuração leva em conta o hardware presente no dispositivo, ou
seja, capacidade que o este possui em termos de processamento, memória e acesso à
rede. Ela define as características da máquina virtual que irá atender o dispositivo e
também as classe básicas do Java que estarão disponíveis.
Atualmente há duas configurações definidas, a Connected Limited Device
Configuration (CLDC) e a Connected Device Configuration (CDC) .
Connected Limited Device Configuration
A CLCD define uma plataforma mínima para que a máquina virtual possa operar, e
um quantidade pequena de classe básicas da plataforma Java. Exemplos típicos de
dispositivos CLCD são os PDAs e os celulares. Por este motivo, muitas vezes a CLCD é
chamada Java Wireless, referenciando a capacidade do usuário poder baixar pela rede
pequenos aplicativos Java, chamados MIDlets, e executá-los no dispositivo.
As características, quanto a capacidade dos dispositivos CLCD são as seguintes:

160kB a 512kB de memória disponível para a plataforma Java.

Processador de 16 ou 32 bits.

Baixo consumo de energia. Normalmente estes dispositivos utilizam bateria.

Suporte a algum tipo de conexão com um rade. Geralmente esta conexão é
intermitente, com baixa taxa de tranferência, próxima a 9600 bps, e sem fio
(wireless).
A máquina virtual utilizada pela CLCD é a Kilobyte Virtual Machine (KVM). A KVM é
uma máquina virtual limitada, que utiliza pouca memória, algo entre 40kb a 80 kb, o que a
torna muito adequada aos dispositivos CLCD.
Connected Device Configuration
A CDC se destina à dispositivos com mais recursos que a CLCD. Ela requer pelo
menos 2Mb de memória para a plataforma Java. A máquina virtual utilizada é a C-Virtual
Machine (CVM), a qual implementa todas as funcionalidades da máquina virtual padrão,
contida no J2SE, com algumas diferenças na implemntação. Exemplos de dispositivos
CDC são os Pocket PCs, gateways residenciais e set-top-boxes utilizados na transmissão
de TV digital.
Perfil
O perfil está associado as funcionalidades que o dispositivo apresenta. Ele define o
conjunto de APIs implementadas pelo dispositivo. Há dispositivos com mesma
capacidade, isto é, de uma mesma configuração, que implementam diferentes perfis. Os
dispositivos suportado por um determinado perfil tente a ter uma aplicabilidade parecida.
O primeiro perfil especificado pela Sun, lançado em 2000, foi justamento o que
estabelece o modelo de aplicação e as APIs para os telefones celulares. Este perfil é o
Mobile Information Device Profile (MIDP), cuja tradução é Perfil para terminais móveis de
Informação. Estre as características definidas pelo MIDP estão:

um modelo de aplicação similar ao Applet, chamado MIDlet

APIs de acesso à tela do telefone

APIs de acesso à rede.

APIs para salvar dados locais

uma estrutura para baixar, instalar e rodar aplicações.
Apesar de outros perfis terem sido definidos, o MIDP é o mais
utilizado no desenvolvimento de aplicações para celular.
Atualmente ele se encontra na versão 2.0, mas uma nova
especificação, MIDP 3.0, já está em andamento.Referências
Bibliográficas
NIST FIPS 180-2.Secure Hash Standard. Federal Information Processing Standards.
National Institute of Standards and Technology. FIPS PUB 180-2 (+Change Notice to
include SHA-224), 2004.
NIST FIPS 186-2. Digital Signature Standard. Federal Information Processing Standards.
National Institute of Standards and Technology. FIPS PUB 186-2, 2000.
NIST FIPS 197. Advanced Encryption Standard (AES). Federal Information Processing
Standards. National Institute of Standards and Technology. FIPS PUB 197, 2001.
MENEZES, A., OORSCHOT, P. C. e Vanstone, S. A. Handbook of Applied Cryptography,
CRC Press, 1996.
WHITE, James; HEMPHILL, David. Java 2 Micro Edition: Java in Small Things. Greewich:
Manning, 2002.
JAVA MAGAZINE. Rio de Janeiro: Devmedia, 2007. Edição 44.
MUNDO JAVA. Rio de Janeiro: Mundo, 2007. Número 16.