NetBill: An Internet Commerce System Optimized for Network-Delivered Service

One-line summary: This paper presents an internet electronic commerce system that uses public/private key encryption, MD-5 encryption, and a trusted third party to provide relatively strong security and authentication.

Overview/Main Points

• Components in the System: The end user's application has a NetBill stub (the checkbook), as does the merchant's (the till). A NetBill server is the third part in the transaction, and is connected to financial institutions to arrange credit, fund transfers, deposits, etc.
• Protocol:
  1. Consumer's application requests a price quote (in the clear).
  2. Merchant's application sends the quote (in the clear).
  3. Consumer's till sends a purchase request to the merchant (in the clear!?).
  4. Merchant encrypts the goods with a one-time key, computes and stores a MD5 checksum on the encrypted data, and sends the encrypted goods.
  5. Consumer's application computes it's own MD5 checksum on the goods, appends the product name, accepted price, checksum, and a timeout stamp to a message and sends the message plus a digital signature (called Electronic Purchase Order or EPO) to the merchant.
  6. The merchant verifies the cheskums and the price, and if OK, merchant appends the decryption key to the EPO, digitally signs that, and forwards it to the NetBill server.
  7. The NetBill server verifies the consumer and merchant's signatures, verifies adequate funds or credit is available, and saves the decryption key. It returns a signed receipt containing the key to the merchant (or error code). The merchant forwards the receipt to the consumer.
• Failures: At step 5 the consumer has committed to the transaction. Before then, if there are any failures, everything is ok. After then, if the consumer doesn't receive the goods, it must first check with the merchant, and if the merchant is dead, then check with the NetBill server to get the decryption key from it. After step 6, the merchant has committed to the transaction. If the EPO never makes it to the NetBill server, the EPO will time out. If it does, one must assume that the NetBill server is reliable and available, and will always respond.

Relevance

Flaws

• The NetBill server must be trusted and absolutely fault tolerant.
• Evil merchants could send garbage goods, and although the NetBill server will have an irrefutable trace of the transaction, the poor consumer could still lose out on that one transaction. Note that the merchant can never charge too much, and never gains enough info to falsify a transaction (as long as the time-out stamp is also a nonce, otherwise the merchant can do a replay attack).