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 C
UNITED STATES PATENT NO.
6,105,013

111111

United States Patent

[19]

Curry et ai.
[54]

METHOD, APPARATUS, SYSTEM AND
FIRMWARE FOR SECURE TRANSACTIONS
Inventors: Stephen M. Curry, Dallas; Donald W.
Loomis, Coppell; Christopher W. Fox,
Dallas, all of Tex.

[73]

Assignee: Dallas Semiconductor Corporation,
Dallas, Tex.

[21]

Appl. No.: 09/041,190

[22]

Filed:

Mar. 10, 1998
Related U.S. Application Data

[60]
[51]
[52]
[58]

Continuation of application No. 08/594,983, Jan. 31, 1996,
Pat. No. 5,748,740.
Provisional application No. 60/004,510, Sep. 29, 1995.
Int. CI? ................................. H04L 9/00; H04L 9/30
U.S. CI. .............................. 705/65; 235/379; 380/30;
705/75; 713/156; 713/173; 713/174
Field of Search ............................... 380/4, 9, 21, 23,
380/24, 25, 30, 46, 49, 50; 235/379, 380;
705/64, 65, 66, 67, 68, 69, 75; 713/155,
156,157,158,168,172,173,174

[56]

References Cited
U.S. PATENT DOCUMENTS
4,731,842
5,577,120
5,748,740

US006105013A

[11]

[45]

[75]

[63]

1111111111111111111111111111111111111111111111111111111111111

3/1988 Smith ........................................ 380/24
11/1996 Penzias ..................................... 380/23
5/1998 Curry et al. .............................. 380/25

FOREIGN PATENT DOCUMENTS
0172670A2. 2/1986
0186981A2. 7/1986
0194839A2. 9/1986
0294248A1 12/1988
0337185A2. 10/1989
045806A2. 11/1991
0624014A2. 11/1994
4406602A1
9/1995
W093/08545 4/1993

European Pat.
European Pat.
European Pat.
European Pat.
European Pat.
European Pat.
European Pat.
Germany.
WIPO.

Off..
Off..
Off..
Off..
Off..
Off..
Off..

Patent Number:
Date of Patent:

6,105,013
Aug. 15, 2000

OTHER PUBLICATIONS
Federal Information Processing Standards Publication,
(FIPS PUB) 186, Digital Signatur Standard (DDS), Issued:
May 19, 1994.
Federal Information Processing Standards Publication,
(FIPS PUB) 190-1, Secure Hash Standard, Issued: May 31,
1994.
Microsoft Corporation's Secure Transaction Technology,
SIT Wire Formats and Protoc version 0.902, Oct. 5, 1995.
Matonis, Jon W., Digital Cash and Monetary Freedom,
http://www.info.isoc.org/HMP/PAPER/136/htm1!paper.html, as of Apr. 1995.
MasterCard, Secure Electronic Payment Protocol, Draft
Version 1.1, Sep. 29, 1995.
MasterCard, Secure Electronic Payment Protocol, Part 2;
Functional Specifications, Draft Version 1.1, Sep. 29, 1995.
MasterCard, Secure Electronic Payment Protocol, Part 3;
Payment System Specification, Draft Version 1.1, Sep. 29,
1995.
MasterCard, Secure Electronic Payment Protocol, Part 4;
Certificate Management Specification, Draft Version 1.1,
Sep. 29, 1995.
SGS-Thomson Microelectronics, CMOS Crypto--Computer
Family, Advance Datasheet ST16xF74, Oct., 1993.
SGS-Thomson Microelectronics, CMOS MCU Based Safeguarded Smartcard IC with Modular Aritmetic Processor,
Advanced Data Sheet, ST16CF54, Sep. 1994.
Micro Card, CP8® Products Crypto Card, Jan. 25, 1995.
Wayner, Peter, Digital CaSh, Commerce on the Net, Chpt. 3
& 10 and Appendix B, Jun. 1995.
Schneier, Bruce, Applied Cryptography, Chpt. 19, pp.
461-482, 1996.
Primary Examiner-Bernarr E. Gregory
Attorney, Agent, or Firm-Jenkens & Gilchrist
[57]

ABSTRACT

The present invention relates to an electronic module used
for secure transactions. More specifically, the electronic
module is capable of passing 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.
16 Claims, 8 Drawing Sheets

12

18

28

30
26

32

u.s.

Patent

Aug. 15,2000

6,105,013

Sheet 1 of 8

~10

12
MICRO PROCESSOR

~---I

_r-16

18
MICRO PROCESSOR

22
20
24

ROM
NVRAM

28
30

+V
34

26
32

MODULE

FIG. 1
CREATE TRANSACTION GROUP

Sl

GENERATE KEYS AND LOAD
INTO A TRANSACTION GROUP

S2

PRIVATIZE DECRYPTION EXPONEN

S3

CREATE TRANSACTION SCRIPT
LOCK TRANSACTION GROUP

FIG. 2

S4
S5

u.s.

Patent

Aug. 15,2000

6,105,013

Sheet 2 of 8

USER RECEWES SECURE E-M~L
AND ENCRYPTED IDEA KEY

~

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

~

t

FIG. 3

TRANSACTION SCRIPT DECRYPTS
THE IDEA KEY

t
DECRYPTED IDEA KEY IS PLACED
IN AN OUTPUT DATA OBJECT

~

CREATE TRANSACTION GROUP FOR
PERFORMING ELECTRONIC
NOTARY FUNCTIONS

t
CREATE OBJECT(S) FOR
RSA ENCRYPTION KEYS

~

FIG. 4

A5

V- B2
B3

CREATE OBLECT FOR TIMEKEEPING

t

A3

V- B1

~

CREATE TRANSACTION SEQUENCE
OBJECT (COUNTER)

A2

r-- A4

t
IDEA KEY IS USED TO DECRYPT
THE SECURE E-MAIL

A1

V- B4

t
CREATE A TRANSACTION SCRIPT THAT CREATES VA 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

t

l
t
I LOCK TRANSACTION GROUP
PRIVATE OBJECTS

B6
B7

B5

u.s.

Patent

Aug. 15,2000

6,105,013

Sheet 3 of 8

,

MESSASGE IS PLACED IN AN
INPUT DATA OBJECT

V- C1

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

V- C2

~

THE CERTIFICATE CAN BE READ AT AV- C3
LATER TIME BY DECRYPTING IT
WITH THE PUBLIC KEY

,

THE CERTIFICATE AND ORIGINAL
DOCUMENT CAN BE
STORED ELECTRONICALLY

V- C4

FIG. 5
PREPARE MODULE
D1

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

~

D2

PRIVATIZE PRIVATE KEY RELATED OBJECT(S)

~

,
,

CREATE TRANSACTION SCRIPT TO
PERFORM MONETARY TRANSACTION
LOCK TRANSACTION GROUP
PUBLISH PUBLIC KEY

FIG. 6

V- D3
D4
D5

u.s. Patent

Aug. 15,2000

USER
USER WANTS TO MAKE
A PURCHASE
USING A MODULE

MERCHANT

r--

BANKf-SERVICE PROVIDER

READS MODULE'S
10 NUMBER

V

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

t
CREATES A SIGNED
MERCHANT CERTIFICATE
BY ENCRYPTING DATA
PACKET WITH
MERCHANT'S PRIVATE KEY

t
SUBTRACT PURCHASE
AMOUNT FROM
MONEY REGISTER

t--

t
INCREMENT
TRANSACTION COUNT

V

6,105,013

Sheet 4 of 8

ATIACHES PURCHASE
PRICE TO MERCHANT'S
SIGNED CERTIFICATE

E2

VE3

V-- E4

V-- E5

E7

t

COMBINE TRANSACTION V- E8
COUNT WITH MERCHANT'S
SIGNED CERTIFICATE
RECEIVED SIGNED MODULE V- E9
AND PURCHASE AMOUNT;
CERTIFICATE AND DECRYPT
THEN ENCRYPT WITH
USING SERVICE PROVIDER'S
SERVICE PROVIDER'S
PUBLIC KEY
E12
PRIVATE KEY THEREBY
CREATING A SIGNED
---.l
MODULE CERTIFICATE
CONFIRM THAT:
__
RECEIVE MODULE'S
1) AMOUNT OF PURCHASE
SIGNED CERTIFICATE
RECEIVE ITEM
IS CORRECT
t
2) DATA IN MERCHANT'S
SERVICE PURCHASED
CERTIFICATE IS THE
DECRYPT MODULE'S
SAME AS ORIGINALLY SENT
CERTIFICATE WITH SERVICE
Ell)
PROVIDER'S PUBLIC KEY
)
E10
E13~
Jl

r--

t

\

r--

DECRYPT MODULE'S
CERTIFICATE WITH
. ~ MERCHANT'S PUBLIC KEY
E14
1

FIG. 7

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

u.s. Patent

Aug. 15,2000

USER
F1

F3

F5

\

\

\

WANTS TO ADD AN
AMOUNT OF CASH
TO MODULE

CREATE RANDOM
SALT NUMBER

DECRYPT SIGNED SERVICE
PROVIDER CERTIFICATE
WITH SERVICE PROVIDER'S
PUBLIC KEY AND CHECK
THE ID NUMBER AND
RANDOM SALT NUMBER
IF THE ID NUMBER
AND RANDOM SALT NUMBER
IS UNCHANGED THEN ADD
THE CASH AMOUNT TO THE
MONEY REGISTER
OF THE MODULE

6,105,013

Sheet 5 of 8

BANK/SERVICE PROVIDER

~

READ MODULE ID
NUMBER AND AMOUNT
OF CASH REQUESTED

v---

REQUEST MODULE TO
PRODUCE A RANDOM SALT

~

COMBINE SALT, ID NUMBER
AND CASH AMOUNT AND
ENCRYPT WITH SERVICE
PROVIDER'S PRIVATE KEY,
THEREBY CREATING A
SIGNED SERVICE
PROVIDER CERTIFICATE

/

/

F2

F4

I
FIC. B

EXAMPLE OF
TRANSFER FROM USER'S MODULE TO MERCHANT'S MODULE
USER/PAYER
MERCHANT/PAYEE
RECEIVE SALT AND
REQUEST FOR MONEY
G2

\

SUBTRACT REQUESTED
MONEY AMOUNT FROM
A MONEY REGISTER

1. CREATE RANDOM SALT
2. DETERMINE-AMOUNT OF
MONEY TO BE
RECEIVED FROM PAYER

G1

V

G3

V

G4

+

CREATE SIGNED PAYMENT
CERTIFICATE BY COMBINING
SALT WITH PAYMENT
AMOUNT THEN ENCRYPTING
WITH BANKER/SERVICE
PROVIDER'S ORIVATE KEY

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

PAYEE = MERCHANT
PAYER = USER

~GAINST ORIGINALLY SENT SALT

FIC. 9

V

~
CHECK DECRYPTED SALT

IF THEY ARE THE
SAME ADD PAYMENT AMOUNT
TO MONEY REGISTER

u.s. Patent

Aug. 15,2000

6,105,013

Sheet 6 of 8

TRANSACTION OVER A NETWORK WITH A MODULE
MERCHANT/PAYEE
H1

~

CREATE RANDOM
PAYER SALT

~
H3

RECEIVE FIRST DATA PACKET

~ AND DECRYPT WITH SERVICE

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

H2

PROVIDER'S PUBLIC KEY

~
COMPARE DECRYPTED
PAYER SALT WITH ORIGINAL
PAYER SALT
H4

IF THEY ARE THE SAME,
SUBTRACT AMOUNT OF MONEY
~
TO BE SENT FROM
PAYER MONEY REGISTER

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

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

V

H6

~

FIC. 10

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

V

H7

u.s. Patent

Aug. 15,2000

6,105,013

Sheet 7 of 8

READ/WRITE OBJECT COMMANDS
MODULE
10
-

LOCKED
TRANSACTION
GROUP
PIN
r- MATCH

44
"

H

v

~ OBJECTS (O)I
OPEN

40

~42
~42

r
r 42
~ LOCKED ( ) r
OBJECTS L

SCRIPTS}K PRIVATE (p)
OBJECTS

READ ONLY OBJECT COMMAND
READ/WRITE OBJECT COMMANDS
LOCKED
TRANSACTION
GROUP
1-WIRE

1/0

DATA
TRANSPORT
LAYER

~

COMMAND
PIN
INTER- l- I- MATCH
PRETER

V 40

J
HSCRIPTS}H OBJECTS (P)J
PRIVATE
~ OBJECTS (L)J
LOCKED
44
"

~ OBJECTS (0)
OPEN

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

"- MATCH

44,

,.-40

~ O~fE~~S (0)J

--/ SCRIPTS tK PRIVATE (P)
OBJECTS

FIG. 11

J

~ OBJECTS (L)
LOCKED

I

READ ONLY OBJECT COMMAND

u.s.

Patent

Aug. 15,2000

6,105,013

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
WORKING REGISTER

40 ~
40
~

GROUP NAME,
PASSWORD AND ATIRIBUTES
OBJECT 1

V

42

OBJECT 2
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-CANTM
HAS BEEN LOCKED

GROUP OBJECT DATE/TIME
10
10
STAMP

ONCE LOCKED ALL
UNUSED RAM IS
ALLOCATED FOR
THE AUDIT TRAIL

FIG.

12

V- 42

6,105,013
1

2

METHOD, APPARATUS, SYSTEM AND
FIRMWARE FOR SECURE TRANSACTIONS

BRIEF DESCRIPTION OF THE DRAWINGS

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
This application is a continuation of application Ser. No. 5 with the accompanying Drawings wherein:
08/594,983 filed Jan. 31, 1996, now U.S. Pat. No. 5,748,740,
FIG. 1 is a block diagram of an embodiment of a module;
and claims the benefit of U.S. Provisional Application No.
FIG. 2 is an exemplary process for creating a transaction
60/004,510, filed Sep. 29, 1995.
group;
The following applications of common assignee contain
FIG. 3 is an exemplary technique for receiving an E-mail
10
related subject matter and are hereby incorporated by refmessage;
erence:
FIG. 4 is an exemplary technique for preparing a module
Ser. No.: 08/595,014, filed Jan. 31, 1996, entitled
for notary functions;
METHOD, APPARATUS, AND SYSTEM FOR TRANSFIG. 5 is an exemplary technique for using the module as
FERRING UNITS OF VALUE, now U.S. Pat. No. 5,805, 15 a notary;
702;
FIG. 6 is an exemplary technique for preparing a module
Ser. No.: 08/594,975, filed Jan. 31, 1996, entitled
to perform a money transaction;
TRANSFER OF VALUABLE INFORMATION
FIG. 7 is an exemplary technique for performing a money
BETWEEN A SECURE MODULE AND ANOTHER
20 transaction using a module;
MODULE, now pending.
FIG. 8 is an exemplary technique for performing a money
transaction using a module;
BACKGROUND OF THE INVENTION
FIG. 9 is an exemplary technique for performing a money
1. Technical Field of the Invention
transaction using a module;
The present invention relates to a method, apparatus and
FIG. 10 is an exemplary technique for passing data over
firmware used for secure transactions. In particular, in an 25
a network;
electronic module based system, the module can be configFIG. 11 is an exemplary organization of the software and
ured to provide at least secure data transfers, digital signafirmware within a module; and
tures or to authorize monetary transactions.
FIG. 12 is an exemplary configuration of software and
2. Description of Related Art
30 firmware within a module.
Presently, credit cards that have a magnetic strip associated with them, are a preferred monetary transaction
DETAILED DESCRIPTION OF A PRESENTLY
medium in the market place. A card user can take the card
PREFERRED EXEMPLARY EMBODIMENT
to an automatic cash machine, a local store or a bank and
FIG. 1 depicts a block diagram of an exemplary module
make monetary transactions. In many instances the card is 35
10 that incorporates an exemplary embodiment of the
used via a telephone interface to make monetary exchanges.
present invention. The module circuitry can be a single
The magnetic strip card is used to help identify the card and
integrated circuit. It is understood that the module 10 could
user of the card. The card provides a relatively low level of
also be on multiple integrated or descrete element circuits
security for the transfer. Regardless, the card enables a card
combined together. The module 10 comprises a microproholder to buy products, pay debts and make monetary 40
cessor 12, a real time clock 14, control circuitry 16, a math
exchanges between separate bank accounts.
coprocessor 18, memory circuitry 20, input/output circuitry
Improvements have been made to the magnetic strip card.
26, and an energy circuit.
There have been cards created with microcircuits instead of
The module 10 could be made small enough to be
magnetic strips. In general the microcircuit, like a magnetic
incorporated into a variety of objects including, but not
strip, is used to enable a card-reader to perform a transaction. 45
limited to a token, a card, a ring, a computer, a wallet, a key
fob, badge, jewelry, stamp, or practically any object that can
SUMMARY OF THE INVENTION
be grasped and/or articulated by a user of the object.
The present invention is an apparatus, system and method
The microprocessor 12 is preferably an 8-bit
for communicating encrypted information between a pref50 microprocessor, but could be 16, 32, 64 or any operable
erably portable module and a service provider's equipment.
number of bits. The clock 14 provides timing for the module
The invention comprises a module, that has a unique
circuitry. There can also be separate clock circuitry 14 that
identification, that is capable of creating a random number,
provides a continuously running real time clock.
for example, a SALT, and passing the random number, along
The math coprocessor circuitry 18 is designed and used to
with, for example, a request to exchange money, to a service
provider's equipment. The service provider's equipment 55 handle very large numbers. In particular, the coprocessor
will handle the complex mathematics of RSA encryption and
may in return encrypt the random number with a private or
decryption.
public key (depending on the type oftransaction), along with
The memory circuitry 20 may contain both read-onlyother information and pass the encrypted information back
memory and non-volatile random-access-memory.
to the module as a signed certificate. The module, upon
receiving the signed certificate, will decrypt the certificate 60 Furthermore, one of ordinary skill in the art would understand that volatile memory, EPROM, SRAM and a variety of
with a public or private key (depending on the type of
other types of memory circuitry could be used to create an
transaction) and compare the decrypted number with the
equivalent device.
original random number. Furthermore, if the numbers are the
Control circuitry 16 provides timing, latching and various
same then the transaction that was requested may be deemed
secure and thereby proceeds. The module is capable of time 65 necessary control functions for the entire circuit.
stamping and storing in memory information about the
An input/output circuit 26 enables bidirectional commutransaction for later review.
nication with the module 10. The input/output circuitry 26
RELATED APPLICATIONS

6,105,013

3

4

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

II. USAGE MODELS OF THE MODULE

65

This section presents a series of practical applications of
the module 10, ranging from the simplest to the most
complex. Each of these applications is described in enough
detail to make it clear why the module 10 is the central
enabling technology for that application.

6,105,013

5

6

A. Background of Secure E-Mail
a. Referring to FIGS. 2, 11 and 12, the user creates a
transaction group 40, SI, generates an RSA key set S2 and
In this section we provide an example of how a module 10
loads it into three objects 42 of the transaction group 40 (one
could be used to allow anyone to receive his or her own
RSA modulus object, N, and two RSA exponent objects, E
e-mail securely at any location.
5 and D). He then privatizes the decryption exponent S3, D.
1. Standard E-Mail
Finally, he creates a transaction script 44, S4 to take data
In a standard e-mail system, a user's computer is conplaced in the input data object, encrypt it with the modulus
nected to a provider of Internet services, and the user's
N and private exponent D and place the result in the output
computer provides an e-mail password when polling the
data object. He locks the group S5 to prevent any additional
provider's computer for new mail. The mail resides on the
provider's computer in plain text form, where it can be read 10 transaction scripts 44 from being added. He "forgets" the
value of D and publishes the values of E and N in public
by anyone working there. In addition, while traveling from
directories and in the signature blocks of his e-mail mesits source, the mail passes through many computers and was
sages. Since he has forgotten D and since the D exponent
also exposed at these locations. If the user receives his mail
object has been privatized, there is no way that anyone will
from his provider over a local area network, anyone else on
the same network can capture and read the mail. Finally, 15 ever find out the value of D.
b. Referring to FIG. 3, to send secure e-mail to the user,
with many e-mail systems that do not require the user to
the P.G.P. system is used. When the user receives the secure
enter the password, anyone sitting at the user's computer can
e-mail AI, he transmits the encrypted IDEA key into the
retrieve and read his mail, since his computer automatically
input data object of the transaction group 40, A2 and then
provides the password when it polls the provider's comcalls the transaction script 44 to decrypt this key A3 and
puter.
It is frequently also possible to copy the password from a 20 place the decrypted result in the output data object A4. He
configuration file in the user's computer and use it to read his
then reads the decrypted IDEA key from the output data
mail from a different computer. As a result of this broad
object and uses it to decrypt his mail A5. Note that it is now
distribution of the e-mail in plain text form and the weakness
impossible for anyone, including the user, to read any new
of password protection, standard e-mail is regarded as very
mail without having physical possession of the module 10.
msecure.
25 There is therefore no way that a user's mail can be read
To counter this problem, the security system known as
without his knowledge, because the module 10 must be
P.G.P. (Pretty Good Privacy) was devised. To use P.G.P., a
physically present on the computer where the mail is read.
user generates a complete RSA key set containing both a
The user can carry his module 10 wherever he goes and use
public and private component. He makes his public key
it to read his forwarded mail anywhere. His home computer
widely available by putting it in the signature block of all his 30 is not the weak point in the security system.
e-mail messages and arranging to have it posted in publicly
Secure e-mail, as described above, is the simplest possible
accessible directories of P.G.P. public keys. He stores his
module application, requiring only one RSA key and one
private key on his own personal computer, perhaps in a
transaction script 44. It is unnecessary even to store the
password-protected form. When someone wishes to send
public key E in the module 10, but it is a good idea to do so
private e-mail to this user, he generates a random IDEA 35 because the public key is supposed to be publicly accessible.
encryption key and encrypts the entire message with the
By storing E in an exponent object and not privatizing that
IDEA encryption algorithm. He then encrypts the IDEA key
object or the modulus object, N, the user insures that the
itself using the public key provided by the intended recipipublic key can always be read from the module 10. There are
ent. He e-mails both the message encrypted with IDEA and
no transaction scripts 44 involving E because the module 10
the IDEA key encrypted with the user's public key to the 40 will never be required to perform an encryption.
user. No one that sees this transmission can read it except the
B. Digital Notary Service
intended recipient because the message is encrypted with
IDEA and the IDEA key is encrypted with the intended
This section describes a preferred notary service using the
recipient's public key. The recipient's computer contains the
module 10.
corresponding private key, and hence can decrypt the IDEA 45 1. Background of a Standard Notary Service
key and use the decrypted IDEA key to decrypt the message.
A conventional Notary Service Provider receives and
This provides security from those who might try to read the
examines a document from an End User and then supplies an
user's mail remotely, but it is less effective when the user's
uncounterfeitable mark on the document signifying that the
document was presented to the notary on a certain date, etc.
computer is accessible to others because the computer, itself,
contains the private key. Even if the private key is password 50 One application of such a notary service could be to record
protected, it is often easy to guess the user's password or
disclosures of new inventions so that the priority of the
eavesdrop on him when he enters it, so the user's computer
invention can later be established in court if necessary. In
provides little security. In addition, the user can receive
this case, the most important service provided by the notary
secure e-mail only at his own computer because his private
is to certify that the disclosure existed in the possession of
key is stored in that computer and is not available elsewhere. 55 the inventor on a certain date. (The traditional method for
establishing priority is the use of a lab notebook in which
Therefore, the weakness of P.G.P. is that it is tied strongly to
the user's computer where the private key resides.
inventors and witnesses sign and date disclosures of signifi2. Module Protected E-Mail
cant inventions.)
2. Electronic Notary Service Using The Module
With the exemplary module 10 being used to protect
e-mail, a user could have his e-mail forwarded to him 60
A company, hereafter referred to as the Service Provider,
decides to go into business to supply a notary service
wherever he goes without fear that it would be read by others
(strictly, a priority verification service) for its customers,
or that his PC would be the weak link that compromises the
hereafter referred to as the End Users. The Service Provider
security of his mail. The module protected e-mail system is
similar to the P.G.P. system, except that the private key used
chooses to do this by using the module 10 as its "agents" and
for decrypting the IDEA key is stored in a privatized object 65 gives them the authority to authenticate (date and sign)
documents on his behalf. The preferred operation of this
in a transaction group of the module 10 instead of in a Pc.
The module protected e-mail system operates as follows:
system is as follows:

6,105,013
7

8

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

6,105,013
9

10

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

6,105,013
11

12

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

6,105,013

13
of time or for a given number of operations before asking the
module 10 for another certificate.
There are many possible variations on this usage model.
For example, the transaction script 44 could also bind up the
true time in the certificate so that the application program
running on the PC could guarantee that the execution time
is accurately measured. (This would require the Service
Provider to create a clock offset object during initialization
to provide a reference for measuring time.)

14

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

6,105,013
15

16

may wish to maintain a registry containing the pubic key of
networked location. By guaranteeing the presence of the
a particular module 10 along with the name, address, and
End User's module 10 at the remote site, this identification
other identifying information of the person to whom the
validates and legitimizes the contents of the data packet and
module 10 is issued. For this purpose, it is essential for the
therefore also any financial transactions, represented by the
Service Provider to make sure that the public key in the 5 contents of the packet, that may be requested by the End
registry corresponds to a private key which is known only to
User.
the module 10. In order to guarantee this, the module 10
The model described here is one in which the authority to
must be in the possession of the Service Provider at the time
perform financial transactions derives from the registry
the public key is extracted from the module 10 and placed
maintained by the Service Provider. It is therefore essential
in the registry. After recording this information in the 10 that this information be accurate and that the private key in
registry, the Service Provider can ship the module 10 to the
the module 10 can be secure from all parties. Because each
End User named in the registry.
module 10 has its own unique RSA key set, there is no
It is also important for the End User to be able to confirm,
provision in this model for the module 10 to represent
when he receives the module 10, that the private key is not
money independently of the registry maintained by the
known to the Service Provider or any of the Service Pro- 15 Service Provider. Instead, the registry and the ability of the
vider's employees. This is important because an ideal regmodule 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.
20
This usage applies to a business model in which the
One way to accomplish this, the Service Provider sends a
command to the module 10 to cause it to generate a complete
Service Provider intends to collect a service charge from the
End User that is a percentage of the total amount of money
RSA key set using random numbers, and then to automatically make one of the exponents private, so that there is no
transferred by the module 10. This model is similar to those
way any person can discover the value of the private key. 25 described in sections C D, E, and F above, but with the
This key set has a special type, different from that of a key
addition of a destructor object that can cause any particular
set programmed into the can by a Service Provider, so that
transaction script 44 to expire at a predetermined date and
anyone doing business directly with the module 10 can
time. This model also requires the use of an additional
determine for themselves that the private key is known only
money object which is programmed (with a suitable transto the module 10.
30 action script 44) to accumulate the total value of all the
1. Preparation
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 35 and E above. The Service Provider also creates an additional
will be locked automatically, while the second exponent will
money object to serve as the volume accumulator. The
Service Provider also creates transaction scripts 44 for
be privatized automatically by the firmware of the module
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 40 includes a destructor object set to expire at a predetermined
time in the future, and the transaction script 44 for withobject. The transaction script 44 might optionally append
additional information (e.g., the transaction counter) to the
drawing money includes an instruction to add the amount of
the withdrawal to the money object serving as the volume
data from the input object, in order to satisfy any additional
accumulator. The service provider then locks the group and
objectives of the application. Other objects 42 and transaction scripts 44 may also be added at the discretion of the 45 ships the module 10 to the End User.
Service Provider. The transaction group 40 is locked by the
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
the time that the module 10 is used, the cumulative total of
public exponent from the transaction group 40 and records
them in the registry along with the information identifying 50 all the money spent from the module 10 is accumulated in
the End User. Finally, the Service Provider ships the module
the money object serving as the volume accumulator. When
10 to the End User, and later conveys to the End User the
the time limit expires, the End User can no longer add
password that can be used to access the transaction group 40.
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 55 User then returns the module 10 to the Service Provider to
of an End User over the Internet or other network, the
be restored. The Service Provider reads the remaining
Merchant generates a unique packet of data and transmits it
amount of money and also the amount of money recorded in
the volume accumulator. The Service Provider bills the End
to the End User, and the End User passes the data into the
input object and invokes the transaction script 44 which
User a service charge that is a percentage of the amount in
causes it to be encrypted with the private key generated by 60 the volume accumulator. If the End User is willing to pay
the module 10. The resulting encrypted packet is transmitted
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
ing in the module 10 when the End User returned it is
key belonging to the End User, and attempts to decrypt the
programmed back into the money object of the transaction
encrypted packet using the End User's public key. If the 65 group 40. The Service Provider then returns the restored
decryption succeeds, the Merchant has proven the physical
module to the End User, provided that the End User pays the
presence of the End User's module 10 at the remotely
service charge.

6,105,013
17
The system described above allows a Service Provider to
collect periodic fees for service without having to monitor
and be involved in every financial transaction performed by
the End user. The fee is based on actual usage, as determined
by the contents of the volume register.

18
Decryption: M~Cd (mod N)

(2)

where C is the cyphertext, d and e are the RSA exponents
(see below), and N is the RSA modulus.
RSA Exponent
5
Both e and d (shown in equations 1 and 2 above) are RSA
exponents. They are typically large numbers but are smaller
Exemplary Firmware Definitions for Use With the
than the modulus (N). RSA exponents can be either private
Module
or public. When RSA exponents are created in the module,
they may be declared as either. Once created an exponent
Object
10 may be changed from a public exponent to a private expoThe most primitive data structure accepted by and opernent. After an exponent has been made private, however, it
ated on by the modules firmware. A list of valid objects and
will remain private until the transaction group 40 to which
their definitions is provided in the next section.
it belongs is destroyed.
Transaction Script
Group
15
A transaction script is a series of instructions to be carried
A self-contained collection of objects. An object's scope
out by the module. When invoked the module firmware
is restricted to the group of which it is a member.
interprets the instructions in the script and places the results
Group ID
in the output data object (see below). The actual script is
simply a list of objects. The order in which the objects are
A number preferably between 0 and 255 representing a
listed specifies the operations to be performed on the objects.
specific group.
20 Transaction scripts 44 preferably may be as long as 128
Object ID
bytes.
A number preferably between 0 and 255 representing a
Transaction Counter
specific object within a specific group.
The transaction counter object is preferably 4 bytes in
Object Type
length and is usually initialized to zero when it is created.
Preferably a 1-byte type specifier that describes a specific 25 Every time a transaction script, which references this object,
is invoked, the transaction counter increments by 1. Once a
object.
transaction counter has been locked it is read only and
PIN
provides an irreversible counter.
An alphanumeric Personal Identification number that is
Money Register
preferably eight bytes in length.
The money register object is preferably 4 bytes in length
30
and may be used to represent money or some other form of
Common PIN
credit. Once this object has been created, it must be locked
The PIN that controls access to shared resources such as
to prevent a user from tampering with its value. Once locked
the audit trail. It is also used to control the host's ability to
the value of this object can be altered only by invoking a
create and delete groups.
35 transaction script. A typical transaction group 40 which
Group PIN
performs monetary transactions might have one script for
withdrawals from the money register and one for deposits to
The PIN that controls access to operations specific to
the money register.
objects within a group.
Clock Offset
Audit Trail
This object is preferably a 4 byte number which contains
A record of transactions occurring after the module has 40 the difference between the reading of the module's real-time
been locked.
clock and some convenient time (e.g., 12:00 a.m., Jan. 1,
Locked Object
1970). The true time can then be obtained from the module
by adding the value of the clock offset to the real-time clock.
An object which has been locked by executing the lock
SALT
object command. Once an object is locked it is not directly
45
A SALT object is preferably 20 bytes in length and should
readable.
be initialized with random data when it is created. When a
Private Object
host transmits a generate random SALT command, the
An object which has been privatized by executing the
module combines the previous SALT with the module's
privatize object command. Once an object is private, it is not
random number (produced preferably by randomly occurdirectly readable or writable.
50 ring power-ups) to generate a new random SALT. If the
Locked Group
SALT object has not been privatized it may subsequently be
A group which has been locked using the locked group
read by issuing a read object command.
command. After a group has been locked it will not allow
Configuration Data
object creation.
This is a user defined structure with preferably a maxi55 mum length of 128 bytes. This object is typically used to
Composite Object
store configuration information specific to its transaction
A combination of several objects. The individual objects
group 40. For example, the configuration data object may be
inherit the attributes of the composite object.
used to specify the format of the money register object (i.e.,
Exemplary Object Definitions
the type of currency it represents). Since this object has no
60 pre-defined structure, it may never be used by a transaction
RSAModulus
object.
A large integer preferably of at most 1024 bits in length.
Input Data
It is the product of 2 large prime numbers that are each about
An input data object is simply an input buffer with
half the number of bits in length of the desired modulus size.
preferably a maximum length of 128 bytes. A transaction
The RSA modulus is used in the following equations for
65 group may have multiple input objects. The host uses input
encrypting and decrypting a message M:
data objects to store data to be processed by transaction
Encryption: C~Me (mod N)
scripts 44.
(1)

6,105,013

19

20

Output Data
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 S12 bytes in
length and inherits password protection from its group.
5
Random Fill
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 10
transaction group is created. It is a private object and may
not be read using the read object command.
Working Register
This object is used by the script interpreter as working
space and may be used in a transaction script. A handle to 15
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.
ROM Data
This object is automatically created when the transaction 20
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™.
Preferred Module Firmware Command Set
Set Common PIN(01H)
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=O
Output Data=O
Notes:
The PIN option byte may be the bitwise-or of any of the
following values:
PIN_TO_ERASE 00000001b require PIN for Master
Erase)
PIN_TO_CREATE OOOOOOlOb (require PIN for group
creation).
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.
Possible error codes for the set common PIN command:
ERR_BAD_COMMON PIN (Common PIN match
failed)
ERR_BAD_PIN_LENGTH (New PIN length>8 bytes)
ERR_BAD_OPTION_BYTE (Unrecognizable option
byte)
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:
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)
Transmit data
02H, Common PIN
Receive data
CSB=O if command was successful, ERR BAD
COMMON PIN otherwise

25

30

35

40

45

50

55

60

65

Output length=O
Output data=O
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=O if command successful, appropriate error code
otherwise
Output length=1 if successful, 0 otherwise
Output data=Group ID 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_
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:
ERR_BAD_COMMON_PIN (Incorrect common PIN)
ERR_BAD_NAME_LENGTH (If group name
length> 16 bytes)
ERR_BAD_PIN_LENGTH (If group PIN length>8
bytes)
ERR_MIAC_LOCKED (The module has been locked)
ERR_INSUFFICIENT_RAM (Not enough memory for
new group)
Set Group PIN (04H)
Transmit data
04H, Group ID, old GPIN, new GPIN
Receive data
CSB=O if command successful, appropriate error code
otherwise
Output length=O
Output data=O
Notes:
The Group PIN only restricts access to objects within the
group specified by the group ID transmitted in the command
packet.
Possible error codes for the set group PIN command:
ERR_BAD_GROUP _PIN (Group PIN match failed)
ERR_BAD_PIN_LENGTH (New group PIN length>8
bytes)
Create Object (OSH)
Transmit data
OSH, Group ID, Group PIN, Object type, Object
attributes, Object data
Receive data
CSB=O if command successful, appropriate error code
otherwise
Output length=1 if successful, 0 otherwise
Output data=object ID if successful, 0 otherwise

6,105,013

21
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 CSB. 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:

22

07H, Group ID, Group PIN, Object ID
Receive data
CSB=O if successful, appropriate error code otherwise
Notes:
5
If the Group ID, Group PIN and Object ID were valid the
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
10 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 (Incorrect group PIN)
15
ERR_GROUP _LOCKED (The group has already been
ERR_BAD GROUP PIN
(Incorrect group PIN)
ERR_GROUP LOCKED
(The group has been
locked)
locked)
ERR_MIAC_LOCKED (The module has been locked)
ERR_BAD_GROUP _ID (Specified group does not
exist)
ERR_MIAC_LOCKED (The module has been locked) 20
ERR_BAD_OBJECT_ID (Specified object does not
ERR_INVALID_TYPE (The object type specified IS
exist)
invalid)
Make Object Destructable (OSH)
ERR_BAD_SIZE (The objects length was invalid)
Transmit data
ERR_INSUFFICIENT_RAM (Not enough memory for
25
OSH, Group ID, Group PIN, Object ID
new object)
Receive data
CSB=O if successful, appropriate error code otherwise
Notes:
Object types:
RSAmodulus
0
If the Group ID, Group PIN and Object ID were valid the
RSA exponent
30 object will be made destructable. If an object is destructable
Money register
2
it becomes unusable by a transaction script after the groups
3
Transaction counter
4
Transaction script
destructor becomes active. If no destructor object exists
Clock offset
5
within the transaction group the destructible object attribute
Random SALT
bit has no affect. Making an object destructable is an
Configuration object
7
35 irreversible operation.
8
Input data object
Output data object
9
Possible error return codes for the make object destrucObject Attributes:
Locked
00000001b
table command:
Privatized
00000010b
ERR_BAD_GROUP _PIN (Incorrect group PIN)
ERR_GROUP _LOCKED (The group has already been
Objects may also be locked and privatized after creation 40
locked)
by using the Lock Object and Privatize Object commands
ERR_MIAC_LOCKED (The module has been locked)
described below.
ERR_BAD_GROUP _ID (Specified group does not
Lock Object (06H)
exist)
Transmit data
ERR BAD OBJECT ID (Specified object does not
45
06H, Group ID, Group PIN, Object ID
exist)
Receive data
Lock Module (09H)
CSB=O if command successful, appropriate error code
Transmit data
otherwise
09H, Common PIN
Output length=O
50
Receive data
Output data=O
CSB=O if successful, appropriate error code otherwise
Notes:
Output length=2 if successful, 0 otherwise
If the Group ID, Group PIN and Object ID are all correct,
Output data=audit trail size if successful, 0 otherwise
the module will lock the specified object. Locking an object
Notes:
55
is an irreversible operation.
If the host supplied Common PIN is correct and the
Possible error return codes for the lock object command:
module has not previously been locked, the command will
ERR_BAD_GROUP _PIN (Incorrect group PIN)
succeed. When the module is locked it will not accept any
new groups or objects. This implies that all groups are
ERR_GROUP _LOCKED (The group has already been
automatically locked. The RAM not used by the system or
locked)
ERR_MIAC_LOCKED (The module has been locked) 60 by groups will be used for an audit trail. There is no audit
trail until the module has successfully been locked!
ERR_BAD_GROUP _ID (Specified group does not
An audit trail record is six bytes long and has the
exist)
following structure:
ERR BAD OBJECT ID (Specified object does not
Group ID I Object ID I Daterrime stamp.
65
exist)
Once an audit trail has been established, a record of the
Privatize Object (07H)
Transmit data
form shown above will be stored in the first available size

6,105,013

23

24

byte location every time a transaction script is executed.
If the object has not been privatized the module will transmit
Note that since the module must be locked before the audit
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
trail begins, neither the group ID nor any object ID is subject
to change. This will always allow an application processing
the output length, and data fields of the return packet.
the audit trail to uniquely identify the transaction script that 5
Possible error codes for the read object command:
was executed. Once the audit trail has consumed all of its
ERR_BAD_GROUP _PIN (Incorrect group PIN)
available memory, it will store new transaction records over
ERR_BAD_GROUP _ID (Specified group does not
the oldest transaction records.
exist)
Possible error codes for the lock module command:
ERR_BAD_OBJECT_ID (Object did not exist in
ERR_BAD_COMMON_PIN (Supplied common PIN 10
group)
was incorrect)
ERR OBJECT PRIVATIZED (Object has been
ERR_MIAC_LOCKED (Module was already locked)
privatized)
Lock Group (OAH)
Write Object (ODR)
Transmit data
Transmit data
15
OAH, Group ID, Group PIN
ODR, Group ID, Group PIN, Object ID, Object size,
Receive data
Object Data
CSB=O if command successful, appropriate error code
Receive data
otherwise
CSB=O if successful, appropriate error code otherwise
Output length=O
20
Output length=O
Output data=O
Output data=O
Notes:
Notes:
If the group PIN provided is correct the module BIOS will
If the Group ID, Group PIN and Object ID were correct,
not allow further object creation within the specified group.
the module checks the attribute byte of the specified object.
Since groups are completely self-contained entities they may 25
If the object has not been locked or privatized the module
be deleted by executing the Delete Group command
will clear the objects previous size and data and replace it
(described below).
with the new object data. Note that the object type and
Possible error return codes for the lock group command:
attribute byte are not affected.
ERR_BAD_GROUP _PIN (Incorrect group PIN)
Possible error codes for the write object command:
30
ERR_GROUP _LOCKED (The group has already been
ERR_BAD_GROUP _PIN (Incorrect group PIN)
locked)
ERR_BAD_GROUP _ID (Specified group does not
ERR_MIAC_LOCKED (The module has been locked)
exist)
ERR_BAD_GROUP _ID (Specified group does not
ERR_BAD_OBJECT_ID (Object did not exist in
exist)
35
group)
Invoke Transaction Script (OBR)
ERR_BAD_OBJECT_SIZE (Illegal object size
Transmit data
specified)
OBR, Group ID, Group PIN, Object ID
ERR_OBJECT_LOCKED (Object has been locked)
Receive data
ERR OBJECT PRIVATIZED (Object has been
CSB=O if command successful, appropriate error code 40
privatized)
otherwise
Read Group Name (OER)
Output length=1 if successful, 0 otherwise
Transmit data
Output data=estimated completion time
OER, Group ID
Notes:
Receive data
45
The time estimate returned by the module is in sixteenths
CSB=O
of a second. If an error code was returned in the CSB, the
Output Length=length of group name
time estimate will be O.
Output data=group name
Possible error return codes for the execution transaction
Notes:
script command:
50
The group name length is a maximum of 16 bytes. All
ERR_BAD_GROUP _PIN (Incorrect group PIN)
byte values are legal in a group name.
ERR_BAD_GROUP _ID (Specified group does not
Delete Group (OFR)
exist)
Transmit data
ERR_BAD_OBJECT_ID (Script object did not exist in
OFR, Group ID, Group PIN
55
group)
Receive data
Read Object (OCR)
CSB=O if successful, appropriate error code otherwise
Transmit data
Output length=O
OCR, Group ID, Group PIN, Object ID
Output data=O
Receive data
60 Notes:
CSB=O if command successful, appropriate error code
If the group PIN and group ID are correct the module will
otherwise
delete the specified group. Deleting a group causes the
automatic destruction of all objects within the group. If the
Output length=object length if successful, 0 otherwise
module has been locked the Delete Group command will
Output data=object data if successful, 0 otherwise
65 fail.
Notes:
Possible error codes for the delete group command:
If the Group ID, Group PIN and Object ID were correct,
ERR_BAD_GROUP _PIN (Incorrect group PIN)
the module checks the attribute byte of the specified object.

6,105,013

25

26

ERR_BAD_GROUP _ID (Specified group does not
Output length=# of new records * 6 if successful, 0
exist)
otherwise
ERR_MIAC_LOCKED (Module has been locked)
Output data=new audit trail records
Get Command Status Info (lOH)
Notes:
5
Transmit data
If the transmitted common PIN is valid and the module
has been locked, it will transfer all new transaction records
lOH
to the host.
Receive data
Possible error codes for the read audit trail command:
CSB=O
ERR_BAD_COMMON_PIN (Common PIN was
Output length=6
10
incorrect)
Output data=module status structure (see below)
ERR_MIAC_NOT_LOCKED module is not locked
Notes:
Read Group Audit Trail (14H)
This operation requires no PIN and never fails. The status
Transmit data
structure is defined as follows:
14H, Group ID, Group PIN
15
Last command executed (1 byte)
Receive data
Last command status (1 byte)
CSB=O if command successful, appropriate error code
Time command received (4 bytes)
otherwise
Get Module Configuration Info (llH)
Output length=# or records for group * 6 if successful, 0
Transmit data
20
otherwise
11H
Output data=audit trail records for group
Receive data
Notes:
CSB=O
This command is identical to the read audit trail
command, except that only records involving the group ID
Output length=4
25 specified in the transmit data are returned to the host. This
Output data=module configuration structure
allows transaction groups to record track their own activities
Notes:
without seeing other groups records.
This operation requires no PIN and never fails. The
Possible error codes for the read group audit trail comconfiguration structure is defined as follows:
mand:
Number of groups (1 byte)
30
ERR_BAD_GROUP _ID (Group ID does not exist)
Flag byte (see below) (1 byte)
ERR_BAD_GROUP _PIN (Common PIN was
Audit trail size/Free RAM (2 bytes)
incorrect)
The flag byte is the bitwise-or of any of the following
ERR MIAC NOT LOCKED (The module is not
values:
locked)
35
OOOOOOOlb (Module is locked)
Read Real Time Clock (1SH)
OOOOOOlOb (Common PIN required for access)
Transmit data
Read Audit Trail Info (12H)
1SH, Common PIN
Transmit data
Receive data
12H, Common PIN
CSB=O if the common PIN matches and ERR BAD
40
Receive data
COMMON PIN otherwise
CSB=O if command successful, appropriate error code
Output length=4
otherwise
Output data=4 most significant bytes of the real time
Output length=audit trail structure size (S) if successful, 0
clock
otherwise
45 Notes:
Output data=audit trail info structure if successful, 0
This value is not adjusted with a clock offset. This
otherwise
command is normally used by a service provider to compute
Notes:
a clock offset during transaction group creation.
If the transmitted Common PIN is valid and the module
Read Real Time Clock Adjusted (16H)
has been locked, it returns audit trail configuration informa - 50
Transmit data
tion as follows:
16H, Group ID, Group PIN, ID of offset object
Number of used transaction records (2 bytes)
Receive data
Number of free transaction records (2 bytes)
CSB=O if successful, appropriate error code otherwise
A boolean specifying whether or (1 byte)
Output length=4 if successful, 0 otherwise
55
not the audit trail rolled
Output data=Real time clock+clock offset ID
since previous read command
Notes:
Possible error codes for the read audit trail info command:
This command succeeds if the group ID and group PIN
ERR_BAD_COMMON_PIN (Common PIN was
are valid, and the object ID is the ID of a clock offset. The
incorrect)
60 module adds the clock offset to the current value of the 4
ERR_MIAC_NOT_LOCKED (Module is not locked)
most significant bytes of the RTC and returns that value in
Read Audit Trail (13H)
the output data field. Note that a transaction script may be
Transmit data
written to perform the same task and put the result in the
13H, Common PIN
output data object.
Receive data
Possible error codes for the real time clock adjusted
65
command:
CSB=O if command successful, appropriate error code
ERR_BAD_GROUP _PIN (Incorrect group PIN)
otherwise

6,105,013

28

27

ERR_BAD_GROUP _ID (Specified group does not
ERR_BAD_COMMON_PIN (81H)
exist)
This error code will be returned when a command
ERR_BAD_OBJECT_TYPE (Object ID is not a clock
requires a common PIN and the PIN supplied does not match
offset)
5 the module's common PIN. Initially the common PIN is set
Get Random Data (17H)
to O.
Transmit data
17H, Length (L)
Receive data
CSB=O if successful, appropriate error code otherwise
Transaction groups may have their own PIN, FIG. 11. If
Output length=L if successful, 0 otherwise
10 this PIN has been set (by a set group PIN command) it must
Output data=L bytes of random data if successful
be supplied to access any of the objects within the group. If
Notes:
the Group PIN supplied does not match the actual group
This command provides a good source of cryptographiPIN, the module will return the ERR_BAD_GROUP _PIN
cally useful random numbers.
error code.
Possible error codes for the get random data command 15
are:
ERR_BAD_SIZE (Requested number of bytes>128)
There are 2 commands which can change PIN values. The
Get Firmware Version ID (18H)
set group PIN and the set common PIN commands. Both of
Transmit data
20 these require the new PIN as well as the old PIN. The
18H
ERR BAD PIN LENGTH error code will be returned if
Receive data
the old PIN supplied was correct, but the new PIN was
CSB=O
greater than 8 characters in length.
Output length=Length of firmware version ID string
Output data=Firmware version ID string
ERR_BAD OPTION BYTE (84H)
Notes:
25
This command returns the firmware version ID as a Pascal
The option byte only applies to the common PIN. When
type string (length+data).
the set common PIN command is executed the last byte the
Get Free RAM (19H)
host supplies is the option byte (described in command
Transmit data
section). If this byte is unrecognizable to the module, it will
19H
30 return the ERR BAD OPTION BYTE error code.
Receive data
CSB=O
Output length=2
When the create transaction group command is executed,
Output data=2 byte value containing the amount of free
35 one of the data structures supplied by the host is the group's
RAM
name. The group name may not exceed 16 characters in
Notes:
length. If the name supplied is longer than 16 characters, the
If the module has been locked the output data bytes will
ERR BAD NAME LENGTH error code is returned.
both be 0 indicating that all memory not used by transaction
groups has been reserved for the audit trail.
ERR_INSUFFICIENT_RAM (86H)
40
Chance Group Name (1AH)
The create transaction group and create object commands
Transmit data
return this error code when there is not enough heap avail1AH, Group ID, Group PIN, New Group name
able in the module.
Receive data
CSB=O if successful or an appropriate error code other45
wIse
Output length=O
When the module has been locked, no groups or objects
Output data=O
can be created or destroyed. Any attempts to create or delete
Notes:
objects will generate an ERR MIAC LOCKED error
If the group ID specified exists in the module and the PIN 50 code.
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
If the module has not been locked there is no audit trail.
PIN. If it is correct, the module name is replaced by the new
If one of the audit trail commands is executed this error code
name supplied by the host.
55 will be returned.
Possible error codes for the change group name command:
ERR_GROUP _LOCKED (89H)
ERR_BAD_GROUP _PIN (Incorrect group PIN)
Once a transaction group has been locked object creation
ERR_BAD_GROUP _ID (Specified group does not
60 within that group is not possible. Also the objects attributes
exist)
and types are frozen. Any attempt to create objects or modify
ERR_BAD_NAME_LENGTH (New group name>16
their attribute or type bytes will generate an ERR
bytes)
GROUP LOCKED error code.
ERROR CODE DEFINITIONS
ERR_BAD COMMAND (80H)
This error code occurs when the module firmware does
not recognize the command just transmitted by the host.

65

When the host sends a create object command to the
module, one of the parameters it supplies is an object type

6,105,013

29
(see command section). If the object type is not recognized
by the firmware it will return an ERR_BAD_OBJECT_
TYPE error code.

30

The module incorporates a numeric coprocessor optimized
for math intensive encryption. The BIOS is preferably
immune to alteration and specifically designed for very
secure transactions.
Each module can have a random "seed" generator with
5
the ability to create a private/public key set. The private key
When the host sends a create object command to the
never leaves the module and is only known by the module.
module, one of the parameters it supplies is an object
Furthermore, discovery of the private key is prevented by
attribute byte (see command section). If the object attribute
active self-destruction upon wrongful entry into the module.
byte is not recognized by the firmware it will return an 10 The module can be bound to the user by a personal identiERR BAD OBJECT_ATTR error code.
fication number (PIN).
When transactions are performed by the module certifiERR_BAD SIZE (8CH)
cates of authentication are created by either or both the
An ERR_BAD_SIZE error code is normally generated
module and a system the module communicates with. The
when creating or writing an object. It will only occur when 15 certificate can contain a variety of information. In particular,
the object data supplied by the host has an invalid length.
the certificate may contain:
1) who is the module user via a unique registration
number.
2) when the transaction took place via a true-time stampAll commands that operate at the transaction group level 20
ing of the transaction.
require the group ID to be supplied in the command packet.
3) where the transaction took place via a registered
If the group ID specified does not exist in the module it will
module interface site identification.
generate an ERR_BAD_GROUP _ID error code.
4) security information via uniquely serialized transactions and digital signitures on message digests.
ERR_BAD OBJECT ID (8EH)
25
5) module status indicated as valid, lost, or expired.
All commands that operate at the object level require the
Although a preferred embodiment of the method and
object ID to be supplied in the command packet. If the object
apparatus of the present invention has been illustrated in the
ID specified does not exist within the specific transaction
accompanying Drawings and described in the foregoing
group (also specified in the command packet) the module
30 Detailed Description, it will be understood that the invention
will generate an ERR_BAD_OBJECT_ID error code.
is not limited to the embodiment disclosed, but is capable of
numerous rearrangements, modifications and substitutions
ERR_INSUFFICIENT_FUNDS (8FH)
without departing from the spirit of the invention as set forth
If a script object that executes financial transactions is
and defined by the following claims.
invoked and the value of the money register is less than the
What is claimed is:
withdrawal amount requested an ERR_INSUFFICIENT_ 35
1. A micro controller based secure transaction integrated
FUNDS error code will be returned.
circuit comprising:
a microcontroller core;
a math coprocessor connected to said microcontroller
core, said math coprocessor being for handling comLocked objects are read only. If a write object command 40
plex mathematics of encryption and decryption;
is attempted and it specifies the object ID of a locked object
memory circuitry which can be programmed by a service
the module will return an ERR OBJECT LOCKED error
provider to enable said microcontroller based secure
code.
transaction integrated circuit to perform predetermined
functions on behalf of the service provider and for the
45
benefit of an end user, said memory circuitry being
Private objects are not directly readable or writable. If a
connected to said microcontroller core;
read object command or a write object command is
an input/output circuit, connected to said microcontroller
attempted, and it specifies the object ID of a private object,
core, for exchanging information with a device external
the module will return an ERR OBJECT PRIVATE error
to said microcontroller based secure transaction inte50
code.
grated circuit; and
a real time clock, connected to said microcontroller core,
ERR_OBJECT_DESTRUCTED (92H)
for providing a time measurement for time stamping a
If an object is destructible and the transaction group's
predetermined function.
destructor is active the object may not be used by a script. 55
2. The micro controller based secure transaction integrated
If a script is invoked which uses an object which has been
circuit of claim 1, wherein said predetermined function is an
destructed, an ERR_OBJECT_DESTRUCTED error code
encrypted data transaction.
will be returned by the module.
3. The micro controller based secure transaction integrated
The exemplary embodiment of the present invention is
circuit of claim 1, further comprising an energy circuit
preferably placed within a durable stainless steel, token-like 60 connected to said memory circuitry.
can. It is understood that an exemplary module can be placed
4. The micro controller based secure transaction integrated
in virtually any articulatable item. Examples of articulatable
circuit of claim 3, wherein said memory circuitry is nonitems include credit cards, rings, watches, wallets, purses,
volatile RAM.
necklaces, jewelry, ID badges, pens, clipboards, etc.
5. The micro controller based secure transaction integrated
The module preferably is a single chip "trusted com- 65 circuit of claim 1, wherein said microcontroller based secure
puter". By the word "trusted" it is meant that the computer
transaction integrated circuit is programmed in a script
is extremely secure from tampering by unwarranted means.
programming language.

6,105,013

31

32

6. The microcontroller based secure transaction integrated
11. The secure transaction integrated circuit of claim 9,
circuit of claim 1, wherein said microcontroller based secure
wherein said memory circuit can comprise a plurality of
transaction integrated circuit is incorporated into an articutransaction groups wherein each said transaction group can
latable item.
comprise a transaction program created by a service pro7. The microcontroller based secure transaction integrated S vider.
circuit of claim 6, wherein said articulatable item is selected
12. The secure transaction integrated circuit of claim 9,
forma group comprising a ring, a bracelet, a credit card, a
further comprising an energy circuit connected at least to
smart card, a necklace, an identification badge, a key fob,
said memory circuit.
and a token shaped object.
13. The secure transaction integrated circuit of claim 9,
8. The microcontroller based secure transaction integrated 10
wherein said input/output circuit is a bidirectional one-wire
circuit of claim 1, further comprising the ability to create
encryption key pairs.
bus comprising a communication/power connection and a
9. A secure transaction integrated circuit comprising:
ground connection.
14. The secure transaction integrated circuit of claim 9,
a microcontroller core;
a memory circuit, in communication with said microcon- 15 wherein said transaction program can enable said secure
troller core, for storing a transaction program;
transaction integrated circuit to perform digital cash transactions.
a modular exponentiation accelerator circuit, in commu15. The secure transaction integrated circuit of claim 9,
nication with said microcontroller core, for performing
encryption and decryption calculations;
20 wherein said secure transaction integrated circuit is further
integrated into an articulatable item.
an input/output circuit, in communication with said
16. The secure transaction integrated circuit of claim 15,
microcontroller core, for receiving and transmitting
wherein said articulatable item is selected from a group
data information with another electronic device; and
comprising a ring, a bracelet, a wallet, a credit card, a smart
a clock circuit for measuring time and providing time
stamp information responsive to functions being per- 25 card, a necklace, an identification card, a key fob, and a
token shaped object.
formed by said microcontroller core.
10. The secure transaction integrated circuit of claim 9,
wherein said memory circuit is a nonvolatile RAM.
* * * * *

UNITED STATES PATENT AND TRADEMARK OFFICE

CERTIFICATE OF CORRECTION
Page 1 of 1

PATENT NO.
: 6,105,013
DATED
: August 15,2000
INVENTOR(S) : Curry et al.

It is certified that error appears in the above-identified patent and that said Letters Patent is
hereby corrected as shown below:

Column 3,
Line 8, replace "photovoitaic" with -- photo-voltaic -Column 14,
Line 18, replace "FIPS" with -- FIBS -Column 19,
Line 49, replace "COMMON PIN" with -- COMMON_PIN -Column 27,
Line 40, replace "Chance" with -- Change -Column 28,
Line 24, replace "BAD OPTION BYTE" with -- BAD_ OPTION_ BYTE -Column 29,
Line 12, replace "BAD SIZE" with -- BAD _ SIZE -Line 24, replace "BAD OBJECT ID" with -- BAD_OBJECT_ID--

Signed and Sealed this
Thirteenth Day of November, 2001
Attest:

Attesting Officer

NICHOLAS P. GODICI
Acting Director of the United States Patent and Trademark Office