Maxim Integrated Products, Inc. v. Starbucks Corporation

Filing 1

COMPLAINT for Patent Infringement against Starbucks Corporation ( Filing fee $ 350 receipt number 0540-3389392.), filed by Maxim Integrated Products, Inc.. (Attachments: # 1 Exhibit A - U.S. Patent No. 5,940,510, # 2 Exhibit B - U.S. Patent No. 5,949,880, # 3 Exhibit C - U.S. Patent No. 6,105,013, # 4 Exhibit D - U.S. Patent No. 6,237,095, # 5 Civil Cover Sheet)(Spangler, Andrew)

EXHIBIT D
UNITED STATES PATENT NO.
6,237,095

111111

1111111111111111111111111111111111111111111111111111111111111
US006237095Bl

United States Patent

(10)

Curry et ai.

(12)

(45)

(54)

APPARATUS FOR TRANSFER OF SECURE
INFORMATION BETWEEN A DATA
CARRYING MODULE AND AN
ELECTRONIC DEVICE

(58)

(75)

Inventors: Stephen M. Curry, Dallas; Donald W.
Loomis, Coppell; Christopher W. Fox,
Dallas, all of TX (US)

Patent No.:
US 6,237,095 BI
Date of Patent:
*May 22, 2001

Field of Search .................................... 380/4, 25, 24,
380/21; 711/164; 705/64, 65, 75; 713/175,
178, 168, 172
References Cited

(56)

(73)

Notice:

4,530,201
5,045,675
5,077,792
5,111,504
5,146,575
5,577,121
5,615,262
5,832,207

Assignee: Dallas Semiconductor Corporation,
Dallas, TX (US)

( *)

U.S. PATENT DOCUMENTS

This patent issued on a continued prosecution application filed under 37 CFR
1.53(d), and is subject to the twenty year
patent term provisions of 35 U.S.c.
154(a)(2).

7/1985 White ................................... 364/408

* 9/1991 Curry ................................... 235/441
*
*
*
*
*

12/1991
5/1992
9/1992
11/1996
3/1997
11/1998

* cited by examiner
Primary Examiner-Tod R. Swann
Assistant Examiner-Matthew Smithers
(74) Attorney, Agent, or Firm-Jenkens & Gilchrist, A
Professional Corporation

Subject to any disclaimer, the term of this
patent is extended or adjusted under 35
U.S.c. 154(b) by 0 days.

ABSTRACT

(57)
(21)

Appl. No.: 09/003,541

(22)

Filed:

The present invention relates to an electronic module used
for secure transactions. More specifically, the electronic
module is capable of passing encrypted information back
and forth between a service provider's equipment via a
secure, encrypted technique so that money and other valuable data can be securely passed electronically. The module
is capable of being programmed, keeping track of real time,
recording transactions for later review, and creating encryption key pairs.

Jan. 6, 1998
Related U.S. Application Data

(62)
(60)
(51)
(52)

Herring .................................. 380/24
Esserman et al. ..................... 380/21
Nolan, Jr.............................. 711/164
Davvis et al. ......................... 380/24
Guy et al. ................................ 380/4
Little et al. .......................... 713/200

Division of application No. 08/595,014, filed on Jan. 31,
1996.
Provisional application No. 60/004,510, filed on Sep. 29,
1995.

Int. CI? ........................................................ H04L 9/00
U.S. CI. .............................................................. 713/178

8 Claims, 8 Drawing Sheets

I/O DATA BUFFERS
SYSTEM DATA
COMMON PIN, RANDOM
NUMBER REGISTER, ETC ...
TRANSACTION GROUP
OUTPUT DATA OBJECT #1
OUTPUT DATA OBJECT #2

GROUP NAME,
PASSWORD AND ATTRIBUTES

/

OBJECT 1

WORKING REGISTER

~

t- 42

OBJECT 2

40
40

-

TRANSACTION GROUP 1
TRANSACTION GROUP 2

TRANSACTION GROUP N

~

OBJECT N

r-- 42

AUDIT TRAIL'
CIRCULAR BUFFER OF
TRANSACTION RECORDS
'THE AUDIT TRAIL DOES
NOT EXIST UNTIL THE
MICRO-IN-A-CAN
HAS BEEN LOCKED
ONCE LOCKED ALL
UNUSED RAM IS
ALLOCATED FOR
THE AUDIT TRAIL

~

"'~

'"

/

''"'"'''''' 'IT,"'

u.s. Patent

US 6,237,095 BI

Sheet 1 of 8

May 22, 2001

~10
ID NUMBER1

IUNIQUE
12

18

-

~

~

MICRO PROCESSOR]

~

~ MATH

I

30

-v
--

26

-

v

32

-

I--' V

-

/'

OUTPUT BUFFER

V

ROM
NVRAM

I

28

CLOCK

iCONTROLK

COPROCESSOR

,

1

~ -

INPUT BUFFER

~ -...

l

14

~

16

f-

22

-... f - 20

-... -

24

+V

T

ENERGY f - CIRCUITRY bONE-WIRE
INTERFACE

MODULE

FIG. 1
S1

CREATE TRANSACTION GROUP

S2

GENERATE KEYS AND LOAD
INTO A TRANSACTION GROUP

S3

PRIVATIZE DECRYPTION EXPONENT

S4

CREATE TRANSACTION SCRIPT

S5

LOCK TRANSACTION GROUP

FIG. 2

I--'

34

u.s. Patent

Al

US 6,237,095 BI

Sheet 2 of 8

May 22, 2001

USER RECEIVES SECURE E-MAIL
AND ENCRYPTED IDEA KEY

A2

MODULE RECEIVES ENCRYPTED
IDEA KEY IN AN INPUT OBJECT
OF A TRANSACTION GROUP

A3

TRANSACTION SCRIPT DECRYPTS
THE IDEA KEY

A4

DECRYPTED IDEA KEY IS PLACED
IN AN OUTPUT DATA OBJECT

A5

IDEA KEY IS USED TO DECRYPT
THE SECURE E-MAIL

FIG. 3

CREATE TRANSACTION GROUP FOR
PERFORMING ELECTRONIC
B1NOTARY FUNCTIONS

~
B2-

CREATE OBJECT(S) FOR
RSA ENCRYPTION KEYS

~
B3

FIG. 4

CREATE OBJECT FOR TIMEKEEPING

~
B4- CREATE TRANSACTION SEQUENCE
OBJECT (COUNTER)

~
B5

-

CREATE A TRANSACTION SCRIPT THAT CREATES A
CERTIFICATE BY COMBINING AN INPUT DATA OBJECT
WITH THE TRUE TIME. THE VALUE OF THE TRANSACTION
COUNTER AND A UNIQUE NUMBER ASSOCIATED TO THE
MODULE, THEN SIGNS THE CERTIFICATE

1
B6

PRIVATIZE OBJECTS

1
B7

LOCK TRANSACTION GROUP

u.s.

C1

C2

Patent

-

US 6,237,095 BI

Sheet 3 of 8

May 22, 2001

,

MESSAGE IS PLACED IN AN
INPUT DATA OBJECT

TRANSACTION SCRIPT COMBINES
MESSAGE WITH OTHER DATA AND
SIGNS THE COMBINATION WITH A
PRIVATE KEY CREATING AN
ENCRYPTED CERTIFICATE

FIG. 5

~
C3

-

THE CERTIFICATE CAN BE READ
AT A LATER TIME BY ENCRYPTING
IT WITH THE PUBLIC KEY

C4

-

THE CERTIFICATE AND ORIGINAL
DOCUMENT CAN BE
STORED ELECTRONICALLY

,

D1 -

PREPARE MODULE
CREATE TRANSACTION GROUP
COMPRISING: MONEY OBJECT
TRANSACTION COUNT OBJECT
PRIVATE KEY AND
PUBLIC KEY OBJECTS ETC.

,
,
~

D2

FIG. 6

PRIVATIZE PRIVATE KEY RELATED OBJECT(S)

D3- CREATE OBJECT FOR TIMEKEEPING
RSA ENCRYPTION KEYS

~

D4

LOCK TRANSACTION GROUP

D5

PUBLISH PUBLIC KEY

u.s. Patent

MERCHANT

USER
USER WANTS TO MAKE
A PURCHASE
USING A MODULE

~

,

H

READS MODULE'S
10 NUMBER

\E1

US 6,237,095 BI

Sheet 4 of 8

May 22, 2001

CREATE DATA PACKET
THAT INCLUDES A
'RANDOM SALT' AND
MODULE 10 NUMBER

BANK/SERVICE PROVIDER

E2

'-E3

j
CREATE A SIGNED
MERCHANT CERTIFICATE
BY ENCRYPTING DATA
I'- E4
PACKET WITH
MERCHANT'S PRIVATE KEY
(E6

,
,

SUBTRACT PURCHASE
AMOUNT FROM
MONEY REGISTER
INCREMENT
TRANSACTION AMOUNT

j
r--

ATTACHES PURCHASE
PRICE TO MERCHANT'S
SIGNED CERTIFICATE

'-E5

E7

COMBINE TRANSACTION I'--- E8
COUNT WITH MERCHANT'S
RECEIVE SIGNED MODULE
SIGNED CERTIFICATE
r- CERTIFICATE AND DECRYPT t'-AND PURCHASE AMOUNT;
USING SERVICE
E9
THEN ENCRYPT WITH
PROVIDER'S PUBLIC KEY
SERVICE PROVIDER'S
PRIVATE KEY THEREBY
( E12
CREATING A SIGNED
CONFIRM THAT:
RECEIVE MODULE'S
MODULE CERTIFICATE
1) AMOUNT OF PURCHASE
SIGNED CERTIFICATE
IS CORRECT
2) DATA IN MERCHANT'S
INCREMENT·
CERTIFICATE IS THE
DECRYPT MODULE'S
TRANSACTION AMOUNT
SAME AS ORIGINALLY SENT
CERTIFICATE WITH SERVICE t'-- E13
\ Ell
PROVIDER'S PUBLIC KEY
'E10

,

t

H

~

t

t

FIC. 7

DECRYPT MERCHANT'S
CERTIFICATE WITH
MERCHANT'S PUBLIC KEY

,

"- E14

IF BOTH CERTIFICATES
ARE OK THEN ADD
PURCHASE AMOUNT TO t--. E15
MERCHANT'S BANK BALANCE

u.s. Patent

May 22, 2001

BANK/SERVICE PROVIDER

USER
Fl

../

F3,./

US 6,237,095 BI

Sheet 5 of 8

WANTS TO ADD AN
AMOUNT OF CASH
TO MODULE

t---

CREATE RANDOM
SALT NUMBER

READ MODULE ID
NUMBER AND AMOUNT
OF CASH REQUESTED

_

~

~~OMBINE

DECRYPT SIGNE SERVICE
PROVIDER CERTIFICATE
WITH SERVICE PROVIDER'S
PUBLIC KEY AND CHECK
TH ID NUMBER AND
RANDOM SALT NUMBER
F5,./ IF THE ID NUMBER AND
RANDOM SALT NUMBER
IS UNCHANGED THEN ADD
HE CASH AMOUNT TO THl
MONEY REGISTER OF
THE MODULE

r--.... F2

REQUEST MODULE TO
PRODUCE A RANDOM SALT
SAlT, 10 NUMBH

AND CASH AMOUNT AND
ENCRYPT WITH SERVICE ~ F4
PROVIDER'S PRIVATE KEY,
THEREBY CREATING A
SIGNED SERVICE
PROVIDER CERTIFICATE

I

FIG.

a

EXAMPLE OF
TRANSFER FROM USER'S MODULE TO MERCHANT'S MODULE
USER/PAYER

MERCHANT/PAYEE

RECEIVE SALT AND
REQUEST FOR MONEY

1. CREATE RANDOM SALT

SUBTRACT REQUESTED
MONEY AMOUNT FROM
A MONEY REGISTER
G
Y

CREATE SIGNED PAYMENT
CERTIFICATE BY COMBINING
SALT WITH PAYMENT
AMOUNT THEN ENCRYPTING
WITH BANK/SERVICE
PROVIDER'S PRIVATE KEY
PAYEE = MERCHANT
PAYER=USER

FIG. 9

2. DETERMINE AMOUNT OF
MONEY TO BE

r--.... Gl

RECEIVED FROM PAYER

I
-~

RECEIVED SIGNED PAYMENT
CERTIFICATE AND DECRYPT
USING SERVICE PROVIDER'S
PUBLIC KEY

r--.... G3

t

CHECK DECRYPTED SALT
AGAINST ORIGINALLY SENT SALT
IF THEY ARE THE SAME
ADD PAYMENT AMOUNT
TO MONEY REGISTER

"- G4

u.s.

Patent

May 22, 2001

US 6,237,095 BI

Sheet 6 of 8

TRANSACTION OVER A NETWORK WITH A MODULE
USER/PAYER
H1. /

CREATE RANDOM
PAYER SALT

,
,

MERCHANT/PAYEE
RECEIVE PAYER SALT AND
COMBINE WITH AMOUNT OF
MONEY TO BE RECEIVED, AND
INCLUDE A PAYEE SALT, THEN I'-- H2
ENCRYPT WITH SERVICE
PROVIDER'S PRIVATE KEY TO
CREATE A FIRST DATA PACKET

RECEIVE FIRST DATA PACKET

H3 . / AND DECRYPT WITH SERVICE
PROVIDER'S PUBLIC KEY
COMPARE ENCRYPTED
PAYER SALT WITH ORIGINAL
PAYER SALT

IF THEY ARE THE SAME,
H4 . / SUBTRACT AMOUNT OF MONEY

,

TO BE SENT FROM
PAYER TO REGISTER

H5 . /

GENERATE A SECOND DATA
PACKET CONSISTING OF
PAYEE'S SALT AND THE
AMOUNT OF MONEY TO
BE SENT AND ENCRYPT
USING SERVICE
PROVIDER'S PRIVATE KEY

1

RECEIVE SECOND DATA PACKET
AND DECRYPT USING SERVICE
PROVIDER'S PUBLIC KEY

t

FIG. 10

~

H6

EXTRACT DECRYPTED PAYEE
SALT AND COMPARE WITH
PAYEE SALT PROVIDED EARLIER i'-- H7
IF BOTH ARE THE SAME ADD
MONEY AMOUNT TO
PAYEE MONEY REGISTER

u.s. Patent

May 22, 2001

US 6,237,095 BI

Sheet 7 of 8

READ/WRITE OBJECT COMMANDS
MODULE
10

-

PIN
MATCH

4\

--l

LOCKED
TRANSACTION
GROUP

;- 40

H (O)~ ";O~jf~TS

SCRIPTS

~

42

IPRIVATE (P)~
IOBJECTS
"r- 42
L{LOCKED ()~
OBJECTS L
r- 42

READ ONLY OBJECT COMMAND
READ/WRITE OBJECT COMMANDS
LOCKED
TRANSACTION
GROUP

1-WIRE

1/0

DATA
TRANSPORT
LAYER

~

COMMAND
INTERPRETER

PIN
MATCH

I--r- 40

~ O~jf~TS (0)1

--l

SCRIPTS

I

IPRIVATE (p)1

IOBJECTS

-i

LOCKED ()
OBJECTS L

1

READ ONLY OBJECT COMMAND
READ/WRITE OBJECT COMMANDS
LOCKED
TRANSACTION
GROUP
PIN
MATCH

"--

--l

SCRIPTS

I

- 40

~O~~f~TS (0)1
IPRIVATE (p)1
IOBJECTS

()I

L{LOCKED
OBJECTS L
I

READ ONLY OBJECT COMMAND

FIG. 11

u.s. Patent

May 22, 2001

US 6,237,095 BI

Sheet 8 of 8

I/O DATA BUFFERS
SYSTEM DATA
COMMON PIN, RANDOM
NUMBER REGISTER, ETC ...
TRANSACTION GROUP
OUTPUT DATA OBJECT #1
OUTPUT DATA OBJECT #2

GROUP NAME,
PASSWORD AND ATTRIBUTES

WORKING REGISTER

OBJECT 1

I-

42

OBJECT 2

40
40

-

TRANSACTION GROUP 1
TRANSACTION GROUP 2

.
.

.

OBJECT N

TRANSACTION GROUP N

AUDIT TRAIL·
CIRCULAR BUFFER OF
TRANSACTION RECORDS
TRANSACTION RECORD

*THE AUDIT TRAIL DOES
NOT EXIST UNTIL THE
MICRO-IN-A-CAN
HAS BEEN LOCKED

GROUP
ID

ONCE LOCKED ALL
UNUSED RAM IS
ALLOCATED FOR
THE AUDIT TRAIL

FIG. 12

OBJECT
ID

DATE/TIME
STAMP

I - 42

US 6,237,095 Bl
1

2

APPARATUS FOR TRANSFER OF SECURE
INFORMATION BETWEEN A DATA
CARRYING MODULE AND AN
ELECTRONIC DEVICE

BRIEF DESCRIPTION OF THE DRAWINGS

RELATED APPLICATIONS

5

This application is a division of Ser. No. 08/595,014 filing
date Jan. 31, 1996.
This application claims the benefit of U.S. Provisional
Application No. 60/004,510, filed Sep. 29, 1995.
The following applications of common assignee contains
related subject matter and are hereby incorporated by reference:
Ser. No. 08/594,983, unknown, filed Jan. 31, 1996,
entitled METHOD, APPARATUS, SYSTEM AND
FIRMWARE FOR SECURE TRANSACTIONS;
Ser. No. 08/594,975, filed Jan. 31, 1996, entitled TRANSFER OF VALUABLE INFORMATION BETWEEN A
SECURE MODULE AND ANOTHER MODULE.

10

15

20

BACKGROUND OF THE INVENTION
1. Technical Field of the Invention
The present invention relates to a method, apparatus and
system for transferring money or its equivalent electroni _
cally. In particular, in an electronic module based system, the
module can be configured to provide at least secure data
transfers or to authorize monetary transactions.
2. Description of Related Art
Presently, credit cards that have a magnetic strip associated with them, are a preferred monetary transaction
medium in the market place. A card user can take the card
to an automatic cash machine, a local store or a bank and
make monetary transactions. In many instances the card is
used via a telephone interface to make monetary exchanges.
The magnetic strip card is used to help identify the card and
user of the card. The card provides a relatively low level of
security for the transfer. Regardless, the card enables a card
holder to buy products, pay debts and make monetary
exchanges between separate bank accounts.
Improvements have been made to the magnetic strip card.
There have been cards created with microcircuits instead of
magnetic strips. In general the microcircuit, like a magnetic
strip, is used to enable a card-reader to perform a transaction.

25

30

DETAILED DESCRIPTION OF A PRESENTLY
PREFERRED EXEMPLARY EMBODIMENT
35

40

45

SUMMARY OF THE INVENTION
The present invention is an apparatus, system and method
for communicating encrypted information between a preferably portable module and a service provider's equipment.
The invention comprises a module, that has a unique
identification, that is capable of creating a random number,
for example, a SALT, and passing the random number, along
with, for example, a request to exchange money, to a service
provider's equipment. The service provider's equipment
may in return encrypt the random number with a private or
public key (depending on the type oftransaction), along with
other information and pass the encrypted information back
to the module as a signed certificate. The module, upon
receiving the signed certificate, will decrypt the certificate
with a public or private key (depending on the type of
transaction) and compare the decrypted number with the
original random number. Furthermore, if the numbers are the
same then the transaction that was requested may be deemed
secure and thereby proceeds. The module is capable of time
stamping and storing in memory information about the
transaction for later review.

A more complete understanding of the method and apparatus of the present invention may be had by reference to the
following Detailed Description when taken in conjunction
with the accompanying Drawings wherein:
FIG. 1 is a block diagram of an embodiment of a module;
FIG. 2 is an exemplary process for creating a transaction
group;
FIG. 3 is an exemplary technique for receiving an E-mail
message;
FIG. 4 is an exemplary technique for preparing a module
for notary functions;
FIG. 5 is an exemplary technique for using the module as
a notary;
FIG. 6 is an exemplary technique for preparing a module
to perform a money transaction;
FIG. 7 is an exemplary technique for performing a money
transaction using a module;
FIG. 8 is an exemplary technique for performing a money
transaction using a module;
FIG. 9 is an exemplary technique for performing a money
transaction using a module;
FIG. 10 is an exemplary technique for passing data over
a network;
FIG. 11 is an exemplary organization of the software and
firmware within a module; and
FIG. 12 is an exemplary configuration of software and
firmware within a module.

50

55

60

65

FIG. 1 depicts a block diagram of an exemplary module
10 that incorporates an exemplary embodiment of the
present invention. The module circuitry can be a single
integrated circuit. It is understood that the module 10 could
also be on multiple integrated or descrete element circuits
combined combined together. The module 10 comprises a
microprocessor 12, a real time clock 14, control circuitry 16,
a math coprocessor 18, memory circuitry 20, input/output
circuitry 26, and an energy circuit.
The module 10 could be made small enough to be
incorporated into a variety of objects including, but not
limited to a token, a card, a ring, a computer, a wallet, a key
fob, badge, jewelry, stamp, or practically any object that can
be grasped and/or articulated by a user of the object.
The microprocessor 12 is preferably an 8-bit
microprocessor, but could be 16, 32, 64 or any operable
number of bits. The clock 14 provides timing for the module
circuitry. There can also be separate clock circuitry 14 that
provides a continuously running real time clock.
The math coprocessor circuitry 18 is designed and used to
handle very large numbers. In particular, the coprocessor
will handle the complex mathematics of RSA encryption and
decryption.
The memory circuitry 20 may contain both read-onlymemory and non-volatile random-access-memory.
Furthermore, one of ordinary skill in the art would understand that volatile memory, EPROM, SRAM and a variety of
other types of memory circuitry could be used to create an
equivalent device.
Control circuitry 16 provides timing, latching and various
necessary control functions for the entire circuit.
An input/output circuit 26 enables bidirectional communication with the module 10. The input/output circuitry 26

US 6,237,095 Bl

3

4

Service Providers that can be supported depends on the
preferably comprises at least an output buffer 28 and an
number and complexity of the objects 42 defined in each
input buffer. For communication via a one-wire bus, onetransaction group 40. Examples of some of the objects 42
wire interface circuitry 32 can be included with the input!
that can be defined within a transaction group 40 are the
output circuitry 26.
5 following:
An energy circuit 34 may be necessary to maintain the
memory circuitry 20 and/or aid in powering the other
circuitry in the module 10. The energy circuit 34 could
consist of a battery, capacitor, R/C circuit, photovoltaic cell,
RSAModulus
Clock Offset
RSA Exponent
Random SALT
or any other equivalent energy producing circuit or means.
Transaction Script
Configuration Data
The firmware architecture of a preferred embodiment of a 10
Transaction Counter
Input Data
secure transaction module and a series of sample applicaMoney Register
Output Data
Destructor
tions using the module 10 will now be discussed. These
examples are intended to illustrate a preferred feature set of
the module 10 and to explain the services that the module
Within each transaction group 40 the module 10 will
offers. These applications by no means limit the capabilities 15
initially accept certain commands which have an irreversible
of the invention, but instead bring to light a sampling of its
effect. Once any of these irreversible commands are
capabilities.
executed in a transaction group 40, they remain in effect
I. OVERVIEW OF THE PREFERRED MODULE AND
until the end of the module's useful life or until the transITS FIRMWARE DESIGN
20 action group 40, to which it applies, is deleted from the
module 10. In addition, there are certain commands which
The module 10 preferably contains a general-purpose,
have an irreversible effect until the end of the module's life
80SI-compatible micro controller 12 or a reasonably similar
or until a master erase command is issued to erase the entire
product, a continuously running real-time clock 14, a highcontents of the module 10. These commands will be disspeed modular exponentiation accelerator for large integers
(math coprocessor) 18, input and output buffers 28, 30 with 25 cussed further below. These commands are essential to give
the Service Provider the necessary control over the operaa one-wire interface 32 for sending and receiving data, 32
tions that can be performed by the End User. Examples of
Kbytes of ROM memory 22 with preprogrammed firmware,
some of the irreversible commands are:
8 Kbytes of NVRAM (non-volatile RAM) 24 for storage of
critical data, and control circuitry 16 that enables the micro
controller 12 to be powered up to interpret and act on the 30
data placed in an input circuitry 26. The module 10 draws its
Privatize Object
Lock Object
Lock Micro-In-A-Can ™
Lock Transaction Group
operating power from the one-wire line. The micro controller 12, clock 14, memory 20, buffers 28, 30, one-wire
front-end 32, modular exponentiation accelerator 18, and
Since much of the module's utility centers on its ability to
control circuitry 16 are preferably integrated on a single 35 keep a secret, the Privatize command is a very important
silicon chip and packaged in a stainless steel microcan using
irreversible command.
packaging techniques which make it virtually impossible to
Once the module 10, as a whole, is locked, the remaining
probe the data in the NVRAM 24 without destroying the
NVRAM memory 24 is allocated for a circular buffer for
data. Initially, most of the NVRAM 24 is available for use
holding an audit trail of previous transactions. Each of the
to support applications such as those described below. One 40 transactions are identified by the number of the transaction
of ordinary skill will understand that there are many comgroup, the number of the transaction script 40 within the
parable variations of the module design. For example,
specified group, and the date/time stamp.
volatile memory can be used, or an interface other than a
The fundamental concept implemented by the firmware is
one-wire could be used. The silicon chip can be packaged in
that the Service Provider can store transaction scripts 44 in
credit cards, rings etc.
45 a transaction group 40 to perform only those operations
among objects that he wishes the End User to be able to
The module 10 is preferably intended to be used first by
perform. The Service Provider can also store and privatize
a Service Provider who loads the module 10 with data to
RSAkey or keys (encryption keys) that allow the module 10
enable it to perform useful functions, and second by an End
to "sign" transactions on behalf of the Service Provider,
User who issues commands to the module 10 to perform
operations on behalf of the Service Provider for the benefit 50 thereby guaranteeing their authenticity. By privatizing and/
or locking one or more objects 42 in the transaction group
of the End User. For this reason, the module 10 offers
40, the Service Provider maintains control over what the
functions to support the Service Provider in setting up the
module 10 is allowed to do on his behalf. The End User
module for an intended application. It also offers functions
cannot add new transaction scripts 44 and is therefore
to allow the End User to invoke the services offered by the
55 limited to the operations on objects 42 that can be performed
Service Provider.
with the transaction scripts 44 programmed by the Service
Each Service Provider can reserve a block of NVRAM
Provider.
memory to support its services by creating a transaction
II. USAGE MODELS OF THE MODULE
group 40 (refer to FIGS. 11 and 12). A transaction group 40
This section presents a series of practical applications of
is simply a set of objects 42 that are defined by the Service
Provider. These objects 42 include both data objects 60 the module 10, ranging from the simplest to the most
complex. Each of these applications is described in enough
(encryption keys, transaction counts, money amounts, date/
detail to make it clear why the module 10 is the central
time stamps, etc.) and transaction scripts 44 which specify
enabling technology for that application.
how to combine the data objects in useful ways. Each
A. BACKGROUND OF SECURE E-MAIL
Service Provider creates his own transaction group 40,
which is independent of every other transaction group 40. 65
In this section we provide an example of how a module 10
Hence, multiple Service Providers can offer different sercould be used to allow anyone to receive his or her own
vices in the same module 10. The number of independent
e-mail securely at any location.

US 6,237,095 Bl
5
1. Standard E-Mail
In a standard e-mail system, a user's computer is connected to a provider of Internet services, and the user's
computer provides an e-mail password when polling the
provider's computer for new mail. The mail resides on the
provider's computer in plain text form, where it can be read
by anyone working there. In addition, while traveling from
its source, the mail passes through many computers and was
also exposed at these locations. If the user receives his mail
from his provider over a local area network, anyone else on
the same network can capture and read the mail. Finally,
with many e-mail systems that do not require the user to
enter the password, anyone sitting at the user's computer can
retrieve and read his mail, since his computer automatically
provides the password when it polls the provider's computer.
It is frequently also possible to copy the password from a
configuration file in the user's computer and use it to read his
mail from a different computer. As a result of this broad
distribution of the e-mail in plain text form and the weakness
of password protection, standard e-mail is regarded as very
insecure.
To counter this problem, the security system known as
P.G.P. (Pretty Good Privacy) was devised. To use P.G.P., a
user generates a complete RSA key set containing both a
public and private component. He makes his public key
widely available by putting it in the signature block of all hIS
e-mail messages and arranging to have it posted in publicly
accessible directories of P.G.P. public keys. He stores his
private key on his own personal computer, perhaps in a
password-protected form. When someone wishes to send
private e-mail to this user, he generates a random IDEA
encryption key and encrypts the entire message with the
IDEA encryption algorithm. He then encrypts the IDEA key
itself using the public key provided by the intended recipient. He e-mails both the message encrypted with IDEA and
the IDEA key encrypted with the user's public key to the
user. No one that sees this transmission can read it except the
intended recipient because the message is encrypted with
IDEA and the IDEA key is encrypted with the intended
recipient's public key. The recipient's computer contains the
corresponding private key, and hence can decrypt the IDEA
key and use the decrypted IDEA key to decrypt the message.
This provides security from those who might try to read the
user's mail remotely, but it is less effective when the user's
computer is accessible to others because the computer, itself,
contains the private key. Even if the private key is password
protected, it is often easy to guess the user's password or
eavesdrop on him when he enters it, so the user's computer
provides little security. In addition, the user ca~ re~eive
secure e-mail only at his own computer because hIS pnvate
key is stored in that computer and is not available elsewhere.
Therefore the weakness of P.G.P. is that it is tied strongly to
the user's' computer where the private key resides.
2. Module Protected E-Mail
With the exemplary module 10 being used to protect
e-mail a user could have his e-mail forwarded to him
where~er he goes without fear that it would be read by others
or that his PC would be the weak link that compromises the
security of his mail. The module protected e-mail system is
similar to the P.G.P. system, except that the private key used
for decrypting the IDEA key is stored in a privatized object
in a transaction group of the module 10 instead of in a Pc.
The module protected e-mail system operates as follows:
a. Referring to FIGS. 2, 11 and 12, the user creates a
transaction group 40, SI, generates an RSA key set S2

6
and loads it into three objects 42 of the transaction
group 40 (one RSA modulus object, N, an.d t~o RSA
exponent objects, E and D). He then pnvatlzes the
decryption exponent S3, D. Finally, he creates a transaction script 44, S4 to take data placed in the input data
5
object, encrypt it with the modulus N and private
exponent D and place the result in the output data
object. He locks the group S5 to prevent any additional
transaction scripts 44 from being added. He "forgets"
the value of D and publishes the values of E and N in
10
public directories and in the signature blocks of his
e-mail messages. Since he has forgotten D and since the
D exponent object has been privatized, there is no way
that anyone will ever find out the value of D.
b. Referring to FIG. 3, to send secure e-mail to the user,
15
the P.G.P. system is used. When the user receives the
secure e-mail AI, he transmits the encrypted IDEA key
into the input data object of the transaction group 40,
A2 and then calls the transaction script 44 to decrypt
20
this key A3 and place the decrypted result in the output
data object A4. He then reads the decrypted IDEA key
from the output data object and uses it to decrypt his
mail A5. Note that it is now impossible for anyone,
including the user, to read any new mail without having
25
physical possession of the module 10. There is therefore no way that a user's mail can be read without his
knowledge, because the module 10 must be physically
present on the computer where the mail is read. The
user can carry his module 10 wherever he goes and use
30
it to read his forwarded mail anywhere. His home
computer is not the weak point in the security system.
Secure e-mail, as described above, is the simplest possible
module application, requiring only one RSA key and one
transaction script 44. It is unnecessary even to store the
35 public key E in the module 10, but it is a good idea to do so
because the public key is supposed to be publicly accessible.
By storing E in an exponent object and not privatizing that
object or the modulus object, N, the user insures that the
public key can always be read from the module 10. There are
40 no transaction scripts 44 involving E because the module 10
will never be required to perform an encryption.
B. DIGITAL NOTARY SERVICE
This section describes a preferred notary service using the
module 10.
45
1. Background of a Standard Notary Service
A conventional Notary Service Provider receives and
examines a document from an End User and then supplies an
uncounterfeitable mark on the document signifying that the
document was presented to the notary on a certain date, etc.
50 One application of such a notary service could be to record
disclosures of new inventions so that the priority of the
invention can later be established in court if necessary. In
this case the most important service provided by the notary
is to cer{ify that the disclosure existed in the possession of
55 the inventor on a certain date. (The traditional method for
establishing priority is the use of a lab notebook in which
inventors and witnesses sign and date disclosures of significant inventions.)
2. Electronic Notary Service Using The Module
60
A company, hereafter referred to as the Service Provider,
decides to go into business to supply a notary service
(strictly, a priority verification service) for its. custom.ers,
hereafter referred to as the End Users. The ServIce ProvIder
chooses to do this by using the module 10 as its "agents" and
65 gives them the authority to authenticate (date. and sig~)
documents on his behalf. The preferred operatIOn of thIS
system is as follows:

US 6,237,095 Bl
7

8

a. Referring to FIGS. 4, 11 and 12, the Service Provider
goods or services. (To simplify the discussion, the subject of
creates a transaction group 40 for performing electronic
refilling the module 10 with cash is postponed until later). In
notary functions in a "registered lot" of modules 10,
this case the Service Provider is a bank or other financial
institution, the End User is the bank's customer who wishes
Bl.
b. The Service Provider uses a secure computing facility 5 to use the module 10 to make purchases, and the Merchant
is the provider of the purchased goods or services. The roles
to generate an RSA key set and program the set into
of the Service Provider, the Merchant, and the End User in
every module 10 as a set of three objects 42, a modulus
these transactions are explained in detail below.
object and two exponent objects B2. The public part of
The fundamental concept of the digital cash purse as
the key set is made known as widely as possible, and
the private part is forgotten completely by the Service 10 implemented in the module 10 is that the module 10 initially
contains a locked money object containing a given cash
Provider. The private exponent object is privatized to
value, and the module 10 can generate, on demand, certifiprevent it from being read back from the modules 10.
cates which are essentially signed documents attesting to the
c. The Service Provider reads the real-time clock 14 from
fact that the amount of money requested was subtracted
each module 10 and creates a clock offset object that
from the value of the money object. These signed documents
contains the difference between the reading of the
real-time clock 14 and some convenient reference time 15 are equivalent to cash, since they attest to the fact that the
internal money object was decreased in value by an amount
(e.g., 12:00 a.m. Jan. 1, 1970). The true time can then
corresponding to the value of the certificate. The merchant
be obtained from any module 10 by adding the value of
can redeem these certificates for cash by returning them to
the clock offset object to the real-time clock B3.
the Service Provider.
d. The Service Provider creates a transaction sequence
When dealing with digital certificates representing cash,
counter object initialized to zero B4.
20
"replay" or duplication is a fundamental problem. Since
e. The Service Provider creates a transaction script 44
digital data can be copied and retransmitted easily, it differs
which appends the contents of the input data object to
from ordinary coins or paper money which are difficult to
the true time (sum of real-time clock 14 and the value
reproduce because of the special technology that is used in
of the clock offset object) followed by the value of the 25 their manufacture. For this reason, the receiver of the
transaction counter followed by the unique lasered
payment must take special steps to insure that the digital
registration number. The transaction script 44 then
certificate he receives is not a replay of some previously
specifies that all of this data be encrypted with the
issued certificate. This problem can be solved by having the
private key and placed in the output data object. The
payee generate a random "SALT", a challenge number, and
instructions to perform this operation are stored in the 30 provide it to the payer.
transaction group 40 as a transaction script object B5.
SALT is a method of preventing replay. A random number
f. The Service Provider privatizes any other objects 42
is sent and used in a challenge/response mode. The other
that it does not wish to make directly readable or
party is challenged to return the random number as part of
their response.
writable B6.
The payer constructs a signed certificate which includes
g. The Service Provider locks the transaction group 40, 35
both the money amount and the payee's SALT. When the
preventing any additional transaction scripts 44 from
payee receives this certificate, he decrypts it with the public
being added B7.
key, checks the money amount, and then confirms that the
h. Referring to FIG. 5, now the Service Provider distribSALT is the same as the one he provided. By personalizing
utes the modules to paying customers (End Users) to
use for notary services. Anytime an End User wishes to 40 the certificate to the payee, the payer proves to the payee that
the certificate is not a duplicate or replay and is therefore
have a document certified, the End User performs the
authentic. This method can be used regardless of whether the
Secure Hash Algorithm (Specified in the Secure Hash
module 10 is the payer or the payee.
Standard, FIPS Pub. 180) to reduce the entire document
Another problem that must be addressed is irrepudiability.
to a 20 byte message digest. The End User then
transmits the 20 byte message digest to the input data 45 This means that none of the parties to the transaction should
be able to argue that he did not actually participate in the
object Cl and calls on the transaction script 44 to bind
transaction. The transaction record (money certificate)
the message digest with the true time, transaction
should contain elements to prove that each party to the
counter, and unique lase red serial number and to sign
transaction was a willing participant.
the resulting packet with the private key C2.
1. Background Conventional Cash Transactions
i. The End User checks the certificate by decrypting it 50
In a conventional cash transaction, the End User first
with the public key and checking the message digest,
receives Federal Reserve Notes from a bank and the bank
true time stamp, etc. to make sure they are correct C3.
subtracts the equivalent amount of money from the balance
The End User then stores this digital certificate along
in his account. The End User can verify the authenticity of
with the original copy of the document in digital form
C4. The Service Provider will attest to the authenticity 55 the Federal Reserve Notes by means of the "public key",
which includes:
of the certificates produced by its modules.
a. Magnetic ink attracted by a magnet.
j. After a period of time specified by the Service Provider,
b. Red and blue threads imbedded in the paper.
the user returns his module 10, pays a fee, and gets a
c. Microfine printing surrounding the engraved portrait.
new module containing a new private key. The old
modules can be recycled by erasing the entire transac- 60
d. Embedded stripe printed with USA and denomination
tion group and reprogramming them. The Service Proof the note.
The "private key" to this system is the details of how the
vider maintains an archive of all the public keys it has
ever used so that it can testify as needed to the
raw materials for printing money are obtained and how the
authenticity of old certificates.
money is actually printed. This information is retained by
C. DIGITAL CASH DISPENSER
65 the government and not revealed.
This exemplary usage model focuses on the module 10 as
These notes are carried by the End User to the Merchant,
a cash reservoir from which payments can be made for
where they are exchanged for goods or services. The Mer-

US 6,237,095 Bl

9

10

g. The bank decrypts the certificate with the Service
chant also uses the "public key" of the notes to verify that
they are legitimate.
Provider's public key E12, extracts the amount of the
Finally, the Merchant carries the notes to a Bank, where
purchase and the transaction count, and decrypts the
the "public key" is again examined by the teller. If the notes
remaining data with the Merchant's public key to
are legitimate, the Merchant's bank account balance is 5
reveal the unique lase red registration number of the
increased by the face value of the notes.
module E14. The bank then looks up the module 10 by
The end result of this transaction is that the End User's
the unique lase red registration number in a database to
bank balance is reduced, the Merchant's bank balance is
confirm that the transaction count for this transaction
increased by the same amount, the goods or services are
has not been submitted before. When this test is passed,
transferred from the Merchant to the End User, and the 10
the bank adds the transaction count value to the
Federal Reserve Notes are ready to be reused for some other
database, and then increases the Merchant's bank baltransaction.
ance by the amount of the purchase E15. The fact that
2. Exemplary Monetary Transactions Using The Module
portions of the certificate were signed by both the
Monetary transactions using the module 10 and digital
module 10 and the Merchant confirms that the transcertificates are somewhat more complicated because digital
action was freely agreed to by both the Merchant and
data, unlike Federal Reserve Notes, can be copied and 15
the module 10.
duplicated easily. Nevertheless, the use of "SALTS" and
Note that there are many different ways of combining data
transaction sequence numbers can guarantee the authenticity
combinations of the transaction counter value, the unique
of digital certificates. (In the following discussion, it is
lasered registration number, the random SALT provided by
assumed that every party to the transaction has its own RSA
20 payee, and the amount of purchase, encrypted by the modkey set with a private key that it is able to keep secret.)
ule's private key, the Merchant's private key, or both. Many
a. Referring to FIG. 6, the Service Provider (bank) preof these combinations can also provide satisfactory guaranpares the module 10 by creating a transaction group 40
tees of uniqueness, authenticity, and irrepudiability, and the
containing a money object representing the monetary
design of the firmware allows the Service Provider fiexibilvalue stored in the module 10. The Service Provider
25 ity in writing the transaction script 44 to serve his particular
also creates a transaction count object, a modulus
needs.
object, and an exponent object and stores the provider's
D. DIGITAL CASH REPLENISHMENT
private key in the exponent object Dl. He privatizes the
The discussion of a digital cash purse is section II.C.,
key so that it cannot be read D2. Next, he stores a
above, did not address the issue of cash replenishment. The
transaction script 44 in the transaction group 40 to
30 Service Provider can add cash replenishment capability to
perform the monetary transaction and locks the group
the module 10, as discussed in section II.C., simply by
so that no further objects can be made D3, D4. (The
adding another modulus object and exponent object condetails of what this transaction script does are described
taining the Service Provider's public key, a random SALT
further below.) Finally, he publishes the corresponding
object, and a transaction script 44 for adding money to the
public key widely so that anyone can obtain it D5.
35 balance. The Service Provider can add money to a module
b. The End User receives the module 10 from the Service
10 either in person or remotely over a network. The process
Provider, and the End User's bank account is debited by
of adding money is as follows:
the amount stored in the module 10. Using a PC or
1. Referring to FIG. 8, the Service Provider reads the
handheld computer, the End User can interrogate the
unique lasered registration number (ID number) of the
module 10 to verify that the balance is correct.
40 module F1, F2 and calls on a transaction script 44 to return
c. Referring to FIG. 7, when the End User wishes to
the value of a random SALT object. The module 10 calcupurchase some goods or services from a Merchant E1,
lates a new random SALT value from the previous value and
the Merchant reads the unique lasered registration
the random number generator and returns it to the Service
number of the module and places it in a packet along
Provider F3.
with a random SALT E2, E3. The merchant then signs 45
2. The Service Provider places the random SALT returned
this packet with the merchant's own private key E4 and
by the module 10 in a packet along with the amount of
transmits the resulting encrypted packet along with the
money to be added and the unique lasered registration
amount of the purchase to the input data object of the
number of the module 10 and then encrypts the resulting
transaction group 40, E5.
packet with the Service Provider's private key F4. This
d. The Merchant then invokes the transaction script 44 50 encrypted packet is then written back into the input data
programmed into the module 10 by the Service Proobject of the transaction group 40.
vider. This transaction script 44 subtracts the amount of
3. The Service Provider invokes a transaction script 44
the purchase from the money object E6, appends the
which decrypts the contents of the input data object with the
value of the transaction counter object to the contents
Service Provider's public key and then checks the unique
of the input data object E7, signs the resulting packet 55 lasered registration number and the value of the random
with the private key, and places the result in the output
SALT against the one that it originally provided. If the SALT
data object E8.
matches, the money amount is extracted from the packet and
e. The Merchant then reads the result from the output data
added to the value of the money object in the module F5.
object and decrypts it with the Service Provider's
Note that the inclusion of the unique lasered registration
public key E9. He then confirms that the amount of the 60 number is not strictly necessary, but it is included to insure
purchase is correct and that the remaining data is
that the Service Provider knows exactly which module is
identical to the packet he signed in step c., E10.
receiving the funds.
E. EXEMPLARY DESCRIPTION OF DIRECT TRANSf. Having confirmed that the certificate provided by the
FER OF FUNDS BETWEEN MODULES
module 10 is both authentic and original (not a
duplicate), the Merchant delivers the goods or services 65
Section II.C.2.g. above reveals a problem that occurs
Ell. Later the Merchant sends the digital certificate to
when the Merchant returns the digital certificates to his bank
for crediting to his account. The Merchant's bank must
a bank.

US 6,237,095 Bl
11

12

either send the certificates back to the Service Provider for
2. The Payee appends the amount of the purchase to the
redemption, or have access to the Service Provider's records
Payer's SALT, followed by a SALT randomly generated by
in a database so that it can determine whether the value of
the Payee. The Payee then encrypts this packet with the
the transaction count object is unique. This is inconvenient
Service Provider's private key and sends it back to the Payer
and requires infrastructure. It also prevents any of the 5 H2.
transactions from being anonymous (as they would have
3. The Payer decrypts the packet with the Service Probeen if cash had been used), because the Merchant's bank
vider's public key H3, extracts the Payer SALT, and commust log used certificate numbers into a database to prevent
pares it with the SALT that the Payer provided in step 1. If
them from being reused. These problems can all be elimithey agree, the Payer subtracts the amount of the purchaser
nated by making use of fund transfers between modules. In 10
from its balance H4 and generates a certificate consisting of
addition, the steps required to accomplish a fund transfer
the amount of the purchase and the Payee's SALT, which it
between modules are considerably simpler than those
encrypts with the Service Provider's private key and returns
described in section II.C.2.
to the Payee H5.
In the discussion which follows, it is assumed that the
4. The Payee decrypts the packet with the Service ProMerchant also has a module which he uses to collect the
funds received from End Users (customers). The module in 15 vider's public key H6, extracts the Payee SALT, and compares it with the SALT that the Payee provided in step 2. If
the possession of the End User will be called the Payer, and
they agree, the Payee adds the amount of the purchase to its
the module in the possession of the Merchant will be called
balance H7.
the Payee. The steps to accomplish the funds transfer are as
The exchange of SALTs allows each module to confirm
follows:
1. Referring to FIGS. 9, 11 and 12, using his computer, the 20 that it is communicating with another module, and that the
Merchant calls on a transaction script 44 in the Payee to
funds transfer requested is therefore legitimate. The SALT
provide a random SALT. He reads this SALT from the output
comparison described in step 3 allows the Payer to confirm
object of the transaction group 40.
that the Payee is a legitimate module 10 before the funds are
2. The Merchant copies the SALT and the amount of the
withdrawn, and the comparison described in step 4 allows
End User's purchase to the input data object of the Payer Gl, 25 the Payee to confirm that the Payer is a legitimate module 10
then calls on a transaction script 44 in the Payer to subtract
before the funds are deposited. The transactions described
the amount of the purchase from the balance, combine the
above provide the minimum necessary information in the
Payee's SALT in a packet with the amount of the purchase,
encrypted packets to confirm that the funds are being
encrypt the resulting package with the Service Provider's
transferred from one module 10 to another. Other
private key, and return it in the output data object G2.
30
information, such as the unique lase red registration number,
3. The Merchant then reads this packet and copies it to the
could be included (at the cost of anonymity) to provide
input data object of the Payee, then calls on a transaction
additional information and greater control over the transacscript 44 in the Payee to decrypt the packet with the Service
tion.
Provider's public key G3 and check the SALT against the
G. AN EXEMPLARY TECHNIQUE FOR SOFTWARE
one originally generated by the Payee. If they agree, the
Payee adds the amount of the purchase to its balance G4. 35 AUTHORIZATION AND USAGE METERING
The module 10 is well-suited for the tasks of enabling
This completes the funds transfer. Note that this transacspecific software features in a comprehensive software systion effectively transferred the amount of the purchase from
tem and for metering usage of those features. (This usage
the Payer to the Payee, and the steps of the transaction were
model parallels the previously described model for withmuch simpler than the three-way transaction described in
II.C.2. The Merchant can transfer the balance to his bank 40 drawing money from a module 10.)
1. Preparation
account by a similar transaction in which the bank provides
a SALT to Merchant's module and the Merchant's module
Referring to FIGS. 11 and 12, the Service Provider creates
prepares a certificate for the balance which it delivers to the
a transaction group 40 and stores a configuration object in
bank. Use of a module by the Merchant to collect funds
the group detailing which software within the module 10 the
simplifies the transaction, eliminates the need for a database 45 End User is allowed to use. The Service Provider also
to confirm uniqueness, and preserves the anonymity of the
creates a money object containing the allowed usage credit
End User that would normally result from a cash transaction.
(which could be in units of time rather than the actual dollar
amount), and stores and privatizes a private RSAkey pair to
F. EXEMPLARY TRANSACTIONS WITH A MODULE
use for authentication. A transaction script 44 is stored to
OVER A NETWORK
The transactions described in section II.C.2., II.D. and 50 receive a SALT and the amount to withdraw from the End
II.E. above could also be performed over a network, allowUser, decrement the balance by the amount withdrawn, and
output an RSA signed certificate containing the amount
ing a physical separation between the Merchant, End User,
withdrawn, the sale, and the value of the configuration
and modules. However, this could produce a potential probobject.
lem because one of the communications to the module 10 is
2. Usage
unencrypted and therefore subject to falsification. To avoid 55
this problem, both parties must produce a SALT so that the
At periodic intervals during the use of the software within
other can demonstrate its ability to encrypt the SALT with
the module 10, the PC program generates a random SALT
the Service Provider's private key and therefore prove
and an amount to charge for the use of the module 10 and
authenticity. The operation of this protocol is described as
transmits this information to the module 10. The module 10
follows as it relates to the transfer of funds between modules 60 decrements the balance and returns the certificate. The PC
(section II.E. above). This method can be employed to allow
decrypts the certificate and confirms that the SALT is the
any of the transactions described above to take place over a
same, the amount withdrawn is correct, and the use of the
network. This clearly enables secure electronic commerce
software within the module 10 is authorized by the information stored in the configuration object. If all of these tests
over the Internet.
1. Referring to FIGS. 10, 11 and 12, the Payer generates 65 are successful, the module 10 executes for a specified period
a random SALT and transmits it over the network to the
of time or for a given number of operations before asking the
Payee HI.
module 10 for another certificate.

US 6,237,095 Bl

13

14

There are many possible variations on this usage model.
encrypts this packet with the private key, subtracts the
For example, the transaction script 44 could also bind up the
amount withdrawn from the balance, and places the
true time in the certificate so that the application program
encrypted certificate in the output object where it can be read
by the Pc.
running on the PC could guarantee that the execution time
The Service Provider initializes the balance with a speis accurately measured. (This would require the Service 5
Provider to create a clock offset object during initialization
cific amount of money, locks the balance and script 44,
to provide a reference for measuring time.)
privatizes the RSA key objects, and locks the group so that
H. SIMULATION OF TRANSACTION TOUCH
no more scripts can be added. The modules prepared in this
MEMORYTM
way can then be sold over the counter for use with PC-based
This usage model describes how the module 10 can be 10 postage metering programs.
used to simulate the behavior of the simpler Transaction
2. Usage
Touch MemoryTM (DS 1962) (hereinafter "TTM") or any
When the first envelope is to be printed, the PC program
similar device or substitute that can operate in a nearly
prepares the first SALT by calculating a one-way hash (e.g.,
equivalent or similar fashion. The principal feature of the
the Secure Hash Standard, FIBS PUB 180) of the date and
TTM is that there is a counter associated with a block of 15 the unique lasered registration number of the part. This
memory in such a way that the counter is incremented
information is passed to the module 10 along with the
automatically whenever the contents of the memory block
amount of postage to be withdrawn. The resulting certificate
are changed.
is printed in the two-dimensional barcode along with the
1. Preparation
hash generation number (one for the first hash), the unique
This simple feature can be programmed into the module 20 lasered registration number, the plaintext denomination of
10 by creating a configuration object, a transaction counter
the stamp, the date, and other information as desired to
object, and a transaction script object which combines the
identify the End User. Subsequent SALTs are generated by
contents of the input object with the value of the transaction
performing the one-way hash again on the previous SALT
and incrementing the hash generation number.
counter object and places them in the configuration object,
When the Service Provider receives the envelopes, most
incrementing the counter automatically in the process. All 25
three objects 42 are locked, but none are privatized.
of them are taken at face value and the digital barcode is not
2. Usage
read. However, a statistical sampling of the barcodes are
To add or remove money, the End User reads the values
read and the information provided is decrypted with the
of the configuration object and the transaction counter object
public key and verified. Discrepancies are investigated, and
directly, then decrypts the configuration object and checks 30 fraud is prosecuted under existing law. Verification is possible because the Service Provider can recreate the SALT
the transaction count from the decrypted package against the
from the unique lasered registration number, date, and hash
value of the counter object. The End User also checks the
unique lase red registration number from the encrypted
generation number, and thereby verify that the transaction is
packet against the registration number of the module 10. If
not only current but also linked to a specific module 10.
these both agree, the balance is considered valid. An amount 35
Note that there are many possible variations on the
is added to or subtracted from the balance, the transaction
method described above, leading to similar results. The most
count is incremented, and the packet is re-encrypted and
likely fraud would be duplication, in which a user captures
stored in the input data object. The transaction script 44 is
the digital information sent to the printer to produce the
then invoked to move the data and the transaction counter
postage certificate and makes many duplicate copies of the
value to the configuration object, automatically increment- 40 same certificate. This could be detected easily by the Service
ing the counter value in the process. (The transaction script
Provider simply by reading the hash generation number and
44 guarantees that the counter object's value will be increunique registration number and looking them up in a datamented anytime data in the configuration object is changed.)
base to make sure that the user is not duplicating the same
This simple operation can be performed relatively quickly
certificate. (This check could be performed more often than
since the module 10 does not have to perform any encryption 45 full certificate verification, which would require RSA
decryption.)
itself. However, as with the TTM, the End User must now
1. SUBSCRIPTION INFORMATION SERVICE
use a secure computing facility to perform the encryption
and decryption operations. This usage is therefore less
This usage model describes an application in which a
Service Provider makes available information in encrypted
protected than those which depend on the module's encryp50 form over the internet to users who have agreed to pay for
tion capabilities.
I. EXEMPLARY TECHNIQUE FOR POSTAL METERsuch information. This application works exactly the same
ING SERVICE
way as the Secure E-mail usage model described in section
This usage model describes an application in which the
A above, except that the Service Provider bills the user for
module 10 is used to dispense postage certificates. The
the encrypted information that the Service Provider e-mails
digital information which constitutes the certificate is 55 to him. The billing information is obtained from a registry of
printed on the envelope in the form of a two-dimensional
pubic RSA keys which allows the Service Provider to
identify and bill a user, based on his public key or on the
barcode which can be read and authenticated by the Service
unique lasered serial number of his module 10.
Provider (U.S.P'S.). A computer program running on an
ordinary PC attached to a laser printer in combination with
K. REGISTRY WITH GUARANTEED PRIVATE KEY
the module 10 can be used to print the postage certificates. 60 SECURITY
1. Preparation
In order to provide Merchants with an independent confirmation of the identity of an End User, a Service Provider
The Service Provider creates a group containing a money
register, a private RSA key (exponent object and modulus
may wish to maintain a registry containing the pubic key of
a particular module 10 along with the name, address, and
object) common to every module, and a transaction script
44. The script 44 combines the SALT and the amount to be 65 other identifying information of the person to whom the
withdrawn (provided by the End User's computer) with the
module 10 is issued. For this purpose, it is essential for the
Service Provider to make sure that the public key in the
unique lasered registration number of the module 10,

US 6,237,095 Bl
15

16

registry corresponds to a private key which is known only to
The model described here is one in which the authority to
the module 10. In order to guarantee this, the module 10
perform financial transactions derives from the registry
must be in the possession of the Service Provider at the time
maintained by the Service Provider. It is therefore essential
the public key is extracted from the module 10 and placed
that this information be accurate and that the private key in
in the registry. After recording this information in the 5 the module 10 can be secure from all parties. Because each
registry, the Service Provider can ship the module 10 to the
module 10 has its own unique RSA key set, there is no
End User named in the registry.
provision in this model for the module 10 to represent
It is also important for the End User to be able to confirm,
money independently of the registry maintained by the
when he receives the module 10, that the private key is not
Service Provider. Instead, the registry and the ability of the
known to the Service Provider or any of the Service Provider's employees. This is important because an ideal reg- 10 module 10 to sign with its private key together serve as a
istry system should not require that any party trust any other
definitive means of identifying the End User remotely to any
party. The system works to everyone's satisfaction only
other party.
when each party can be convinced that none of the other
L. TAXATION OF TRANSACTION VOLUME
parties could possibly know the private key.
This usage applies to a business model in which the
One way to accomplish this, the Service Provider sends a 15
Service Provider intends to collect a service charge from the
command to the module 10 to cause it to generate a complete
End User that is a percentage of the total amount of money
RSA key set using random numbers, and then to automatitransferred by the module 10. This model is similar to those
cally make one of the exponents private, so that there is no
described in sections C D, E, and F above, but with the
way any person can discover the value of the private key.
This key set has a special type, different from that of a key 20 addition of a destructor object that can cause any particular
transaction script 44 to expire at a predetermined date and
set programmed into the can by a Service Provider, so that
time. This model also requires the use of an additional
anyone doing business directly with the module 10 can
determine for themselves that the private key is known only
money object which is programmed (with a suitable transto the module 10.
action script 44) to accumulate the total value of all the
1. Preparation
25 money passed out of the module 10.
The Service Provider creates a password-protected trans1. Preparation
action group 40 for the application, and then creates an RSA
The Service Provider creates a transaction group 40
key set in the group that is generated by the module 10.
containing money objects, etc. as described in sections D
(After generating the key set, the modulus and one exponent
and E above. The Service Provider also creates an additional
will be locked automatically, while the second exponent will 30 money object to serve as the volume accumulator. The
be privatized automatically by the firmware of the module
Service Provider also creates transaction scripts 44 for
10. The Service Provider then creates a transaction script 44
withdrawing or depositing money as in D and E, except that
which will encrypt data from the input object with the
the transaction script for adding money to the module 10
private key and place the encrypted result in the output
includes a destructor object set to expire at a predetermined
object. The transaction script 44 might optionally append 35
time in the future, and the transaction script 44 for withadditional information (e.g., the transaction counter) to the
drawing money includes an instruction to add the amount of
data from the input object, in order to satisfy any additional
the withdrawal to the money object serving as the volume
objectives of the application. Other objects 42 and transacaccumulator. The service provider then locks the group and
tion scripts 44 may also be added at the discretion of the
Service Provider. The transaction group 40 is locked by the 40 ships the module 10 to the End User.
2. Usage.
Service Provider when it is complete.
The End user uses the module 10 for deposits and
Next, the Service Provider reads the RSA modulus and
withdrawals as described in sections D and E above. During
public exponent from the transaction group 40 and records
the time that the module 10 is used, the cumulative total of
them in the registry along with the information identifying
the End User. Finally, the Service Provider ships the module 45 all the money spent from the module 10 is accumulated in
10 to the End User, and later conveys to the End User the
the money object serving as the volume accumulator. When
password that can be used to access the transaction group 40.
the time limit expires, the End User can no longer add
money to his module 10, although he can continue to
2. Usage
withdraw money if desired until there is none left. The End
When a Merchant wishes to obtain positive identification
of an End User over the Internet or other network, the 50 User then returns the module 10 to the Service Provider to
Merchant generates a unique packet of data and transmits it
be restored. The Service Provider reads the remaining
to the End User, and the End User passes the data into the
amount of money and also the amount of money recorded in
input object and invokes the transaction script 44 which
the volume accumulator. The Service Provider bills the End
User a service charge that is a percentage of the amount in
causes it to be encrypted with the private key generated by
the module 10. The resulting encrypted packet is transmitted 55 the volume accumulator. If the End User is willing to pay
this amount to continue his service, the transaction group 40
back to the Merchant. The Merchant then accesses the data
is destroyed and rebuilt, then the amount of money remainbase provided by the Service Provider to obtain the public
key belonging to the End User, and attempts to decrypt the
ing in the module 10 when the End User returned it is
encrypted packet using the End User's public key. If the
programmed back into the money object of the transaction
decryption succeeds, the Merchant has proven the physical 60 group 40. The Service Provider then returns the restored
presence of the End User's module 10 at the remotely
module to the End User, provided that the End User pays the
networked location. By guaranteeing the presence of the
service charge.
End User's module 10 at the remote site, this identification
The system described above allows a Service Provider to
validates and legitimizes the contents of the data packet and
collect periodic fees for service without having to monitor
therefore also any financial transactions, represented by the 65 and be involved in every financial transaction performed by
contents of the packet, that may be requested by the End
the End user. The fee is based on actual usage, as determined
by the contents of the volume register.
User.

US 6,237,095 Bl
17

18

Exemplary Firmware Definitions for Use with the
Module

-continued

5
Object

Group

Group 10
Object ID

Object Type
PIN

Common PIN

Group PIN

Audit Trail
Locked Object

Private Object

Locked Group

Composite Object

The most primitive data structure
accepted by and operated on by the
modules firmware. A list of valid
objects and their definitions is
provided in the next section.
A self-contained collection of
objects. An object's scope is
restricted to the group of which it
is a member.
A number preferably between 0 and
255 representing a specific group.
A number preferably between 0 and
255 representing a specific object
within a specific group.
Preferably a 1-byte type specifier
that describes a specific object.
An alphanumeric Personal
Identification number that is
preferably eight bytes in length.
The PIN that controls access to
shared resources such as the audit
trail. It is also used to control
the host's ability to create and
delete groups.
The PIN that controls access to
operations specific to objects
within a group.
A record of transactions occurring
after the module has been locked.
An object which has been locked by
executing the lock object command.
Once an object is locked it is not
directly readable.
An object which has been privatized
by executing the privatize object
command. Once an object is private,
it is not directly readable or
writable.
A group which has been locked using
the locked group command. After a
group has been locked it will not
allow object creation.
A combination of several objects.
The individual objects inherit the
attributes of the composite object.

Exemplary Object Definitions

Transaction Script
10

15

Transaction Counter
20

25
Money Register

30

35

Clock Offset
40

45
SALT

RSAModulus

A large integer preferably of at
most 1024 bits in length. It is the
product of 2 large prime numbers
that are each about half the number
of bits in length of the desired
modulus size. The RSA modulus is
used in the following equations for
encrypting and decrypting a message
M:

(1)
(2)

RSA Exponent

Encryption: C ~ M' (mod N)
Decryption: M ~ Cd (mod N)
where C is the cyphertext, d and e
are the RSA exponents (see below),
and N is the RSA modulus.
Both e and d (shown in equations 1
and 2 above) are RSA exponents.
They are typically large numbers but
are smaller than the modulus (N).
RSA exponents can be either private
or public. When RSA exponents are
created in the module, they may be
declared as either. Once created an
exponent may be changed from a

50

55
Configuration Data

60

65

public exponent to a private
exponent. After an exponent has
been made private, however, it will
remain private until the transaction
group 40 to which it belongs is
destroyed.
A transaction script is a series of
instructions to be carried out by
the module. When invoked the module
firmware interprets the instructions
in the script and places the results
in the output data object (see
below). The actual script is simply
a list of objects. The order in
which the objects are listed
specifies the operations to be
performed on the objects.
transaction scripts 44 preferably
may be as long as 128 bytes.
The transaction counter object is
preferably 4 bytes in length and is
usually initialized to zero when it
is created. Every time a
transaction script, which references
this object, is invoked, the
transaction counter increments by 1.
Once a transaction counter has been
locked it is read only and provides
an irreversible counter.
The money register object is
preferably 4 bytes in length and may
be used to represent money or some
other form of credit. Once this
object has been created, it must be
locked to prevent a user from
tampering with its value. Once
locked the value of this object can
be altered only by invoking a
transaction script. A typical
transaction group 40 which performs
monetary transactions might have one
script for withdrawals from the
money register and one for deposits
to the money register.
This object is preferably a 4 byte
number which contains the difference
between the reading of the module's
real-time clock and some convenient
time (e.g., 12:00 a.m., January 1,
1970). The true time can then be
obtained from the module by adding
the value of the clock offset to the
real-time clock.
A SALT object is preferably 20 bytes
in length and should be initialized
with random data when it is created.
When a host transmits a generate
random SALT command, the module
combines the previous SALT with the
module's random number (produced
preferably by randomly occurring
power-ups) to generate a new random
SALT. If the SALT object has not
been privatized it may subsequently
be read by issuing a read object
command.
This is a user defined structure
with preferably a maximum length of
128 bytes. This object is typically
used to store configuration
information specific to its
transaction group 40. For example,
the configuration data object may be
used to specify the format of the
money register object (i.e., the
type of currency it represents).
Since this object has no pre-defined
structure, it may never be used by a
transaction object.

US 6,237,095 Bl

19

20
Possible error codes for the set common PIN command:

-continued
Input Data

Output Data

Random Fill

Working Register

ROM Data

An input data object is simply an
input buffer with preferably a
maximum length of 128 bytes. A
transaction group may have multiple
input objects. The host uses input
data objects to store data to be
processed by transaction scripts 44.
The output data object is used by
transaction scripts as an output
buffer. This object is
automatically created when the
transaction group is created. It is
preferably 512 bytes in length and
inherits password protection from
its group.
When the script interpreter
encounters this type of object it
automatically pads the current
message so that its length is 1 bit
smaller than the length of the
preceding modulus. A handle to this
object is automatically created when
the transaction group is created.
It is a private object and may not
be read using the read object
command.
This object is used by the script
interpreter as working space and may
be used in a transaction script. A
handle to this object is
automatically created when the
transaction group is created. It is
a private object and may not be read
using the read object command.
This object is automatically created
when the transaction group is
created. It is a locked object and
may not be altered using the write
object command. This object is 8
bytes and length and its contents
are identical to the 8 by ROM data
of the Micro-In-A-Can TM.

Preferred Module Firmware Command Set

5

Notes:
The PIN option byte may be the bitwise--{)r of any of the
following values:

PIN_TO ERASE
PIN_TO CREATE

OOOOOOOlb (require PIN for Master Erase)
00000010b (require PIN for group creation).

(Common PIN match failed)
(New PIN length> 8 bytes)
(Unrecognizable option byte)

10

For all commands described in this section, data received
by the host will be in the form of a return packet. A return
packet has the following structure:

15

Command status byte (0 if command successful, error
code otherwise, 1 byte)
Output data length (Command output length, 2 bytes)
Output data (Command output, length specified above).
Master Erase (02H)

20

25

30

35

40

Set Common PIN (OlH)

Transmit (to module)
OlH, old PIN, new PIN, PIN option byte
Receive data
CSB (command status byte) ~ 0 if successful,
appropriate error code otherwise
Output length ~ 0
Output Data ~ 0

ERR BAD COMMON_PIN
ERR BAD PIN_LENGTH
ERR BAD OPTION_BYTE

45

50

Transmit data
02H, Common PIN
Receive data
CSB = 0 if command was successful,
ERR_BAD COMMON_PIN otherwise
Output length ~ 0
Output data ~ 0

Notes:
If the LSB (least significant bit) of the PIN option is clear
(i.e. PIN not required for Master Erase) then a 0 is transmitted for the Common PIN value. In general this text will
always assume a PIN is required. If no PIN has been
established a 0 should be transmitted as the PIN. This is true
of the common PIN and group PINS (see below). If the PIN
was correct the firmware deletes all groups (see below) and
all objects within the groups. The common PIN and common
PIN option byte are both reset to zero.
After everything has been erased the module transmits the
return packet. The CSB is as described above. The output
data length and output data fields are both set to o.
Create Group (03H)

Transmit data
03H, Common PIN, Group name, Group PIN
Receive data
CSB ~ 0 if command successful, appropriate
error code otherwise
Output length ~ 1 if successful, 0 otherwise
Output data ~ Group 10 if successful, 0
otherwise

Notes:
The maximum group name length is 16 bytes and the
maximum PIN length is eight bytes. If the PIN_TO_
ss CREATE bit is set in the common PIN option byte and the
PIN transmitted does not match the common PIN the
module will set the OSC to ERR_BAD COMMON_PIN.
Possible error return codes for the create group command:
60

Initially the module has a PIN (Personal Identification
Number) of 0 (Null) and an option byte of o. Once a PIN has
been established it can only be changed by providing the old
PIN or by a Master Erase. However, if the PIN TO ERASE
bit is set in the option byte, the PIN can only be changed
through the set common PIN command.

ERR_BAD COMMON_PIN
ERR_BAD NAME_LENGTH
ERR_BAD PIN_LENGTH
ERR_MIAC_LOCKED
65 ERR_INSUFFICIENT_RAM

(Incorrect common PIN)
(If group name length> 16 bytes)
(If group PIN length> 8 bytes)
(The module has been locked)
(Not enough memory for new group)

US 6,237,095 Bl

21

22

Set Group PIN (04H)
-continued
Transmit data
04H, Group ID, old GPIN, new GPIN
Receive data
CSB ~ 0 if command successful, appropriate
error code otherwise
Output length ~ 0
Output data

~

0

10

Notes:
The Group PIN only restricts access to objects within the
group specified by the group ID transmitted in the command
packet.

20
(Group PIN match failed)
(New group PIN length> 8 bytes)

25

Create Object (OSH)

Transmit data
05H, Group ID, Group PIN, Object type, Object
attributes, Object data
Receive data
CSB ~ 0 if command successful, appropriate
error code otherwise
Output length ~ 1 if successful, 0 otherwise
Output data ~ object ID if successful, 0
otherwise

00000001b
00000010b

Objects may also be locked and privatized after creation
by using the Lock Object and Privatize Object commands
described below.
Lock Object (06H)

15

Possible error codes for the set group PIN command:

ERR BAD GROUP PIN
ERR BAD PIN_LENGTH

8
9

Locked
Privatized

5

Input data object
Output data object
Object Attributes:

30

Transmit data
06H, Group ID, Group PIN, Object ID
Receive data
CSB ~ 0 if command successful, appropriate
error code otherwise
Output length ~ 0
Output data ~ 0

Notes:
If the Group ID, Group PIN and Object ID are all correct,
the module will lock the specified object.
Locking an object is an irreversible operation.
Possible error return codes for the lock object command:

ERR_BAD GROUP PIN
ERR_GROUP LOCKED
35 ERR_MIAC_LOCKED
ERR_BAD GROUP ID
ERR_BAD OBJECT_ID

(Incorrect group PIN)
(The group has already been locked)
(The module has been locked)
(Specified group does not exist)
(Specified object does not exist)

Notes:
If the Create Object command is successful the module
firmware returns the object's ID within the group specified
by the Group ID. If the PIN supplied by the host was
incorrect or the group has been locked by the Lock Group
command (described below) the module returns an error
code in the CSE. An object creation will also fail if the
object is invalid for any reason. For example, if the object
being created is an RSA modulus (type 0) and it is greater
than 1024 bits in length. transaction script creation will
succeed if it obeys all transaction scripts rules.
Possible error return codes for the create object command:

Privatize Object (07H)
40

45

Transmit data
07H, Group ID, Group PIN, Object ID
Receive data
CSB = 0 if successful, appropriate error code
otherwise

Notes:
If the Group ID, Group PIN and Object ID were valid the
50
object will be privatized. Privatized objects share all the
properties of locked objects but are not readable. Privatized
objects are only modifiable through transaction scripts. Note
that locking a privatized object is legal, but has no meaning
55 since object privatization is a stronger operation than object
locking. Privatizing an object is an irreversible operation.
Possible error return codes for the privatize object command:

ERR BAD GROUP PIN
ERR GROUP LOCKED
ERR MIAC_LOCKED
ERR INVALID_TYPE
ERR BAD SIZE
ERR INSUFFICIENT_RAM
Object types:

(Incorrect group PIN)
(The group has been locked)
(The module has been locked)
(The object type specified is invalid)
(The objects length was invalid)
(Not enough memory for new object)

RSAmodulus
RSA exponent
Money register
Transaction counter
Transaction script
Clock offset
Random SALT
Configuration object

0

60

2
3
4
5

ERR _BAD GROUP PIN
ERR _GROUP LOCKED
ERR _MIAC_ LOCKED
ERR _BAD GROUP ID
65 ERR _BAD OBJECT_ID

7

(Incorrect group PIN)
(The group has already been locked)
(The module has been locked)
(Specified group does not exist)
(Specified object does not exist)

US 6,237,095 Bl
23

24

Make Object Destructable (OSH)

Transmit data
OSH, Group ID, Group PIN, Object ID
Receive data
CSB = 0 if successful, appropriate error code
otherwise

Possible error codes for the lock module command:

5

BAD GROUP PIN
GROUP LOCKED
MIAC_LOCKED
BAD GROUP ID
BAD OBJECT_ID

(Incorrect group PIN)
(The group has already been locked)
(The module has been locked)
(Specified group does not exist)
(Specified object does not exist)

Lock Module (09H)

Transmit data
09H, Common PIN
Receive data
CSB = 0 if successful, appropriate error code
otherwise
Output length ~ 2 if successful, 0 otherwise
Output data = audit trail size if successful,
o otherwise

25

Group ID

I Object ID I Daterrime stamp.

Once an audit trail has been established, a record of the
form shown above will be stored in the first available size
byte location every time a transaction script is executed.
Note that since the module must be locked before the audit
trail begins, neither the group ID nor any object ID is subject
to change. This will always allow an application processing
the audit trail to uniquely identify the transaction script that
was executed. Once the audit trail has consumed all of its
available memory, it will store new transaction records over
the oldest transaction records.

Transmit data
OAH, Group ID, Group PIN
Receive data
CSB ~ 0 if command successful, appropriate
error code otherwise
Output length ~ 0
Output data ~ 0

Notes:
If the group PIN provided is correct the module BIOS will
not allow further object creation within the specified group.
Since groups are completely self-contained entities they may
be deleted by executing the Delete Group command
(described below).

Possible error return codes for the lock group command:

30 ERR_BAD GROUP PIN
ERR_GROUP LOCKED
ERR_MIAC_LOCKED
ERR_BAD GROUP ID

35

40

Notes:
If the host supplied Common PIN is correct and the
module has not previously been locked, the command will
succeed. When the module is locked it will not accept any
new groups or objects. This implies that all groups are
automatically locked. The RAM not used by the system or
by groups will be used for an audit trail. There is no audit
trail until the module has successfully been locked!
An audit trail record is six bytes long and has the
following structure:

(Supplied common PIN was incorrect)
(Module was already locked)

Lock Group (OAR)

Notes:
10
If the Group ID, Group PIN and Object ID were valid the
object will be made destructable. If an object is destructable
it becomes unusable by a transaction script after the groups
destructor becomes active. If no destructor object exists 15
within the transaction group the destructible object attribute
bit has no affect. Making an object destructable is an
irreversible operation.
Possible error return codes for the make object destruc20
table command:

ERR
ERR
ERR
ERR
ERR

ERR_BAD COMMON_PIN
ERR_MIAC_LOCKED

(Incorrect group PIN)
(The group has already been locked)
(The module has been locked)
(Specified group does not exist)

Invoke Transaction Script (OBH)

Transmit data
OBH, Group ID, Group PIN, Object ID
Receive data
CSB ~ 0 if command successful, appropriate
error code otherwise
Output length ~ 1 if successful, 0 otherwise
Output data ~ estimated completion time

45

Notes:

50

The time estimate returned by the module is in sixteenths
of a second. If an error code was returned in the CSB, the
time estimate will be O.
Possible error return codes for the execution transaction
script command:

55
ERR_BAD GROUP PIN
ERR_BAD GROUP ID
ERR_BAD OBJECT_ID

60

65

(Incorrect group PIN)
(Specified group does not exist)
(Script object did not exist in group)

Read Object (OCH)

Transmit data
OCH, Group ID, Group PIN, Object ID
Receive data
CSB ~ 0 if command successful, appropriate

US 6,237,095 Bl

25

26
Notes:

-continued
error code otherwise
Output length ~ object length if successful, 0
otherwise
Output data ~ object data if successful, 0
otherwise

The group name length is a maximum of 16 bytes. All
byte values are legal in a group name.
5

Notes:
If the Group ID, Group PIN and Object ID were correct, 10
the module checks the attribute byte of the specified object.
If the object has not been privatized the module will transmit
the object data to the host. If the Group PIN was invalid or
the object has been privatized the module will return a 0 in
the output length, and data fields of the return packet.
15
Possible error codes for the read object command:

Delete Group (OFR)

Transmit data
OFH, Group ID, Group PIN
Receive data
CSB

=

0 if successful, appropriate error code

otherwise
Output length

~

~

0

Output data

0

Notes:
ERR
ERR
ERR
ERR

BAD GROUP PIN
BAD GROUP ID
BAD OBJECT_ID
OBJECT_PRIVATIZED

(Incorrect group PIN)
(Specified group does not exist)
(Object did not exist in group)
(Object has been privatized)

Write Object (ODR)

20

25

Transmit data
ODH, Group ID, Group PIN, Object ID, Object
size, Object Data
Receive data
CSB = 0 if successful, appropriate error code
otherwise
Output length ~ 0
Output data ~ 0

ERR_BAD GROUP PIN
ERR_BAD GROUP ID

(Incorrect group PIN)
(Specified group does

ERR MIAC LOCKED

30

(Module has been

not exist)
locked)

35

Notes:
If the Group ID, Group PIN and Object ID were correct,
the module checks the attribute byte of the specified object.
If the object has not been locked or privatized the module
will clear the objects previous size and data and replace it
with the new object data. Note that the object type and
attribute byte are not affected.
Possible error codes for the write object command:

If the group PIN and group ID are correct the module will
delete the specified group. Deleting a group causes the
automatic destruction of all objects within the group. If the
module has been locked the Delete Group command will
fail.
Possible error codes for the delete group command:

Get Command Status Info (lOR)

Transmit data
10H
Receive data
CSB ~ 0
Output length ~ 6
Output data ~ module status structure (see
below)

40

45
ERR_BAD GROUP PIN
ERR_BAD GROUP ID
ERR_BAD OBJECT_ID

(Object did not exist

ERR BAD OBJECT_SIZE

(Illegal object size

ERR _OBJECT_ LOCKED

(Object has been

ERR_OBJECT_PRIVATIZED

Notes:

(Incorrect group PIN)
(Specified group does

(Object has been

This operation requires no PIN and never fails. The status
structure is defined as follows:

not exist)
in group)

50

specified)
Last command executed
Last command status
Time command received

locked)
privatized)

(1 byte)
(1 byte)
(4 bytes)

55

Get Module Configuration Info (llR)

Read Group Name (OER)

60
Transmit data
OEH, Group ID
Receive data
CSB ~ 0
Output Length ~ length of group name
Output data ~ group name

65

Transmit data
llH
Receive data
CSB ~ 0
Output length ~ 4
Output data = module configuration structure

US 6,237,095 Bl
27

28

Notes:
This operation requires no PIN and never fails. The
configuration structure is defined as follows:

Possible error codes for the read audit trail command:

ERR_BAD COMMON_PIN
5
Number of groups
Flag byte (see below)
Audit trail size/Free RAM

(1 byte)
(1 byte)
(2 bytes)

(Common PIN was

incorrect)

Read Group Audit Trail (14H)
10

The flag byte is the bitwise---{)r of any of the following
values:

15
00000001b
00000010b

(Module is locked)
(Common PIN required for access)

Transmit data
14H, Group 10, Group
Receive data
CSB ~ 0 if command successful, appropriate
error code otherwise
Output length ~ # or records for group * 6 if
successful, 0 otherwise
Output data ~ audit trail records for group

Read Audit Trail Info (12H)
Notes:
This command IS identical to the read audit trail
command, except that only records involving the group ID
specified in the transmit data are returned to the host. This
allows transaction groups to record track their own activities
25 without seeing other groups records.
Possible error codes for the read group audit trail command:
20

Transmit data
12H, Common PIN
Receive data
CSB ~ 0 if command successful, appropriate
error code otherwise
Output length ~ audit trail structure size (5)
if successful, 0 otherwise
Output data ~ audit trail info structure if
successful, 0 otherwise

30

Notes:
If the transmitted Common PIN is valid and the module
has been locked, it returns audit trail configuration informati=~fulli~:

Number of used transaction records
Number of free transaction records
A boolean specifying whether or
not the audit trail rolled
since previous read command

~

(2 bytes)
(2 bytes)
(1 byte)

40

ERR BAD GROUP_!D
ERR BAD GROUP _PIN
ERR MIAC_NOT_LOCKED

(Group 10 does not exist)
(Common PIN was incorrect)
(The module is not locked)

Read Real Time Clock (1SH)

Transmit data
15H, Common PIN
Receive data
CSB ~ 0 if the common PIN matches and
ERR_BAD COMMON_PIN otherwise
Output length ~ 4
Output data ~ 4 most significant bytes of the
real time clock

Possible error codes for the read audit trail info command:
45

ERR_BAD COMMON_PIN
incorrect)
ERR_MIAC_NOT_LOCKED

(Common PIN was
(Module is not locked)

Notes:
This value is not adjusted with a clock offset. This
command is normally used by a service provider to compute
a clock offset during transaction group creation.
Read Real Time Clock Adjusted (16H)
50

Read Audit Trail (13H)

55
Transmit data
13H, Common PIN
Receive data
CSB ~ 0 if command successful, appropriate
error code otherwise
Output length ~ # of new records * 6 if
successful, 0 otherwise
Output data ~ new audit trail records

Notes:
If the transmitted common PIN is valid and the module
has been locked, it will transfer all new transaction records
to the host.

60

65

Transmit data
16H, Group !D, Group PIN, 10 of offset object
Receive data
CSB = 0 if successful, appropriate error code
otherwise
Output length ~ 4 if successful, 0 otherwise
Output data ~ Real time clock + clock offset !D

Notes:
This command succeeds if the group ID and group PIN
are valid, and the object ID is the ID of a clock offset. The
module adds the clock offset to the current value of the 4
most significant bytes of the RTC and returns that value in
the output data field. Note that a transaction script may be
written to perform the same task and put the result in the
output data object.

US 6,237,095 Bl

29

30

Possible error codes for the real time clock adjusted
command:

-continued

5
ERR BAD GROUP PIN
ERR BAD GROUP ID
ERR BAD OBJECT_TYPE

(Incorrect group PIN)
(Specified group does not exist)
(Object ID is not a clock offset)

Get Random Data (17H)

Transmit data
17H, Length (L)
Receive data
CSB = 0 if successful, appropriate error code
otherwise
Output length ~ L if successful, 0 otherwise
Output data ~ L bytes of random data if
successful

Notes:
This command provides a good source of cryptographically useful random numbers.
Possible error codes for the get random data command
are:

ERR BAD SIZE

code otherwise
Output length ~ 0
Output data ~ 0

Notes:
If the group ID specified exists in the module and the PIN
10 supplied is correct, the transaction group name is replaced
by the new group name supplied by the host. If a group ID
of 0 is supplied the PIN transmitted must be the common
PIN. If it is correct, the module name is replaced by the new
name supplied by the host.
Possible error codes for the change group name com15
mand:

ERR_BAD GROUP PIN
20 ERR_BAD GROUP ID
ERR_BAD NAME_LENGTH

(Incorrect group PIN)
(Specified group does not exist)
(New group name> 16 bytes)

ERROR CODE DEFINITIONS
25

This error code occurs when the module firmware does
not recognize the command just transmitted by the host.

(Requested number of bytes> 128)

30

Get Firmware Version ID (18H)

Transmit data
18H
Receive data
CSB ~ 0
Output length ~ Length of firmware version ID
string
Output data = Firmware version ID string

Notes:
This command returns the firmware version ID as a Pascal
type string (length+data).
Get Free RAM (19H)

Transmit data
19H
Receive data
CSB ~ 0
Output length ~ 2
Output data ~ 2 byte value containing the
amount of free RAM

35

40

Transmit data
1AH, Group 10, Group PIN, New Group name
Receive data
CSB = 0 if successful or an appropriate error

Transaction groups may have their own PIN, FIG. 11. If
this PIN has been set (by a set group PIN command) it must
be supplied to access any of the objects within the group. If
the Group PIN supplied does not match the actual group
PIN, the module will return the ERR_BAD_GROUP_PIN
error code.

45

50

55

Notes:
If the module has been locked the output data bytes will
both be 0 indicating that all memory not used by transaction
groups has been reserved for the audit trail.
Change Group Name (1AH)

This error code will be returned when a command
requires a common PIN and the PIN supplied does not match
the module's common PIN. Initially the common PIN is set
to O.

60

65

There are 2 commands which can change PIN values. The
set group PIN and the set common PIN commands. Both of
these require the new PIN as well as the old PIN. The
ERR_BAD_PIN_LENGTH error code will be returned if
the old PIN supplied was correct, but the new PIN was
greater than 8 characters in length.

The option byte only applies to the common PIN. When
the set common PIN command is executed the last byte the
host supplies is the option byte (described in command
section). If this byte is unrecognizable to the module, it will
return the ERR_BAD OPTION_BYTE error code.

When the create transaction group command is executed,
one of the data structures supplied by the host is the group's
name. The group name may not exceed 16 characters in
length. If the name supplied is longer than 16 characters, the
ERR_BAD_NAME_LENGTH error code is returned.

US 6,237,095 Bl

31

32

ERR_INSUFFI CIENT_RAM (86H)

ERR_OBJECT_PRIVATE (9IH)

The create transaction group and create object commands
return this error code when there is not enough heap available in the module.

Private objects are not directly readable or writable. If a
read object command or a write object command is
attempted, and it specifies the object ID of a private object,
the module will return an ERR OBJECT_PRIVATE error
code.

When the module has been locked, no groups or objects
can be created or destroyed. Any attempts to create or delete
objects will generate an ERR_MIAC_LOCKED error
code.

5

ERR_OBJECT_DESTRUCTED (92H)
10

If an object is destructible and the transaction group's
destructor is active the object may not be used by a script.
If a script is invoked which uses an object which has been
ERR_MIAC_NOT_LOCKED (88H)
destructed, an ERR_OBJECT_DESTRUCTED error code
If the module has not been locked there is no audit trail.
will be returned by the module.
If one of the audit trail commands is executed this error code 15
The exemplary embodiment of the present invention is
will be returned.
preferably placed within a durable stainless steel, token-like
can. It is understood that an exemplary module can be placed
ERR_GROUP_LOCKED (89H)
in virtually any articulatable item. Examples of articulatable
Once a transaction group has been locked object creation
items include credit cards, rings, watches, wallets, purses,
within that group is not possible. Also the objects attributes 20 necklaces, jewelry, ID badges, pens, clipboards, etc.
and types are frozen. Any attempt to create objects or modify
The module preferably is a single chip "trusted comtheir attribute or type bytes will generate an ERR
puter". By the word "trusted" it is meant that the computer
GROUP_LOCKED error code.
is extremely secure from tampering by unwarranted means.
The module incorporates a numeric coprocessor optimized
ERR_BAD_OBJECT_TYPE (8AH)
25 for math intensive encryption. The BIOS is preferably
When the host sends a create object command to the
immune to alteration and specifically designed for very
module, one of the parameters it supplies is an object type
secure transactions.
(see command section). If the object type is not recognized
Each module can have a random "seed" generator with
by the firmware it will return an ERR_BAD_OBJECT_
30 the ability to create a private/public key set. The private key
TYPE error code.
never leaves the module and is only known by the module.
ERR_BAD_OBJECT_ATTR (8BH)
Furthermore, discovery of the private key is prevented by
active self-destruction upon wrongful entry into the module.
When the host sends a create object command to the
The module can be bound to the user by a personal identimodule, one of the parameters it supplies is an object
attribute byte (see command section). If the object attribute 35 fication number (PIN).
When transactions are performed by the module certifibyte is not recognized by the firmware it will return an
cates of authentication are created by either or both the
ERR_BAD OBJECT_ATTR error code.
module and a system the module communicates with. The
certificate can contain a variety of information. In particular,
An ERR_BAD_SIZE error code is normally generated 40 the certificate may contain:
1) who is the module user via a unique registration
when creating or writing an object. It will only occur when
number.
the object data supplied by the host has an invalid length.
2) when the transaction took place via a true-time stamping of the transaction.
All commands that operate at the transaction group level 45
3) where the transaction took place via a registered
require the group ID to be supplied in the command packet.
module interface site identification.
If the group ID specified does not exist in the module it will
4) security information via uniquely serialized transacgenerate an ERR_BAD_GROUP_ID error code.
tions and digital signitures on message digests.
5) module status indicated as valid, lost, or expired.
ERR_BAD_OBJECT_ID (8EH)
50
Although a preferred embodiment of the method and
All commands that operate at the object level require the
apparatus of the present invention has been illustrated in the
object ID to be supplied in the command packet. If the object
accompanying Drawings and described in the foregoing
ID specified does not exist within the specific transaction
Detailed Description, it will be understood that the invention
group (also specified in the command packet) the module
55 is not limited to the embodiment disclosed, but is capable of
will generate an ERR_BAD_OBJECT_ID error code.
numerous rearrangements, modifications and substitutions
without departing from the spirit of the invention as set forth
ERR_INSUFFICIENT_FUNDS (8FH)
and defined by the following claims.
If a script object that executes financial transactions is
What is claimed is:
invoked and the value of the money register is less than the
1. An apparatus for receiving and transmitting encrypted
withdrawal amount requested an ERR_INSUFFICIENT_ 60
data, comprising:
FUNDS error code will be returned.
an input/output interface for receiving a challenge number
ERR_OBJECT_LOCKED (90H)
from an electronic device;
a microprocessor circuit connected to said input/output
Locked objects are read only. If a write object command
interface;
is attempted and it specifies the object ID of a locked object 65
the module will return an ERR OBJECT_LOCKED error
a coprocessor circuit, connected to said microprocessor
code.
circuit;

US 6,237,095 Bl

33

34

a tlmmg circuit connected to the microprocessor, the
4. The apparatus of claim 1, wherein said apparatus is
timing circuit for generating a time stamp;
capable of producing random encryption key pairs.
a first memory connected to said microprocessor circuit,
5. The apparatus of claim 1, further comprising memory
said first memory for storing a first data object; and
means for storing a predetermined program, said memory
a second memory connected to said microprocessor 5 means being connected to said microprocessor.
circuit, said second memory including instructions
6. The apparatus of claim 1, further comprising a transreadable by said microprocessor circuit to thereby
action counter for counting a number of transactions that
cause said microprocessor circuit to:
said apparatus performs, said transaction counter being
initiate generation of a certificate, said certificate
connected to said microprocessor.
including said challenge number and a second data 10
7. The apparatus of claim 1 wherein said first data object
object; and
includes a base monetary amount and wherein said second
adjust said first data object according to said second
data object includes a transaction monetary amount.
data object responsive to a verification signal from
8. The apparatus of claim 6 wherein the second memory
said electronic device;
store a transaction script, the transaction script includ- 15 further comprises instructions readable by said microprocessor circuit to thereby cause said microprocessor circuit to
ing at least a representation of the time stamp genstore a verification for one of said transactions, said verifierated by the timing circuit.
cation including a value of said transactions counter for said
2. The apparatus of claim 1, wherein said apparatus is
one of said transactions and an encrypted signature.
programmable.
3. The apparatus of claim 2, wherein said apparatus is 20
programmable via object oriented software.
* * * * *