3. License transfer with delegation certificates
In order to achieve flexibility and ease of use, our goal is to allow a single smart card to act as a token for arbitrarily many software packages. The licenses are distributed on cards that the customers get bundled with each software package. Normally each card holds only a single license. With a simple procedure, the licenses on one card can be transferred onto another card. After the transfer, the ``empty'' card may be discarded.Every card has a unique public-private key pair. The private key is stored on the card and never revealed to the outside. At any time when the card is in the reader, it will respond to a challenge to prove that it, indeed, has the private key corresponding to the public key. This way, the software can check that the card associated with the license is present in the reader.
It is still necessary to bind a license to the public key. A convenient way to do this is to issue a certificate to the public key of the card. The certificate will be signed by the software publisher's master key and it will be verified with a public key incorporated in the software or in the operating system. The certificate can be stored outside the card. In fact, the card never needs to know which licenses it is certified to have.
It is crucial that the publisher's master public key and the procedure for checking the certificate and the presence of the card are embedded in the software in such a way that the key cannot be changed and the check cannot be disabled. In general, this is not an easy task. The protection can always be removed by reverse engineering the code. In practice, however, obfuscation of the checking procedure can significantly delay the reverse-engineering process and the production of marketable copies. Section 6 describes some measures that make the marketing of the modified software less attractive after the protections have been removed.
We will now outline the mechanism for transferring licenses from one card to another. Once the license is bound to a public key, it can be given to other keys by delegation. The key having a license simply signs a certificate stating its willingness to give the same rights also to the key of another card. This kind of certificate with which one key delegates access rights to another one is called a delegation certificate. The signing is done with public-key cryptography. It is possible to use standard certificate formats and techniques [5,2].
Unfortunately, this simple procedure is not quite enough; it would result in duplication of the license. After handing over the license, the first card must cease to function as a token. Furthermore, it must never sign another delegation certificate (at least not to delegate the same license). The simplest way to ensure this is to erase the private key from the delegating card. Erasing the key means that we must always transfer all licenses together to the same card and then discard the original card.
Thus, license transfer comprises two steps:
- delegating the license to another card
- disabling the delegating card as a token.
In principle, a license can be transferred an unlimited number of times. Every transfer adds a new delegation certificate to a chain that passes a growing collection of licenses from card key to card key. When the right to use a certain software package is verified, there must be a complete chain of certificates starting from a license certificates signed by the publisher's master key and ending with the public key of the card that is currently in the smart card reader. In practice, the number of transfers for a single license will be very small (usually one). The licenses cannot be transferred onto previously disabled cards and every transfer accumulates all the licenses on two cards onto a single one.
The cards need to have only two basic functions: proving the possession of a private key by responding to a challenge and signing a delegation certificate after which the card disables itself. Further management of the certificates is done outside the smart card. Sec. 4 details the transfer protocol.
The idea of transferring licenses from one smart card to another bears
resemblance to the transferable digital cash of Pagnia and Jansen
[12]. From the result of Chaum and Pedersen
[4], we can infer that the growth of the license data with
each transfer is inevitable. In our scheme, another delegation
certificate will be appended to the license in each step. It is
important, however, to note that the growing collection of delegation
certificates is not stored in or processed on the smart cards. The
smart cards act as tamper-resistant observers that guard against
copying of licenses. This is equivalent to double spending prevention
for digital money [3].
(The notation SK(M) means the message M
signed with the key K. Our view of the signature function is
ideal. Implementations should follow accepted standards such as PKCS
[7].)
The certificate contains the production date or serial number of the
card. The licenses can only be transferred from older to newer
cards. This ensures that cryptanalysis of old card keys or cracking
the defenses of old tamper-resistant cards cannot be used for copying
new software products. It should be noted that the card certificates
and the dates on them originate from the software publisher or trusted
card manufacturers, the date stamps are compared against each other,
and the comparison is done on the tamper-resistant license cards. No
clocks are needed on the smart cards and clocks in the user equipment
are not relied on. Therefore, the comparison of dates is reliable. As
a secondary protection, the software checking the presence of the
token should also ensure that the date on the card certificate is not
older than the software itself.
Normal cards originally hold only one license as they are sold in
retail stores with software packages. The license is a certificate
signed by the PMK that binds the right to use a certain software
package to the CK. The license certificate is of the form
Although it is not necessary to store the license information on the
card, it is convenient to distribute licenses on the cards that come
bundled with the software distribution media. This way, the software
itself can be on identical media, e.g. printed CD-ROMs. For
efficiency, it is best to read the card and license certificates from
the card into the workstation only once when the software is installed
and never refer to them on the card again. It is possible to ship
several license certificates with a single card (e.g. stored on a
floppy disk). This is practical when the publisher ships products
directly to the users or when workstation manufacturers pre-install a
standard set of software.
In addition to carrying the
certificates, the card can perform two main functions: proof of
identity and license transfer. The former means proving
the possession of the private CK. The card does this simply
by signing a challenge.
Protocol 1 (proof of identity):
The checking software first needs the public card key CK and the
card certificate. Then, it can send a challenge to the card and verify
that the card is authentic. To decide if the card has a certain
license, the software follows the delegation certificates to find a
chain of delegation from PMK to CK. These certificates are stored
outside the card and can be written into a file or onto a floppy disk
for keeping with the card.
The delegation certificates are created in the second main function of
the card, the license transfer. All licenses on the card are always
transferred at the same time. After the transfer, the original card
can be thrown away.
The transfer protocol is very simple. Licenses on two cards will be
combined onto one of them. The source card (the one to transfer from)
must be the older card and the destination card (the one to transfer
to) the newer one. Before the transfer, the workstation obtains the
card certificate of the destination card. After that, the protocol is
between the workstation and the source card only. The destination card
is not involved in the communication. The delegation certificate
produced in the transfer will be stored in the workstation and it will
later be used together with the destination card. However, the
destination card does not need to know anything about the transfer and
the certificate is never saved onto the card.
Protocol 2 (license transfer):
In the first step of the protocol, before delegating the license to
the public key CK', the source card checks that the key belongs to
an authentic license card. It therefore needs the card certificate
for CK'. It also compares the date on the card certificate to its
own production date to see that the destination card is the same age
or newer.
In step 2, the card signs a delegation certificate for
CK'. The certificate is of the form SCK(``I
give all my licenses to", CK'). After signing the certificate,
the card permanently erases its own private key CK from its
memory. After erasing the key, the card is not anymore able to
perform Protocol 1, i.e. the proof of
identity. This means that it is disabled as a license token.
Having created the delegation certificate, the card returns it to the
requesting workstation in Step 3 of the transfer protocol. After the
transfer, the source card is useless and it can be thrown away. In
order to protect against loss of certificates, the card certificate,
the license certificate and the new delegation certificate are still
stored on the otherwise disabled card and can be reread an unlimited
number of times.
A crucial point for the smart card implementation is that signing the
delegation certificate and erasing key private key must be an atomic
operation. If the operation is interrupted, for example, by cutting
power from the card, the card must either complete the signing and
erasure immediately after power-up, or it must return to the original
state where the delegation certificate does not exist. Moreover, the
production and storage of the delegation certificate on the card must
be reliable because the signing cannot be repeated after the private
key has been erased.
In summary, the protocol performs the two steps that make a complete
transfer: delegation and disabling the old card as a token. In the
workstation, the new delegation certificate will be combined with the
ones both cards previously had. All these certificates are needed for
use with the destination card (Fig. 2).
When licenses are sold on-line, they can be personalized for each
customer. The key to controlling the distribution of the licenses is
to bind each license to exactly one user workstation at a time. There
are plans for incorporating unique identifiers into the
microprocessors in personal computers for this purpose. Because of
privacy concerns, it is not clear whether such identifiers will ever
be implemented be all vendors. Some copy protection products compute
a fingerprint of the hardware and software configuration to identify
the workstation [13]. Unfortunately, this may cause
invalidation of the license when parts of the system are updated.
In our system, the card key of a smart card is a unique identifier to
which the licenses are bound. The same smart cards that are sold in
retail stores can be used for on-line purchases. Instead of getting
the licenses with the card, the customer buys license certificates for
his card from the on-line store. If the particular workstation already
has a license management card, the license certificate will be issued
to the public card key of that card. Most customers have recent cards
e.g. from purchasing the operating system and, since the price of the
smart card itself is low, empty cards without a license can be
distributed free of charge.
Protocol 3 (on-line purchase):
The on-line store needs to see the card certificate to check that the
public key CK belongs to an authentic license card.
The only limitation for this type of on-line sales is that licenses
should not be sold to cards that are too old because their keys might
have already been recovered by pirates. (If the pirate knows the
private key of an authentic license card, he can purchase one license
on-line and delegate it to any number of cards.) If the card is older
than some threshold time, the customer needs to obtain a new card and
move licenses from his old card onto it before buying new software
on-line. The threshold time for rejecting old cards can be adjusted
for new products according to the experiences from earlier releases.
Actually, it is not important how the software itself is distributed:
on-line or on a CD-ROM or on some other medium. The distribution of
licenses can be completely independent of the software distribution.
On-line services open new possibilities for strengthening the security
of the system. If the product includes parts or services, such as
updates, that are delivered over the Internet, the servers can check
for the license before providing the service. The on-line server will
send the user workstation a challenge. The response from the smart
card is sent to the on-line service along with the public key of the
smart card, the license certificate or a chain of certificates from
PMK to CK, and the card certificates for all card keys in the
delegation chain. The server can store fingerprints of the keys in
the chain and refuse to repeatedly provide the same service for the
same keys. Similarly, the same license should not be sold twice to the
same card because it may indicate that the card is a clone. This
improves the strength of the copy protection in case a pirate is able
to recover the private key of a single card. Users of the pirated
licenses will be refused on-line service.
It is for the purpose of bookkeeping at the on-line servers that we
retain all the card certificates in the license transfer. If on-line
services are not available or the on-line server has a database of all
valid card keys, it is not necessary to store the card certificates of
the disabled cards after the transfer. It suffices to keep the one
belonging to the active card.
The two most dangerous attacks against the copy protection in our
license management scheme are recovering of the private key from the
smart card and modifying of the software to bypass the checking for
the token.
When on-line updates or other Internet services are an essential part
of the product, the problem of recovered private keys is alleviated by
having the servers remember the keys for which the service has already
been provided (see Sec. 5). Professional pirates
cannot produce fully functional copies even if they are able to crack
the protections of a single card because users of the illegal copies
will not be able to access the on-line services. This works because
the cards have unique keys instead of one shared secret. Continuing
the analogy to digital cash, the database of served card keys
resembles double-spending detection by banks that keep track of spent
coins.
Another way of discouraging the purchase of pirated copies is to have
the users authenticate the software. The person installing or using a
pirated software package should get a warning about potentially
dangerous, unauthentic code. The warning can be implemented by
signing the code with the publisher master key PMK or with another
key held by the publisher. The public verification keys can be
distributed on-line or with the operating system. If the pirates
modify the software in order to remove the check for the license, the
pirated copies inevitably fail the test for correct signatures. This
kind of integrity check is beneficial even if copy protection is not
an issue: software distributed over the Internet should be
authenticated in any case.
Implementation of the integrity warning messages requires co-operation
with the operating system or with a generic installation program. The
warnings can naturally be avoided by modifying also these support
programs. However, most business users of software are probably
unwilling to tweak their operating system according to the pirate's
instructions. Also, the embedded operating systems in special-purpose
devices such as game consoles and multimedia terminals often cannot
be modified by the user.
Instead of completely disabling the check for the token, pirates may
try to modify the smart card reader or its driver software in such a
way that several workstations can share one reader. The challenges and
responses could be transferred over the network between a single
reader and a large number of verifiers. To prevent such
modifications, the checking software should have direct access to the
smart card reader hardware so that it can trust the responses to be
from a local source. Sometimes, especially if the operating system
consists of replaceable modules or layers, it may be impossible to
prevent tapping between the card and the verifier. Even then, the
attack is only possible if the modification to the operating system is
available and if the user organization is willing to install the
patches on all workstations. Other possible defenses include binding
the licenses to workstation identities and limiting the number and
frequency of answered challenges per license. Such measures, however,
imply unique processor identifiers, on-card timers, counters, and much
more complex protocols that are beyond the scope of this paper.
There is one effective technique for checking the presence of the
token which requires some adjustment for our public-key protocols.
That is, the software on the distribution media can be encrypted and
the license token should contain the key for decrypting it. If the
software is never stored outside the computer memory in decrypted
form, it cannot be loaded without the token. (Naturally, this is just
a way of obscuring the check for the tokens. The program in the
insecure computer memory can be read and saved with special tools and
skillful reverse engineering.) Dongles sometimes carry a secret key
for decrypting the code [13]. If we want to use this
technique in our license transfer scheme, we have to pass the
decryption keys to the destination card and erase them from the source
card as a part of the license transfer. The keys can be transferred
by encrypting them with the public key of the receiving card.
The physical theft of license cards may be a problem anywhere where
untrusted persons have physical access to the workstations. The
standard protection against the theft of smart cards is that the card
requires the user to enter a password after it is inserted into the
reader. The card refuses to work unless activated with the correct
password. This effectively prevents the use of stolen license cards.
The password can be distributed on paper with the card. For
convenience, the users should be able to disable the password feature
in environments where theft is not a major threat.
Even with the password protection, there is still the danger that
someone removes the card not for his own profit but to cause damage to
the owner. Vandalism is a problem for public-access computers in
places like universities and libraries. The card could be protected by
enclosing the card reader inside the workstation casing or by using
lockable special-purpose readers.
A more interesting scenario is that the thief transfers the license
onto his own card. A hacker could even break into the computer from
the network and invoke the transfer procedure without having physical
access and without exposing himself to much danger of being
identified. Again, a separate one-time password should be required by
the card before the transfer. Since the transfer is activated only
once for each card, passive sniffing for the passwords does not
benefit an attacker. In theory, the hacker could take over the
transfer process after the user has entered the password and replace
the destination card certificate with his own. Therefore, license
transfers should be done on a trusted workstation, preferably
off-line. An alternative protection that prevents attacks from the
network is a physical write-protect switch on the card that must be
shifted to allow the transfer.
The license transfer is an extremely simple procedure for the user. He
inserts the two cards into the smart card reader, the newer card
first. (If the order is wrong, he is asked to reinsert the first
card.) He may be asked to provide a floppy disk for backing up the
certificates.
The system requires the user to have a smart card reader on every
workstation and the license card must be in the reader for most of the
time. Beyond the card reader, no changes to existing hardware (e.g.
Internet connection, secure processors or hardware identity numbers)
are needed. After the initial investment in the readers, the marginal
cost of protecting each new product is small. Since the certificates
are stored and handled mostly outside the cards, the storage and
computational capacity needed in the smart cards is bounded.
We have seamlessly integrated shrink-wrap and on-line sales of
software licenses. The license management does not require any changes
to existing software distribution channels. In particular,
incorporating a smart card into shrink-wrap software packages does not
increase the workload at retail stores or require users to have
network connections.
The security of the system relies on two non-trivial assumptions.
First, the smart card must be tamper resistant in the sense that the
private key cannot be recovered from the card. Recovering the key of
even one card makes it possible for a professional pirate to sell
counterfeit licenses. With on-line distribution of licenses, the
pirate must crack a new card when the previously cracked card becomes
so old that the on-line store refuses to sell new licenses to it. If
software is not sold on-line, the pirate must recover a new key for
each new software product or version. It depends on the state of the
tamper-resistant smart card technology how long it takes to analyze a
card. Service can be denied to those users of pirated software who
try to utilize on-line updates and services associated with the
products.
Second, the checking for the token in the software package must be
obscured in such a way that the check cannot be disabled. Since the
public key of the software publisher (PMK) is used for the checking,
one should not be able to change this key in the code. Like
tamper-resistant cards, obscured software can be analyzed with time
and resources. In this case, it is probably the easier line of
attack. We suggest discouraging the use of modified software by
issuing warnings to the user.
When these basic assumptions are satisfied, the license transfer
protocol itself is fairly robust. The transfer process cannot be
interrupted to prevent erasure of the old license because the private
key is erased as soon as the delegation certificate has been
signed. We state formally the claim that the protocols do not allow
copying of licenses (see the Appendix for the
proof):
Proposition 1:
The number of keys with valid licenses is at most equal to the number
license certificates signed by PMK.
Moreover, licenses are not easily lost because the delegation
certificates can be reread from the card at any later time and the
certificates are backed up on the workstation hard disks or on floppy
disks.
In summary, the license management system prevents multiple use of one
license and it increases significantly the work of professional
pirates. Although the user must keep the license card in the smart
card reader, it is much more convenient than having separate tokens
for each product.
Although the protocol is fairly robust against accidental loss of
licenses, there should be some off-line recovery mechanisms in case
the license card is damaged or the delegation certificates are lost.
The software producer can be generous with replacing cards and lost
licenses. If a log is kept of the customers who receive a replacement
certificate or smart card, the number of customers willing to cheat to
get one extra copy of the product is likely to be small.
Although we have designed the license transfer protocol with local
transfer in mind, the protocol itself has no restriction for remote
transfer over a network. If this is implemented, the customer can
transfer licenses over large distances without waiting to get the
physical license card in mail. The remote transfer cannot be abused so
that several remote users would pool to share a license (with at most
one user at a time) because a new smart card is needed for each
transfer.
In order to have only a single card per workstation, software
publishers must co-operate. All card must use the same protocol and
meet the same standard of tamper-resistance. Fortunately, it is not
necessary to have all publishers share the master key PMK. Instead,
the products of each publisher can check for a delegation chain
starting from its own master key. These publisher keys, however,
cannot be used for signing the card certificates because the safety of
the cards affects all publishers. For this purpose, another layer of
delegation can be added: a trusted agency holding a master key that
will certify card manufacturers' master keys. The manufacturer will
include its certificate on the card and sign the card key CK with its
own key. This allows accreditation of new manufacturers at any time.
Naturally, the use of the delegation certificates for license
management is not restricted to smart cards. The same ideas could be
used with any intelligent hardware tokens as long as the tokens are
capable of processing public-key signatures and their cost is low
enough so that they can be discarded. Different physical
implementations of the tokens can be mixed as long as they follow the
same protocols. Non-discardable physical tokens such as dongles and
chips embedded in the computer hardware work well but licenses should
be only transferred onto them, not from them. One possibility is to
have one embedded token per workstation and to use smart cards only
for license distribution.
Finally, an alternative to having a card for each workstation is to
let each user carry a personal license card. That naturally leads to
using the card as a general-purpose identifier for the user. Our
protocols are equally well suited for many other purposes such as
maintaining personal key rings for smart-card locks. However, such
applications are beyond the scope of this paper.
[2]
Tuomas Aura.
Distributed access-rights management with delegation certificates.
In J. Vitek and C. Jensen, editors, Secure Internet Programming:
Security Issues for Distributed and Mobile Objects, LNCS. Springer, 1999.
[3]
Stefan Brands.
Untraceable off-line cash in wallets with observers.
In Advances in Cryptology - Proceedings of CRYPTO '93, volume
773 of LNCS, pages 302-318, Santa Barbara, 1993. Springer-Verlag.
[4]
David Chaum and Torben Pryds Pedersen.
Transferred cash grows in size.
In Advances in Cryptology - Proceedings of EUROCRYPT '92,
volume 658 of LNCS, pages 390-407. Springer-Verlag, May 1992.
[5]
Carl M. Ellison, Bill Franz, Butler Lampson, Ron Rivest, Brian M. Thomas, and
Tatu Ylönen.
Simple public key certificate.
Internet draft, IETF SPKI Working Group, March 1998.
[6]
Amir Herzberg and Shlomit S. Pinter.
Public protection of software.
ACM Transactions on Computer Systems, 5(4):371-393, November
1987.
[7]
Burt Kaliski and Jessica Staddon.
PKCS #1: RSA cryptography specifications, version 2.0.
Internet draft, IETF Network Working Group, September 1998.
[8]
Davis P. Maher.
Fault induction attacks, tamper resistance, and hostile reverse
engineering in perspective.
In Proc. 1st International Conference on Financial Cryptography
FC '97, volume 1318 of LNCS, pages 109-121, Anguilla, British West
Indies, February 1997. Springer Verlag.
[9]
Nasir Menon and Ping Wah Wong.
Protecting digital media contect.
Communication of ACM, 41(7):35-43, July 1998.
[10]
Mondex.
Mondex home page, 1998.
URL:http://www.mondex.com.
[11]
Information Technology Association of America.
Intellectual property protection in cyberspace: towards a new consensus.
ITAA discussion paper, 1998.
[12]
Hans-Henning Pagnia and Ralph Jansen.
Towards multiple-payment schemes for digital money.
In Proc. 1st International Conference on Financial Cryptography
FC '97, volume 1318 of LNCS, pages 203-215, Anguilla, British West
Indies, February 1997. Springer Verlag.
[13]
John Phipps.
Physical protection devices.
In Derrick Grover, editor, The protection of Computer Software -
its technology and applications, British Computer Society (BCS) Monographs
in Informatics, chapter 3. Cambridge University Press, 2nd edition, 1992.
[14]
George B. Purdy, Gustavus J. Simmons, and James A. Studier.
A software protection scheme.
In Proc. 1982 Symposium on Security and Privacy, pages
99-103, Oakland, California, April 1982. IEEE Computer Society Press.
[15]
Steve R. White.
ABYSS: A trusted architecture for software protection.
In Proc. 1987 IEEE Symposium on Security and Privacy, pages
38-51, Oakland, California, April 1987. IEEE Computer Society Press.
Definition 1:
A key CK has a valid license if the private part of the
key CK is unerased, and there is a card certificate signed by
PMK and issued to the public part of CK, and a
certificate chain:
This forms a valid license because the verifier checks for these
conditions before allowing the use of the software. It is possible
that k=0, i.e. there are no delegation certificates. We ignore the
check for the other card certificates (of CK0 ... CKk-1) and
for the production dates because they have effect only if some other
assumption is broken.
Assumption 1:
PMK only issues license and card certificates to authentic card keys.
An authentic card key only issues delegation certificates to
keys with a card certificate. []
Assumption 2:
For every authentic card key CK, exactly one of the following holds:
The second assumption follows from the policy of erasing the private
key immediately after signing a delegation certificate.
Proposition 1:
The number of keys with valid licenses is at most equal to the number
license certificates signed by PMK. []
Proof:
The subjects of license certificates (CK0) are
always authentic card keys. An authentic card key only delegates to a
key with card certificate and such keys are authentic card keys
(Ass. 1). Consequently, all keys in the chains starting from license
certificates are authentic card keys. The authentic card keys delegate
to at most one other key and a key that has delegated is itself erased
(Ass. 2). Thus, the certificate chains starting from license
certificates do not branch and only the last key in a chain can be
unerased.
If there would be more keys with valid licenses than license
certificates, there should be some two valid licenses whose
corresponding certificate chains (Def. 1) begin with the same license
certificate but end in two different unerased keys. However, this is
not possible since the chains do not branch and only the
maximal-length chains end in unerased keys.
4. Protocol for license verification and transfer
Each card has a unique signature key pair. The public part of the card
key (CK) can be read from the card at any time while the private key
is never exported outside the card. In addition to the keys, the card
stores a card certificate signed by the software-publisher
master key (PMK). The card certificate states that CK is the
public key of an authentic license card. The certificate can be freely
read from the card. Anyone knowing the public PMK can verify the
certificate on the card and conclude that this is an authentic
license card approved by the software publisher. The PMK and the
card certificate will be used to ensure that licenses are transferred
only to smart cards that reliably protect them from copying. Every
card has to store the authentic public PMK for verifying card
certificates. A card certificate is of the form
![[A GIF image of a license card]](card.gif)
Fig. 1 A basic license card has a key pair and two certificates.
1. Workstation -> Card : ``License card challenge'', N
2. Card -> Workstation : SCK(``License card response'', N)
1. Workstation -> Source card : ``Please transfer to'', CK', SPMK(CK', ``is a license card key with production date'', date)
2. The source card signs a certificate and erases its private key CK.
3. Source card -> Workstation : SCK(``I give all my licenses to'', CK')
Fig. 2 License transfer = signing a delegation certificate +
disabling the source card. The certificates are stored outside
the cards.
5. On-line software distribution
Although we cannot assume all customers or all workstations to have
Internet connections, an increasing number of customers is willing to
purchase software on-line. Two-way communication between the user
workstation and the software publisher opens new possibilities for
license management. It is necessary for the same license management
system to support both traditional shrink-wrap software sales and
on-line commerce.
1. Customer -> Publisher : ``I buy a license for'', CK, SPMK(CK, ``is a license card key produced on ", date)
2. Publisher -> Customer : SPMK(CK, ``has a license for'', software)
6. Enhancing the copy protection
Copy protection is never perfect. Therefore, we will consider ways of
strengthening the protection. The effectiveness of these techniques
depends on the nature of the product and the environment where it is
mainly used.
7. Preventing license theft
New technology often creates new types of vulnerabilities that are
beyond our prior experience. When the software licenses are bound to
small, tangible objects, a new threat emerges: theft of licenses. And
what is most disconcerting, the transfer protocol could be misused to
steal licenses electronically over the network. Luckily, theft can be
prevented with simple password protection.
8. Evaluation
The main goal in the development of our license management scheme was
to make the use of hardware tokens user-friendly. In particular, we
have solved the problem of smart-card juggling. Although the user must
insert a smart card into the reader, it is not any more necessary to
periodically switch between cards. Licenses of several software
packages are transferred onto a single card.
9. Protocol extensions
Our license management protocol can be extended in several ways to
increase its flexibility for users.
10. Conclusion
We have described protocols for binding software licenses to
tamper-resistant smart cards, for transferring them between cards and
for buying licenses on-line. There must be smart card readers at the
workstations but no network connection or other changes to existing
hardware are needed. The protocols support software distribution both
through retail stores and over the Internet. The user can transfer
licenses from several cards onto a single card so that juggling
between several card in the reader is eliminated. The transfer
protocol is easy and intuitive for the user. The smart cards must be
able to process public-key signatures. In other respects, the
protocols are simple both to implement and to analyze. Most of the
data involved is stored outside the smart card. The protocols may also
have applications in other system where smart cards are used for
storing credentials.
Acknowledgments
Tuomas Aura's work was funded by Helsinki Graduate School for Computer
Science and Engineering (HeCSE) and Academy of Finland and it was done
mostly at UC Davis Computer Security Laboratory.
References
[1]
Ross Anderson and Markus Kuhn.
Tamper resistance - a cautionary note.
In The Second USENIX Workshop on Electronic Commerce
Proceedings, pages 1-11. USENIX Association, November 1996.
Appendix (proof of protocol security)
We consider the licenses for a single software product.
a delegation certificate signed by CK0
to CK1,
a delegation certificate signed by CK1
to CK2,
···
a delegation certificate signed by CKk-1
to CKk