Lightweight security primitives for E-Commerce

  • Authors:
  • Yossi Matias;Alain Mayer;Avi Silberschatz

  • Affiliations:
  • Bell Laboratories, Lucent Technologies, Murray Hill, NJ;Bell Laboratories, Lucent Technologies, Murray Hill, NJ;Bell Laboratories, Lucent Technologies, Murray Hill, NJ

  • Venue:
  • USITS'97 Proceedings of the USENIX Symposium on Internet Technologies and Systems on USENIX Symposium on Internet Technologies and Systems
  • Year:
  • 1997

Quantified Score

Hi-index 0.00

Visualization

Abstract

Emerging applications in electronic commerce often involve very low-cost transactions, which execute in the context of ongoing, extended client-server relationships. For example, consider a website (server) which offers repeated authenticated personalized stock quotes to each of its subscribers (clients). The value of a single transaction (e.g., delivery of a web-page with a customized set of quotes) does not warrant the cost of executing a handshake and key distribution protocol. Also, a client might not always use the same machine during such an extended relationship (e.g., a PC at home, a laptop on a trip). Typical transport/session-layer security mechanisms such as SSL and S-HTTP either require handshake/key distribution for each transaction or do not support client mobility. We propose a new security framework for extended relationships between clients and servers, based on persistent shared keys. We argue that this is a preferred model for inexpensive transactions executing within extended relationships. Our main contribution is the design and implementation of a set of lightweight application-layer primitives, for (1) generating and maintaining persistent shared keys without requiring a client to store any information between transactions and (2) securing a wide range of web-transactions (e.g., subscription, authenticated and/or private delivery of information, receipts) with adequate computational cost. Our protocols require public key infrastructure only for servers/vendors, and its usage only once per client (upon first interaction).