`Curry et al.
`
`[54] METHOD, APPARATUS, SYSTEM AND
`FIRMWARE FOR SECURE TRANSACTIONS
`
`[75]
`
`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
`
`[63] Continuation of application No. 08/594,983, Jan. 31, 1996,
`Pat. No. 5,748,740.
`[60] Provisional application No. 60/004,510, Sep. 29, 1995.
`Int. Cl? ................................. H04L 9/00; H04L 9/30
`[51]
`[52] U.S. Cl. .............................. 705/65; 235/379; 380/30;
`705!75; 713/156; 713/173; 713/174
`[58] 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
`
`3/1988 Smith ........................................ 380/24
`4,731,842
`5,577,120 11/1996 Penzias ..................................... 380/23
`5/1998 Curry eta!. .............................. 380/25
`5,748,740
`
`FOREIGN PATENT DOCUMENTS
`
`0172670A2.
`0186981A2.
`0194839A2.
`0294248A1
`0337185A2.
`045806A2.
`0624014A2.
`4406602A1
`W093/08545
`
`2/1986
`7/1986
`9/1986
`12/1988
`10/1989
`11/1991
`11/1994
`9/1995
`4/1993
`
`European Pat. Off ..
`European Pat. Off ..
`European Pat. Off ..
`European Pat. Off ..
`European Pat. Off ..
`European Pat. Off ..
`European Pat. Off ..
`Germany.
`WIPO.
`
`111111
`
`1111111111111111111111111111111111111111111111111111111111111
`US006105013A
`[11] Patent Number:
`[45] 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/html/pa(cid:173)
`per.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 Safe(cid:173)
`guarded Smartcard IC with Modular Aritmetic Processor,
`Advanced Data Sheet, ST16CF54, Sep. 1994.
`Micro Card, CPS® Products Crypto Card, Jan. 25, 1995.
`Wayner, Peter, Digital Ca$h, 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
`ABSTRACT
`[57]
`
`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
`
`Page 1 of 26
`
`UNITED SERVICES AUTOMOBILE ASSOCIATION
`Exhibit 1001
`
`
`
`U.S. Patent
`
`Aug. 15,2000
`
`Sheet 1 of 8
`
`6,105,013
`
`~10
`
`MICRO PROCESSOR .,___--1
`
`MICRO PROCESSOR
`
`12
`
`18
`
`28
`
`30
`
`26
`
`32
`
`22
`20
`24
`
`34
`
`ROM
`
`NVRAM
`
`+V
`
`MODULE
`
`FIG. 1
`
`CREATE TRANSACTION GROUP
`
`GENERATE KEYS AND LOAD
`INTO A TRANSACTION GROUP
`
`PRIVATIZE DECRYPTION EXPONEN
`
`CREATE TRANSACTION SCRIPT
`
`LOCK TRANSACTION GROUP
`
`FIG. 2
`
`S1
`
`S2
`
`S3
`
`S4
`
`S5
`
`Page 2 of 26
`
`
`
`U.S. Patent
`
`Aug. 15,2000
`
`Sheet 2 of 8
`
`6,105,013
`
`FIG. 3
`
`FIG. 4
`
`,-- A1
`
`,-- A2
`
`,-- A3
`
`USER RECEIVES SECURE E-MAIL
`AND ENCRYPTED IDEA KEY
`t
`MODULE RECEIVES ENCRYPTED
`IDEA KEY IN AN
`INPUT
`OBJECT OF A TRANSACTION GROUP
`t
`TRANSACTION SCRIPT DECRYPTS
`THE IDEA KEY
`t
`IDEA KEY IS PLACED _,r- A4
`DECRYPTED
`IN AN OUTPUT DATA OBJECT
`t
`IDEA KEY IS USED TO DECRYPT
`THE SECURE E-MAIL
`
`,-- A5
`
`v-B2
`
`B3
`
`v-B4
`
`CREATE TRANSACTION GROUP FOR v-B1
`PERFORMING ELECTRONIC
`NOTARY FUNCTIONS
`t
`CREATE OBJECT(S) FOR
`RSA ENCRYPTION KEYS
`~
`CREATE OBLECT FOR TIMEKEEPING
`t
`CREATE TRANSACTION SEQUENCE
`OBJECT (COUNTER)
`t
`CREATE A TRANSACTION SCRIPT THAT CREATES v- B5
`A CERTIFICATE BY COMBINING AN
`INPUT DATA
`OBJECT WITH THE TRUE TIME, THE VALUE OF
`THE TRANSACTION COUNTER AND A UNIQUE
`NUMBER ASSOCIATED TO THE MODULE, THEN
`SIGNS THE CERTIFICATE
`t
`l
`PRIVATE OBJECTS
`t
`I LOCK TRANSACTION GROUP
`
`B6
`
`B7
`
`Page 3 of 26
`
`
`
`U.S. Patent
`
`Aug. 15,2000
`
`Sheet 3 of 8
`
`6,105,013
`
`MESSASGE IS PLACED IN AN v- C1
`INPUT DATA OBJECT
`
`'
`
`,.--- C2
`
`TRANSACTION SCRIPT COMBINES
`MESSAGE WITH OTHER DATA AND
`SIGNS THE COMBINATION WITH A
`PRIVATE KEY CREATING AN
`ENCRYPTED CERTIFICATE
`~
`THE CERTIFICATE CAN BE READ AT A _,.,- C3
`LATER TIME BY DECRYPTING IT
`WITH THE PUBLIC KEY
`
`'
`
`THE CERTIFICATE AND ORIGINAL v- C4
`DOCUMENT CAN BE
`STORED ELECTRONICALLY
`
`FIG. 5
`
`PREPARE MODULE
`CREATE TRANSACTION GROUP
`COMPRISING: MONEY OBJECT
`TRANSACTION COUNT OBJECT
`PRIVATE KEY AND
`PUBLIC KEY OBJECTS ETC.
`~
`PRIVATIZE PRIVATE KEY RELATED OBJECT(S)
`J
`CREATE TRANSACTION SCRIPT TO
`PERFORM MONETARY TRANSACTION
`
`'
`'
`
`LOCK TRANSACTION GROUP
`
`PUBLISH PUBLIC KEY
`
`FIG. 6
`
`D1
`
`D2
`
`,--D3
`
`D4
`
`D5
`
`Page 4 of 26
`
`
`
`U.S. Patent
`
`Aug. 15,2000
`
`Sheet 4 of 8
`
`6,105,013
`
`USER
`USER WANTS TO MAKE f-(cid:173)
`A PURCHASE
`USING A MODULE
`
`t--
`
`BANKf-SERVICE PROVIDER
`
`v-E2
`
`v-E3
`
`v-E4
`
`MERCHANT
`READS MODULE'S
`ID NUMBER
`t
`CREATES DATA PACKET
`THAT INCLUDES A
`'RANDOM SALT' AND
`MODULE ID NUMBER
`t
`CREATES A SIGNED
`MERCHANT CERTIFICATE
`BY ENCRYPTING DATA
`PACKET WITH
`MERCHANT'S PRIVATE KEY
`t
`ATIACHES PURCHASE V E5
`PRICE TO MERCHANT'S
`SIGNED CERTIFICATE
`
`SUBTRACT PURCHASE
`AMOUNT FROM
`MONEY REGISTER
`t
`INCREMENT
`TRANSACTION COUNT
`t
`COMBINE TRANSACTION v- EB
`COUNT WITH MERCHANT'S
`RECEIVED SIGNED MODULE v- E9
`SIGNED CERTIFICATE
`AND PURCHASE AMOUNT;
`CERTIFICATE AND DECRYPT
`THEN ENCRYPT WITH r-- USING SERVICE PROVIDER'S
`SERVICE PROVIDER'S
`PUBLIC KEY
`E 12
`t
`\
`PRIVATE KEY THEREBY
`CREATING A SIGNED
`_l
`CONFIRM THAT:
`MODULE CERTIFICATE
`RECEIVE MODULE'S
`1} AMOUNT OF PURCHASE
`SIGNED CERTIFICATE
`t
`IS CORRECT
`f-- 2) DATA IN MERCHANT'S
`CERTIFICATE IS THE
`DECRYPT MODULE'S
`SAME AS ORIGINALLY SENT
`CERTIFICATE WITH SERVICE
`PROVIDER'S PUBLIC KEY
`)
`E13~
`Jl
`DECRYPT MODULE'S
`CERTIFICATE WITH
`. ~ MERCHANT'S PUBLIC KEY
`l
`E14
`IF BOTH CERTIFICATES ARE
`OK THEN ADD PURCHASE
`__, AMOUNT TO MERCHANT'S
`E15--
`BANK BALANCE
`
`v-E7
`
`--
`
`ITEM
`RECEIVE
`SERVICE PURCHASED
`
`E11)
`
`E10
`
`FIG. 7
`
`Page 5 of 26
`
`
`
`U.S. Patent
`
`Aug. 15,2000
`
`Sheet 5 of 8
`
`6,105,013
`
`USER
`
`BANK/SERVICE PROVIDER
`
`Fl \
`
`F3
`
`\
`
`F5
`
`\
`
`G2
`
`\
`
`WANTS TO ADD AN
`
`TO MODULE
`
`READ MODULE ID
`NUMBER AND AMOUNT
`OF CASH REQUESTED
`
`CREATE RANDOM
`
`PRODUCE A RANDOM SALT
`
`AMOUNT OF CASH ~
`v--- REQUEST MODULE TO
`SALT NUMBER ~ COMBINE SALT,
`
`DECRYPT SIGNED SERVICE
`PROVIDER CERTIFICATE
`WITH SERVICE PROVIDER'S
`PUBLIC KEY AND CHECK
`THE
`ID NUMBER AND
`RANDOM SALT NUMBER
`
`ID NUMBER
`AND CASH AMOUNT AND
`ENCRYPT WITH SERVICE
`PROVIDER'S PRIVATE KEY,
`THEREBY CREATING A
`SIGNED SERVICE
`PROVIDER CERTIFICATE
`I
`
`F2
`
`/
`
`F4
`
`/
`
`ID NUMBER
`IF THE
`AND RANDOM SALT NUMBER
`IS UNCHANGED THEN ADD
`THE CASH AMOUNT TO THE
`MONEY REGISTER
`OF THE MODULE
`
`FIG. 8
`
`EXAMPLE OF
`TRANSFER FROM USER'S MODULE TO MERCHANT'S MODULE
`USER/PAYER
`MERCHANT/PAYEE
`
`RECEIVE SALT AND
`REQUEST FOR MONEY
`
`SUBTRACT REQUESTED
`MONEY AMOUNT FROM
`A MONEY REGISTER
`
`CREATE SIGNED PAYMENT
`CERTIFICATE BY COMBINING
`SALT WITH PAYMENT
`AMOUNT THEN ENCRYPTING
`WITH BANKER/SERVICE
`PROVIDER'S ORIVATE KEY
`PAYEE = MERCHANT
`PAYER = USER
`FIG. 9
`
`1. CREATE RANDOM SALT
`
`2. DETERMINE._AMOUNT OF v Gl
`
`MONEY TO BE
`RECEIVED FROM PAYER
`
`+
`RECEIVE SIGNED PAYMENT v
`
`CERTIFICATE AND DECRYPT
`USING SERVICE PROVIDER'S
`PUBLIC KEY
`~
`CHECK DECRYPTED SALT v
`
`~GAINST ORIGINALLY SENT SALT
`IF THEY ARE THE
`SAME ADD PAYMENT AMOUNT
`TO MONEY REGISTER
`
`G3
`
`G4
`
`Page 6 of 26
`
`
`
`U.S. Patent
`
`Aug. 15,2000
`
`Sheet 6 of 8
`
`6,105,013
`
`TRANSACTION OVER A NETWORK WITH A MODULE
`
`H1
`
`H3
`
`~ CREATE RANDOM
`PAYER SALT
`
`~
`~ RECEIVE FIRST DATA PACKET
`AND DECRYPT WITH SERVICE
`PROVIDER'S PUBLIC KEY
`~
`COMPARE DECRYPTED
`PAYER SALT WITH ORIGINAL
`PAYER SALT
`
`H4
`
`H5
`
`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
`~ AMOUNT OF MONEY TO
`BE SENT AND ENCRYPT
`USING SERVICE
`PROVIDER'S PRIVATE KEY
`
`FIG. 10
`
`MERCHANT/PAYEE
`
`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
`
`J
`RECEIVE SECOND DATA PACKET v
`AND DECRYPT WITH SERVICE
`PROVIDER'S PUBLIC KEY
`~
`EXTRACT DECRYPTED PAYEE
`SALT AND COMPARE WITH
`PAYEE SALT PROVIDED EARLIER
`
`IF BOTH ARE THE SAME ADD v
`
`MONEY AMOUNT TO
`PAYEE MONEY REGISTER
`
`H6
`
`H7
`
`Page 7 of 26
`
`
`
`U.S. Patent
`
`Aug. 15,2000
`
`Sheet 7 of 8
`
`6,105,013
`
`READ/WRITE OBJECT COMMANDS
`
`MODULE
`10
`-
`
`44
`,,
`
`PIN
`r- MATCH
`
`LOCKED
`TRANSACTION
`GROUP
`~ OPEN
`OBJECTS
`
`v-40
`
`~42
`(O)J
`
`~42
`
`OBJECTS
`
`OBJECTS L
`
`H SCRIPTS tK PRIVATE (P) r
`~LOCKED ( ) r r42
`
`IRE
`1-W
`1/
`0
`
`DATA ~ COMMAND
`PIN
`INTER- 1-1- MATCH
`PRETER
`
`TRANSPORT
`LAYER
`
`READ ONLY OBJECT COMMAND
`READ/WRITE OBJECT COMMANDS
`
`v-..40
`
`LOCKED
`TRANSACTION
`GROUP
`~ OPEN
`OBJECTS
`
`44
`.,
`
`OBJECTS
`
`OBJECTS L
`
`(O) J
`H SCRIPTS }H PRIVATE (P) J
`~LOCKED () J
`
`READ ONLY OBJECT COMMAND
`READ/WRITE OBJECT COMMANDS
`
`,...-40
`
`LOCKED
`TRANSACTION
`GROUP
`~ o~fE~NTS (O) J
`MATCH --1 SCRIPTS }K PRIVATE (P) J
`
`PIN
`
`44,
`
`"-
`
`OBJECTS
`
`FIG. 11
`
`~LOCKED ()I
`OBJECTS L
`
`READ ONLY OBJECT COMMAND
`
`Page 8 of 26
`
`
`
`U.S. Patent
`
`Aug. 15,2000
`
`Sheet 8 of 8
`
`6,105,013
`
`TRANSACTION GROUP
`
`GROUP NAME,
`PASSWORD AND ATIRIBUTES
`
`v 42
`
`v- 42
`
`40
`-.......___
`40
`-.......___
`
`1/0 DATA BUFFERS
`
`SYSTEM DATA
`COMMON PIN, RANDOM
`NUMBER REGISTER, ETC ...
`
`OUTPUT DATA OBJECT #1
`
`OUTPUT DATA OBJECT #2
`
`WORKING REGISTER
`
`TRANSACTION GROUP 1
`
`TRANSACTION GROUP 2
`
`. .
`.
`
`TRANSACTION GROUP N
`
`AUDIT TRAIL*
`
`CIRCULAR BUFFER OF
`TRANSACTION RECORDS
`
`*THE AUDIT TRAIL DOES
`NOT EXIST UNTIL THE
`MICRO-IN-A-CANTM
`HAS BEEN LOCKED
`
`ONCE LOCKED ALL
`UNUSED RAM
`IS
`ALLOCATED FOR
`THE AUDIT TRAIL
`
`OBJECT 1
`
`OBJECT 2
`
`.
`.
`.
`OBJECT N
`
`TRANSACTION RECORD
`GROUP OBJECT DATE/TIME
`ID
`ID
`STAMP
`
`FIG. 12
`
`Page 9 of 26
`
`
`
`1
`METHOD, APPARATUS, SYSTEM AND
`FIRMWARE FOR SECURE TRANSACTIONS
`
`RELATED APPLICATIONS
`
`This application is a continuation of application Ser. No.
`08/594,983 filed Jan. 31, 1996, now U.S. Pat. No. 5,748,740,
`and claims the benefit of U.S. Provisional Application No.
`60/004,510, filed Sep. 29, 1995.
`The following applications of common assignee contain
`related subject matter and are hereby incorporated by ref-
`erence:
`Ser. No.: 08/595,014, filed Jan. 31, 1996, entitled
`METHOD, APPARATUS, AND SYSTEM FOR TRANS(cid:173)
`FERRING UNITS OF VALUE, now U.S. Pat. No. 5,805,
`702;
`Ser. No.: 08/594,975, filed Jan. 31, 1996, entitled
`TRANSFER OF VALUABLE INFORMATION
`BETWEEN A SECURE MODULE AND ANOTHER
`MODULE, now pending.
`
`BACKGROUND OF THE INVENTION
`
`6,105,013
`
`2
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`10
`
`20
`
`A more complete understanding of the method and appa(cid:173)
`ratus of the present invention may be had by reference to the
`following Detailed Description when taken in conjunction
`5 with the accompanying Drawings wherein:
`FIG. 1 is a block diagram of an embodiment of a module;
`FIG. 2 is an exemplary process for creating a transaction
`group;
`FIG. 3 is an exemplary technique for receiving an E-mail
`message;
`FIG. 4 is an exemplary technique for preparing a module
`for notary functions;
`FIG. 5 is an exemplary technique for using the module as
`15 a notary;
`FIG. 6 is an exemplary technique for preparing a module
`to perform a money transaction;
`FIG. 7 is an exemplary technique for performing a money
`transaction using a module;
`FIG. 8 is an exemplary technique for performing a money
`transaction using a module;
`FIG. 9 is an exemplary technique for performing a money
`transaction using a module;
`FIG. 10 is an exemplary technique for passing data over
`a network;
`FIG. 11 is an exemplary organization of the software and
`firmware within a module; and
`FIG. 12 is an exemplary configuration of software and
`30 firmware within a module.
`
`1. Technical Field of the Invention
`The present invention relates to a method, apparatus and
`firmware used for secure transactions. In particular, in an 25
`electronic module based system, the module can be config(cid:173)
`ured to provide at least secure data transfers, digital signa(cid:173)
`tures or to authorize monetary transactions.
`2. Description of Related Art
`Presently, credit cards that have a magnetic strip associ(cid:173)
`ated with them, are a preferred monetary transaction
`medium in the market place. A card user can take the card
`to an automatic cash machine, a local store or a bank and
`make monetary transactions. In many instances the card is 35
`used via a telephone interface to make monetary exchanges.
`The magnetic strip card is used to help identify the card and
`user of the card. The card provides a relatively low level of
`security for the transfer. Regardless, the card enables a card
`holder to buy products, pay debts and make monetary 40
`exchanges between separate bank accounts.
`Improvements have been made to the magnetic strip card.
`There have been cards created with microcircuits instead of
`magnetic strips. In general the microcircuit, like a magnetic
`strip, is used to enable a card-reader to perform a transaction. 45
`
`DETAILED DESCRIPTION OF A PRESENTLY
`PREFERRED EXEMPLARY EMBODIMENT
`FIG. 1 depicts a block diagram of an exemplary module
`10 that incorporates an exemplary embodiment of the
`present invention. The module circuitry can be a single
`integrated circuit. It is understood that the module 10 could
`also be on multiple integrated or descrete element circuits
`combined together. The module 10 comprises a micropro(cid:173)
`cessor 12, a real time clock 14, control circuitry 16, a math
`coprocessor 18, memory circuitry 20, input/output circuitry
`26, and an energy circuit.
`The module 10 could be made small enough to be
`incorporated into a variety of objects including, but not
`limited to a token, a card, a ring, a computer, a wallet, a key
`fob, badge, jewelry, stamp, or practically any object that can
`be grasped and/or articulated by a user of the object.
`The microprocessor 12 is preferably an 8-bit
`microprocessor, but could be 16, 32, 64 or any operable
`number of bits. The clock 14 provides timing for the module
`circuitry. There can also be separate clock circuitry 14 that
`provides a continuously running real time clock.
`The math coprocessor circuitry 18 is designed and used to
`55 handle very large numbers. In particular, the coprocessor
`will handle the complex mathematics of RSA encryption and
`decryption.
`The memory circuitry 20 may contain both read-only(cid:173)
`memory and non-volatile random-access-memory.
`60 Furthermore, one of ordinary skill in the art would under(cid:173)
`stand that volatile memory, EPROM, SRAM and a variety of
`other types of memory circuitry could be used to create an
`equivalent device.
`Control circuitry 16 provides timing, latching and various
`65 necessary control functions for the entire circuit.
`An input/output circuit 26 enables bidirectional commu(cid:173)
`nication with the module 10. The input/output circuitry 26
`
`50
`
`SUMMARY OF THE INVENTION
`The present invention is an apparatus, system and method
`for communicating encrypted information between a pref(cid:173)
`erably portable module and a service provider's equipment.
`The invention comprises a module, that has a unique
`identification, that is capable of creating a random number,
`for example, a SALT, and passing the random number, along
`with, for example, a request to exchange money, to a service
`provider's equipment. The service provider's equipment
`may in return encrypt the random number with a private or
`public key (depending on the type oftransaction), along with
`other information and pass the encrypted information back
`to the module as a signed certificate. The module, upon
`receiving the signed certificate, will decrypt the certificate
`with a public or private key (depending on the type of
`transaction) and compare the decrypted number with the
`original random number. Furthermore, if the numbers are the
`same then the transaction that was requested may be deemed
`secure and thereby proceeds. The module is capable of time
`stamping and storing in memory information about the
`transaction for later review.
`
`Page 10 of 26
`
`
`
`6,105,013
`
`3
`preferably comprises at least an output buffer 28 and an
`input buffer. For communication via a one-wire bus, one(cid:173)
`wire interface circuitry 32 can be included with the input/
`output circuitry 26.
`An energy circuit 34 may be necessary to maintain the
`memory circuitry 20 and/or aid in powering the other
`circuitry in the module 10. The energy circuit 34 could
`consist of a battery, capacitor, RIC circuit, photovoltaic cell,
`or any other equivalent energy producing circuit or means.
`The firmware architecture of a preferred embodiment of a 10
`secure transaction module and a series of sample applica(cid:173)
`tions using the module 10 will now be discussed. These
`examples are intended to illustrate a preferred feature set of
`the module 10 and to explain the services that the module
`offers. These applications by no means limit the capabilities 15
`of the invention, but instead bring to light a sampling of its
`capabilities.
`
`5
`
`I. OVERVIEW OF THE PREFERRED MODULE
`AND ITS FIRMWARE DESIGN
`
`4
`vices in the same module 10. The number of independent
`Service Providers that can be supported depends on the
`number and complexity of the objects 42 defined in each
`transaction group 40. Examples of some of the objects 42
`that can be defined within a transaction group 40 are the
`following:
`
`RSAModulus
`RSA Exponent
`Transaction Script
`Transaction Counter
`Money Register
`Destructor
`
`Clock Offset
`Random SALT
`Configuration Data
`Input Data
`Output Data
`
`Privatize Object
`Lock Transaction Group
`
`Lock Object
`Lock Micro-In-A-Can TM
`
`Within each transaction group 40 the module 10 will
`initially accept certain commands which have an irreversible
`effect. Once any of these irreversible commands are
`executed in a transaction group 40, they remain in effect
`20 until the end of the module's useful life or until the trans-
`action group 40, to which it applies, is deleted from the
`module 10. In addition, there are certain commands which
`have an irreversible effect until the end of the module's life
`or until a master erase command is issued to erase the entire
`25 contents of the module 10. These commands will be dis-
`cussed further below. These commands are essential to give
`the Service Provider the necessary control over the opera(cid:173)
`tions that can be performed by the End User. Examples of
`some of the irreversible commands are:
`
`The module 10 preferably contains a general-purpose,
`8051-compatible micro controller 12 or a reasonably similar
`product, a continuously running real-time clock 14, a high(cid:173)
`speed modular exponentiation accelerator for large integers
`(math coprocessor) 18, input and output buffers 28, 30 with
`a one-wire interface 32 for sending and receiving data, 32
`Kbytes of ROM memory 22 with preprogrammed firmware,
`8 Kbytes of NVRAM (non-volatile RAM) 24 for storage of
`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
`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
`silicon chip and packaged in a stainless steel microcan using
`packaging techniques which make it virtually impossible to
`probe the data in the NVRAM 24 without destroying the
`data. Initially, most of the NVRAM 24 is available for use 40
`to support applications such as those described below. One
`of ordinary skill will understand that there are many com(cid:173)
`parable variations of the module design. For example,
`volatile memory can be used, or an interface other than a
`one-wire could be used. The silicon chip can be packaged in 45
`credit cards, rings etc.
`The module 10 is preferably intended to be used first by
`a Service Provider who loads the module 10 with data to
`enable it to perform useful functions, and second by an End
`User who issues commands to the module 10 to perform
`operations on behalf of the Service Provider for the benefit
`of the End User. For this reason, the module 10 offers
`functions to support the Service Provider in setting up the
`module for an intended application. It also offers functions
`to allow the End User to invoke the services offered by the
`Service Provider.
`Each Service Provider can reserve a block of NVRAM
`memory to support its services by creating a transaction
`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
`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, 65
`which is independent of every other transaction group 40.
`Hence, multiple Service Providers can offer different ser-
`
`Since much of the module's utility centers on its ability to
`keep a secret, the Privatize command is a very important
`irreversible command.
`Once the module 10, as a whole, is locked, the remaining
`NVRAM memory 24 is allocated for a circular buffer for
`holding an audit trail of previous transactions. Each of the
`transactions are identified by the number of the transaction
`group, the number of the transaction script 40 within the
`specified group, and the date/time stamp.
`The fundamental concept implemented by the firmware is
`that the Service Provider can store transaction scripts 44 in
`a transaction group 40 to perform only those operations
`among objects that he wishes the End User to be able to
`perform. The Service Provider can also store and privatize
`RSAkey or keys (encryption keys) that allow the module 10
`to "sign" transactions on behalf of the Service Provider,
`thereby guaranteeing their authenticity. By privatizing and/
`or locking one or more objects 42 in the transaction group
`55 40, the Service Provider maintains control over what the
`module 10 is allowed to do on his behalf. The End User
`cannot add new transaction scripts 44 and is therefore
`limited to the operations on objects 42 that can be performed
`with the transaction scripts 44 programmed by the Service
`Provider.
`
`50
`
`60
`
`II. USAGE MODELS OF THE MODULE
`
`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.
`
`Page 11 of 26
`
`
`
`6,105,013
`
`10
`
`6
`a. Referring to FIGS. 2, 11 and 12, the user creates a
`transaction group 40, S1, generates an RSA key set S2 and
`loads it into three objects 42 of the transaction group 40 (one
`RSA modulus object, N, and two RSA exponent objects, E
`5 and D). He then privatizes the decryption exponent S3, D.
`Finally, he creates a transaction script 44, S4 to take data
`placed in the input data object, encrypt it with the modulus
`N and private exponent D and place the result in the output
`data object. He locks the group S5 to prevent any additional
`transaction scripts 44 from being added. He "forgets" the
`value of D and publishes the values of E and N in public
`directories and in the signature blocks of his e-mail mes(cid:173)
`sages. Since he has forgotten D and since the D exponent
`object has been privatized, there is no way that anyone will
`ever find out the value of D.
`b. Referring to FIG. 3, to send secure e-mail to the user,
`the P.G.P. system is used. When the user receives the secure
`e-mail A1, he transmits the encrypted IDEA key into the
`input data object of the transaction group 40, A2 and then
`calls the transaction script 44 to decrypt this key A3 and
`20 place the decrypted result in the output data object A4. He
`then reads the decrypted IDEA key from the output data
`object and uses it to decrypt his mail AS. Note that it is now
`impossible for anyone, including the user, to read any new
`mail without having physical possession of the module 10.
`25 There is therefore no way that a user's mail can be read
`without his knowledge, because the module 10 must be
`physically present on the computer where the mail is read.
`The user can carry his module 10 wherever he goes and use
`it to read his forwarded mail anywhere. His home computer
`30 is not the weak point in the security system.
`Secure e-mail, as described above, is the simplest possible
`module application, requiring only one RSA key and one
`transaction script 44. It is unnecessary even to store the
`public key E in the module 10, but it is a good idea to do so
`35 because the public key is supposed to be publicly accessible.
`By storing E in an exponent object and not privatizing that
`object or the modulus object, N, the user insures that the
`public key can always be read from the module 10. There are
`no transaction scripts 44 involving E because the module 10
`40 will never be required to perform an encryption.
`
`5
`A Background of Secure E-Mail
`In this section we provide an example of how a module 10
`could be used to allow anyone to receive his or her own
`e-mail securely at any location.
`1. Standard E-Mail
`In a standard e-mail system, a user's computer is con(cid:173)
`nected to a provider of Internet services, and the user's
`computer provides an e-mail password when polling the
`provider's computer for new mail. The mail resides on the
`provider's computer in plain text form, where it can be read
`by anyone working there. In addition, while traveling from
`its source, the mail passes through many computers and was
`also exposed at these locations. If the user receives his mail
`from his provider over a local area network, anyone else on
`the same network can capture and read the mail. Finally, 15
`with many e-mail systems that do not require the user to
`enter the password, anyone sitting at the user's computer can
`retrieve and read his mail, since his computer automatically
`provides the password when it polls the provider's com(cid:173)
`puter.
`It is frequently also possible to copy the password from a
`configuration file in the user's computer and use it to read his
`mail from a different computer. As a result of this broad
`distribution of the e-mail in plain text form and the weakness
`of password protection, standard e-mail is regarded as very
`msecure.
`To counter this problem, the security system known as
`P.G.P. (Pretty Good Privacy) was devised. To use P.G.P., a
`user generates a complete RSA key set containing both a
`public and private component. He makes his public key
`widely available by putting it in the signature block of all his
`e-mail messages and arranging to have it posted in publicly
`accessible directories of P.G.P. public keys. He stores his
`private key on his own personal computer, perhaps in a
`password-protected form. When someone wishes to send
`private e-mail to this user, he generates a random IDEA
`encryption key and encrypts the entire message with the
`IDEA encryption algorithm. He then encrypts the IDEA key
`itself using the public key provided by the intended recipi(cid:173)
`ent. He e-mails both the message encrypted with IDEA and
`the IDEA key encrypted with the user's public key to the
`user. No one that sees this transmission can read it except the
`intended recipient because the message is encrypted with
`IDEA and the IDEA key is encrypted with the intended
`recipient's public key. The recipient's computer contains the
`corresponding private key, and hence can decrypt the IDEA 45
`key and use the decrypted IDEA key to decrypt the message.
`This provides security from those who might try to read the
`user's mail remotely, but it is less effective when the user's
`computer is accessible to others because the computer, itself,
`contains the private key. Even if the private key is password 50
`protected, it is often easy to guess the user's password or
`eavesdrop on him when he enters it, so the user's computer
`provides little security. In addition, the user can receive
`secure e-mail only at his own computer because his private
`key is stored in that computer and is not available elsewhere. 55
`Therefore, the weakness of P.G.P. is that it is tied strongly to
`the user's computer where the private key resides.
`2. Module Protected E-Mail
`With the exemplary module 10 being used to protect
`e-mail, a user could have his e-mail forwarded to him 60
`wherever he goes without fear that it would be read by others
`or that his PC would be the weak link that compromises the
`security of his mail. The module protected e-mail system is
`similar to the P.G.P. system, except that the private key used
`for decrypting the IDEA key is stored in a privatized object 65
`in a transaction group of the module 10 instead of in a PC.
`The module protected e-mail system operates as follows:
`
`B. Digital Notary Service
`This section describes a preferred notary service using the
`module 10.
`1. Background of a Standard Notary Service
`A conventional Notary Service Provider receives and
`examines a document from an End User and then supplies an
`uncounterfeitable mark on the document signifying that the
`document was presented to the notary on a certain date, etc.
`One application of such a notary service could be to record
`disclosures of new inventions so that the priority of the
`invention can later be established in court if necessary. In
`this case, the most important service provided by the notary
`is to certify that the disclosure existed in the possession of
`the inventor on a certain date. (The traditional method for
`establishing priority is the use of a lab notebook in which
`inventors and witnesses sign and date disclosures of signifi(cid:173)
`cant inventions.)
`2. Electronic Notary Service Using The Module
`A company, hereafter referred to as the Service Provider,
`decides to go into business to supply a notary service
`(strictly, a priority verification service) for its customers,
`hereafter referred to as the End Users. The Service Provider
`chooses to do this by using the module 10 as its "agents" and
`gives them the authority to authenticate (date and sign)
`documents on his behalf. The preferred operation of this
`system is as follows:
`
`Page 12 of 26
`
`
`
`6,105,013
`
`7
`a. Referring to FIGS. 4, 11 and 12, the Service Provider
`creates a transaction group 40 for performing electronic
`notary functions in a "registered lot" of modules 10, Bl.
`b. The Service Provider uses a secure computing facility
`to generate an RSA key set and program the set into every 5
`module 10 as a set of three objects 42, a modulus object and
`two exponent objects B2. The public part of the key set is
`made known as widely as possible, and the private part is
`forgotten completely by the Service Provider. The private
`exponent object is privatized to prevent it from being read 10
`back from the