 |
Description  |
|
|
BACKGROUND OF THE INVENTION
This invention relates to smartcards.
Advances in microelectronics have made it possible to put a vast amount of
computing power in a small space. In fact, it is possible to effectively
put an entire computer inside a credit card, creating thereby a
"smartcard". Because of the tremendous processing and memory capabilities
of the smartcard, it is expected that smartcards will replace conventional
credit cards which, typically, serve to confirm the right of the card's
holder to debit a given account. Smartcards will provide a higher level of
assurance that the smartcard possessor is the rightful Holder. This will
solve a major problem of conventional credit cards. Moreover, smartcards
will be more than an "authorizer" to debit (or credit) an account. For
example, they will "carry" pre-approved credit.
To allow smartcards to fulfill their promise, Service Providers must feel
secure that the computer within the smartcard cannot be employed for
improper uses. A number of approaches have already been used to meet this
need. First, smartcards are provided only with a power port and a
controlled information pass-through port. Second, the computer embedded in
the smartcard operates under control of an operating system which ensures
that instructions sent to the computer do not carry out operations that
are detrimental to the card's purpose and security guidelines; i.e., only
instructions that read and alter permitted data areas are allowed. Third,
the issuers of today's smartcards insist on populating the card on their
premises and not through remote communication.
The memory in smartcards is large enough to hold the programs and data of a
number of service providers. That is, there is sufficient memory to allow,
for example, VISA, AMERICAN EXPRESS, and MASTERCARD to coexist on a single
smartcard. Alas, smartcards have yet to be developed that, in a commercial
sense, succeed in carrying the services of more than one Service Provider.
It is believed that the reason for this state of affairs is a number of
security problems have not been solved. One problem, for example, arises
in connection with who is the card's owner and what powers does the owner
have over all the files in the smartcards memory. Stated in commercial
terms, the question is to what extent does the owner of a smartcard (who
may also be a Service Provider) have powers over the smartcard that are
inconsistent with the security that other Service Providers seek. This is
a trust issue.
A second issue relates to remote provisioning. Particularly, it is
undesirable to require the smartcard holder to have a service installed
only by bringing the card to the provider. It is also undesirable to
require surrender of the smartcard when one of the services on the
smartcard is to be canceled. Rather, it is desirable and perhaps even
essential for commercial success, to allow remote provisioning.
When the remote provisioning issue is solved, a third issue relates to the
need to reuse space in the holder's smartcard as old services are canceled
and new services are installed.
A fourth issue relates to the commercial conflict between competitive
services, and the desire by some providers to restrict access by their
customers to competing services.
SUMMARY OF THE INVENTION
The issues described above are resolved with an operating system that
allows different Service Providers to coexist on a smartcard with none of
the Service Providers, nor the owner of the smartcard, having access to
the files created for, or by, each of the resident Service Providers
unless authorized in advance.
The operating system of the smartcard, somewhat akin to the UNIX.RTM.
(registered trademark of UNIX System Laboratories) operating system,
includes a root directory that is owned by the smartcard's issuer/owner,
and each Service Provider is a "user" that is installed by the
issuer/owner. Each such user is provided with a subdirectory of the root
directory, and within the subdirectory the user creates files and
subdirectories with files, as the user deems necessary.
The operating system prevents all users of the smartcard, including the
smartcard's issuer/owner and the smartcard's holder, from accessing any
files that are owned by any other user, when that user chooses to prevent
such access. This power to exclude is effected through a password file
that is owned by the user and which cannot be altered by any other user,
including the smartcard's issuer/owner. Optionally, the smartcard's
issuer/owner is given the power to erase all files of a given user.
The operating system also includes means for digital signature-supplemented
communication as well as for completely encrypted communication. This
capability imparts confidence in remote communications, which permits
remote provisioning, effective maintenance of a database that keeps track
of all services contained in each smartcard, and re-provisioning of a
smartcard in case of loss or general failure of the smartcard.
BRIEF DESCRIPTION OF THE DRAWING
FIG. 1 depicts the structure of the UNIX operating system;
FIG. 2 presents the tree structure of a smartcard operating system embedded
in the memory of the othserwise conventional smartcard;
FIG. 3 shows a log-in protocol between a smartcard and its issuer/owner;
FIG. 4 illustrates a protocol involving a smartcard, the issuer/owner and a
Service Provider;
FIG. 5 presents a protocol for a smartcard obtaining services from a
Service Provider;
FIG. 6 presents a protocol involving a smartcard, a Visitor user and a
Service Provider;
FIG. 7 presents a protocol between a smartcard and a Visitor user, without
connection to a Service Provider
FIG. 8 depicts an arrangement for remote provisioning of smartcards using
the telecommunication network; and
FIG. 9 presents a flowchart of an operating system command for drawing upon
a value stored in a service provider's file.
DETAILED DESCRIPTION
A number of smartcard operating systems are already known. One example is
U.S. Pat. No. 4,816,654, issued to Anderl et al. on Mar. 28, 1989 having a
hardware block diagram that is reflected in FIG. 2. The operating system
described below has many similarities to that operating system and to the
well known UNIX operating system. A brief description of some well known
aspects of the UNIX operating system will help in understanding the
smartcard operating system disclosed herein.
The UNIX Operating System
The UNIX operating system comprises a collection of files. Some are files
that primarily contain information about related files, and they are
called directory files or directories. Others are files that contain user
data, and they are "normal" files. Also in the UNIX operating system, a
user can be the "owner" of the file, can belong to a specified "group"
recognized by the file, or can belong to "other". Each file contains a
data portion that specifies the file characteristics, such as ownership,
information access capabilities relative to the three types of users, etc.
The owner of the file can change all file characteristics.
Architecturally, the first and primary file is a root directory file. The
user who is the owner of this directory is, in effect, the owner of the
entire operating system. This user can create other files which are
pointed-to by the root file. These files, which can be other "directory"
files as well as "normal" files, are considered to be "below" the root
directory, in a tree-like structure.
In many UNIX operating systems, one of the directories below the root is
named "etc.", and it has a file below it that is designated "passwd". The
full address, or path name, of that file is "/etc./passwd" (the file "/"
at the beginning of the path name designates the root address). The "etc."
and the "passwd" files are owned by the system administrator, typically
called "Root", who is the also the owner of the root directory. The
"passwd" file contains an encrypted representation of Root's password, and
Root's access to the operating system is allowed only after Root logs in
by providing the password. The presented password is encrypted and
compared to the encrypted password stored in the "passwd" file. When the
comparison is favorable, the user is accepted and granted permission to
access other files; i.e., the user is "logged in".
Multi-user capability is provided by allowing Root to create a subdirectory
below the root directory and to assign ownership of that subdirectory to
another user. Root can then install a password for that user in the
"passwd" file and allow the user to enter the system at that subdirectory
file when that user presents his/her password. The user has the ability to
modify his/her own password, but only through a command provided by the
operating system. That password resides in the system only in encrypted
form and only in the "passwd" file. This architecture is depicted in FIG.
1.
The log-in process can be summarized as follows. A computer operating under
the UNIX operating system begins by executing a loop that scans the
computer's input port. When connection by a user is detected, control is
transferred from the loop to a program that begins interactions with the
user. The program sends a "login:" message to the user and waits for the
user's response. The user identifies himself/herself, for example, by
returning the string "htb", and that identifies the user to the operating
system. The program continues with the challenge message "Password:" and
the user must supply a password string. The program encrypts the password
string and compares it to the encrypted password that is found in the
"/etc/passwd" file for the identified user. When the match is positive, it
is determined that the user is bona fide, and control passes to a file
owned by Root (typically named ".profile"). That file sets various
parameters for the user and passes control to another file that is owned
by the user (typically also named ".profile", but this file is located in
the directory owned by that user). Whatever instructions are found in the
user's ".profile" file are executed, and the computer is placed in a loop,
awaiting further instructions from the user.
Root is the owner of all files that comprise the operating system as well
as of the "passwd" file. Therefore, Root can modify any and all files and
is, therefore, a "super user". It is important to note that even files
that are not owned by Root are nevertheless subject to Root's commands.
Reason: Root has the power to change the "passwd"file as well as the files
that control Root's capabilities generally. That capability gives Root the
power to change the password itself and, therefore, Root can always make
itself the owner of a file. Hence, it makes sense to let Root have all
owner powers in the first instance. In short, Root has absolute control
and total knowledge over all files in the system.
Aside from being able to log in (by providing the correct password), users
are granted the ability to read files, write into files, and execute
files--i.e., pass program control to files. (Without the power to pass
program control to a specified file nothing can be done, for executing a
program is noting more than passing control to a file.) Since Root has
access to all files in the system, it follows that Root can read, write,
and execute all files.
All system-provided instructions in the UNIX operating system are merely
files that can be executed, and those files can be located in any
directory--as long as the system knows where those files are found. As
stated earlier, Root owns all those directories and all those files. Since
Root controls the read and execute permissions of all those directories
and files, it follows that Root can restrict anyone (including itself, if
that were desired) from executing any file, simply by limiting the
permissions of that file. That gives Root the power to create customized
sets of files whose execution is blocked to particular groups of users. In
other words, Root can create various restricted operating systems, or
"restricted shells", that encompass less than all of the commands
available on the system.
The Smartcard Operating System
The absolute power that Root has in the UNIX operating system makes it
unsuitable for smartcards. While it is patently clear that providers such
as VISA, MASTERCARD, and AMERICAN EXPRESS will not allow each other to be
the Root, it is also quite likely that, absent demonstrably sufficient
security means, they would not want anyone else to be the Root either.
That is part of the problem that has been blocking the smartcard from
enjoying the commercial success it deserves.
FIG. 2 presents the otherwise conventional block diagram of a smartcard,
and illustrates a file structure that responds to this sensitivity of
Service Providers. According to the structure of FIG. 2, Root owns the
root directory and any number of files (directory files or normal files)
that it wishes to create. For example, FIG. 2 includes a root directory
file 10 and below it there are the following Root-owned files: ".profile"
file 11, "passwd" file 12, "log" file 17, "filex" file 13, "filey" file
14, and "ID" file 18. A number of subdirectories are also found below
root, with each being used as the "HOME" directory of a user (Service
Provider). For example, FIG. 2 includes a directory file 15, named "htb"
(the smartcard's Holder), a directory file 20 named "bankA", and a
directory file 25 named "airlineA". Each one of the directories also
includes a "passwd" file (16, 21, and 26, respectively) below the
associated user's HOME directory, as well as a ".profile" file. This
placing of the password files has some advantages, but it is not a
requirement. Importantly, ownership of each such password files is
assigned to the user associated with that file and the directory above it.
It may also be advantageous to grant ownership of directories 15, 20 and
25 to the respective users.
FIG. 2 includes one additional important directory (and a user). That is
the "Visitor" directory 30, which is the entry point for non-Service
Providers who wish to interact with the smartcard.
The FIG. 2 file architecture is coupled to an operating system that differs
from that of the UNIX operating system primarily in that the operating
system of the FIG. 2 structure does not allow Root the ability to modify
files that it does not own. To insure that this capability is not
circumvented by Root, the operating system does not allow Root to modify
some of the files that define the operating system (in a sense, Root does
not own those files). One means for achieving the latter result is to
encase those non-Root-owned operating system files in a read-only memory
(ROM). At the very least, the ROM contains the commands/modules/files that
effect writing to a file. More specifically, the writing to a file is
restricted to whatever the owner of the file specifies (the owner of a
file is, initially, the user that creates the file), and Root is treated
as merely another user. Commands that effect writing to a file are
operating system commands that, for example, move files, copy files, save
files, change file attributes (e.g., ownership), and rename files. Other
items that may be installed in the ROM, or more typically in a "write
once" memory (because they are unique to each smartcard), are the Root
password and the smartcard's ID information (i.e., files 12 and 18) The ID
information may simply be an arbitrary string, or it may include the
smartcard's Holder name. Including the Holder's name is probably preferred
by merchants who will get the ID information. Actually, both the Root
password and the smartcard's ID can be encased in the file that
establishes the Root directory (i.e., in block 10). In FIG. 2 these are
shown to be independent files, however, to more clearly illustrate the
concepts.
One file-writing power that is granted to Root in some embodiments is the
power to delete any file in its entirely (and in the process, effectively
deleting any file that the deleted file points to). This includes
directory files and normal files and it applies to files that Root owns
and to files that Root does not own. Such a capability may be imbued in
embodiments where memory space is to be reused when a given Service
Provider is no longer providing services to the smartcard's Holder.
Another difference between the operating system of FIG. 2 and that of a
standard UNIX operating system is that the former includes an encryption
key pair that is installed in a file owned by Root (e.g., in "filex" 13),
and that key pair is unique to each smartcard. The pair includes a private
key, f, that is kept secret by the smartcard, and a public key, g, that
the smartcard does not care to keep secret. Of course, both keys are
initially known to the smartcard's owner/issuer, who is also the Root user
(i.e., super user) of the smartcard, but Root need not keep the private
key (and probably would choose to destroy that knowledge). This pair of
keys can also be "burned" into an appropriate memory, such as the memory
containing Root's password, or included in the file that defines the root
directory. More about public key encryption is found below.
The fact that the password of a user's directory is stored in a file that
is owned by the user is a key difference between the UNIX operating system
and the operating system shown in FIG. 2. The fact that these passwords
can't be read by anyone other than the files' owners permits storing the
passwords in an unencrypted form. Combined with the restriction on
writing, this file organization prevents Root from becoming the owner of
any file (normal file or directory file), and thus prevents Root from
circumventing the permissions set by the file's owner. This key difference
allows one user's files to be completely opaque to Root as well as to
other users. Thus, the FIG. 2 arrangement overcomes the "trust issue"
between the providers of services and the smartcard's issuer/owner.
Transactional Security
The next issue that must be addressed is transactional security of the
smartcard. This concept encompasses the measures employed by the
smartcard's operating system and by the agreed-upon communication
protocols to ensure that unauthorized transactions do not occur which
would adversely affect the Holder or any of the Service Providers. This
includes activities by Root, the Holder, any of the Service Providers, any
Visitor user, or an interloper. (An interloper is a party that interjects
itself into a communication session between a smartcard and another party
and substitutes its messages for the true messages.)
One way to thwart interlopers is to construct messages that include a date
and time stamp, with at least that portion of the message being encrypted.
Alternatively, the entire message can be encrypted. Also, wherever
necessary, the communication protocol can require a confirmation sequence
(which differs from session to session) to be exchanged between the
parties. It is also a good general approach to minimize the flow of
sensitive information in the clear (i.e., without encryption). These
techniques are employed in the log-in and communication protocols
described below.
Encryption
The field of encryption is not new. What follows is merely a summary of a
few encryption techniques that may be employed in connection with the
smartcard disclosed herein.
As is well known, the "shared secret" approach to encryption calls for the
two communicating parties to share a secret function, f. The party wishing
to transmit a message, m, encrypts the message with the secret function to
form an encrypted message f(m). The encrypted message is transmitted and
the receiving party decrypts the received signal by forming the function
f(f(m)). The function f is such that discovering the message m from f(m)
is computationally very difficult, but applying the function twice
recovers the original message; i.e., f(f(m))=m.
The "shared secret" approach to encryption is very good, but its weak link
lies in the need to communicate, i.e., share, the secret function. If an
eavesdropper obtains the shared secret during that communication session
when the function is transmitted, then it is no longer secret.
In public key encryption, each party maintains one member of a pair of
keys, f and g. More particularly, one party keeps one key (f) secret, but
makes the other key (g) known to all. Thus, the key g is "public" and the
key f is "private". The pair, f and g, is such that
1. g(f(m))=m;
2. even when g is known, the function f cannot be determined; and
3. it is computationally very difficult to determine the message m from
f(m).
Whereas the public key approach solves the key distribution/administration
problem described above, it does have a disadvantage in that public key
encryption and decryption is slower (requires more computation time) than
the "shared secret" approach.
As it relates to smartcards, speed of communication has different levels of
importance, based on the kind of party that is communicating with the
smartcard. With respect to the smartcard's issuer/owner and the service
Providers, low speed is not a major disadvantage because it is expected
that such communication will be rare and, therefore, processing time is
not "of the essence". In communication with others, however, (i.e.,
merchants that log in as the Visitor user), speed is important.
The speed issue can be resolved, where necessary, by combining the "shared
secret" approach with the public key approach. That is, when communication
is initiated, the public key approach may be used to communicate a
temporary "shared secret" between the smartcard and the merchant.
Specifically, the party having the public key chooses a "shared secret"
and communicates it to the party having the private key. Thereafter, the
faster "shared secret" approach is used to encrypt the entire messages.
Alternatively, a certification approach may be used (using the shared
secret). In a certification approach, the message is sent in the clear,
and is appended, or "signed" , with a "digital signature". A "digital
signature" is a hashing of the message (e.g., adding the ASCII codes of
the characters in the message, in a selected modulus) that is encoded. 0f
course, in applications where it is assured that an interloper cannot
substitute the true data with false data the information can be sent in
the clear (probably, following a verification process using the public
key).
Use of the public key approach solves most of the key-administrations
concerns. It still leaves the question of the initial knowledge of the
public key by the party wishing to communicate with the smartcard; but
that is a non-problem since the smartcard itself can provide that
information.
Log-in by Root and Installation of a Service Provider/User
Because encryption ensures secure communication, the smartcard's
issuer/owner can have confidence in remote installation of services. Of
course, the issuer/owner (i.e., Root) must first log in into the
smartcard. A protocol for the log-in is presented in FIG. 3, and a
protocol for service installation process is presented in FIG. 4. The
physical, remote, connection that is possible with the smartcard disclosed
herein is shown in FIG. 8.
As depicted in FIG. 3, the process begins with the smartcard's possessor
(P) being authenticated as the bona fide Holder (H) of the smartcard (S).
As shown in FIG. 3, the process begins with a prompt from the smartcard,
and an entry of the possessor's PIN (Personal Identification Number) into
the smartcard. The use of the smartcard's processing power to authenticate
the possessor has an advantage in that is requires no communication of the
PIN string to any equipment that might capture the PIN. Even in
applications where P and S are at a merchant's premises it is possible for
the merchant to possess a stand-alone piece of equipment that interfaces
with the smartcard in a secure manner. This equipment may be battery
operated, with a keyboard and a display, and certified to include no other
ports, no processor, and no writable memory. In operation, P would insert
S into the stand-alone equipment, input the PIN via the keyboard, and the
smartcard would determine whether the PIN is correct. It would then output
an "OK" message through the display, if appropriate.
When such stand-alone equipment is unavailable (or when the communication
is remote as, for example, when a "dumb" card reader is used at the
possessor's home), the submitted PIN is processed in the smartcard and the
"OK" message from the smartcard (to the merchant's equipment) is "time
stamped" and encrypted. This suggests that P's actual confirmation as H
may be postponed until after the appropriate encryption keys are
established and date and time information is imparted to S (this is not
the approach shown in FIG. 3).
Returning to FIG. 3 generally, after the bona fide of H is established, S
verifies that the user logging is a valid user and the user confirms that
S is a valid smartcard. More specifically, the protocol of FIG. 3, in its
entirety, proceeds as follows:
a. S prompts for an input and P provides a PIN string. (Within the
smartcard, the PIN resides in a Root-owned file that is open for the
Holder to modify, for example, file 14 in FIG. 2.) S compares the provided
PIN string to the stored PIN string and, if the comparison is positive, P
is confirmed as H.
b. Once H is confirmed, attention can turn to the communication between S
and O. S identified itself to O by providing its ID information and a
password challenge in the form of a random string, RND1.
c. O encrypts RND1 with O's password to form string K.sub.1 (RND1) and
returns it to S. This form of password response obviously changes from
session to session and ensures that the true password of O is not snared
by an interloper. There does remain the question of where O keeps the
passwords of all the smartcards that it owns, and how secure such a
database is. However, there is actually no need for O to keep a database
of passwords. All that O needs is a single seed string which, when
processed with the data supplied by S, yields the smartcard's password.
That data is the ID information.
d. Since the string submitted by the smartcard will always be either the
same or unknown to O beforehand, an additional authentication step may be
desir | | |
