 |
Description  |
|
|
FIELD OF THE INVENTION
The present invention relates to metered use cryptographic systems, and
particularly to a data package record used in a method and apparatus for
effecting purchases of the metered use of encrypted data. A co-pending
application assigned to the same assignee as the present invention,
entitled "SECURE COMMUNICATION SYSTEM WITH CROSS LINKED CRYPTOGRAPHIC
CODES", U.S. application Ser. No. 08/488,624 is filed on Jun. 8, 1995.
BACKGROUND OF THE INVENTION
Systems for metering information use are known. For example, see U.S. Pat.
No. 4,827,508 to Shear, or U.S. Pat. No 5,010,571 to Katznelson in which
access to an encrypted CD ROM database is metered. Briefly, a CD ROM
containing an encrypted database of interest to a user is distributed
typically at nominal cost or at no cost. A user terminal includes a host
computer, a CD ROM reader, and a remote cryptographic control unit which
is provided with stored cryptographic keys needed to access the database.
The amount of actual data use, i.e. the retrieval and decryption of data
from the CD ROM, is metered locally and recorded as a stored data usage
record. The charge for data access may be either in accordance with the
amount of data decrypted, or in accordance with price information recorded
in the respective data headers of each individual data package.
The local stored data usage record is reported (uploaded) by telephone
modem or other telecommunications link from a remote user terminal, such
as a host personal computer containing the remote cryptographic control
unit, to a cryptographic operations center. Each remote cryptographic
control unit has a secret stored key, unique to that remote user terminal.
Communication between the user terminal and the cryptographic operations
center is protected by encryption using the secret key, which is stored in
a secure memory in the cryptographic control unit. The secret key for each
user is also stored in the cryptographic operations center. When a remote
user terminal calls in and identifies itself, the cryptographic operations
center looks up the corresponding user secret key, which is then used in a
secure subsequent communication data exchange between the remote user
terminal and the cryptographic operations center.
Also stored in the cryptographic operations center are the various
cryptographic keys corresponding to the available CD ROM database titles.
The user secret key is also used to secure the delivery of secret database
keys from the cryptographic operations center to the user terminal for a
desired CD ROM database, usually upon first encountering a new CD ROM
title.
As indicated, the remote cryptographic control unit reports data usage by
telephone modem. After the data usage report is successfully uploaded to
the cryptographic operations center, the user is then billed, charged or
debited for the actual database usage, based on the content of the
uploaded data usage report. Thus, rather than being required to purchase
an entire CD ROM database, the user pays only for the amount of data
actually used or decrypted from the CD ROM.
Typically, the remote cryptographic control unit in the user terminal
contains one or more credit registers. As each data purchase is made and
recorded as a purchase log, a debit is made from the appropriate credit
register. The credit register limits the amount of data which may be
decrypted before requiring downloaded credit from the cryptographic
operations center. The purpose of the credit register is to prevent
unlimited access to the database without reporting the purchase logs and
paying for data usage, and limited off line access to credit. If the
available credit is exhausted, no further data decryption is allowed until
new credit is downloaded to the user terminal. Past data usage is reported
by the user terminal to the cryptographic operations center in a usage
report consisting of multiple purchase logs (stored data usage records).
However, prior art systems have several operational problems solved by the
data package record and system operation of the present invention.
In the prior art, a separate encryption code is typically used for each
separate data package. In such manner, a separate charge may be made for
each data package. While one header per data package is adequate when the
data package is large relative to the encryption key, such system becomes
inefficient when the data package is smaller. In such case, the encryption
keys could use more memory than the data. For example, in a database such
as a mailing list, the records are too small to justify a separate
encryption key for each entry, yet it is desired to charge separately and
encrypt separately, for each data record in the mailing list.
Also, in prior art systems, running out of credit terminates the data
decryption session and forces the user to establish communication with the
cryptographic operations center to download further credit. Thus,
exhausting the credit registers in the middle of a data session will abort
the session.
Further, in prior art systems, information publishers had no direct control
over who purchased their data, since a purchase could be made locally off
line merely by having sufficient credit available at the local user
terminal.
SUMMARY OF THE INVENTION
The present invention is embodied in a data package record for use in an
encrypted data system including on line remote transaction capability
between a user terminal containing a remote cryptographic control unit
(CRYPTO unit) and a cryptographic operations center (OPC).
In particular, a first embodiment of an encrypted database for use in
accordance with the present invention includes a header containing a
message key encrypted under a database key, and a data package encrypted
under said message key. Another embodiment of an encrypted database for
use in accordance with the present invention includes a header containing
a message key encrypted under said database key, a subunit message key
encrypted under said message key, and a subunit data package encrypted
under said subunit message key. In yet another embodiment, the subunit
message key is truncated to save memory space. In a further embodiment,
the subunit message key is derived from the data address by masking the
virtual data address to match the length of the desired subunit message
key. In the latter embodiment, no additional memory space is needed to
store subunit message keys.
During the process (referred to herein as DP setup) to derive encryption
keys and decrypt the desired data from the encrypted database, the CRYPTO
unit checks whether sufficient credit and/or sufficient database keys are
present to complete the purchase transaction. If credit is missing, a
remote transaction mode may be used if the user chooses to initiate the
remote transaction mode, and, if the database permits a remote
transaction. For a remote transaction, the CRYPTO unit initiates an
immediate report to the OPC, in a remote transaction operation.
In making a purchase during a remote transaction, no credit or refund is
downloaded and no entry of the current purchase is made as a purchase log.
Instead, an online purchase of the data package is effected in real time
which permits continuation of the user's data session. Thus, remote
transaction mode combines the use of an encrypted off line database, and a
real time on line financial transaction, to purchase off line encrypted
data.
Remote transaction mode also permits greater control by an information
publisher over the distribution of its product. The software publisher may
require that all purchases be made by remote transaction mode, by setting
a purchase permission field in a control record called a DB info record.
By requiring on line purchases (as opposed to purchases made off line and
later reported), the information publisher knows the identity of the
purchaser before the purchase, and thus may restrict product sales to
certain users.
The remote transaction data exchange is made as short as possible in order
to complete the transaction and permit the user to resume database use as
soon as possible. In a remote transaction the CRYPTO unit generates a
message which combines a secure header, a report of a single purchase log
and a credit request record, all in one message. The OPC responds by
downloading an encrypted version of the desired database key encrypted
under a key unique to the remote transaction to approve credit, which acts
as a double check on the proper delivery of database keys.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram of a system for reporting metered use of
encrypted information embodying the present invention,
FIG. 2 is a block diagram illustrating the communication protocol between a
remote CRYPTO unit and an OPC in accordance with the present invention.
FIG. 3 is a flow chart diagram illustrating a method for generating a
secure header in a remote CRYPTO unit in accordance with the present
invention.
FIG. 4 is a flow chart diagram illustrating a method and apparatus for
receiving a secure header in an operations center in accordance with the
present invention,
FIG. 5 is a flow chart diagram illustrating a method and apparatus for
generating a secure request message and a secure report usage message in a
remote CRYPTO unit in accordance with the present invention,
FIG. 6 is a diagram partially in block form illustrating the packet format
of a secure message generated in a remote CRYPTO unit in accordance with
the present invention.
FIG. 7 is a flow chart diagram illustrating a method and apparatus for
receiving a secure request message and a secure report message in an
operation center.
FIG. 8 is a flow chart diagram illustrating a method and apparatus for
preparing secure commands in an operation center in accordance with the
present invention.
FIG. 9 is a diagram partially in block form illustrating the packet format
for a secure message in an operation center in accordance with the present
invention.
FIG. 10 is a flow chart diagram illustrating a method and apparatus for
receiving secure commands in a remote CRYPTO unit in accordance with the
present invention.
FIG. 11A is a diagram partially in block form illustrating the data format
and decryption of an encrypted database.
FIG. 11B is a flow chart diagram illustrating the use of remote transaction
request during a data purchase in the metered decryption of an encrypted
database.
FIG. 12 is a flow chart diagram illustrating a method and apparatus for
generating a remote transaction request in a remote CRYPTO unit in
accordance with the present invention.
FIG. 13 is a flow chart diagram illustrating a method and apparatus for
receiving a remote transaction request in an operation center embodying
the present invention.
FIG. 14 is a flow chart diagram illustrating a method and apparatus for
preparing a remote transaction response at an operations center in
accordance with the present invention.
FIG. 15 is a flow chart diagram illustrating a method and apparatus for
receiving a remote transaction response in a remote CRYPTO unit.
FIG. 16 is diagram of various data fields of the DB info record represented
in memory in accordance with the present invention.
DETAILED DESCRIPTION
A Metered Data System
A system for metering and reporting access to an encrypted database is
shown FIG. 1. The system includes a user terminal 16 and an OPC 12. The
user terminal 16 is typically a host personal computer containing CPU 18,
CD ROM reader 20, modem 19, and a remote cryptographic control unit
(CRYPTO unit or information meter) 10 coupled to a non-volatile RAM
storage memory 11. The user terminals 16 is linked to the OPC 12 through a
telephone line modem connection 17.
In operation, information publisher 14 provides an encrypted database 20,
which may be in CD ROM form, to the user terminal 16. The user inserts the
encrypted CD ROM into the CD ROM player 20. Using search and retrieval
software in the user's host personal computer, CPU 18 performs searches on
the encrypted CD ROM database. In order to use the results of the search,
the CPU requests that the CRYPTO unit 10 decrypt the desired data package
from the CD ROM player 20.
If the CRYPTO unit has been previously provided with the necessary database
keys (DB) for the particular encrypted CD ROM, and there is sufficient
credit in the internal credit registers to make the purchase, then the
CRYPTO unit 10 will decrypt the desired encrypted data. Thereafter, the
cost of the decrypted data will be subtracted from the internal credit
register. In addition, a record of the purchase and decryption of the data
will be recorded in the non-volatile RAM 11 as a purchase log entry.
Eventually, in order to replenish credit and report data usage, the host PC
16 which contains the CRYPTO unit 10 will establish a telephone line
connection to the OPC 12. Under control by the host PC, the CRYPTO unit 10
will call the OPC in the event that 1) the user initiates a command which
causes the CRYPTO unit 10 to call the OPC 12, typically when the
additional local credit is needed, 2) the amount of available memory space
for recording the data usage records (purchase logs) in the non-volatile
RAM 11 is low or exhausted, 3) a fixed time period has elapsed, 4) a
remote transaction request is initiated by the user (if the database
allows a remote transaction mode), to make a real time, on line purchase
of a data package in the remote transaction mode.
In any event, the CRYPTO unit 10 commands the modem 19 to establish a
telephone link 17 to the OPC 12. After a telephone link is established,
the CRYPTO unit 10 identifies itself to the OPC 12 either in a secure
header message, or a remote transaction request. Following transmission of
a secure header message, the CRYPTO unit 10 can report usage, or send a
secure request for either a consumer identification number (consumer ID)
or for a credit or refund. In response, the OPC in a secure command
forwards a consumer ID, a credit, or a refund to the CRYPTO unit 10, and
any other commands it wishes to send at that time. The OPC 12 can respond
to a remote transaction request by immediately approving the transaction.
Following the data exchanges, the CRYPTO unit 10 will either be allowed to
make further purchases of encrypted information or denied further
purchases. At periodic intervals, the OPC 12 reports on information use to
information publisher 14.
Conventions Used
As used herein, the preferred encryption and decryption process is the Data
Encryption Standard (DES). Briefly, for the electronic code book mode
(ECB) of DES, an input block of 64 bits (8 bytes) is transformed into an
output block of 64 bits in accordance with a 56 bit key. For decryption
the reverse process is carried out, transforming 64 input bits to 64
output bits using the same 56 bit key. DES keys are typically represented
in 64 bit, 8 byte quantities, with each byte having seven bits plus one
parity bit, or 56 key bits plus 8 parity bits. As used herein, performing
an encrypted keyload of a variable under a secret key means to encrypt (or
decrypt) that variable (usually a key) under the secret key to generate
another key. Encryption may be performed under a single key, or under
multiple keys, such as a triple key set. Unless otherwise stated,
encryption or decryption shall mean ECB mode of DES encryption or
decryption under a triple key set. For triple key encryption, a key set of
three keys are used to encrypt a variable using DES as follows: encrypt
with key 1, decrypt with key 2, and encrypt with key 3. Triple key
decryption is the reverse--decrypt with key 3, encrypt with key 2, and
then decrypt with key 1.
As used herein, CBC shall mean a cipher block chaining mode with an initial
vector, such as the cipher block chaining mode of the DES standard using
an initial vector, IV. In going from a triple key load of a triple key
from either a triple message key or a single message key, the convention
will be as follows: output key 1 is derived from the application of key 1,
key 2, key 3 encrypted, decrypted and encrypted respectively in that order
(for encryption), output key 2 is derived from the application of key 3,
key 2, key 1, encrypted, decrypted and encrypted respectively in that
order (for encryption), and output key 3 is derived from the application
of key 2, key 1, key 3, encrypted, decrypted and encrypted in that order
(for encryption). Also, unless otherwise stated, the IV for a CBC DES
encryption or decryption shall be zero.
Packet Communications Protocol
FIG. 2 illustrates the data exchange protocol between the OPC 12 and the
CRYPTO unit 10. First, a secure header message 234 is sent from the CRYPTO
unit 10 to OPC 12 which serves to identify and authenticate the CRYPTO
unit 10. Following a secure header message 234, one or more secure
requests or usage reports are sent in secure messages 236 from the CRYPTO
unit 10 to the OPC 12. Responsive to the secure request and/or report, the
OPC 12 responds with one or more secure OPC command messages 238 from the
OPC 12 to the CRYPTO unit 10, such as downloading credit to the CRYPTO
unit 10. The received credit is used by the CRYPTO unit 10 in a data
package (DP setup) routine to decrypt data.
Alternatively, the user at CRYPTO unit 10 may request a real time, on line
purchase of a data package in a remote transaction, if the database
permits such remote transaction mode. For this purpose, CRYPTO unit 10
issues a remote transaction request message 240 to the OPC 12. In a remote
transaction request, the OPC 12 decides whether or not to approve the
purchase and responds with a secure remote transaction response message
242 back to the CRYPTO unit 10. All security functions such as
authentication and the like, are compressed into a single CRYPTO unit
request and OPC response. No credit register in the CRYPTO unit 10 is
affected and no record of the purchase is recorded in the CRYPTO unit 10
non-volatile RAM. Following approval of the remote transaction request,
the DP setup routine provides a key which is used to decrypt desired data.
FIGS. 3 through 14 illustrate the foregoing message protocol in greater
detail.
Prepare Secure Header Message--Rypto Unit
The CRYPTO unit stores a secret key called a client key set CK in a battery
backed volatile random access memory (RAM) 22. CK is unique to a given
CRYPTO unit. In addition, the CRYPTO unit stores two fixed constants: a
first fixed string 24 and a second fixed string 26. A meter ID 30
identifies the individual meter which the CRYPTO unit represents. A
measure of current time is provided by a real time clock (RTC) 28.
Several communication keys, including a unit key (UK), a transaction
identification (TID), and a transaction verification key (TVK) are
generated as follows. Fixed string 24 is encrypted under CK in encryptor
36, the result of which is used as a key to encrypt fixed string 26 in
encryptor 38, forming UK. Real time from the real time clock 28 is
encrypted in encryptor 40 under UK to form TID. TID is encrypted under CK
in encryptor 42 to provide an intermediate key SA which in turn is used as
a key to encrypt the meter identification 30 (ID) in encryptor 44 to form
a transaction verification key (TVK). Unless otherwise specified,
encryption of a variable under a key set means a triple key DES block ECB
encryption.
To form a secure header packet, secure header data 32 is triple key CBC
encrypted in encryptor 48 under the TVK using an IV equal to the TID.
Insecure header data consisting of the Meter ID (identification number for
the meter) 30, the Meter Version 34 (like a revision number for the
integrated circuit implementation), and the TID are sent in the clear. A
MAC (message authentication code or manipulation detection code) is
calculated by assembling the insecure header data with encrypted header
data, and triple key CBC encrypting the combination 52 in encryptor 54
under the UK to form a MAC. Unless otherwise specified, CBC encryption
uses triple key and an IV equal to zero.
The insecure header data, the encrypted header data from encryptor 48, and
the calculated MAC are assembled into a packet forming a secure header
message and transmitted 50 to the OPC. At the CRYPTO unit, the calculated
secure header MAC is further encrypted in encryptor 56 under the TVK to
form a checkblock 57 which is stored locally.
Receive Secure Header Message--Opc
The secure header message 58 is received and processed as shown in FIG. 4.
Client key database 60 contains the secret keys for all of the users of
the system. Using the insecure header data for the Meter ID and the Meter
Version, the client key CK is looked up in the client key database 60. UK
is replicated by encrypting the stored first fixed string 62 under CK in
encryptor 64 and using the result as the key to encrypt the second fixed
string 66 in encryptor 68. Received insecure header data TID is encrypted
under CK in encryptor 70 and the result SA used as the key to encrypt the
meter ID in encryptor 72 to recreate TVK. The secure header MAC is
encrypted in encryptor 74 under TVK to form a locally regenerated version
of the checkblock 76 which is stored in the OPC.
To recreate the secure header MAC at the OPC, the received secure header
packet (except for the MAC) is encrypted in CBC encryptor 80 under UK as
the key with IV equal to zero. The calculated MAC at the output of
encryptor 80 is compared to the received secure header MAC in comparator
78. If the MAC received from the CRYPTO unit is not equal to the MAC
calculated by the OPC, then the telephone connection is disconnected at
step 82. However, if the MAC comparison 78 indicates equality,
authenticity of the transmitting CRYPTO unit is presumed, and the process
of receiving secure data is continued at step 84.
Encrypted secure data is decrypted in CBC decryptor 86 using an IV equal to
TID. The data is processed at step 88. In particular, the OPC checks the
present time, the report time and the expiration time for the CRYPTO unit.
Also processed is the total untaxed usage, the total taxed usage, the tax
collected, the tax rate and the message key used for each meter. Received
values are checked against the records for the particular CRYPTO unit. Any
detected errors are noted as irregularities warranting manual review of
the consumer account.
Prepare Secure Request/Report--Crypto Unit
There are three types of messages as shown in FIG. 5, generated by the
CRYPTO unit to the OPC: REPORT USAGE, REQUEST CREDIT/REFUND and REQUEST
CONSUMER ID.
Report Usage
In REPORT USAGE, the totals and summaries of the purchase logs 100
previously entered in the non-volatile RAM 11, each with an appended MAC
and control signals, are forwarded to the OPC in the secure packets of a
REPORT USAGE message. Purchase logs are transmitted without any
encryption. The purchase log entries forming the data usage report provide
an audit trail to cross check total credit purchases.
Request a Consumer Id
Initially, a CRYPTO unit has no particular identity other than its client
key CK and its meter ID. However, before any transactions can be
conducted, an individual identity is needed from the OPC, which identity
links the user to a particular CRYPTO unit, and is used in future
communications. Therefore, before any transactions are conducted, the
CRYPTO unit requests and receives an assigned consumer ID which is stored
locally in the CRYPTO unit.
Request for Credit or Refund
If a consumer ID has been previously assigned, then a secure request for
credit or a secure request for a refund can be sent from the CRYPTO unit
10. In a SECURE REQUEST FOR CREDIT, the CRYPTO unit requests a financial
transaction to deliver credit, typically from the user's credit card
account. In a SECURE REQUEST FOR REFUND, the CRYPTO unit requests a
financial transaction to refund previously delivered credit, typically to
the user's credit card account.
Secure Request Packet Generation
In the event of any of the above secure requests, secure packet data 90 is
CBC encrypted in encryptor 94 under TVK using TID as the IV. The resulting
encrypted packet data is assembled 96 with insecure packet data 92 and
encrypted in CBC encryptor 98 under UK, the output of which forms the MAC
for the secure request packet. The encrypted packet data, and the insecure
packet data and the generated MAC is assembled into a secure request
message and forwarded 102 to the OPC. As indicated above, the purchase
logs 100 are not combined with any of the secure requests but are sent as
a separate packet stream to the OPC, only if the report usage command is
executed.
Crypto Packet Format
FIG. 6 illustrates the format of the secure packets which are sent from the
CRYPTO unit to the OPC. Two consecutive packets 112 and 114 forming a
secure CRYPTO request are shown. The first packet 112 is preceded by
header bits 104 and followed by trailer bits 106 which are part of the
higher order session layer level of the protocol. Similarly, following
packet 114 is framed by header bits 108 and trailer bits 110 which are
part of the higher order session layer level of the protocol.
Each packet 112 and 114 contains a portion of clear data 116 and 122
respectively which contains the insecure packet data. By way of example,
each of clear data portions 116 and 122 contain 3 blocks of 8 bytes each,
or 24 bytes total. Following the clear data portions 116 and 122, are
encrypted data DES blocks 118, 120 and 128 (for packet 112) and DES blocks
124, 126 and 130 (for packet 114) respectively.
A first encryption key TVK is used to encrypt the packet data, and a second
encryption key UK is used to generate the packet MAC. Both packet data and
MAC generation use triple key DES in CBC mode. The MAC encryption key is
UK, with the IV equal to zero for each packet. The data encryption key is
TVK with the IV equal to the previous encrypted DES block, except for the
first DES block 118 of the first packet 112, in which case the IV is TID.
For the first DES block of each successive packet, the IV is the last DES
block of the previou | | |
