Beruflich Dokumente
Kultur Dokumente
F L OAT I N G L I C E N S E M A N AG E M E N T
A REVIEW OF FLEXlm
Table of Contents
ABSTRACT 1.0 INTRODUCTION 1.1 LICENSING POLICIES NODE-LOCKING USER-BASED LICENSING SITE LICENSING NETWORK LICENSING 1.2 LICENSE MANAGEMENT 2.0 FLEXLM, FLEXIBLE LICENSE MANAGER 2.1 OVERVIEW 2. 2 COMPONENTS License Manager Daemon ( lmgrd ) Vendor Daemon License File Client Application Program 2.4 THE LICENSE FILE SERVER lines DAEMON lines FEATURE lines 2.5 LICENSE FILE TYPES 2.6 THE OPTIONS FILE 2.7 FLEXLM STANDARD ENCRYPTION ALGORITHM 2.8 HOW IT ALL WORKS? 2.9 SEED HIDING SYSTEM 3.0 FLEXLM THE OTHER SIDE 3. 1 LIMITATIONS 3.2 THE REVERSING Generating the license key that belongs in the license file Disabling Verification Emulating the Vendor Daemon Extraction of seeds FLEXlm protected targets Decryption of FLEXCrypted Files 3.3 WHERE ARE THEY NOW? 4.0 RELATED TECHNOLOGIES 4.1 AUTO-X 4.2 HASP HL NET USB KEY 4.3 IBM LICENSE USE MANAGEMENT (LUM) 5.0 RECOMMENDATIONS 6.0 SUMMARY BIBLIOGRAPHY 3 4 5 5 5 5 5 6 8 8 8 9 9 10 10 11 12 12 12 13 14 15 15 16 18 18 19 19 20 20 21 22 22 23 23 24 24 24 25 25
Abstract
This paper presents an overview of license management that is used for the protection of software products. This mechanism falls into the software-based protection category. The emphasis is on the Flexible License Manager (FLEXlm) system. It highlights the different components of the system as well as describes the license request process. The paper also provides an analytical view of some methods employed to secure the system and how they can be reversed. Finally, some recommendations of a desirable software protection system are concluded based on the analyses of different methods.
1.0 Introduction
The first models of software licensing developed in the days of stand-alone computing and million dollar computers included licenses were fixed to a particular CPU, prices of software licenses increased as the computer's performance increase and limiting the number of copies of software made to disk or tape was important as this was seen as an exhaustive and expensive task. When PCs became popular in the early 1980s, PC software vendors kept this earlier view of licensing software with the exception of pricing based on CPU performance. However, with the rapid evolution and market acceptance of networked computing in the late 1980s, the industry was forced to rethink what software licensing means in a networked environment of workstations, servers, and terminals. With this concept of software licenses, system administrators could keep track of software by limiting the copies of software to hard disks that were directly attached to licensed CPUs. Networked file systems made this view of licensing obsolete. The new workstation customer called for a new wave of software licensing. Software was now seen as a network resource, therefore licenses "float" on the network. Software costs were defined in terms of how many users simultaneously run the software, as opposed to pricing based on number of users or CPU performance. Furthermore, actually value existed in the use of software and not in the number of copies on disk.
Node-locking
This was once the most common form of licensing. It parallels the view that software is licensed to a particular computer. This licensing model is usually found in computationally intense applications and with software used on workstations dedicated to a particular application.
User-based licensing
This form of licensing assigns a given license to a named user identification. This is useful for products that are user dependent, such as an e-mail product, or business transaction applications or any other application in which "lending" user identification conflicts with the very nature of the application.
Site licensing
This involves licensing software to a geographical site. This model can be used for example, in a company with a large corporate campus where multiple sites are defined. Site licenses are most appropriate when companies standardize on a specific product.
Network licensing
This model also know as floating licenses is almost synonymous with license management. Floating licenses fit very well with the concepts of networked computing due to its efficient matching of usage to the number of licenses sold. Users can have access to a software product, but the cost of this access may be the price of a few licenses. As the software becomes widely used, additional licenses are purchased.
Floating licensing provides benefits for users, administrators and vendors: Users have access to the shared resource, versus limiting access to those with a license on their workstation. Administrators can control the node(s) where the licenses will be available across heterogeneous networks. Vendors can control who uses the licensed application. Other licensing policies include specifying an "expiration date" or a "start date" for licenses. This type is often used in software evaluations or leasing programs. There is no "right" licensing policy for all products. Software developers decide policies based upon the way the software product is designed and used, and commercial competitive factors. Sometimes the same software may be licensed in many different ways depending on the users needs.
Workstations today are on large heterogeneous networks, and license managers may be called upon to serve hundreds or thousands of licenses at one time. These networks may support workstations from Microsoft, Sun, HP, IBM, etc. In addition, many applications run on several different workstations. The license manager should allow licenses for Sun applications to be shared with the HP and IBM workstations; if the software developer so chooses. Some of the first license managers were special purpose license managers written by software developers for their own products. Today, however, software developers rarely write their own license manager. Instead, they license commercially sold license managers, such as FLEXlm (a contraction of FLEXible License Manager) to assist in the administration of license usage. License management is a growing trend and most system administrators prefer to learn and use only one license manager for controlling applications at their sites, rather than learning a different one for each licensed product. Even developers with their own license manager switch to standardized package like FLEXlm because of requests from their clients for them to be consistent with the commercial license managers.
Globetrotter Inc., FLEXlm is now owned by Macrovision and has now been renamed to FLEXnet. It is commonly used for the management of licenses of electronic design automation software, normally on computers running on both UNIX and Windows operating systems.
2. 2 Components
FLEXlm consists of the following main components: License manager daemon Vendor daemon License file Client application
FLEXenabled Application
Application Code
Vendor Daemon
In FLEXlm, licenses are handled by running processes. There is one process for each vendor who has a FLEXlm-licensed product on the network. This process is called the vendor daemon. The vendor daemon keeps track of how many licenses are checked out, and
Vendor Daemon
Options File
License(s)
who has them. If the vendor daemon terminates for any reason, all users lose their licenses. Users normally regain their license when lmgrd restarts the vendor daemon. Client programs communicate with the vendor daemon through TCP/IP or UDP/IP sockets. The client (where the application runs) and the daemon processes (the license server) can run on separate nodes on your network. Also, the traffic between the client and the license manager daemon is machine-independent, allowing for heterogeneous networks. This simply means the license server and the workstation running an application can be either different hardware platforms or different operating systems.
License File
Licensing data is stored in a text file called the license file. The license file is created by the system administrator. It contains information about the server nodes and vendor daemons, and at least one line of data (called a FEATURE line) for each licensed feature. Each FEATURE line contains an encryption code based on the data in that line, the hostids specified in the SERVER lines, and other vendor-specific data.