A Study in Electronic Commerce: Design

Cornell University
Computer Science Department
Masters of Engineering Project
Spring 1998

Han-Yang Lo
Sanjeev Topiwala
Joyce Wang
with assistance from Keith Sollers

Under the supervision of: Professor Fred B. Schneider
last modified: Monday, 4/27/98

System Architecture
Component Architecture
Driver Program
Network Services
File Services

System Architecture

Component Architecture

The v-óa$h system is composed of five main modules: file/data services, cryptographic services, network services, driver program, and user interface (as shown in the following illustration).

Driver Program

The driver program provides an extra layer of security by preventing direct access to the underlying subsystems. All interactions between the subsystems must pass through the driver. This provides for a smaller trusted computing base (TCB). The module categories were designed to isolate unrelated services, reducing the complexity of the overall system.

Driver Program interactions with Network Services

Network Services

Client Specific Elements

A client will support up to two socket connections at one time: one to the bank and one to a merchant.

Bank Specific Elements

The bank is considered to be a network server and as such will run around the clock. It will support an arbitrary number of client and/or merchant socket connections at one time. Each connection will be handled by an individual thread. The assumption is that the bank server is physically secure.

Merchant Specific Elements

The merchant is considered to be a network server and as such will run around the clock. It will support an arbitrary number of client socket connections and it will also support an arbitrary number of connections to the bank. Each connection will be handled by an individual thread.

Comments

All communications will occur over TCP sockets.

All communications will use the following packet format:

Packet Format

Table 1 Packet Types

Table 2 Packet Subtypes

Length

Length in bytes of the data section (including data checksum).

Header Checksum

Checksum of the data in the header.

Each side of the communication will be handled by an appropriate message packet processor. The message processor will be specific to each of the three units. The packets that need to be handled by each unit are labeled above in the packet format specification.

The following functions are implemented:

BankProcessMessage(	// process message packets received by the bank
				// and respond with a packet
				Input:		message packet
				Output:	none			)

Consumer:
	ProcessMerchantMessage(	// process message packets received from the merchant
					// and respond with a packet
					Input: message packet
					Output: none			)

	ProcessBankMessage(	// process message packets received from the bank
					// and respond with a packet
					Input: message packet
					Output: none			)

Merchant:
	ProcessConsumerMessage(	// process message packets received from the consumer
					// and respond with a packet	
					Input: message packet
					Output: none			)

	ProcessBankMessage(	// process message packets received from the bank
					// and respond with a packet
					Input: message packet
					Output: none			)

Cryptographic Services

We used Wei-Dai's Crypto++ cryptographic library. This can be found at http://www.eskimo.com/~weidai/cryptlib.html. We wrote wrappers for the functionality that we needed, and added functions to implement blinding. The following function definitions are implemented :

DESCrypto (Symmetric)
	unsigned int Encrypt(const byte *inBlock, byte * outBlock, unsigned int length);
		inBlock must have size greater than or equal to length
		outBlock must have size greater than or equal to length + 16 (because 9 to 16 bytes of padding)
		length is the amount of inBlock that will be encrypted
		return value is the number of data bytes in outBlock (including padding)

	unsigned int Decrypt(const byte *inBlock, byte * outBlock, unsigned int length);
		inBlock must have size greater than or equal to length
		outBlock must have size greater than or equal to length
		length is the amount of inBlock that will be decrypted
		return value is the number of data bytes in outBlock (because padding is removed)

DESCrypto constructor takes a char * (null terminated string) so be careful when generating random strings for symmetric encryption..

RSAPrivateCrypto and RSAPublicCrypto (Asymmetric)
	void Encrypt(const byte *inBlock, byte * outBlock, unsigned int length);
		inBlock must have size greater than or equal to length
		outBlock must have size greater than or equal to 64  (because inBlock padded to 64 bytes)
		length is the amount of inBlock that will be encrypted (must be less than or equal to 53)
	
	unsigned int Decrypt(const byte *inBlock, byte * outBlock);
		inBlock must have size equal to 64 (because 64 bytes always decrypted)
		outBlock must have size greater than or equal to 53 (because padding is removed)
		return value is the number of data bytes in outBlock (because padding is removed)

	void Sign(const byte *inBlock, byte * outBlock, unsigned int length);
		inBlock must have size greater than or equal to length
		outBlock must have size greater than or equal to 64  (because inBlock padded to 64 bytes)
		length is the amount of inBlock that will be encrypted (must be less than or equal to 53)

	unsigned int Recover(const byte *inBlock, byte * outBlock);
		inBlock must have size equal to 64 (because 64 bytes always decrypted)
		outBlock must have size greater than or equal to 53 (because padding is removed)
		return value is the number of data bytes in outBlock (because padding is removed)

	void Blind(Integer& blindingFactor, const Integer plaintext, Integer& blindtext);
		blindingFactor is initialized inside
		plaintext is the text to blind
		blindtext is the blinded text

	void SignBlind(const Integer plaintext, Integer &signtext);
		plaintext is the text to sign
		signtext is the signed text

	bool Unblind(Integer blindingFactor, const Integer plaintext, Integer& blindtext);
		blindingFactor is used to unblind text
		plaintext is the original text to compare to
		blindtext is the blinded signed text that will be unblinded
		return value: true if blindtext equals plaintext signed, false otherwise
 

Cryptographic services only communicate with the driver program. The user's RSA key pair and the bank's public keys are stored locally. The user's private key is accessed via a password generated by the user (not implemented 4/27). The bank acts as a certificate authority.

The cryptography service provides a core virtual class, with generic methods for generating prime numbers and random numbers, as well as a method for generating a checksum for a byte of data and hashing a block of data. Within this core class, we provide a separate class for each encryption algorithm (symmetric and asymmetric). Each of these classes includes methods for encryption, decryption, and key generation - a single key for the symmetric algorithm, and a key pair for the asymmetric algorithm. In addition, the asymmetric class also contains signature methods for signing and verification, as well as blinding methods.

File Services

Methods:

• Open – Open an already existing data source.
• Close – Close the open data source.
• Create – Create a new data store. (included with open 4/27)
• Write – Write the given object to the data store. (append it to the end).
• Read – Read an object from the data store.
• Copy – copy the existing data store to a new one.(not implemented 4/27)

Abstractions:

Coin – Data format for v-óa$h coins

Purse – Format for storing client coin information during execution

Methods:

• Generate purse when starting application
• Modifying the purse data
• Add entries
• Delete entries
• Make it persistent

Log – Format for storing log

Methods:

• Write to stable storage (atomic).
• Query – Methods to query the log. ((not implemented)
• Print – Print the log. (not implemented)