`
` “3'3“?““cckw\
`
`
`
`3
`?
`
`1
`
`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
`
`IEEE®
`COMPUTER
`SOCIETY
`
`0
`
`Los Alamitos, California
`
`Washington
`
`0
`
`Brussels
`
`0
`
`Tokyo
`
`Apple Exhibit 1120 Page 00001
`
`Apple Exhibit 1120 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, PO. Box 133, Piscataway, NJ 08855-1331.
`
`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 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
`PO. Box 3014
`Los Alamitos, CA 90720-1314
`Tel: + 1-714—821-8380
`Fax: + 1-714—821—4641
`E-mail: cs,books@computer.org
`
`IEEE Service Center
`445 Hoes Lane
`PO. Box 1331
`Piscataway, NJ 08855-1331
`Tel: + 1-908-981—1393
`Fax: + 1-908-981—9667
`miscustserv@computer.org
`
`IEEE Computer Society
`13, Avenue de l’Aquilon
`8—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
`t0kyo.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
`
`f:
`
`
`
`
`
`
`
`
`
`
`
`
`IEEE
`
`0
`
`' COMPUTER @
`
`SOCIETY
`
`
`
`
`
`Page 00002
`
`Page 00002
`
`

`

`TABLE OF CONTENTS
`
`13th Annual Computer Security Applications Conference—ACSAC’97
`
`Conference Committee ..................................................................... ix
`
`Program Committee ........................................................................ x
`Tutorial Committee ......................................................................... x
`Reviewers ................................................................................ x
`
`TRACK A, WEDNESDAY, DECEMBER 10
`
`VIRTUAL MONEY
`
`SESSION CHAIR: K. Keus
`
`Micro-Digital Money for Electronic Commerce ................................................... 2
`K. Nguyen, Y. Mu, V. Varadharajan
`
`Secure and Efficient Digital Coins ............................................................. 9
`K. Nguyen, Y. Mu, V. Varadlzarajan
`
`The Secure Distribution of Digital Contents ..................................................... 16
`E. van Faber; R. Hammelraz‘h, F. Heider
`
`ASSURANCE
`
`SESSION CHAIR: J. Adams
`
`Simple Assured Bastion Hosts ............................................................... 24
`C. Cant, S. Wiseman
`
`Kernel and Shell-Based Applications Integrity Assurance ........................................... 34
`G. Mohay, J. Zellers
`
`Risk Assessment for Large Heterogeneous Systems ............................................... 44
`J. Freeman, T. Darr, R. Neely
`
`PANEL: PRODUCT ASSURANCE ........................................................... 54
`
`MODERATOR: J. Adams
`
`Panelists: D. Gambel, E. Weiss, M. Aldrich
`
`Page 00003
`
`
`
`
`E t
`
`Page 00003
`
`

`

`
`
`TRACK B, WEDNESDAY, DECEMBER 10
`
`FORUM:EVOLVINGTHEEVALUATIONPARADIGM
`
`....... 56
`
`MODERATOR: M. Schanken
`
`Speakers: K. Britton, G. Copeland
`
`DATABASE SECURITY
`
`SESSION CHAIR: L. Notargiacomo
`
`Securing an Object Relational Database ........................................................ 59
`S. Lewis, S. Wiseman
`
`Supporting Secure Canonical Upgrade Policies in Multilevel Secure Object Stores ........................ 69
`S. Foley
`
`Incremental Assurance for Multilevel Applications ................................................ 81
`D. Thompson, M. Denz
`
`NETWORK SECURITY
`
`SESSION CHAIR: S. LaFountain
`
`An Efficient Message Authentication Scheme for Link State Routing ..................................90
`S. Chenng
`
`Detection and Classification of TCP/iP Network Services ........................................... 99
`K. Tan, B. Collie
`
`Achieving User Privacy in Mobile Networks ................................................... 108
`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 ........................................... 118
`
`MODERATOR: S. League
`
`.
`
`Panelists: D. Keyes, D. Knauf, M. Woods
`
`GUARDS AND FIREWALLS
`
`SESSION CHAIR: E. Siarkiewicz
`
`Domain and Type Enforcement Firewalls ...................................................... 122
`K. Oostendorp, L. Badger, C. Vance, W. Morrison, D. Sherman, D. Sterne
`
`A Reference Model for Firewall Technology .................................................... 133
`C. Schuba, E. Spafi‘ord
`
`Using Type Enforcement to Assure a Configurable Guard .......................................... 146
`P. Greve, J. Hofi‘inan, R. Smith
`
`
`
`
`
`Page 00004
`
`Page 00004
`
`

`

`FORUM: ASSURANCE LESSONS LEARNED ................................................. 155
`MODERATOR: J. Adams
`
`Speakers: B. Dawson, D. Baker, T. Filsinger, K. Ferraiolo, R. Hefner
`
`ACCESS CONTROL
`
`SESSION CHAIR: E. Coyne
`
`Implementing-RBAC on a Type Enforced System ..................................... _. .......... 158
`J. Hoffman
`
`Lattice Based Models for Controlled Sharing of Confidential Information in the
`Saudi Hajj System ..................................................................... 164
`T. Himdi, R. Sand/m
`
`Using Kernel Hypervisors to Secure Applications ................................................ 175
`T Mitchem, R. Lu, R. O’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 .................................... 183
`T. Lowmcm, D. Mosier
`
`An Architecture for Multilevel Secure Interoperability ............................................ 194
`M. Kang, J. Fmschel; I. Moskowitz
`
`Using Web Technologies in Two MLS EnvironmentszA Security Analysis ............................. 205
`R. Niemeyer
`
`CRYPTOGRAPHY AND KEY MANAGEMENT
`
`SESSION CHAIR: M. Bishop
`
`On the Key Recovery of the Key Escrow System ................................................ 216
`Y. Lee, C. Liah
`
`Threshold and Generalized DSS Signatures without a Trusted Party .................................. 221
`C. Wang, T Hwang
`
`An Improved E-Mail Security Protocol ........................................................ 227
`B. Schneier, C. Hall
`
`FORUM: PKI
`
`MODERATOR: A. Friedman
`
`Speakers: T. Burke, P. Mellinger, B. Thompson, G. Moore
`
`Vii
`
`Page 00005
`
`
`
`
`E E gE EE
`
`Page 00005
`
`

`

`TRACK A, FRIDAY, DECEMBER 12
`
`NEW SECURITY DOMAINS
`
`SESSION CHAIR: V. Reed
`
`Remote Electronic Gambling ............................................................... 232
`C. Hall, B. Schneier
`
`Ethical Responsibilities and Legal Liabilitiesiof Network Security Professionals ........................ 239
`F. Smith
`
`PCASSO: Applying and Extending State—of—the—Art Security in the Healthcare Domain ................... 251
`D. Baker; R. Barnhart, T. 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 ..................................... 265
`J. McDermott, R. Gelinas, S. Omstein.
`
`Protecting Unattended Computers Without Software .............................................. 274
`C. Landwehr
`
`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
`
` gll
`
`Page 00006
`
`Page 00006
`
`

`

`The Secure Distribution of Digital Contents
`
`Eberhard von Faber - Robert Hammelrath - Franz—Peter Heider
`
`debis IT Security Services
`OxfordstraBe 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 sufiicient payment has been
`authorised. The system described here is designed (i) to
`be independent front the method used for distribution of
`the encrypted contents,
`(ii) to support many difi‘erent
`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
`42 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 description’of 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.
`
`I
`
`Content
`
`Provider
`
`#2
`
`Content
`
`Distributor
`
`
`
`
`I
`
`Key Management
`system
`
`Authorization
`
`System
`
`'3'
`
`
`i
`
`
`
`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
`
`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 (anonymity).
`
`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
`
`
`
`17
`
`
`
`Page 00008
`
`Page 00008
`
`

`

`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.
`
`
`
` xxx-9:0: wrmmz.”Hams“
`
`Content
`
`Provider
`
`Key Management
`System
`
`
`
`I
`Customer
`
`
`
`(End User)
`
`———>
`information flow
`
`I
`
`
`
`I
`
`Content
`
`Distributor
`
`-,e§%:¢»§fii§v
`contractual relationship
`
`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 (pKi) 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
`
`3%‘§‘%
`
`
`
`”WWfiemsmnWm’’eesrndxmmammfimuamsweetenersmmm’swaimwwimam
`"“5““W“W‘mWmmmmmwWWW\WNWWWWW
`
`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 (pKi)
`
`b) Message AuthenticationCode (MAC) calculated
`over the header (alternative: digital signature)
`
`18
`
`Page 00009
`
`
`Page 00009
`
`

`

`key (pKi) 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 to'the 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
`
`

`

` i i
`
`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 loan contents being included or to their headers,
`respectively. The headers of the loan contents are also a
`part of the package.
`
`the package
`When the package is being registered,
`header is created and signed by the Key Management
`System. It contains a directory of the loan contents. The
`latter are only modified by the Key Management System.
`The loan contents can be integrated in an encrypted form
`as being processed by their Contents Providers. In any
`case the new components are encrypted with the new
`Content Specific Encryption Key (KENC).
`
`When the key is requested by the Customer to use the
`package, the directory containing headers is transferred to
`the Key Management System. This way it is guaranteed
`that the prices for the integrated loan contents are trans-
`ferred to the corresponding Content Providers whenever
`the package is purchased.
`
`5.2 Payment Systems being Supported
`
`Different electronic payment methods can be inte-
`grated independent from the number of protocol steps
`needed. This includes credit card based systems as well as
`electronic purses. (In case of using the Internet, Java-
`
`20
`
`Page 00011
`
`Page 00011
`
`

`

`technology is used to be independent from peculiarities of
`the operating system.)
`
`Note that payment data are actually exchanged be-
`tween the Customer and the Authorisation System. They
`are only routed by the Key Management System. To
`support multi—step payment protocols a suitable signalling
`mechanism is implemented to inform the Key Manage-
`ment System on the status of the authorisation.
`
`In addition, this flexibility leads to the fact that totally
`different authorisation methods can be integrated (refer to
`below for details).
`
`5.3 Workflow Management
`
`Payment is only one example for the user’s authorisa—
`tion to receive the key. Especially,
`in a business—to—
`business model, access control facilities to support work—
`flow management can be integrated instead of payment
`without major changes. Access control
`is
`realised by
`restricting access to the Content Specific Encryption Keys
`(KENC). As a consequence, open (public) networks and
`unprotected storage media can be used to transfer or store
`
`data. There is no longer the restriction of using special
`systems which support access control the traditional way.
`
`So, encrypted contents are distributed Without any re—
`striction but not
`the keys necessary to decrypt. The
`Authorisation System identifies the Customer and checks
`if he/she is authorised to get the key. So, access control is
`realised in a very elegant way. There is no need to use a
`separate network providing access control facilities the
`traditional way. This is regarded as being an essential
`advantage of the concept presented here.
`
`All communication methods (even insecure channels
`and file servers) can be used to exchange the digital
`content. This means that a virtual private network is
`established by restricting access to keys only.
`
`The Authorisation System authenticates individuals
`and grants access rights if the individual is allowed to
`work in the context desired (workflow management). As
`above the Key Management System will deliver the key
`provided that a positive acknowledge (allowance) has
`been received from the Authorisation System.
`
`If a content is created or changed by Customers, a new
`key may be required before that content is written back.
`So, the Key Management System will create and deliver a
`key for re—encryption in that case. The content originator
`(Customer) defines the context in which the content can
`
`be accessed later on. Context means groups individuals
`belong to, roles they play in the process, or projects in
`which the content is being used.
`
`Figure 3: Structure of the Pilot Environment
`
`The Customers use standard hard- and software com-
`
`ponents (refe