NetCash - A promising future for internet commerce

I'm sure all businesses know that the internet provides a massive potential customer base. You've set up a successful web site with an online shop allowing customers to purchase your products with a credit card. You may have thousands of visitors per week, but how many actually purchase anything, 10%-20%. The net is predited to generate upto $50US billion dollars per year in the year 2000. But if people felt safer in purchasing products over the internet that figure could grow into the trillions! Here is where NetCash comes into play. Below is the HTML version of a MS Word document freely downloadable at the bottom of this page. This document is only a sampling of the entire system. At the moment we need technical and financial support in order to get this idea of the ground. If your a business and feel you may want to sponsor this system please feel free to leave your details below.

Safe Transfer of Funds Over the Internet

NetCash - an Introduction

Overview

By using the already proven security of PGP (Pretty Good Privacy) I intend to develop a system that will allow business to occur over the Internet without. The transfer of credit card numbers, or account information if so desired.

Users who do not wish their account information be transferred over the Internet (even with PGP encryption) would have to set up an account with the service provider (us) via other means (mail, phone, etc.) and once an account has been set up they would only need to transfer their account number and password (encrypted with PGP of course) and they’re order would be processed.

Users how feel secure enough to use PGP to encrypt their credit card details would be able to use it instantly, only with the need to send their public key to the relevant authorities.

Merchants, who wish to be able to sell their good and/or services by this system will have to set up an account with the service provider so that funds may be transferred into the merchants account directly.

During testing stages this all will be done by hand so transactions may take hours or days to complete. But at fruition all transactions will be done electronically, and therefore instantaneously (well almost).

Detailed Plan

Becoming a Merchant (Seller)

When a business want to begin selling goods and services using this new system, the business must set up an account with us (the service provider). To set up an account, a Merchant Number will be issued. When the business receives this number a new PGP public/private key pair will need to be generated, the guidelines for this key are below:

w A Diffie Hellman/DSS Key of at least 2048 bits;

w The user ID must be in the following format:

Business Name <Merchant Number>

Then the business is to submit the public key via e-mail. The PGP Key Fingerprint is to be confirmed with the Service Provider over the phone lines. Once a PGP key has been set up the transfer of account information may begin. The merchant will send the bank account details, digitally signed with the merchant’s new private key and encrypted with the Service Provider’s public key. After this has been completed the merchants account has been set up and may commence trading using the Merchant Number.

Becoming a Buyer

To become a buyer, you will also need an account similar to that of a merchant. You’ll first send your request for an account, and you’ll be given a Customer Number. Using this Customer Number you will generate a new PGP private/public key pair, the guidelines for this key pair follows:

w A Diffie Hellman/DSS Key of at least 1024 bits;

w The User ID must be in the following format:

Customer Name <Customer Number>

Once generated the public key will need to be sent to the Service Provider, and then the account details (credit card, EFTPOS account, etc.) can be transferred, by signed and encrypted mail, or via normal postal mail, which has been typed, signed using the customers private key, and printed. After this the account will be opened and the user will be informed by e-mail, and may commence using his/her account.

A Typical Transaction

A transaction will involve the sending of a transaction request, encrypted and signed between the customer, merchant, and service provider. A transaction request will look something like this below (a simple text message):

Transaction Request

Customer Number: CN12846754

Merchant Number: MN45764821

Product Name: A sample product S/N 123456

Price: 29.00 US$

Receipt Number: 764237623

Date: 01/01/99

Time: 13:05:20 GMT

Comments: Miscellaneous messages can be written here.

This would then be encrypted using the merchants public key, and signed with the customers private key. This is then sent to the merchants computer system, where it is decrypted, validated, encrypted using the Service Providers public key, and signed by the Customer & Merchant. Then sent to the service provider. The Service Provider will decrypt the message, validate both the merchants and customers signatures, and if all goes well, the funds are transferred, an encrypted message is sent back to the merchant telling it that the order is valid. The merchant will then start to dispatch the goods, or services, and send an encrypted message tot he customer indicating that their account has been debited the correct amount and their, goods or services are on the way.

Deciding Who Writes the Transaction Request

Depending on the business you may just ask for the customers, number, use the number to generate an e-mail with the other relevant details, and then e-mail the message to the customer for the signature. Or, you may let the customer write the entire request form, and sign it, there by cutting out a step.

Details

PGP v5.5 will be used to start with, until a server based application is written using the PGPsdk to automate the procedure. The Service Providers private/public key pair will be a Diffie Hellman/DSS key of 4096 bits in length (the maximum available at this time) This will prove to be the strongest link (we don’t want to be the weakest link). Ultimately the customer is the one who may be the weakest link if they only choose to generate a 1024 bit key pair. But of course everybody may chose to use a 4096 bit key pair.

The Service Provider will provide all the necessary banking facilities (credit transfers, EFTPOS transfers) to make the merchants, side of the dealing easier, and cheaper. All this time the money is absolutely safe, as the transaction will only be completed if the signatures of both the merchant and customer check out with those in the Service Providers database.

Vulnerability’s of the System

The only vulnerability of this system (as with any other public key system) is if one of the three participants (the service provider, the merchant, and the customer) lose or have their Private keys stolen (used to sign their transaction requests). Because the signatures on transaction request are acted upon as real handwritten signatures, the Private key if stolen can be used to forge your signatures. If any of the three participants have their private key compromised, they must immediately, notify the service provider, so that their account can be temporarily frozen.

When the service provider has received notice of the lost or stolen private key, the customers, or merchants account will be disabled, to prevent any misuse (the sooner the lost key is reported to less chance of having the account misused).

Once the account has been disabled, the customer or merchant can go about generating a new public/private key pair, and sending the public key to the service provider, as when setting up a new account. The old public key will be kept on record so that if it is used again we will be able to track where it is being used from, and alert the appropriate authorities.

A less likely loophole in the system, is if the merchant, does not deliver the goods, and or services, after you have paid. This will have nothing to do with the service provider and must be dealt with between the customer and merchant.

In the unlikely event that someone actually breaks you public key (so that they can then generate the matching private key), just like forging your handwritten signature, there is no way the service provider can tell if it is real or forged (because they are both real, it just depends on who is using them, you or some crook somewhere). But if you choose a large enough key the chances of someone actually reverse engineering your key is minimal, if not almost non-existent.

Example Transaction

In this example Bill want’s to buy two music CD’s from the online shop ‘Music CD Shop’, From the online form the following Transaction request is generated sent to Bill to fill in his Customer Number, Sign and send back to the merchant.

Transaction Request

Customer Number: __________

Merchant Number: MN45764821

Product Name: 2x Music CDs at $9 each

Price: 18.00 US$

Receipt Number: 42376234

Date: 01/01/99

Time: 14:34:00 GMT

Comments: Please allow 4 to 6 weeks for delivery, thankyou for shopping

at the 'Music CD Shop'

Next when Bill receives this (could be via e-mail or directly from the WWW page server, he will sign it with his private key. The signed message will appear as below:

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

Transaction Request

Customer Number: CN13462344

Merchant Number: MN45764821

Product Name: 2x Music CDs at $9 each

Price: 18.00 US$

Receipt Number: 42376234

Date: 01/01/99

Time: 14:34:00 GMT

Comments: Please allow 4 to 6 weeks for delivery, thankyou for

shopping

at the 'Music CD Shop'

-----BEGIN PGP SIGNATURE-----

Version: PGP for Business Security 5.5

Comment: Chris Vidler Software - <[email protected]>

iQA/AwUBNNrqzN+ltkrFahxgEQJV5wCcCv1t0ejdmhYpCqVT3LPLEPvUcpgAn0W4

S90nsE+wRsExQUYpmq9eg3Em

=KrZv

-----END PGP SIGNATURE-----

This signed message is then sent to the merchant how then signs the entire message (including the customer’s signature). The message signed by both the customer and the merchant will appear as below:

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

- -----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

Transaction Request

Customer Number: CN13462344

Merchant Number: MN45764821

Product Name: 2x Music CDs at $9 each

Price: 18.00 US$

Receipt Number: 42376234

Date: 01/01/99

Time: 14:34:00 GMT

Comments: Please allow 4 to 6 weeks for delivery, thankyou for

shopping

at the 'Music CD Shop'

- -----BEGIN PGP SIGNATURE-----

Version: PGP for Business Security 5.5

Comment: Chris Vidler Software - <[email protected]>

iQA/AwUBNNrqzN+ltkrFahxgEQJV5wCcCv1t0ejdmhYpCqVT3LPLEPvUcpgAn0W4

S90nsE+wRsExQUYpmq9eg3Em

=KrZv

- -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNATURE-----

Version: PGP for Business Security 5.5

Comment: Chris Vidler Software - <[email protected]>

iQA/AwUBNNrrW9SW1cfpgxxbEQIhegCg3xgTSLmEs0aTIx+f9j2t0PzNYSAAn0nC

tKPHzBMXGSDW28d9kf6bgyen

=K2Hk

-----END PGP SIGNATURE-----

The double signed message is then sent to the service provider, who processes the message in the following order:

Validates the merchant’s signature, with the merchant’s public key stored on the database.

Validates the customer’s signature, with the customer’s public key stored on the database.

If both signatures validate successfully, the order is processed (money being transferred from the customers account to the merchants account).

The message is then signed by the service provider, and sent back to the merchant.

The now triple signed message will appear as below:

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

- -----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

- - -----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

Transaction Request

Customer Number: CN13462344

Merchant Number: MN45764821

Product Name: 2x Music CDs at $9 each

Price: 18.00 US$

Receipt Number: 42376234

Date: 01/01/99

Time: 14:34:00 GMT

Comments: Please allow 4 to 6 weeks for delivery, thankyou for

shopping

at the 'Music CD Shop'

- - -----BEGIN PGP SIGNATURE-----

Version: PGP for Business Security 5.5

Comment: Chris Vidler Software - <[email protected]>

iQA/AwUBNNrqzN+ltkrFahxgEQJV5wCcCv1t0ejdmhYpCqVT3LPLEPvUcpgAn0W4

S90nsE+wRsExQUYpmq9eg3Em

=KrZv

- - -----END PGP SIGNATURE-----

- -----BEGIN PGP SIGNATURE-----

Version: PGP for Business Security 5.5

Comment: Chris Vidler Software - <[email protected]>

iQA/AwUBNNrrW9SW1cfpgxxbEQIhegCg3xgTSLmEs0aTIx+f9j2t0PzNYSAAn0nC

tKPHzBMXGSDW28d9kf6bgyen

=K2Hk

- -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNATURE-----

Version: PGP for Business Security 5.5

Comment: Chris Vidler Software - <[email protected]>

iQA/AwUBNNrscvzdfTDeAnyqEQLOIgCePMXTFzkp1KXfcSFnFGHPYCGrJksAoKF0

kfRolUJiWHIASl0CaN9IZkw4

=2XnX

-----END PGP SIGNATURE-----

Note: The PGP public keys used to make these signatures are below. You will need PGP v5 or later to be able to read the new style Diffie Hellman/DSS keys.

When the merchant receives the triple signed message it knows the transaction has been successful and proceeds to honour the order, by packing the CD’s into a box and shipping them to Bill. The merchant forwards the triple signed message to Bill for his records, and proof of his purchase. When Bill receives this message he knows that his order is on the way. He can then store the entire message and all three signatures as undeniable proof of purchase. As the message can not be altered with out recalculating the three signatures (involving three different private keys in possibley three different countries, makes this prospect nearly impossible). This way if the merchant does not deliver there will be at least two of three singatures wich will say otherwise.

Options to the System

Other options to the system may include optional encryption. Allowing encryption won’t provide any more security than the signature, but will just hide the transaction from others during transit between the three participants.

Refunds, or payments could also be made to the customer, by simply transferring a negative amount.

Further enhancements to the transaction request forms could be made, but for now the current system (as above) is adequate. Examples of enhancements may include multiple product orders in the one request, this will make multiple purchases easier to be tracked. The above example used the product name ‘2x Music CDs at $9 each’, instead of one not so clear order the transaction request may contain other orders, thus allowing more descriptive product names when more than one product is being ordered.

Closing

This system will provide merchants and customers with a cheap and secure method of transferring funds over the Internet without ever needing to send their account details over insecure channels. Customer account will be cheap to run and easy to use. PGP 5 or later will be needed to provide the cryptographic signatures needed. And the service provider and merchant software, will be written using the PGPsdk so that automated signing will increase the speed at which the system operates. This system hopefully will end the so far endless search for a secure and reliable system of transferring funds over the Internet.

Downloads

NetCash an introduction (MS Word 6, 60Kb)

Sponsorship Needed

If you or your company wishes to help us get this idea off the groud please e-mail Chris Vidler at the following address and we shall talk buisness:

[email protected]