Pagamento Electrónico.
Dinheiro Digital.

Esquemas de Pagamento na Internet

Os pagamentos na "internet" podem ser divididos em duas categorias que sofrem tratamentos bastante difrenciados:

"Macro-Pagamentos"

Dizem respeito a transações de ordem de grandeza superior ao dolar, geralmente trata-se da aquisição de produtos, por exemplo com cartão de crédito. Este tipo de transação obriga à utilização de mecanismos apropriados de autenticação e cifragem.

"Micro-Pagamentos"

Referem-se a valores inferiores a um centimo de dolar, geralmente taxas de acesso. Devido aos valores envolvidos a segurança é geralmente pouco apertada.

"i-Key-Protocol" (iKP)

Trata-se de uma familia de protocolos (1KP; 2KP e 3KP) desenvolvida para permitir o "macro-pagamento" na "internet", totalmente vocacionados para a utilização de cartão de crédito.

Numa transação devem considerar-se as seguintes partes envolvidas:

• (C) - Cliente
• (V) - Vendedor
• (B) - Entidade Bancária do Vendedor / Entidade Emissora do Cartão de Crédito do Cliente

A entidade bancária funciona como interface relativamente a uma rede financeira que pode envolver várias outras entidades e sobre a qual os "i-Key-Protocol" não se preocupam. Nesta rede será verificado o crédito do cliente e o montante em causa será transferido.

Estas três entidades relacionam-se do seguinte modo durante uma transacção:

1. O cliente e o vendedor acordam a transacção e o cliente fornece a informação de pagamento.
2. O vendedor pede autorização à entidade bancária, fornecendo-lhe a informação de pagamento.
3. A entidade bancária autoriza e a transacção realiza-se.
4. A entidade bancária fornece a autorização ao vendedor e a transação é completada.
5. Posteriormente o emissor do cartão fornece ao cliente informação sobre a transação.

Para cada uma das partes envolvidas existem vários aspectos de segurança que serão exigidos:

Os protocolos iKP utilizam chave pública, o valor de i é substituido pelo número de entidades que tem chaves, assim:

	1KP - Apenas a entidade B tem chave pública.
	2KP - Tanto B como V têm chave pública.
	3KP - Todas as entidades B, V e C têm chave pública.

Utilizando a seguinte notação:

EI( )	Cifragem com a chave pública de I
AI( )	Assinatura (cifragem com a chave privada de I)
CI	Certificado de chave pública de I
HASH( )	Função "hash", não reversivel, com elevada resistencia a colisões
Oferta	descrição; montante; unidade monetária; data; identificação do vendedor
Encomenda	descrição; montante; unidade monetária; data; identificação do vendedor; endereço de entrega
Ordem	montante; unidade monetária; data; identificação do vendedor; número do cartão de crédito; data de validade; PIN; HASH(encomenda)
Autorização	SIM | NÃO; HASH(montante; unidade monetária; data; identificação do vendedor); HASH(encomenda)

Protocolo 1KP Apenas B necessita de chave. As trocas de dados entre entidades têm a seguinte ordem:
Envio de Dados	Dados
V para C	Oferta; CB
C para V	EB(Ordem); Encomenda
V para B	EB(Ordem); HASH(Encomenda)
B para V	AB(Autorização, EB(Ordem))
V para C	AB(Autorização, EB(Ordem))
Nota-se que a entidade B não fica a conhecer a Encomenda, apenas HASH(Encomenda), isto garante alguma privacidade ao cliente. Neste protocolo a entidade B aceita como autenticação de C os dados relativos ao seu cartão de crédito. O facto de a entidade V não se autenticar, nem perante C, nem perante B, é um ponto fraco desta versão.

Protocolo 2KP Nesta versão tanto V com B necessitam de chave. As trocas de dados entre entidades têm a seguinte ordem:
Envio de Dados	Dados
V para C	Oferta; CB; CV
C para V	EB(Ordem); Encomenda
V para B	AV(EB(Ordem); HASH(Encomenda)); CV
B para V	AB(Autorização, EB(Ordem))
V para C	AB(Autorização, EB(Ordem)); AV(EB(Ordem); HASH(Encomenda))
Além da ausência de autenticação do cliente (apenas baseada nos dados do cartão), a segurança poderia ser reforçada com algumas assinaturas adicionais, nomeadamente da oferta que poderia ser assinada por V e no envio da resposta ao cliente.

Protocolo 3KP Nesta versão todas as entidades necessitam de chave. As trocas de dados entre entidades têm a seguinte ordem:
Envio de Dados	Dados
V para C	Oferta; CB; CV
C para V	AC(EB(Ordem); HASH(Encomenda)); CC
V para B	AV(AC(EB(Ordem); HASH(Encomenda))); CC; CV
B para V	AB(Autorização, EB(Ordem))
V para C	AB(Autorização, EB(Ordem)); AV(AC(EB(Ordem); HASH(Encomenda)))
Porque a entidade V têm de retransmitir a ordem juntamente com a encomenda à entidade B, a encomenda é substituida pelo resultado da aplicação da função HASH().

Dinheiro Digital.

Pretende-se para o dinheiro digital propriedades identicas ao dinheiro corrente (notas, moedas, cheques, ...) de entre as muitas propriedades este tipo de dinheiro deve ter aceitação imediata.

Existem dois tipos de implementação:

• baseada em conta - o banco mantém uma conta, para efectuar um pagamento o sistema bancário é contactado é contactado e é realizada uma transferência entre contas. Este mecanismo é simples de implementar, contudo está muito longe dos objectivos pretendidos, nomeadamente é demasiado pesado para transacções de pequeno valor.
• baseada em "token" - o "token" representa o dinheiro, um pagamento é feito por simples entrega do "token", este mecanismo é identico ao dinheiro corrente, contudo a sua implementação informática não é simples.

Dinheiro Digital baseado em "token"

Numa primeira abordagem poderia pensar-se em algo tipo "cheque-visado", com a assinatura digital do banco. Nestas condições o cliente dirigia-se ao banco e requesitava um bloco de informação ("token") com determinado montante que lhe seria debitado da conta e sobre o qual o banco aplicaria a sua assinatura digital.

O grande problema do "token" é a facilidade de ser replicado, a fraude pode ser facilmente detectada porque não existem dois "token´s" iguais a questão é por quem, os "token's" funcionam como moedas, circulam e pode ser dificil seguir o seu percurso.

A solução é limitar o número de transacções, após X transacções as moedas ("tokens") perdem a validade, assim há garantia que as moedas regressam ao banco sem demasiada circulação.

"Micromint"

A utilização de assinatura digital pelo banco não é conveniente quando se pretende emitir uma grande quantidade de moeda ("tokens") de pequeno valor.

As moedas digitais devem ter duas caracteristicas:

O "Micromint" utiliza uma função "hash", basicamente utiliza-se como moedas conjuntos de valores de entrada que produzem o mesmo "hash code" (colisões).

É muito simples de verificar se a moeda é verdadeira, basta aplicar a função "hash" à moeda e verificar se os "hash code" são todos iguais.

É muito dificil produzir moedas, encontrar colisões numa função "hash" exige muitas tentativas, o que o banco faz é previamente produzir uma vasta tabela com pares de valores [x, hash(x)]. Procura então nesta tabela valores repetidos na segunda coluna (hash(x)) e então utiliza os respectivos valores de x para constituir uma moeda.

Uma moeda Micromint é assim um conjunto de valores (x₁, x₂, x₃, ..., x_k) que produzem todos o mesmo "hash code".