Transfer of valuable information between a secure module and another module

Abstract

The present invention rotates to system, apparatus and method for communicating valuable data from a portable module to another module via an electronic device. More specifically, the disclosed system, apparatus and method are useful for enabling a user to fill a portable module with a cash equivalent and to spend the cash equivalent at a variety of locations. The disclosed system incorporates an encryption/decryption method.

Claims

What is claimed is:

1. A system for communicating data securely, comprising:

a first portable module comprising:

a nonvolatile memory for storing a first data;

a first real time clock circuit for time stamping data transactions;

a counter for counting a transaction count;

an input/output circuit;

a substantially unique electronically readable identification number readable by said input/output circuit; and

a memory control circuit in electrical communication with said nonvolatile memory, said real time clock, said counter, and said input/output circuit;

a portable module reader that can be placed in communication with said first portable module, said portable module reader can be connected to a plurality of other devices;

a secure microcontroller based module in electronic communication with said portable module reader, said secure microcontroller comprising:

a microcontroller core;

a math coprocessor, in communication with said microcontroller core, for processing encryption calculations;

an energy circuit for storing energy;

a memory circuit connected to said microcontroller core;

a memory circuit in communication with said microcontroller core; and

a second real time clock circuit in communication with said microcontroller,

said combination of said portable module reader and said secure microcontroller performing secure data transfers with said first portable module.

2. The system for communicating data securely of claim 1, wherein said plurality of other devices includes at least one of a credit card reader, a cash machine, an automatic teller machine, and a phone line.

3. The system for communicating data securely of claim 1, wherein said first data is a packet of encrypted data.

4. The system for communicating data securely of claim 1, wherein said first portable module communicates with said portable module reader via a single wire bus comprising a single bidirectional communication wire and a ground connection.

5. The system for communicating data securely of claim 1, wherein said first module can create random public/private key sets for encryption purposes.

6. The system for communicating data securely of claim 1, wherein said secure microcontroller can create random public/private key sets for encryption purposes.

Description

CROSS REFERENCE TO OTHER APPLICATIONS

The following applications of common assignee contains related subject matter and is hereby incorporated by reference:

Ser. No. 08/594,983, filed Jan. 31, 1996, entitled METHOD, APPARATUS, SYSTEM AND FIRMWARE FOR SECURE TRANSACTIONS; and

Ser. No. 08/595,014, filed Jan. 31, 1996, entitled METHOD, APPARATUS AND SYSTEM FOR TRANSFERRING UNITS OF VALUE.

BACKGROUND OF THE INVENTION

1. Technical Field of the Invention

The present invention relates to a method and system for transferring valuable information securely between a secure module and another module. More particularly, the present invention relates to transferring units of value between a microprocessor based secure module and another module used for carrying a monetary equivalent.

2. Description of Related Art

In the past the preferred means for paying for an item was cash. As our society has become more advanced, credit cards have become an accepted way to pay for merchandise or services. The payment is not a payment to the merchant, but instead is a credit given by a bank to the user that the merchant accepts as payment. The merchant collects money from the bank based on the credit. As time goes on, cash is used less and less, and money transfers between parties are becoming purely electronic.

Present credit cards have magnetic strips to identify the owner of the card and the credit provider. Some credit cards have electronic circuitry installed that identifies the credit card owner and the credit or service provider (the bank).

The magnetic strips installed in present credit cards do not enable the card to be used as cash. That is the modern credit card does not allow the consumer to buy something with the credit card and the merchant to receive cash at the time of the transaction. Instead, when the consumer buys something on credit, the merchant must later request that the bank pay for the item that the consumer bought. The bank then bills the consumer for the item that was bought.

Thus, there is a need for an electronic system that allows a consumer to fill an electronic module with a cash equivalent in the same way a consumer fills his wallet with cash. When the consumer buys a product or service from a merchant, the consumer's module can be debited and the merchant's cash drawer can be credited without any further transactions with a bank or service provider.

SUMMARY OF THE INVENTION

The present invention is an apparatus, system and method for communicating a cash equivalent electronically to and from a portable module. The portable module can be used as a cash equivalent when buying products and services in the market place.

The present invention comprises a portable module that can communicate to a secure module via a microprocessor based device. The portable module can be carried by a consumer, filled with electronic money at an add-money station, and be debited by a merchant when a product or service is purchased by the consumer. As a result of a purchase, the merchant's cash drawer will indicate an increase in cash value.

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 with the accompanying Drawings wherein:

FIG. 1 depicts an exemplary system for transferring valuable information between a module and a secure device;

FIG. 2 is a block diagram of an embodiment of a portable module;

FIG. 3 is a block diagram of an embodiment of a microprocessor based module;

FIG. 4 is an exemplary technique for transferring valuable data securely into a portable module;

FIG. 5 is an exemplary technique for transferring valuable data securely out of a portable module;

FIG. 6 is an exemplary organization of the software and firmware within a secure microprocessor based device; and

FIG. 7 is an exemplary configuration of software and firmware within a secure microprocessor based device.

DETAILED DESCRIPTION OF A PRESENTLY PREFERRED EXEMPLARY EMBODIMENT

FIG. 1 depicts a block diagram of an exemplary system 100 for transferring valuable information to and from a portable module. A portable module 102, which will be described in more detail later, communicates to a microprocessor based device 104. The portable module 102 may contain information that represents units of exchange or a currency equivalent. The microprocessor based device 104 can be any of an unlimited number of devices. For example, the microprocessor based device 104 could be a personal computer, an add-a-fare machine at a train or bus station (similar to those in today's District of Columbia metro stations), a turn style, a toll booth, a bank's terminal, a ride at a carnival, a washing machine at a Laundromat, a locking device, a mail metering device or any device that controls access, or meters a monetary equivalent, etc.

The means for communication 106 between the portable module 102 and the microprocessor based device 104 is preferably via a single wire or contact connection. The single wire connection 106 preferably incorporates a communication protocol that allows the portable module 102 and the microprocessor based device 104 to communicate in a bidirectional manner. Preferably the communication protocol is a one-wire protocol developed by Dallas Semiconductor. It is understood that the means for communicating 106 is not limited to a single wire connection. The communication means 106 could be multiple wires, a wireless communication system, infrared light, any electromagnetic means, a magnetic technique, or any other similar technique.

The microprocessor based device 104 is electrically connected to another microprocessor based device, which is preferably a secure device 108. The term secure device means that the device is designed to contain a secret code and the secret code is extremely difficult to learn. An example of a secure device 108 is explained later in this document.

The microprocessor based device 104 can be connected to a variety of other devices. Such devices include, but are not limited to a cash acceptor 110, an automatic teller machine (ATM) 112, a credit card reader 114, and a phone line 116.

The cash acceptor 110 is adapted to receive cash in the form of currency, such as dollar bills or coins. The cash acceptor 110, preferably, determines the value of the accepted currency. The cash acceptor 110 communicates to the microprocessor based device 104 and informs the device 104 of how much currency has been deposited in the cash acceptor 110.

The cash acceptor 110 can also be a device which provides currency. That is, the cash accepter 110 in response to a communication from the microprocessor based device 104, may provide a metered amount of currency to a person.

The credit card reader 114, and ATM 112 can also be attached to the microprocessor based device 104. The credit card reader 114 could be used to read a user's credit card and then, when authorized, either communicate to the microprocessor based device 104 that units of exchange need to be added to the portable module or that units of exchange need to be extracted from the portable module to pay for a good, service or credit card bill.

The ATM 112 may also be connected to the microprocessor based device. Via communications from the ATM 112, the microprocessor based device 104 can be informed that units of exchange need to be added or subtracted from the portable module 102.

Furthermore, it is also possible that the microprocessor based device 104 is connected to a phone line 116. The phone line may be used for a variety of things. Most importantly, the phone line may be used to allow the microprocessor based device 104 to communicate with a network of devices. Such telephonic communication may be for validating transactions or for aiding the accounting of transactions that are performed via the microprocessor based device's 104 aid. It is further understood that the phone line may be any of a vast variety of communication lines including wireless lines. Video, analog, or digital information may be communicated over the phone line 116.

FIG. 2 depicts a preferred exemplary portable module 102. The portable module 102 is preferably a rugged read/write data carrier that can act as a localized data base and be easily accessed with minimal hardware. The module can be incorporated in a vast variety of portable items which includes, but is not limited to a durable micro-can package that is highly resistant to environmental hazards such as dirt, moisture, and shock. The module can be incorporated into any object that can be articulated by a human or thing, such as a ring, bracelet, wallet, name tag, necklace, baggage, machine, robotic device, etc. Furthermore, the module 102 could be attached to a stationary item and the microprocessor based device 104 may be articulated to the portable module 102. For example, the module 102 may be attached to a piece of cargo and a module reader may be touched to or brought near the module 102. The module reader may be part of the microprocessor based device 104.

The portable module 102 comprises a memory 202 that is preferably, at least in part, nonvolatile memory for storing and retrieving vital information pertaining to the system to which the module 102 may become attached to. The memory 202 may contain a scratchpad memory which may act as a buffer when writing into memory. Data is first written to the scratchpad where it can be read back. After data has been verified, the data is transferred into the memory.

The module 102 also comprises a counter 206 for keeping track of the number of transactions the module has performed (the number of times certain data in the memory of the module has been changed). A timer 102 may be provided in the module to provide the ability to time stamp transactions performed by the module. A memory controller 204 controls the reading and writing of data into and out of the memory 202.

The module also may comprise an identification number 210. The identification number preferably uniquely identifies the portable module from any other portable module.

An input/output control circuit 212 controls the data flow into and out of the portable module 102. The input/output control ("I/O") 212 preferably has an input buffer and an output buffer and interface circuitry 214. As stated above, the interface circuitry 214 is preferably a one-wire interface. Again, it is understood that a variety of technologies can be used to interface the portable module 102 to another electronic device. A single wire or single connection is preferred because the mechanics of making a complete connection is simplified. It is envisioned that a proximity/wireless communication technique is also a technique for communicating between the module 102 and another device. Thus, the interface circuit 214 can be a single wire, multiple wire, wireless, electromagnetic, magnetic, light, or proximity, interface circuit.

FIG. 3 depicts a block diagram of an exemplary secure microprocessor based device ("secure device") 108. The secure device circuitry can be a single integrated circuit. It is understood that the secure device 108 could also be a monolithic or multiple circuits combined together. The secure device 108 preferably 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 34.

The secure device 108 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, a badge, jewelry, a stamp, or practically any object that can be grasped and/or articulated by a user of the object. In the present system 100, the secure device 108 is preferably adapted to be a trusted certifying authority. That is the secure device 108 is a trusted computer. The secure device 108 comprises a numeric coprocessor 18 optimized for math intensive encryption. The BIOS is immune to alteration and is specifically designed for secure transactions. This secure device 108 is preferably encased in a durable, dirt, moisture and shock resistant stainless steel enclosure, but could be encased in wide variety of structures so long as specific contents of the secure device 108 are extremely difficult to decipher. The secure device 108. The secure device 108 may have the ability to store or create a private/public key set, whereby the private key never leaves the secure device 108 and is not revealed under almost any circumstance. Furthermore, the secure module 108 is preferably designed to prevent discovery of the private key by an active self-destruction of the key upon wrongful entry.

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 or other types of math intensive encryption or decryption techniques.

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 understand that volatile memory, EPROM, SRAM and a variety of other types of memory circuitry might be used to create an equivalent device.

Control circuitry 16 provides timing, latching and various necessary control functions for the entire circuit.

An input/output circuit 26 enables bidirectional communication with the secure module 108. The input/output circuitry 26 preferably comprises at least an output buffer and an input buffer. For communication via a one-wire bus, one-wire interface circuitry can be included with the input/output circuitry 26. It is understood that the input/output circuitry 26 of the secure device 108 can be designed to operate on a single wire, a plurality of wires or any means for communicating information between the secure module 108 and the microprocessor based device 104.

An energy circuit 34 may be necessary to maintain stored information in the memory circuitry 20 and/or aid in powering the other circuitry in the module 108. The energy circuit 34 could consist of a battery, capacitor, R/C circuit, photo-voltaic cell, or any other equivalent energy producing circuit or means.

The firmware architecture of the secure module 108 and how it operates within the exemplary system for transferring valuable information, such as units of exchange or currency, between the secure module 108 and a portable module 102 will now be discussed. The secure module 108 provides encryption and decryption services for confidential data transfer through the microprocessor based device 104. The following examples are intended to illustrate a preferred feature set of the secure module 108 and to explain the services that the exemplary system 100 can offer. These applications and examples by no means limit the capabilities of the invention, but instead bring to light a sampling of its capabilities.

I. OVERVIEW OF THE PREFERRED SECURE MODULE 108 AND ITS FIRMWARE DESIGN

Referring to FIG. 3 again, the secure module 108 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 firmware, 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 data object. The module 108 draws its operating power from a single wire, one-wire communication line. The micro controller 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 micro can 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 comparable variations of the module design. For example, volatile memory might be used, or an interface other than a one-wire interface could be used.

The secure module 108 is preferably intended to be used first by a Service Provider who loads the secure module 108 with data to enable it to perform useful functions, and second by an End User who issues commands to the secure module 108 to perform operations on behalf of the Service Provider for the benefit of the End User. For this reason, the secure module 108 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. 6 and 7). A transaction group 40 is simply a set of software 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, which is independent of every other transaction group 40. Hence, multiple Service Providers can offer different services in the same module 108. 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:

    ______________________________________
    RSA Modulus         Clock Offset
    RSA Exponent        Random SALT
    Transaction Script  Configuration Data
    Transaction Counter Input Data
    Money Register      Output Data
    Destructor
    ______________________________________

    ______________________________________
    Privatize Object   Lock Object
    Lock Transaction Group
                       Lock Micro-In-A-Can .TM.
    ______________________________________

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


______________________________________
    Exemplary Object Definitions
    ______________________________________
    RSA Modulus     A large integer preferably of at
                    most 1024 bits in length. It is the
                    product of 2 large prime numbers
                    that are each about half the number
                    of bits in length of the desired
                    modulus size. The RSA modulus is
                    used in the following equations for
                    encrypting and decrypting a message
                    M:
                    Encryption: C = M.sup.e (mod N) (1)
                    Decryption: M = C.sup.d (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    Both e and d (shown in equations 1
                    and 2 above) are RSA exponents.
                    They are typically large numbers but
                    are smaller than the modulus (N).
                    RSA exponents can be either private
                    or public. When RSA exponents are
                    created in the secure module, they
                    may be declared as either. Once
                    created an exponent may be changed
                    from a public exponent to a private
                    exponent. After an exponent has
                    been made private, however, it will
                    remain private until the transaction
                    group 40 to which it belongs is
                    destroyed.
    Transaction Script
                    A transaction script is a series of
                    instructions to be carried out by
                    the secure module. When invoked the
                    secure module firmware interprets
                    the instructions in the script and
                    places the results in the output
                    data object (see below). The actual
                    script is simply a list of objects.
                    The order in which the objects are
                    listed specifies the operations to
                    be performed on the objects.
                    transaction scripts 44 preferably
                    may be as long as 128 bytes.
    Transaction Counter
                    The transaction counter object is
                    preferably 4 bytes in length and is
                    usually initialized to zero when it
                    is created. Every time a
                    transaction script, which references
                    this object, is invoked, the
                    transaction counter increments by 1.
                    Once a transaction counter has been
                    locked it is read only and provides
                    an irreversible counter.
    Money Register  The money register object is
                    preferably 4 bytes in length and may
                    be used to represent money or some
                    other form of credit. Once this
                    object has been created, it must be
                    locked to prevent a user from
                    tampering with its value. Once
                    locked the value of this object can
                    be altered only by invoking a
                    transaction script. A typical
                    transaction group 40 which performs
                    monetary transactions might have one
                    script for withdrawals from the
                    money register and one for deposits
                    to the money register.
    Clock Offset    This object is preferably a 4 byte
                    number which contains the difference
                    between the reading of the secure
                    module's real-time clock and some
                    convenient time (e.g., 12:00 a.m.,
                    January 1, 1970). The true time can
                    then be obtained from the secure
                    module by adding the value of the
                    clock offset to the real-time clock.
    SALT            A SALT object is preferably 20 bytes
                    in length and should be initialized
                    with random data when it is created.
                    When a host transmits a generate
                    random SALT command, the secure
                    module combines the previous SALT
                    with the secure module's random
                    number (produced preferably by
                    randomly occurring power-ups) to
                    generate a new random SALT. If the
                    SALT object has not been privatized
                    it may subsequently be read by
                    issuing a read object command.
    Configuration Data
                    This is a user defined structure
                    with preferably a maximum length of
                    128 bytes. This object is typically
                    used to store configuration
                    information specific to its
                    transaction group 40. For example,
                    the configuration data object may be
                    used to specify the format of the
                    money register object (i.e., the
                    type of currency it represents)
                    Since this object has no pre-defined
                    structure, it may never be used by a
                    transaction object.
    Input Data      An input data object is simply an
                    input buffer with preferably a
                    maximum length of 128 bytes. A
                    transaction group may have multiple
                    input objects. The host uses input
                    data objects to store data to be
                    processed by transaction scripts 44.
    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 512 bytes in length and
                    inherits password protection from
                    its group.
    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 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 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 group is
                    created. It is a locked object and
                    may not be altered using the write
                    object command. This object is 8
                    bytes and length and its contents
                    are identical to the 8 by ROM data
                    of the Micro-In-A-Can .TM..
    ______________________________________


______________________________________
    PIN.sub.-- TO.sub.-- ERASE
                      00000001b (require PIN for
                      Master Erase)
    PIN.sub.-- TO.sub.-- CREATE
                      00000010b (require PIN for
                      group creation)
    ______________________________________

    ______________________________________
    ERR.sub.-- BAD.sub.-- COMMON PIN
                        (Common PIN match
                        failed)
    ERR.sub.-- BAD.sub.-- PIN.sub.-- LENGTH
                        (New PIN lenqth
                        > 8 bytes)
    ERR.sub.-- BAD.sub.-- OPTION.sub.-- BYTE
                        (Unrecognizable option
                        byte)
    ______________________________________

    ______________________________________
    Output data length
                      (Command output length, 2
                      bytes)
    Output data       (Command output, length
                      specified above).
    ______________________________________

    ______________________________________
    ERR.sub.-- BAD.sub.-- COMMON.sub.-- PIN
                       (Incorrect common PIN)
    ERR BAD.sub.-- NAME.sub.-- LENGTH
                       (If group name length > 16
                       bytes)
    ERR.sub.-- BAD.sub.-- PIN.sub.-- LENGTH
                       (If group PIN length
                       > 8 bytes)
    ERR.sub.-- MIAC.sub.-- LOCKED
                       (The secure module has
                       been locked)
    ERR.sub.-- INSUFFICIENT.sub.-- RAM
                       (Not enough memory for
                       new group)
    ______________________________________

    ______________________________________
    ERR.sub.-- BAD.sub.-- GROUP.sub.-- PIN
                        (Group PIN match
                        failed)
    ERR.sub.-- BAD.sub.-- PIN.sub.-- LENGTH
                        (New group PIN length
                        > 8 bytes)
    ______________________________________

    ______________________________________
    ERR BAD.sub.-- GROUP.sub.-- PIN
                        (Incorrect group PIN)
    ERR.sub.-- GROUP.sub.-- LOCKED
                        (The group has been
                        locked)
    ERR MIAC.sub.-- LOCKED
                        (The secure module has
                        been locked)
    ERR.sub.-- INVALID.sub.-- TYPE
                        (The object type
                        specified is invalid)
    ERR.sub.-- BAD.sub.-- SIZE
                        (The objects length
                        was invalid)
    ERR.sub.-- INSUFFICIENT.sub.-- RAM
                        (Not enough memory for
                        new object)
    Object types:
    RSA modulus         0
    RSA exponent        1
    Money register      2
    Transaction counter 3
    Transaction script  4
    Clock offset        5
    Random SALT         6
    Configuration object
                        7
    Input data object   8
    Output data object  9
    Object Attributes:
    Locked              00000001b
    Privatized          00000010b
    ______________________________________

    ______________________________________
    ERR.sub.-- BAD.sub.-- GROUP.sub.-- PIN
                        (Incorrect group PIN)
    ERR.sub.-- GROUP.sub.-- LOCKED
                        (The group has already
                        been locked)
    ERR.sub.-- MIAC.sub.-- LOCKED
                        (The secure module has
                        been locked)
    ERR.sub.-- BAD.sub.-- GROUP.sub.-- ID
                        (Specified group does
                        not exist)
    ERR.sub.-- BAD.sub.-- OBJECT.sub.-- ID
                        (Specified object does
                        not exist)
    ______________________________________

    ______________________________________
    ERR BAD.sub.-- GROUP.sub.-- PIN
                       (Incorrect group PIN)
    ERR.sub.-- GROUP.sub.-- LOCKED
                       (The group has already
                       been locked)
    ERR.sub.-- MIAC.sub.-- LOCKED
                       (The secure module has
                       been locked)
    ERR.sub.-- BAD.sub.-- GROUP.sub.-- ID
                       (Specified group does
                       not exist)
    ERR.sub.-- BAD.sub.-- OBJECT ID
                       (Specified object does
                       not exist)
    ______________________________________

    ______________________________________
    ERR.sub.-- BAD.sub.-- GROUP.sub.-- PIN
                       (Incorrect group PIN)
    ERR.sub.-- GROUP.sub.-- LOCKED
                       (The group has already
                       been locked)
    ERR.sub.-- MIAC.sub.-- LOCKED
                       (The secure module has
                       been locked)
    ERR.sub.-- BAD.sub.-- GROUP.sub.-- ID
                       (Specified group does
                       not exist)
    ERR.sub.-- BAD.sub.-- OBJECT.sub.-- ID
                       (Specified object does
                       not exist)
    ______________________________________

    ______________________________________
    ERR.sub.-- BAD.sub.-- COMMON.sub.-- PIN
                        (Supplied common PIN
                        was incorrect)
    ERR.sub.-- MIAC.sub.-- LOCKED
                        (Secure module was
                        already locked)
    ______________________________________

    ______________________________________
    ERR.sub.-- BAD.sub.-- GROUP.sub.-- PIN
                        (Incorrect group PIN)
    ERR.sub.-- GROUP.sub.-- LOCKED
                        (The group has already
                        been locked)
    ERR.sub.-- MIAC.sub.-- LOCKED
                        (The secure module has
                        been locked)
    ERR.sub.-- BAD.sub.-- GROUP.sub.-- ID
                        (Specified group does
                        not exist)
    ______________________________________

    ______________________________________
    ERR.sub.-- BAD.sub.-- GROUP.sub.-- PIN
                        (Incorrect group PIN)
    ERR.sub.-- BAD.sub.-- GROUP.sub.-- ID
                        (Specified group does
                        not exist)
    ERR.sub.-- BAD.sub.-- OBJECT.sub.-- ID
                        (Script object did not
                        exist in group)
    ______________________________________

    ______________________________________
    ERR.sub.-- BAD.sub.-- GROUP.sub.-- PIN
                        (Incorrect group PIN)
    ERR.sub.-- BAD.sub.-- GROUP.sub.-- ID
                        (Specified group does
                        not exist)
    ERR.sub.-- BAD.sub.-- OBJECT.sub.-- ID
                        (Object did not exist
                        in group)
    ERR.sub.-- OBJECT.sub.-- PRIVATIZED
                        (Object has been
                        privatized)
    ______________________________________

    ______________________________________
    ERR.sub.-- BAD.sub.-- GROUP.sub.-- PIN
                        (Incorrect group PIN)
    ERR.sub.-- BAD.sub.-- GROUP.sub.-- ID
                        (Specified group does
                        not exist)
    ERR.sub.-- BAD.sub.-- OBJECT.sub.-- ID
                        (Object did not exist
                        in group)
    ERR.sub.-- BAD.sub.-- OBJECT.sub.-- SIZE
                        (Illegal object size
                        specified)
    ERR.sub.-- OBJECT.sub.-- LOCKED
                        (Object has been
                        locked)
    ERR OBJECT.sub.-- PRIVATIZED
                        (Object has been
                        privatized)
    ______________________________________

    ______________________________________
    ERR.sub.-- BAD.sub.-- GROUP.sub.-- PIN
                        (Incorrect group PIN)
    ERR.sub.-- BAD.sub.-- GROUP.sub.-- ID
                        (Specified group does
                        not exist)
    ERR.sub.-- MIAC.sub.-- LOCKED
                        (Secure module has
                        been locked)
    ______________________________________

    ______________________________________
    Last command executed  (1 byte)
    Last command status    (1 byte)
    Time command received  (4 bytes)
    ______________________________________

    ______________________________________
    Number of groups       (1 byte)
    Flag byte (see below)  (1 byte)
    Audit trail size/Free RAM
                           (2 bytes)
    ______________________________________

    ______________________________________
    ERR.sub.-- BAD.sub.-- COMMON.sub.-- PIN
                       (Common PIN was
                       incorrect)
    ERR.sub.-- MIAC.sub.-- NOT.sub.-- LOCKED
                       secure module is not locked
    ______________________________________

    ______________________________________
    ERR.sub.-- BAD.sub.-- GROUP.sub.-- ID
                        (Group ID does not
                        exist)
    ERR.sub.-- BAD.sub.-- GROUP.sub.-- PIN
                        (Common PIN was
                        incorrect)
    ERR.sub.-- MIAC.sub.-- NOT.sub.-- LOCKED
                        (The secure module is
                        not locked)
    ______________________________________

    ______________________________________
    ERR.sub.-- BAD.sub.-- GROUP.sub.-- PIN
                        (Incorrect group PIN)
    ERR.sub.-- BAD.sub.-- GROUP.sub.-- ID
                        (Specified group does
                        not exist)
    ERR.sub.-- BAD.sub.-- OBJECT.sub.-- TYPE
                        (Object ID is not a
                        clock offset)
    ______________________________________

    ______________________________________
    ERR.sub.-- BAD.sub.-- GROUP.sub.-- PIN
                       (Incorrect group PIN)
    ERR.sub.-- BAD.sub.-- GROUP.sub.-- ID
                       (Specified group does
                       not exist)
    ERR.sub.-- BAD.sub.-- NAME.sub.-- LENGTH
                       (New group name > 16 bytes)
    ______________________________________

• Inventors
  Curry, Stephen M.; Loomis, Donald W.; Bolan, Michael L.;
• Assignee
  Dallas Semiconductor Corporation (Dallas, TX)
• Published
  Aug-17-1999
• Current US Classes:
  705/65
  705/76
  713/173
• Application #
  594975
• International Classes
  H04L 009/00
• Field of Search
  380/49 380/24 380/23 380/25
• Examiner
  Cangialosi; Salvatore
• Agent
  Jenkens & Gilchrist
• US Patent References:
  5003594
  5150407
  5189700
  5241599
  5539825
  5539828
  5546463
  5577121
  5621796
  5787174