Check out the new USENIX Web site. next up previous
Next: Parties and roles Up: Model and System Architecture Previous: Model and System Architecture

Security design goals

We start by identifying the basic aspects that compose the security of an e-money system.



PROTOCOL SECURITY. By this we mean liveness and safety guarantees, namely, that the protocols achieve their goals and that every participant gets its information, and is secure in the sense that the other parties which are considered adversaries do not compromise or spoil the system. This aspect is the main focus of this paper.



INTERNAL SECURITY. The security of the internal operation system of the issuer of electronic currency, its capability to withstand insider attacks and abuses. The internal network architecture, operation policies, employment of tamper-proof hardware as well as dual control measures and access-control and physical access limitations should be reviewed. The internal security architecture has to be combined with issues such as availability, reliability, load balancing and back-up requirements.



NETWORK SECURITY. The security of the network (e.g., Internet) of users and the issuer, to prevent attacks not via the protocol but rather through ``break-ins;'' these attacks exploit the lack of proper protection into the system and software holes. Careful design of the interface to the external network (firewall protection) is required. Both the internal and the network systems have to be evaluated under ``Global Security Testing,'' which includes penetration attempts and security assessment of design and implementation.



USER SECURITY. Security of the user's assets. The user must obviously protect his electronic currency, and the software and procedures supplied to the user have to provide for protection at a proper level (e.g., beyond password-only protection), but at the same time be user-friendly.

In this paper, we deal specifically with the protocol aspects and their security. In this presentation we do not cover all the protocols, but what we cover seems to capture the basic needs of the system.

For simplicity, nor do we deal with the temporal aspects of maintaining the system, such as long-term key management and cryptographic policies.


next up previous
Next: Parties and roles Up: Model and System Architecture Previous: Model and System Architecture
Juan A. Garay
7/20/1998