`Curry et al.
`
`US006237095B1
`(10) Patent N0.:
`US 6,237,095 B1
`(45) Date 0f Patent:
`*May 22, 2001
`
`(54) APPARATUS FOR TRANSFER OF SECURE
`INFORMATION BETWEEN A DATA
`CARRYING MODULE AND AN
`ELECTRONIC DEVICE
`
`(75) Inventors: Stephen M. Curry, Dallas; Donald W.
`Loomis, Coppell; Christopher W. FOX,
`Dallas, all of TX (US)
`
`Assigneez Dallas Semiconductor Corporation,
`Dallas, TX (Us)
`
`(*) Notice:
`
`This patent issued on a continued pros
`ecution application ?led under 37 CFR
`1.53(d), and is subject to the tWenty year
`patent term provisions of 35 U.S.C.
`154(aX2)‘
`
`.
`.
`.
`.
`SubJect to any disclaimer, the term of this
`atent is extended or adjusted under 35
`£3 S C 154(k)) by 0 days
`
`(21) Appl' NO': 09/003’541
`(22) Filed;
`Jan, 6, 1998
`
`Related US. Application Data
`
`(62) Division of application No. 08/595,014, ?led On Jan- 31,
`(60) lligsisional a lication No 60/004 510 ?led on Se 29
`1995
`pp
`'
`’
`’
`p‘
`’
`
`(51) Int. Cl.7 ...................................................... .. H04L 9/00
`(52) US. Cl. ............................................................ .. 713/178
`
`(58) Field Of Search .................................. .. 380/4, 25, 24,
`380/21; 711/164; 705/64, 65, 75; 713/175,
`178, 168, 172
`
`(56)
`
`References Cited
`Us PATENT DOCUMENTS
`
`7/1985 White ................................. .. 364/408
`4,530,201
`5,045,675 * 9/1991 Curry
`.. 235/441
`5,077,792
`12/1991 Herring ............. ..
`380/24
`5,111,504 * 5/1992 Esserman et a1.
`.. 380/21
`5,146,575 * 9/1992 Nolan, Jr. ...... ..
`711/164
`
`
`
`2W“? elt a1‘ Z: 5’832’2O7 * 11/1998 Lilgieeetaa'l
`
`’
`’
`' "
`* Cited by eXaIIliIlef
`Primary Examiner—Tod R. SWann
`
`
`
`" "913/200
`
`Assistant Examiner—MattheW Smithers
`.
`.
`.
`(74) Attorney, Agent,‘ or Fzrm—Jenkens & Gilchrist, A
`Professional Corporation
`(57)
`ABSTRACT
`The present invention relates to an electronic module used
`for secure transactions. More speci?cally, the electronic
`module is capable of passing encrypted information back
`and forth betWeen a service provider’s equipment via a
`secure, encrypted technique so that money and other valu
`able data can be securely passed electronically. The module
`1S Capable of bemg programmed, keepmg track of real tune,
`recording transactions for later revieW, and creating encryp
`tion key pairs.
`
`8 Claims, 8 Drawing Sheets
`
`SYSTEM DATA
`COMMON PIN, RANDOM
`NUMBER REGISTER, ETC...
`
`OUTPUT DATA OBJECT #1
`OUTPUT DATA OBJECT #2
`WORKING REGISTER
`
`40/
`
`40/
`
`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-CAN
`HAS BEEN LOCKED
`
`ONCE LOCKED ALL
`UNUSED RAM IS
`ALLOCATED FOR
`THE AUDIT TRAIL
`
`TRANSACTION GROUP
`
`PAsswoctsdllxFImNliTTEélaurEs
`OBJECT 1
`
`_42
`
`OBJECT 2
`
`OBJECT N
`
`-42
`
`TRANSACTION RECORD
`
`GROUP OBJECT
`ID
`ID
`
`DATE/TIME
`STAMP
`
`Page 1 of 26
`
`UNITED SERVICES AUTOMOBILE ASSOCIATION
`Exhibit 1001
`
`
`
`U.S. Patent
`
`May 22, 2001
`
`Sheet 1 0f 8
`
`US 6,237,095 B1
`
`14
`T
`12// MICRO PROCESFOR W I
`
`10
`
`V
`18_// MATH COPROCESSOR
`
`II
`I
`OUTPUT BUFFER
`28 -'//
`_'// INPUT BUFFER
`30
`I
`26 _,/
`I
`
`/ ONE-wIRE
`32 --/
`INTERFACE
`I
`
`w CONTROL \‘ 16
`
`— ROM \\__ 22
`
`\_
`= NVRAM \ 20
`\~ 24
`
`+V
`/;,4
`—|-
`ENERGY -—'T
`CIRCUITRY g
`
`MODULE
`
`FIG. 1
`
`51/ CREATE TRANsACTION GROUP
`
`T
`GENERATE KEYS AND LOAD
`52/ INTO A TRANSACTION GROUP
`
`II
`S3/PRIVATIZE DECRYPTION EXPONENT
`
`TI
`54/ CREATE TRANSACTION SCRIPT
`
`II
`55/ LOCK TRANSACTION GROUP
`
`FIG. 2
`
`Page 2 of 26
`
`
`
`U.S. Patent
`
`May 22, 2001
`
`Sheet 2 0f 8
`
`US 6,237,095 B1
`
`USER RECEIVES SECURE E-MAIL
`AND ENCRYPTED IDEA KEY
`AI/
`
`I
`MODULE RECEIVES ENCRYPTED
`IDEA KEY IN AN INPUT OBJECT
`OF A TRANSACTION GROUP
`
`I
`TRANSACTION SCRIPT DECRYPTS
`THE IDEA KEY
`
`I
`DECRYPTED IDEA KEY IS PLACED
`A4 /
`IN AN OUTPUT DATA OBJECT
`
`I
`IDEA KEY IS USED TO DECRYPT
`THE SECURE E-MAIL
`
`FIG. 3
`
`CREATE TRANSACTION GROUP FOR
`PERFORMING ELECTRONIC
`NOTARY FUNCTIONS
`
`82/
`
`I
`CREATE OBJECT(S) FOR
`RSA ENCRYPTION KEYS
`
`I
`CREATE OBJECT FOR TIMEKEEPING
`
`I
`CREATE TRANSACTION SEQUENCE
`OBJECT (COUNTER)
`I
`CREATE A TRANSACTION SCRIPT THAT CREATES A
`CERTIFICATE BY COMBINING AN INPUT DATA OBJECT
`WITH THE TRUE TIME. THE VALUE OF THE TRANSACTION
`55/
`COUNTER AND A UNIQUE NUMBER ASSOCIATED TO THE
`MODULE, THEN SIGNS THE CERTIFICATE
`
`56/
`
`PRIVATIZE OBJECTS
`
`LOCK TRANSACTION GROUP
`
`Page 3 of 26
`
`
`
`U.S. Patent
`
`May 22, 2001
`
`Sheet 3 0f 8
`
`US 6,237,095 B1
`
`61-’
`
`MESSAGE IS PLACED IN AN
`INPUT DATA OBJECT
`
`II
`TRANSACTION SCRIPT COMBINES
`MESSAGE WITH OTHER DATA AND
`(32/ SIGNS THE COMBINATION WITH A
`PRIVATE KEY CREATING AN
`ENCRYPTED CERTIFICATE
`
`I
`THE CERTIFICATE CAN BE READ
`C3—/AT A LATER TIME BY ENCRYPTING
`IT WITH THE PUBLIC KEY
`
`I
`THE CERTIFICATE AND ORIGINAL
`DOCUMENT CAN BE
`STORED ELECTRONICALLY
`
`C4—-"
`
`5
`
`PREPARE MODULE
`CREATE TRANSACTION GROUP
`COMPRISING: MONEY OBJECT
`TRANSACTION COUNT OBJECT
`PRIVATE KEY AND
`PUBLIC KEY OBJECTS ETC.
`
`D1;
`
`I
`PRIVATIZE PRIVATE KEY RELATED OBJECT(S)
`
`I
`_./CREATE OBJECT FOR TIMEKEEPING
`D3
`RSA ENCRYPTION KEYS
`I
`
`D4_/ LOCK TRANSACTION GROUP
`
`I
`Ds/ PUBLISH PUBLIC KEY
`
`F I G. 6‘
`
`Page 4 of 26
`
`
`
`U.S. Patent
`
`May 22, 2001
`
`Sheet 4 0f 8
`
`US 6,237,095 B1
`
`w w BANK/w
`USER WANTS TO MAKE
`I
`A PURCHASE
`REIIIgSNWEEFEES
`USING A MODULE
`I
`\H
`I
`CREATE DATA PACKET
`THAT INCLUDES A
`'RANDOM SALT’ AND \E3
`MODULE ID NUMBER
`
`\Ez
`
`CREATE A SIGNED
`MERCHANT CERTIFICATE
`BY ENCRYPTING DATA \E4
`PACKET WITH
`MERCHANT'S PRIVATE KEY
`
`ATTACHES PURCHASE
`PRICE TO MERCHANT'S \E5
`SIGNED CERTIFICATE
`
`E6 /
`SUBTRACT PURCHASE
`AMOUNT FROM
`MONEY REGISTER
`
`INCREMENT
`TRANSACTION AMOUNT \E7
`I
`COMBINE TRANSACTION
`COUNT WITH MERCHANT'S
`RECEIvE SIGNED MODULE
`SIGNED CERTIFICATE _ _ CERTIFICATE AND DECRYPT
`AND PURCHASE AMOUNT,
`\
`THEN ENCRYPT wITH
`USIN? SERVICE
`E9
`
`PRIvATE KEY THEREBY
`CREATINC A SIGNED
`MODULE CERTIFICATE
`
`.
`CONFIRM THAT‘
`I) AMOUNT OF PURCHASE _
`
`/ E12
`
`RECEIVE MODULE'S
`
`I
`INCREMENT‘
`TRANSACTION AMOUNT
`\
`EII
`
`4
`
`2) DATA IN MERCHANT's
`CERT'F'CATE '3 THE
`SAME AS ORIGINALLY SENT
`\Em
`
`FIG. 7
`
`I
`.
`DECRYPT MODULES
`CERTIFICATE wITH SERVICE \513
`PROVIDER'S PUBLIC KEY
`I
`DECRYPT MERCHANT'S
`CERTIFICATE wITH \
`MERCHANT'S PUBLIC KEY
`E14
`
`IF BOTH CERTIFICATES
`ARE 0K THEN ADD
`PURCHASE AMOUNT TO \E15
`MERCHANT'S BANK BALANCE
`
`Page 5 of 26
`
`
`
`U.S. Patent
`
`May 22,2001
`
`Sheet 5 0f8
`
`US 6,237,095 B1
`
`BANK/SERVICE PROVIDER
`
`I§E_R
`WANTS TO ADD AN
`READ M0DULE ID
`AM$5NLO°DFUfEASH \ NUMBER AND AMOUNT
`OF CASH REQUESTED
`/ REQUEST MoDULE TO
`PRODUCE A RANDOM SALT
`
`CREATE RANDOM
`SALT NUMBER
`
`/
`F1
`
`F3/
`
`DECRYPT SIGNE SERVICE
`PROVIDER CERTIFICATE
`WITH SERVICE PROVIDERS
`PUBLIC KEY AND CHECK
`TH ID NUMBER AND
`RANDOM SALT NUMBER
`
`COMBINE SALT. ID NUMBER
`AND CASH AMOUNT AND
`ENCRYPT WITH SERVICE
`PRovIDER's PRIvATE KEY, \F4
`THEREBY CREATING A
`SIGNED SERVICE
`PROVIDER CERTIFICATE
`__—J
`
`IF THE ID NUMBER AND
`RANDOM SALT NUMBER
`IS UNCHANGED THEN ADD
`THE CASH AMOUNT TO THE
`MONEY REGISTER OF
`THE MODULE
`
`F I G. 8
`
`EXAMPLE OF
`TRANSFER FROM USER'S MODULE TO MERCHANT'S MODULE
`USER/FEB
`MERCHANT/PAYEE
`RECEIVE SALT AND
`1. CREATE RANDOM SALT
`REQUEST FOR MONEY
`
`2. DETERMINE AMOUNT OF
`MONEY TO BE
`RECEIVED FROM PAYER
`
`SUBTRACT REQUESTED
`MONEY AMOUNT FROM
`A MONEY REGISTER
`
`02/
`CREATE SIGNED PAYMENT
`CERTIFICATE BY COMBINING
`SALT WITH PAYMENT
`AMOUNT TI-IEN ENCRYPTING
`WITH BANK/SERVICE
`PROVIDER'S PRIVATE KEY
`
`PAYEE=MERCHANT
`PAYER=USER
`FIG. 9
`
`RECEIVED SIGNED PAYMENT
`CERTIFICATE AND DECRYPT
`USING SERVICE PROVIDERS
`PUBLIC KEY
`
`II
`CHECK DECRYPTED SALT
`AGAINST ORIGINALLY SENT SALT
`IF THEY ARE THE SAME
`ADD PAYMENT AMOUNT
`TO MONEY REGISTER
`
`Page 6 of 26
`
`
`
`U.S. Patent
`
`May 22, 2001
`
`Sheet 6 0f 8
`
`US 6,237,095 B1
`
`/
`H1
`
`TRANSACTION OVER A NETWORK WITH A MODULE
`USER/PAYER
`wT/EALEE
`CREATE RANDOM
`, RECEIVE PAYER SALT AND
`PAYER SALT
`COMBINE wITH AMOUNT OF
`MONEY To BE RECEIVED, AND
`INCLUDE A PAYEE SALT, THEN \H2
`ENCRYPT wITH SERVICE
`PRDVIDER'S PRIVATE KEY TO
`CREATE A FIRST DATA PACKET
`
`I
`RECEIVE FIRST DATA PACKET
`H3/ AND DECRYPT wITH SERVICE
`PRDVIDER'S PUBLIC KEY
`
`II
`COMPARE ENCRYPTED
`PAYER SALT WITH ORIGINAL
`PAYER SALT
`
`/ IF THEY ARE THE SAME,
`H4 SUBTRACT AMOUNT OF MONEY
`To BE SENT FROM
`PAYER TO REGISTER
`
`II
`GENERATE A SECOND DATA
`PACKET CDNSISTINC OF
`PAYEE‘S SALT AND THE
`AMOUNT OF MONEY TO
`H5/ BE SENT AND ENCRYPT
`USING SERVICE
`PRDVIDER’S PRIVATE KEY
`
`F I G. 10
`
`"
`RECEIVE SECOND DATA PACKET
`AND DECRYPT USING SERVICE
`PROVIDERS PUBLIC KEY
`
`I
`EXTRACT DECRYPTED PAYEE
`SALT AND COMPARE WITH
`PAYEE SALT PROVIDED EARLIER \H7
`IF BOTH ARE THE SAME ADD
`MONEY AMOUNT TO
`PAYEE MONEY REGISTER
`
`Page 7 of 26
`
`
`
`U.S. Patent
`
`May 22, 2001
`
`Sheet 7 0f 8
`
`US 6,237,095 B1
`
`READ/ WRITE OBJECT COMMANDS
`
`MODULE
`1Q
`_
`
`PIN
`MATCH
`
`44
`\
`
`_
`
`LOCKED
`TRANSACTION
`GROUP OPEL
`(0) \
`I’ OBJECTS
`~42
`/
`
`\~ 40
`
`PRIVATE
`
`/
`
`/
`
`' SCR'PTS
`
`LOBJECTS (P) \42
`LOCKED
`OBJECTS (L)
`|
`<__|
`READ ONLY OBJECT COMMAND
`READ/WRITE OBJECT COMMANDS
`
`1—W|RE
`I/O
`
`INCT‘EIAIIQPPER
`TRTJBORT
`LAYER O
`
`MTB
`'
`
`II
`
`SCRIPTS
`
`PR'VATE (P)
`OBJECTS
`
`LOCKED
`TRANSACTION
`GROUP
`__ OPEN (0)
`
`\40
`
`LOCKED
`OBJECTS (L)
`<__I
`READ ONLY OBJECT COMMAND
`
`‘READ/WRITE OBJECT COMMANDS
`
`PIN
`MATCH
`
`LOCKED
`TRANSACTION
`GROUP
`
`\~ 40
`
`‘
`OPEN (0)
`|* OBJECTS
`PRIVATE
`~ SCRIPTS L OBJECTS (P)
`LOCKED
`OBJECTS (L)
`<‘I
`READ ONLY OBJECT COMMAND
`
`FIG. 11
`
`Page 8 of 26
`
`
`
`U.S. Patent
`
`May 22, 2001
`
`Sheet 8 0f 8
`
`US 6,237,095 B1
`
`V0 DATA BUFFERS
`
`SYSTEM DATA
`COMMON PIN, RANDOM
`NUMBER REGISTER, ETC“.
`
`OUTPUT DATA OBJECT #1
`
`OUTPUT DATA OBJECT #2
`
`WORKING REGISTER
`
`40’
`
`40’
`
`TRANSACTION GROUP ‘I
`
`TRANSACTION GROUP 2
`
`TRANSACTION GROUP N
`
`AUDIT TRAIL‘
`
`CIRCULAR BUFFER OF
`TRANSACTION RECORDS
`
`*THE AUDIT TRAIL DOES
`NOT EXIST UNTIL THE
`MICRO—|N—A-CAN
`HAS BEEN LOCKED
`
`ONCE LOCKED ALL
`UNUSED RAM IS
`ALLOCATED FOR
`THE AUDIT TRAIL
`
`FIG. 12
`
`TRANSACTION GROUP
`
`GROUP NAME,
`PASSWORD AND ATTRIBUTES
`
`OBJECT 1
`
`OBJECT 2
`
`L42
`
`OBJECT N
`
`~42
`
`TRANSACTION RECORD
`
`GROUP OBJECT
`ID
`ID
`
`DATE/TIME
`STAMP
`
`Page 9 of 26
`
`
`
`US 6,237,095 B1
`
`1
`APPARATUS FOR TRANSFER OF SECURE
`INFORMATION BETWEEN A DATA
`CARRYING MODULE AND AN
`ELECTRONIC DEVICE
`
`RELATED APPLICATIONS
`
`This application is a division of Ser. No. 08/5 95 ,014 ?ling
`date Jan. 31, 1996.
`This application claims the bene?t of US. Provisional
`Application No. 60/004,510, ?led Sep. 29, 1995.
`The following applications of common assignee contains
`related subject matter and are hereby incorporated by ref
`erence:
`Ser. No. 08/594,983, unknown, ?led Jan. 31, 1996,
`entitled METHOD, APPARATUS, SYSTEM AND
`FIRMWARE FOR SECURE TRANSACTIONS;
`Ser. No. 08/594,975, ?led Jan. 31, 1996, entitled TRANS
`FER OF VALUABLE INFORMATION BETWEEN A
`SECURE MODULE AND ANOTHER MODULE.
`20
`
`15
`
`10
`
`BACKGROUND OF THE INVENTION
`
`1. Technical Field of the Invention
`The present invention relates to a method, apparatus and
`system for transferring money or its equivalent electroni
`cally. In particular, in an electronic module based system, the
`module can be con?gured to provide at least secure data
`transfers or to authoriZe monetary transactions.
`2. Description of Related Art
`Presently, credit cards that have a magnetic strip associ
`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
`used via a telephone interface to make monetary exchanges.
`The magnetic strip card is used to help identify the card and
`user of the card. The card provides a relatively loW level of
`security for the transfer. Regardless, the card enables a card
`holder to buy products, pay debts and make monetary
`exchanges betWeen separate bank accounts.
`Improvements have been made to the magnetic strip card.
`There have been cards created With microcircuits instead of
`magnetic strips. In general the microcircuit, like a magnetic
`strip, is used to enable a card-reader to perform a transaction.
`
`SUMMARY OF THE INVENTION
`The present invention is an apparatus, system and method
`for communicating encrypted information betWeen a pref
`erably portable module and a service provider’s equipment.
`The invention comprises a module, that has a unique
`identi?cation, 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 of transaction), along With
`other information and pass the encrypted information back
`to the module as a signed certi?cate. The module, upon
`receiving the signed certi?cate, Will decrypt the certi?cate
`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.
`
`30
`
`35
`
`40
`
`45
`
`55
`
`60
`
`65
`
`2
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`A more complete understanding of the method and appa
`ratus of the present invention may be had by reference to the
`folloWing Detailed Description When taken in conjunction
`With the accompanying DraWings Wherein:
`FIG. 1 is a block diagram of an embodiment of a module;
`FIG. 2 is an exemplary process for creating a transaction
`group;
`FIG. 3 is an exemplary technique for receiving an E-mail
`message;
`FIG. 4 is an exemplary technique for preparing a module
`for notary functions;
`FIG. 5 is an exemplary technique for using the module as
`a notary;
`FIG. 6 is an exemplary technique for preparing a module
`to perform a money transaction;
`FIG. 7 is an exemplary technique for performing a money
`transaction using a module;
`FIG. 8 is an exemplary technique for performing a money
`transaction using a module;
`FIG. 9 is an exemplary technique for performing a money
`transaction using a module;
`FIG. 10 is an exemplary technique for passing data over
`a netWork;
`FIG. 11 is an exemplary organiZation of the softWare and
`?rmWare Within a module; and
`FIG. 12 is an exemplary con?guration of softWare and
`?rmWare Within a module.
`
`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 combined together. The module 10 comprises a
`microprocessor 12, a real time clock 14, control circuitry 16,
`a math coprocessor 18, memory circuitry 20, input/output
`circuitry 26, and an energy circuit.
`The module 10 could be made small enough to be
`incorporated into a variety of objects including, but not
`limited to a token, a card, a ring, a computer, a Wallet, a key
`fob, badge, jeWelry, stamp, or practically any object that can
`be grasped and/or articulated by a user of the object.
`The microprocessor 12 is preferably an 8-bit
`microprocessor, but could be 16, 32, 64 or any operable
`number of bits. The clock 14 provides timing for the module
`circuitry. There can also be separate clock circuitry 14 that
`provides a continuously running real time clock.
`The math coprocessor circuitry 18 is designed and used to
`handle very large numbers. In particular, the coprocessor
`Will handle the complex mathematics of RSA encryption and
`decryption.
`The memory circuitry 20 may contain both read-only
`memory and non-volatile random-access-memory.
`Furthermore, one of ordinary skill in the art Would under
`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
`necessary control functions for the entire circuit.
`An input/output circuit 26 enables bidirectional commu
`nication With the module 10. The input/output circuitry 26
`
`Page 10 of 26
`
`
`
`US 6,237,095 B1
`
`10
`
`15
`
`25
`
`35
`
`3
`preferably comprises at least an output buffer 28 and an
`input buffer. For communication via a one-Wire bus, one
`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, R/ C circuit, photovoltaic cell,
`or any other equivalent energy producing circuit or means.
`The ?rmWare architecture of a preferred embodiment of a
`secure transaction module and a series of sample applica
`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
`of the invention, but instead bring to light a sampling of its
`capabilities.
`I. OVERVIEW OF THE PREFERRED MODULE AND
`ITS FIRMWARE DESIGN
`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
`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 ?rmWare,
`8 Kbytes of NVRAM (non-volatile RAM) 24 for storage of
`critical data, and control circuitry 16 that enables the micro
`controller 12 to be poWered up to interpret and act on the
`data placed in an input circuitry 26. The module 10 draWs its
`operating poWer from the one-Wire line. The micro control
`ler 12, clock 14, memory 20, buffers 28, 30, one-Wire
`front-end 32, modular exponentiation accelerator 18, and
`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
`to support applications such as those described beloW. One
`of ordinary skill Will understand that there are many com
`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
`credit cards, rings etc.
`The module 10 is preferably intended to be used ?rst 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 bene?t
`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.
`55
`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 de?ned 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,
`Which is independent of every other transaction group 40.
`Hence, multiple Service Providers can offer different ser
`vices in the same module 10. The number of independent
`
`45
`
`65
`
`4
`Service Providers that can be supported depends on the
`number and complexity of the objects 42 de?ned in each
`transaction group 40. Examples of some of the objects 42
`that can be de?ned Within a transaction group 40 are the
`folloWing:
`
`RSA Modulus
`RSA Exponent
`Transaction Script
`Transaction Counter
`Money Register
`Destructor
`
`Clock Offset
`Random SALT
`Con?guration Data
`Input Data
`Output Data
`
`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
`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
`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
`tions that can be performed by the End User. Examples of
`some of the irreversible commands are:
`
`Privatize Object
`Lock Transaction Group
`
`Lock Object
`Lock Micro-In-A-Can TM
`
`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 identi?ed by the number of the transaction
`group, the number of the transaction script 40 Within the
`speci?ed group, and the date/time stamp.
`The fundamental concept implemented by the ?rmWare 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
`RSA key 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
`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.
`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.
`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.
`
`Page 11 of 26
`
`
`
`1. Standard E-Mail
`In a standard e-mail system, a user’s computer is con
`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,
`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
`puter.
`It is frequently also possible to copy the passWord from a
`con?guration ?le in the user’s computer and use it to read his
`mail from a different computer. As a result of this broad
`distribution of the e-mail in plain text form and the Weakness
`of passWord protection, standard e-mail is regarded as very
`insecure.
`To counter this problem, the security system knoWn as
`P.G.P. (Pretty Good Privacy) Was devised. To use P.G.P., a
`user generates a complete RSA key set containing both a
`public and private component. He makes his public key
`Widely available by putting it in the signature block of all his
`e-mail messages and arranging to have it posted in publicly
`accessible directories of P.G.P. public keys. He stores his
`private key on his oWn personal computer, perhaps in a
`passWord-protected form. When someone Wishes to send
`private e-mail to this user, he generates a random IDEA
`encryption key and encrypts the entire message With the
`IDEA encryption algorithm. He then encrypts the IDEA key
`itself using the public key provided by the intended recipi
`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
`key and use the decrypted IDEA key to decrypt the message.
`This provides security from those Who might try to read the
`user’s mail remotely, but it is less effective When the user’s
`computer is accessible to others because the computer, itself,
`contains the private key. Even if the private key is passWord
`protected, it is often easy to guess the user’s passWord or
`eavesdrop on him When he enters it, so the user’s computer
`provides little security. In addition, the user can receive
`secure e-mail only at his oWn computer because his private
`key is stored in that computer and is not available elseWhere.
`Therefore, the Weakness of P.G.P. is that it is tied strongly to
`the user’s computer Where the private key resides.
`2. Module Protected E-Mail
`With the exemplary module 10 being used to protect
`e-mail, a user could have his e-mail forWarded to him
`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
`in a transaction group of the module 10 instead of in a PC.
`The module protected e-mail system operates as folloWs:
`a. Referring to FIGS. 2, 11 and 12, the user creates a
`transaction group 40, S1, generates an RSA key set S2
`
`10
`
`15
`
`25
`
`55
`
`65
`
`US 6,237,095 B1
`
`5
`
`6
`and loads it into three objects 42 of the transaction
`group 40 (one RSA modulus object, N, and tWo RSA
`exponent objects, E and D). He then privatiZes the
`decryption exponent S3, D. Finally, he creates a trans
`action 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 messages. Since he has forgotten D and since the
`D exponent object has been privatiZed, there is no Way
`that anyone Will ever ?nd 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 place the decrypted result in the output
`data object A4. He then reads the decrypted IDEA key
`from the output data object and uses it to decrypt his
`mail A5. Note that it is noW impossible for anyone,
`including the user, to read any neW mail Without having
`physical possession of the module 10. There is there
`fore 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 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
`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
`Will never be required to perform an encryption.
`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 signi?
`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 veri?cation 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
`
`
`
`US 6,237,095 B1
`
`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,
`B1.
`b. The Service Provider uses a secure computing facility
`to generate an RSA key set and program the set into
`every 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 back from the modules 10.
`c. The Service Provider reads the real-time clock 14 from
`each module 10 and creates a clock offset object that
`contains the difference betWeen the reading of the
`real-time clock 14 and some convenient reference time
`(e.g., 12:00 am. Jan. 1, 1970). The true time can then
`be obtained from any module 10 by adding the value of
`the clock offset object to the real-time clock B3.
`d. The Service Provider creates a transaction sequence
`counter object initialiZed to Zero B4.
`e. The Service Provider creates a transaction script 44
`Which appends the contents of the input data object to
`the true time (sum of real-time clock 14 and the value
`of the clock offset object) folloWed by the value of the
`transaction counter folloWed by the unique lasered
`registration number. The transaction script 44 then
`speci?es that all of this data be encrypted With the
`private key and placed in the output data object. The
`instructions to perform this operation are stored in the
`transaction group 40 as a transaction script object B5.
`f. The Service Provider privatiZes any other objects 42
`that it does not Wish to make directly readable or
`Writable B6.
`g. The Service Provider locks the transaction group 40,
`preventing any additional transaction scripts