`
`3
`
`PROCEEDINGS
`
`13TH ANNUAL
`
`COMPUTER SECURITY
`
`APPLICATIONS CONFERENCE
`
`San Diego, California
`December 8-12, 1997
`
`Sponsored by
`
`Applied Computer Security Associates
`
`in cooperation with
`
`ACM Special Interest Group on Security, Audit, and Control
`
`I
`
`COMPUTER
`SOCIETY
`
`i
`
`Los Alamitos, California
`
`Washington
`
`-
`
`Brussels
`
`-
`
`Tokyo
`.. ..
`5 wavy} A
`e P I»
`dr'.€4“!l;1_~'_q|£
`‘I
`5.: . M T If
`A
`”’=
`.-
`‘Kg’:
`'2
`I um C 23 {IRE
`
`I}
`
`.
`
`Apple Exhibit 1013
`Pace 00001
`
`V
`
`Apple Exhibit 1018
` Page 00001
`
`
`
`Copyright © 1997 by The Institute of Electrical and Electronics Engineers, Inc.
`All rights reserved
`
`to the source. Libraries may
`Copyright and Reprint Permissions: Abstracting is permitted with credit
`photocopy beyond the limits of US copyright law, for private use of patrons, those articles in this volume that
`carry a code at the bottom of the first page, provided that the per-copy fee indicated in the code is paid
`through the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923.
`
`Other copying, reprint, or republication requests should be addressed to: IEEE Copyrights Manager, IEEE
`Service Center, 445 Hoes Lane, P.O. Box 133, Piscataway, NJ 08855-1331.
`
`IEEE Computer Society Order Number PR08274
`ISBN 0-8186-8274-4
`
`ISBN 0-8186-8275-2 (case)
`ISBN 0-8186-8276-0 (microfiche)
`IEEE Order Plan Catalog Number 97TB 100213
`ISSN 1063-9527
`
`Additional copies may be orderedfrom:
`
`IEEE Computer Society
`Customer Service Center
`10662 Los Vaqueros Circle
`P.O. Box 3014
`Los Alamitos, CA 90720-1314
`Tel: + 1-714-821-8380
`Fax: + 1-714-821-4641
`E-mail: cs.books@compute1'.org
`
`IEEE Service Center
`445 Hoes Lane
`P.O. Box 1331
`Piscataway, NJ 08855-1331
`Tel: + 1-908-981-1393
`Fax: + 1-908-981-9667
`mis.custserv@computer.org
`
`IEEE Computer Society
`13, Avenue de 1’Aquilon
`B-1200 Brussels
`BELGIUM
`Tel: + 32-2-770-2198
`Fax: + 32-2-770-8505
`euro.ofc@computer.org
`
`IEEE Computer Society
`Ooshima Building
`2—19—1 Minami-Aoyama
`Minato-ku, Tokyo 107
`JAPAN
`Tel: + 81-3-3408-3118
`Fax: + 81—3—3408—3553
`tokyo.ofc@computer.0rg
`
`Editorial production by Bookmark Media
`
`Cover art production by Joe Daigle/Studio Productions
`
`Printed in the United States of America by Technical Communication Services
`
`
`
`The papers in this book comprise the proceedings of the meeting mentioned on the cover and title page. They
`reflect the authors’ opinions and,
`in the interests of timely dissemination, are published as presented and
`without change. Their inclusion in this publication does not necessarily constitute endorsement by the
`editors, the IEEE Computer Society, or the Institute of Electrical and Electonics Engineers, Inc.
`
`IEEE
`
`49
`
` COMPUTER @
`
`IEEE
`
`
`
`Page 00002
`
`Page 00002
`
`
`
`TABLE OF CONTENTS
`
`13th Annual Computer Security Applications Conference——ACSAC’97
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .ix
`
`Conference Committee .
`
`.
`
`.
`
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.x
`.x
`.x
`
`Program Committee .
`Tutorial Committee .
`.
`Reviewers .
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`TRACK A, WEDNESDAY, DECEMBER 10
`
`VIRTUAL MONEY
`
`SESSION CHAIR: K. Keus
`
`Micro-Digital Money for Electronic Co'mmeI‘ce .
`K. Nguyen,
`l/. Mu, V. Varadharajcm
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.2
`
`.
`.
`.
`.
`Secure and Efficient Digital Coins
`K. Nguyen, Y. Ma, V. Varaclliarajan
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.9
`
`. .16
`
` t
`
`The Secure Distribution of Digital Contents .
`E. van Faber; R. Hammelraz‘/1, F Heic/er
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`ASSURANCE
`
`SESSION CHAIR: J. Adams
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .24
`
`Simple Assured Bastion Hosts
`C. Cam‘, S. Wiseman
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`,
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .34
`
`Kernel and Shell-Based Applications Integrity Assurance .
`G. Mohay, J. Zellers
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .44
`
`Risk Assessment for Large Heterogeneous Systems
`J. Freeman, T. Darr, R. Neely
`
`PANEL: PRODUCT ASSURANCE .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`MODERATOR.’ J. Adams
`
`Panelists: D. Gambel, E. Weiss, M. Aldrich
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .54
`
`Page 00003
`
`Page 00003
`
`
`
`
`
`TRACK B, WEDNESDAY, DECEMBER 10
`
`FORUM: EVOLVING THE EVALUATION PARADIGM .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .56
`
`MODERATOR: M. Schanken
`
`Speakers: K. Britton, G. Copeland
`
`DATABASE SECURITY
`
`SESSION CHAIR: L. Notargiacomo
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .59
`
`Securing an Object Relational Database .
`S. Lewis, S. Wiseman
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .69
`
`Supporting Secure Canonical Upgrade Policies in Multilevel Secure Object Stores .
`S. Foley
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.81
`
`Incremental Assurance for Multilevel Applications .
`D. Thompson, M. Denz
`
`.
`
`NETWORK SECURITY
`
`SESSION CHAIR: S. LaFountain
`
`An Efficient Message Authentication Scheme for Link State Routing .
`S. Cheimg
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .90
`
`.
`
`.99
`
`Detection and Classification of TCP/lP Network Services .
`K. Tan, B. Collie
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`,
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .108
`
`.
`.
`.
`Achieving User Privacy in Mobile Networks
`B. Askwith, M. Merabti, Q. Shi, K. Whiteley
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`TRACK A, THURSDAY, DECEMBER 11
`
`PLENARY PANEL SESSION: CRITICAL INFRASTRUCTURE PROTECTION——
`THE CYBER/INFORMATION DIMENSION: REPORT ON NATIONAL
`INFRASTRUCTURE COORDINATION INITIATIVES .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`
`.
`
`.
`
`MODERATOR: S. League
`
`\
`
`Panelists: D. Keyes, D. Knauf, M. Woods
`
`GUARDS AND FIREWALLS
`
`SESSION CHAIR: E. Siarkiewicz
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .118
`
`
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .l22
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Domain and Type Enforcement Firewalls .
`K. Oostendorp, L. Badger, C. Vance, W. Morrison, D, Sherman, D. Sterne
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .133
`
`A Reference Model for Firewall Technology .
`C. Schuba, E. Spafiford
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`Using Type Enforcement to Assure a Configurable Guard .
`P. Greve, J. Hofiinan, R. Smith
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .146
`
`
`
`vi
`
`Page 00004
`
`Page 00004
`
`
`
`FORUM: ASSURANCE LESSONS LEARNED .
`MODERATOR: J. Adams
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .155
`
`Speakers: B. Dawson, D. Baker, T. Filsinger, K. Ferraiolo, R. Hefner
`
`ACCESS CONTROL
`
`SESSION CHAIR: E. Coyne
`
`.
`
`. .158
`
`Implementing-RBAC on a Type Enforced System .
`J. Hoffman
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .164
`
`Lattice Based Models for Controlled Sharing of Confidential Information in the
`Saudi Hajj System .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`T Himdi, R. Sandhu
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .175
`
`Using Kernel Hypervisors to Secure Applications .
`T Mitchem, R. Lu, R. 0’Brian.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`TRACK B, THURSDAY, DECEMBER 11
`
`SECURITY ARCHITECTURE
`
`SESSION CHAIR: J. Heaney
`
`Applying the DOD Goal Security Architecture as a Methodology for the
`Development of System and Enterprise Security Architectures .
`.
`.
`.
`.
`T. Lowmcm, D. Mosier
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .183
`
`.
`
`. .194
`
`%
`
`An Architecture for Multilevel Secure Interoperability .
`M. Kang, J. Froschei; I. Moskowitz
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .205
`
`Using Web Technologies in Two MLS Environments:A Security Analysis
`R. Niemeyer
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`CRYPTOGRAPHY AND KEY MANAGEMENT
`
`SESSION CHAIR: M. Bishop
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .216
`
`On the Key Recovery of the Key Escrow System .
`Y. Lee, C. Liah
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`Threshold and Generalized DSS Signatures without a Trusted Party .
`C. Wang, T Hwang
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .221
`
`.
`
`. .227
`
`An Improved E—Mail Security Protocol .
`B. Schneier, C. Hall
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`FORUM: PKI
`
`MODERATOR: A. Friedman
`
`Speakers: T. Burke, P. Mellinger, B. Thompson, G. Moore
`
`Vii
`
`Page 00005
`
`Page 00005
`
`
`
`TRACK A, FRIDAY, DECEMBER 12
`
`NEW SECURITY DOMAINS
`
`SESSION CHAIR: V. Reed
`
`Remote Electronic Gambling .
`C. Hall, B. Schneier
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`Ethical Responsibilities and Legal Liabilitiesof Network Security Professionals
`F Smith
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .232
`
`. .239
`
`.
`
`.251
`
`PCASSO: Applying and Extending State—Of-the—Art Security in the Healthcare Domain .
`D. Baker; R. Bamhart, '1". Buss
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`PANEL: ETHICAL RESPONSIBILITIES AND LEGAL LIABILITIES
`FOR NETWORK SECURITY COMPLIANCE
`
`MODERATOR: F. Smith
`
`Panelists: L. McCarthy, C. Byrne, S. Smaha
`
`TRACK B, FRIDAY, DECEMBER 12
`
`PANEL: TALES FROM THE DARKSIDE: A REALISTIC VIEW
`OF PROTECTING AN ORGANIZATION .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .262
`
`MODERATOR: I. Winkler
`
`Panelists: C. Kostick, F. Rica, J. Ryan
`
`SECURITY MECHANISMS
`
`SESSION CHAIR: F. Sledge
`
`Doc, Wyatt, and Virgil: Prototyping Storage Jamming Defenses .
`J. McDerm.ott, R. Gelinas, S. Ornstein.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .265
`
`. .274
`
`Protecting Unattended Computers Without Software .
`C. Lczndwehr
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`TRACK C, FRIDAY, DECEMBER 12
`
`FORUM: PROTECTING LAPTOPS .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .285
`
`MODERATOR: M. Abrams
`
`Speakers: A. Marmor—Squires, B. Ramsey, J. Trammel
`
`FORUM: INTEGRATED INFORMATION PROTECTION OPERATIONS .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .287
`
`MODERATOR: S. Hanson
`
`E. Carter, D. Allain, T. Metcalf, M. Ruhl
`
`INDEX OF AUTHORS .
`
`.
`
`.
`
`.
`
`..
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. .288
`
`viii
`
` 3lJ
`
`Page 00006
`
`Page 00006
`
`
`
`The Secure Distribution of Digital Contents
`
`Eberhard Von Faber — Robert Hammelrath — Franz—Peter Heider
`
`debis IT Security Services
`Oxfordstrafie 12- 16, 531 1 1 Bonn, Germany
`e—vonfaber@itsec—debis.de
`
`Abstract
`
`6 Pilot—System in Germany
`
`A report is given on the development of a system for
`the distribution of encrypted digital contents via freely
`accessible distribution media. To be able to use this
`information the key needed for decryption has to be
`ordered from a Key Management System. The distribution
`of the keys required for decryption is restricted whereas
`the distribution of the encrypted contents is not.‘ The key
`is sent to the customer only if suflicient payment has been
`authorised. The system described here is designed (i) to
`be independent from the method used for distribution of
`the encrypted contents,
`(ii) to support many difierent
`payment systems, (iii) to support casual customers (non-
`registered users), (iv) to avoid complicated software set-
`up, contract conclusion and registration processes, and
`(v) to support re—selling of other manufacturer’s contents
`in simple way without extra contracts. In addition, (vi) the
`system can be easily adapted to support workflow man-
`agement in a business—to—business environment.
`
`Table of Contents
`
`1 Introduction
`
`2 Security Objectives
`
`3 Simple Cryptography
`
`3.1 Structure of the Encrypted Contents
`3.2 Secure Delivery of the Content Specific Key
`3.3 Re—ordering the Content Specific Key
`3.4 Integrity of the Content Header
`4 Discussion
`
`4.1 Authenticity of the Key Management System
`4.2 Copy (Right) Protection
`5 Additional Features
`
`.
`5.1 Content Packages
`5.2 Payment Systems being Supported
`5.3 Workflow Management
`
`7 Summary
`
`8 References
`
`1
`
`Introduction
`
`Electronic commerce systems dealing with the distri-
`bution of digital contents like software or multimedia data
`have to couple the use of the provided digital goods with a
`prior payment for the goods in a way which cannot be by-
`passed. The basic idea of one possible solution is to dis-
`tribute the contents in encrypted form, and to have the
`customer pay for the key which he needs to transform the
`encrypted content in an usable form. The security problem
`can in this way be transformed into a problem of key
`distribution. An architectural design was developed which
`is independent from the use of a specific payment system
`or payment protocols. In this paper a descriptionof the
`system, the basic messages, and the software components
`will be given.
`
`In the system one can distinguish the following proc-
`esses:
`
`—
`
`—
`
`—
`
`—
`
`encryption of the content to be sold (preparation
`phase; performed once for each content),
`
`distribution of the encrypted content (using stan-
`dard methods),
`
`key distribution (usually right after receiving the
`encrypted content but only if authorisation was
`successful), and
`
`authorisation (payment; right before distributing
`the key).
`
`This system includes the following participants (refer
`to Figure 1):
`— Content Provider,
`
`— Content Distributor,
`
`— Customer,
`
`0-8186-8274-4 $10.00 © 1997 IEEE
`
`16
`
`Page 00007
`
`
`
`Page 00007
`
`
`
`— Key Management System, and
`
`- Authorisation System.
`
`the payment acquirer only (e. g. credit card) or support the
`payments by itself (e.g. electronic purse).
`
`The Content Provider provides digital contents in en-
`crypted form being distributed by the Content Distributor.
`The Key Management System holds the keys for the
`contents
`to be decrypted. The Authorisation System
`
`permits the distribution of the appropriate key after set-
`tling of the fees payable by the Customer, who will enjoy
`the decrypted digital contents. The role of the Content
`Distributor is not essential for the subsequent discussion
`but, of course, for the business to take place.
`
`2
`
`Security Objectives
`
`The system being developed shall meet the following
`requirements:
`
`1. Manipulations especially on quotation of prices and
`product information including identification of the Con-
`tent Provider are detected (integrity).
`
`2. The Content Provider (and the Content Distributor) can
`be uniquely identified to ensure that money can be dis—
`tributed correctly (identification).
`
`3. The content decryption key is transferred in a secure
`way to that Customer only who paid for it (confidentiality,
`authorisation).
`
`is guaranteed that payment has been authorised
`4. It
`before the key is sent to a customer and that money can be
`distributed to that Content Provider(s) only who created
`the content (integrity).
`
`5. It is guaranteed that the encrypted content including
`price, product
`information and identification of
`the
`manufacturer has been received by the Customer correctly
`before payment is processed (integrity, availability).
`
`6. The content decryption key can be re—ordered and
`received by that Customer only who already paid for the
`key (availability).
`
`7. The Customer only needs to participate (be registered)
`in a payment system supported. The Customer can not be
`identified by the Key Management System (anonyrnity).
`
`8. In the purchasing process the identity of the Customer
`can be disclosed only if payment acquirer (with Authori-
`sation System as front—end) cooperates with the Key
`Management System (no traceability of purchase, ano-
`nymity).
`
`These security objectives were derived from the inter-
`ests of the Customers and of the Content Providers in our
`
`pilot environment. The system also supports participation
`of profit for the Content Distributor.
`
`Additionally, the system must guarantee secure com-
`munication between (i) the Key Management System and
`the Content Providers and (ii) the Key Management
`System and the Authorisation System.
`
`In addition there are the following contractual rela-
`tions (refer to Figure 2):
`
`(and subsequently the
`- The Content Providers
`Content Distributors) must have a contract with
`the Key Management System but must trust the
`
`Authorization
`SY3l9m
`
`#6
`
`#5
`
`
`
`
`Key Management
`System
`
`Content
`Provider
`
`#2
`
`|
`
`Content
`
`Distributor
`
`
`
`
`
`
`Customer
`(End User)
`
`'
`
`Figure 1: Participants of the Systems and Illustration of
`the Purchasing Process
`
`The Content Provider is registered by the Key Man-
`agement System. The Content Provider creates the con-
`tent which is encrypted with the help of the Key Man-
`agement System (message #1 in Figure l).
`
`The encrypted content is handed over to the Content
`Distributor (#2) who provides the infrastructure for dis-
`tributing the encrypted content to the Customer.
`
`The Customer gets the encrypted content (#3). Then
`the Customer’s software contacts the Key Management
`System and requests the key (#4a) for the contents to be
`decrypted. Authorisation information (payment data, #4b)
`is routed by the Key Management System to the Authori-
`sation System (#5). The Authorisation System permits the
`distribution of the appropriate key after settling of the fees
`payable by the Customer (#6).
`
`. If the Key Management System receives a positive ac-
`knowledgement from the Authorisation System, the key is
`transferred to the Customer (#7).
`
`The Customer can decrypt the content using the key
`he has paid for. The Customer
`is registered by the
`Authorisation System only.
`
`Note that depending on the payment system used the
`Authorisation System can be an interface to the system of
`
`
`
`17
`
`Page 00003
`
`Page 00008
`
`
`
`The MAC is calculated with the Content Specific
`
`Authentication Key (KMAC) known by the Key
`Management System only.
`
`c) Encrypted contents
`
`The original content is encrypted with the Content
`Specific Encryption Key (KENC) generated by the
`Key Management System and handed over to the
`Content Provider.
`
`is a
`The Content Specific Encryption Key (KENC)
`symmetric‘ secret key which protects the contents against
`usage without payment. This key is generated by the Key
`Management System but handed over to the Content
`Provider too. During the purchasing process each Cus-
`tomer who has paid for will get the key.
`
`The hash value (HASH) can be re—calculated by the
`Customer’s software to check if the content is received
`correctly. The hash value itself is checked by the Key
`Management System later on (see next paragraph).
`
`is
`The ‘Content Specific Authentication Key (KMAC)
`available to the Key Management System only. With the
`help of the corresponding Message Authentication Code
`(MAC) the integrity of the data within the header is
`guaranteed. The header is sent to the Key Management
`System when the key is requested by the Customer; the
`integrity of the header is checked before any payment is
`processed.
`
`The Key Management System creates a public key pair
`(pKi; sKi). The public key or public key certificate (pK;) is
`received by the Customer as a part of the header in order
`to create a secure channel between the Customer and the
`
`Key Management System. The corresponding secret key
`(sK;) is available to the Key Management System only.
`
`3.2 Secure Delivery of the Content Specific Key
`
`The Content Specific Encryption Key (KENC) is gen-
`erated and registered for each content by the Key Man—
`agement System. It must be transferred both to the Con-
`tents Provider and later on to the Customer.
`
`When the encrypted content to be sold is created this
`key is handed over to the Content Provider. To protect
`this communication standard technologies using advanced
`cryptography can be used because both parties may ex-
`change public keys when setting up the contract relation.
`
`Secondly, the Content Specific Encryption Key (KENC)
`must be transferred to the Customer if payment has been
`authorised. Since the Customer is not registered by the
`Key Management System, we use a rather simple protocol
`to protect communication. The Customer generates a
`session key (Km) and encrypts this key with the public
`
`if
`ié
`
`
`
`"\ ’'ea»swéndxsm>nata3a<w»v;<(->r~2éé:«m<»qe;'')i*m74$*SS“<?€F>t1‘.~‘i~“7M€ftY$%“>§’§a>r§’Aime<«vrt”<e:*b;fi»Jm</
`
`Figure 2: Contractual Relationships
`
`It should be emphasised that the Customer must be
`sure that heis communicating with the original Key
`Management System he can rely on (see below for more
`detail).
`
`3
`
`Simple Cryptography
`
`In order to achieve high performance, widespread use
`and easy integration especially into the Customer’s envi-
`ronment (browser in case of the Internet) rather simple
`mechanisms should be used to meet the above security
`
`requirements.
`
`3.1 Structure of the Encrypted Contents
`The encrypted contents have the following structure:
`
`a) Header consisting of
`
`-
`
`—
`—
`
`price; currency; content identifier
`
`algorithm identifier; key variant
`identifier of the Content Provider
`
`- margin for Content Distributor (percentage of
`price)
`
`-
`
`—
`
`hash value (HASH) calculated over the en-
`crypted contents
`
`public key or public key certificate (pK;)
`
`b) Message Authentication~Code (MAC) calculated
`over the header (alternative: digital signature)
`
`Page 00009
`
`
`18
`
`latter that money is distributed correctly (Trusted
`Third Party, Trust Centre).
`— The Customer must have a contract with the pay-
`
`ment acquirer (may be the Authorisation System
`itself). He must trust the Authorisation System to
`co—operate with fair dealers only.
`
`
`
` .».».».-.-¢.~.-; \~;.~.~.~::¢.»:......w».~.~«-
`
`System Key Management
`
`Authorization
`
`
`
`i
`
`|
`
`Content
`
`Provider
`
`Content
`
`Distributor
`
`.,¢;=,§.~>»§;§:v,»
`contractual relationship
`
`System I
`
`Customer
`
`(End User)
`
`‘
`
`———>
`information flow
`
`
`
`Page 00009
`
`
`
`key (pK,) received together with the encrypted contents.
`The Key Management System is able to reproduce the
`Customer’s session key using the secret key (SK). As a
`result the Key Management System can send the Content
`Specific Encryption Key (KENC) in a secure way to the
`Customer.
`
`3.3 Re-ordering the Content Specific Key
`If the Content Specific Encryption Key (KENC) has not
`been received correctly by the Customer,
`it may be
`re—ordered by sending a special message to the Key Man-
`agement System. The latter stores the secured response
`messages sent to Customers recently.
`
`In order to receive the right response messages the
`Customer must identify it without disclosing his identity.
`This is done using a transaction number TNC generated
`by the Customer’s software and sent to the Key Manage-
`ment System using the technique described above. The
`Key Management System reproduces
`the transaction
`number and is therefore able to re-send the response
`message containing the Content Specific Encryption Key
`(KENC). Since this key is encrypted with the Customer’s
`session key the latter must be still available at the Cus-
`tomer’s site.
`
`3.4 Integrity of the Content Header
`
`When the encrypted contents to be sold is created the
`header information is signed by the Key Management
`System using a Message Authentication Code (MAC)
`which is attached to the header in order to guarantee the
`integrity of the data within.
`
`The header certified by the Key Management System
`is sent tothe Key Management System when the key is
`requested by the Customer. The integrity of the header is
`then checked before any payment is processed. The Con-
`tent Specific Authentication Key (KMAC)
`is available to
`the Key Management System only.
`If the Customer receives the correct Content Specific
`Encryption Key (KENC), which can easily be checked
`using some additional data, he can be sure that all data in
`the header were correct. Then he has paid the price he
`had seen for the product which is now available to him.
`
`4 Discussion
`
`4.1 Authenticity of the Key Management System
`
`It should be emphasised that the Customer should be
`sure that he is communicating with the original Key
`Management System he can rely on. Here are the risks:
`
`(i) A fake system can obtain by fraud payments and
`earn money while not providing keys for products
`of the original system.
`
`(ii)A fake system can obtain by fraud payments and
`earn money while selling useless products.
`In both cases the Customer will notice that he was
`
`cheated. Then he will go to the Authorisation System (or
`the corresponding payment acquirer) and tell
`the story.
`This is possible since the Customer has a contract with
`that instance.
`
`Note that payment information is expected to be sent
`to the Key Management System in a form which can not
`be used by it. The payment information is encrypted so
`that it can be received in a usable form by that Authorisa-
`tion System only the Customer had chosen. (Usually the
`Customer has a public key certificate of the Authorisation
`System.)
`
`This security feature of the payment system leads to
`the fact that the Authorisation System can find the fake
`Key Management System if any financial loss occurred,
`because the Key Management System is registered and
`uniquely addressed by the Authorisation System.
`
`As a result, one can conclude that no extra risk arises
`
`due to the design of the system. Hereby it has been as-
`sumed that payment can be traced back from the Cus-
`tomer via the Authorisation System to the Key Manage-
`ment System.
`
`On the other hand there are also payment systems
`which allow for anonymous, non—traceable payments.
`Examples are the electronic purse of the German Banks
`and the usage of electronic money equivalents. Here
`anonymous electronic checks are transferred where valid-
`ity can be checked but no relation can be established
`between the individual getting the check first (by paying
`real money) and the one Cashes the check later on (to get
`real money).
`
`So, there are two reasons to further improve the sys-
`tem (i) it might be unpleasant to contact the Authorisation
`System to complain about cheats (bad payments) and
`(ii) there are payment systems which allow for anony-
`mous, non—traceable payments.
`
`As a consequence, it is advantageous to include public
`key certificates (pKi)
`instead of public keys into the
`header. Then the Customer can check in advance whether
`
`he is willing to trust the Key Management System he is
`asked to contact.
`
`
`
`19
`
`Page 00010
`
`Page 00010
`
`
`
`4.2 Copy (Right) Protection
`
`5 Additional Features
`
`Copyright protection is discussed in two directions.
`Originally copyright means that the creator or proprietor
`of the content can be uniquely identified. But treatment of
`such content including copying is restricted by law only.
`Watermarks identifying the Content Provider can be
`integrated into digital contents for that. In the electronic
`world illegal copying or usage can in general neither be
`restricted nor traced back. Watermarking identifying the
`Customer is not possible.
`
`We use static symmetric keys to protect the contents
`against unauthorised usage. It may be well questioned
`whether this will induce sufficient security in a realistic
`environment. Neither this simple method nor any other
`we know protects reliably the distributed contents against
`unlawful copying once it is decrypted to clear informa-
`tion.
`
`However, the system can establish a link to the legiti~
`mate Customer who has paid for the content or more
`precisely for a license to use the content, and to distin—
`guish her/him from the illegitimate who cannot prove
`herself/himself that such a link to the information pro-
`vider existed. But then the system is not independent from
`the application actually using the content or must be
`supported by the operating system.
`On the other hand the system is obviously open to im-
`provements by using secure environments which can
`prevent the unauthorised export of clear contents or the
`like. Such security modules must have secret identifiers or
`keys. These data are used by the Key Management System
`for authentication, other instances may contact the Key
`Management System but will never receive the correct
`Content Specific Encryption Key (KENC). In this way it
`can be guaranteed that neither the key nor the plain
`contents can illegally be exported. Regarding the security
`modules as trusted environment one may think of further
`developed and enhanced set-top boxes or special drives.
`
`In order to be able to integrate security modules on the
`Customer’s site, the protocol and the cryptographic op-
`erations were designed to be as simple as possible. But
`adaptation requires additional efforts, the worth of which
`has to be decided upon by the Content Provider.
`
`At present we plan to distribute low price products for
`the mass market where the existence of some illegal
`copies might not be a problem. Professionals which may
`cause significant financial losses must offer the products
`on the public market. Hence the risk of being made re-
`sponsible is high. To summarise we regard the level of
`protection achieved till now as-being sufficient for our
`market.
`
`5.1 Content Packages
`
`As already mentioned we plan to distribute low price
`products for the mass market. Examples are still pictures
`(photos, cliparts) for the commercial use by advertising
`agencies and publishing houses. At present the sale of
`such pictures is often carried out with the help of printed
`catalogues and standard payments. Here our system helps
`to turn that process to be more efficient.
`
`Companies may use contents purchased electronically
`to create other products (packages, e. g. catalogues, books)
`which are then offered for sale on the market. Obviously,
`the Customer who purchased the whole package gets parts
`of that catalogue (single pictures) too. But the Content
`Providers of that parts must get fees. To sign contracts
`and to manually exchange quantities being sold is not a
`workable way in the electronic commerce framework. The
`money must be automatically transferred to all Content
`Providers having a content in the package. This can be
`done as follows.
`
`The package is created by adding other manufacturer’s
`contents (let say: loan contents) to new components. The
`header is added for the package. Along with the informa-
`tion described above this header describes the structure of
`
`the package in form of a directory: It contains references
`to the loa