• No results found

(51) Int Cl.: G06F 21/00 ( )

N/A
N/A
Protected

Academic year: 2021

Share "(51) Int Cl.: G06F 21/00 ( )"

Copied!
15
0
0

Loading.... (view fulltext now)

Full text

(1)

Note: Within nine months of the publication of the mention of the grant of the European patent in the European Patent Bulletin, any person may give notice to the European Patent Office of opposition to that patent, in accordance with the

1 6

74 963

B1

&

(11)

EP 1 674 963 B1

(12)

EUROPEAN PATENT SPECIFICATION

(45) Date of publication and mention

of the grant of the patent:

13.08.2008 Bulletin 2008/33

(21) Application number: 05024856.6

(22) Date of filing: 14.11.2005

(51) Int Cl.:

G06F 21/00(2006.01)

(54) Secure license management

Sicheres Management von Lizenzen Gestion de licences sécurisée (84) Designated Contracting States:

AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

(30) Priority: 22.12.2004 US 20386

(43) Date of publication of application:

28.06.2006 Bulletin 2006/26 (73) Proprietor: SAP AG 69190 Walldorf (DE) (72) Inventors: • Kilian-Kehr, Roger 64291 Darmstadt (DE) • Kuemmerle, Jan 65817 Eppstein (DE)

(74) Representative: Müller-Boré & Partner Patentanwälte Grafinger Strasse 2 81671 München (DE) (56) References cited: US-A- 5 933 498 US-A1- 2003 037 237 US-A1- 2004 039 924 US-A1- 2004 078 572 US-A1- 2004 093 505 US-A1- 2004 230 797

• "Trusted Computing Platform Alliance (TCPA) Main Specification Version 1.1b" TCPA MAIN SPECIFICATION, 22 February 2002 (2002-02-22), page COMPLETE332, XP002294897

(2)

5 10 15 20 25 30 35 40 45 50 55 Description BACKGROUND

[0001] The present disclosure relates to data process-ing by digital computer, and more particularly to license management.

[0002] Software vendors use license management programs, also referred to as license managers, to pre-vent unauthorized use of the software. The license man-ager is designed to enforce the conditions of the software license and to prevent access to the software when those conditions are not met.

[0003] Unfortunately, the license manager, like any software program, is vulnerable to tampering. Conven-tional license managers, however, are unable to deter-mine the trustworthiness of the computing environment in which they are running.

[0004] US 2004/0039924 discloses a system and method for securing a computing device using a master cryptographic key that is bound to the device. The master key is used to derive sensitive data that is transferred to storage that is only accessible in a restricted mode of operation.

SUMMARY OF THE INVENTION

[0005] Methods, systems, and computer program products, implementing techniques for license manage-ment.

[0006] In one general aspect, a system implementing the techniques comprises a host computer running in a trusted state, and a license manager installed on the host computer. The license manager is configured to provide access to one or more software programs. The one or more software programs are accessible only through the license manager. The license manager is bound to the trusted state of the host computer, such that if the trusted state ceases to exist, then the license manager is not executable and the one or more software programs are not accessible.

[0007] The host computer is a TCPA (Trusted Com-puting Platform Alliance) enabled computer.

[0008] The trusted state is established by booting the host computer using a secure boot process.

[0009] The host computer includes hardware nents and software components. The software compo-nents include an operating system. The hardware com-ponents include a Core Root of Trust for Measurement (CRTM). The CRTM is a trusted component.

[0010] The secure boot process involves using the trusted component to verify the trustworthiness of the hardware components before handing system control over to the operating system, which then verifies the in-tegrity of the software components.

[0011] The hardware components further include a Trusted Platform Module (TPM). The trustworthiness of the hardware and software components are verified

us-ing system configuration data stored in the TPM.

[0012] The license manager is partitioned into a dy-namic data section and a static code section, the dydy-namic data section includes data that changes during execution of the license manager, the static code section including data that does not change during execution of the license manager.

[0013] The static code section is partitioned into two subsections, a first subsection that stores code for the software programs and a second subsection that stores configuration data for the license manager.

[0014] The dynamic data section is protected by a cryptographic key (data key), the static code section is protected by a different cryptographic key (code key).

[0015] Implementations can include one or more of the following features

[0016] The data key and the code key may be protect-ed by a different cryptographic key (external key). The external key may be bound to the trusted state of the host computer.

[0017] In another general aspect, a computer program product implementing the techniques is operable to cause data processing apparatus to perform operations including verifying that the host computer is running in a trusted state, receiving a first cryptographic key from the host computer, the first cryptographic key being bound to the trusted state of the host computer, encrypting the license manager using the first cryptographic key, and transferring the encrypted license manager to the host computer.

[0018] Implementations can include one or more of the following features. Verifying that the host computer is run-ning in a trusted state may include performing a remote attestation process on the host computer.

[0019] Performing a remote attestation process on the host computer may include: receiving system configura-tion data from the host computer and comparing the re-ceived system configuration data to a set of known sys-tem configurations.

[0020] The license manager may be partitioned into a dynamic data section and a static code section, the dy-namic data section may include data that changes during execution of the license manager, the static code section including data that does not change during execution of the license manager.

[0021] Encrypting the license manager using the first cryptographic key may include encrypting the dynamic data section using a second cryptographic key, encrypt-ing the static code section usencrypt-ing a third cryptographic key, and encrypting the first and second cryptographic keys using the first cryptographic key.

[0022] The techniques can be implemented to realize one or more of the following advantages. The license manager is secure from tampering. A trusted state is es-tablished on the host computer before the license man-ager is installed on the host computer. As long as the trusted state exists, the license manager can be assured that the hosting environment does not contain any rouge

(3)

5 10 15 20 25 30 35 40 45 50 55

programs that attempt to prevent the license manager from working correctly. One implementation provides all of the above advantages.

[0023] Details of one or more implementations are set forth in the accompanying drawings and in the description below. Further features, aspects, and advantages will become apparent from the description, the drawings, and the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0024]

FIG. 1 illustrates a system for secure license man-agement.

FIG. 2 illustrates a TCPA-enabled host computer. FIG. 3 illustrates a license manager.

FIG. 4 illustrates a key container.

FIG. 5 illustrates a process for transferring the li-cense manager and the key container to the host computer.

[0025] Like reference numbers and designations in the various drawings indicate like elements.

DETAILED DESCRIPTION

[0026] As shown in FIG. 1, a system 100 includes a license manager 110 for managing the use of one or more software programs 120. The license manager 110 en-forces certain conditions of use, as defined by one or more software licenses 130 associated with each soft-ware program 120. The softsoft-ware programs 120 are only accessible through the license manager 110. Thus, if the license manager 110 is not running, then the software programs 120 are not accessible.

[0027] The license manager 110 and the software pro-grams 120 are installed on a host computer 140.

[0028] Prior to installing the license manager 110 on the host computer 140, a trusted state 150 is established on the host computer 140.

[0029] The license manager 110 is then bound to this trusted state 150 so that the license manager 110 can only operate while the trusted state 150 exists. If the trust-ed state 150 ceases to exist, then the license manager 110 cannot operate and the one or more software pro-grams 120 cannot be accessed.

[0030] The trusted state 150 is established by booting the host computer 140 using a secure boot process. In one implementation, the secure boot process requires that the host computer 140 be a TCPA-enabled compu-ter. TCPA (Trusted Computing Platform Alliance) is an initiative led by various computing companies (e.g., Ad-vanced Micro Devices, Hewlett-Packard, Intel, IBM, Mi-crosoft, Sony, Sun) to implement technologies for trusted computing. This group of companies, also known as the Trusted Computing Group has published a TCPA spec-ification (available at

http://www.trustedcomputing-group.org) that describes the technologies developed by this group.

[0031] As shown in FIG. 2, a TCPA-enabled host com-puter 200 includes two TCPA components, a Core Root of Trust for Measurement (CRTM) 210 and a Trusted Platform Module (TPM) 220.

[0032] In one implementation, the trusted platform module 220 is a computer chip (e.g., a smartcard) that is hard-wired to provide certain functions, for example, key generation and controlled access to the generated keys. The trusted platform module 220 includes a set of memory registers known as platform configuration reg-isters (PCRs) 230. The platform configuration regreg-isters 230 store system configuration data 240. The system configuration data 240 can be metrics taken from various hardware and software components of the host computer 140. As will be described below, these metrics will be used during the secure boot process to verify the trust-worthiness of the host computer 140.

[0033] The CRTM 210 is the only portion of the host computer 140 that can be trusted initially, that is, before the trusted state 150 is established on the host computer 140. In one implementation, the CRTM 210 is the BIOS (Basic Input/Output System) of the host computer 140. Alternatively, the CRTM 210 makes up only a portion of the host computer’s BIOS.

[0034] The CRTM 210 begins executing when the host computer 200 is started. The CRTM 210 verifies the in-tegrity of the hardware components before handing sys-tem control over to the operating syssys-tem. The operating system then verifies the integrity of the software compo-nents. The verification of the hardware and software com-ponents is performed using the system configuration data 240 stored in the platform configuration registers 230 of the trusted platform module 220. The metrics are a re-flection of how the system components are configured. If the system configuration is tampered with or otherwise modified, the metrics will reflect this change. If any chang-es to the hardware or software components are detected by either the CRTM 210 or the operating system, then the boot process is stopped. Once the boot process has been completed, a trusted state 150 has been estab-lished on the host computer 140. Once the trusted state 150 has been established, the license manager 110 can be installed on the host computer 140.

[0035] As shown in FIG. 3, in one implementation, the license manager 110 is partitioned into a dynamic data section 310 and a static code section 320. Optionally, the license manager 110 can contain a third partition, metadata section 330, for storing metadata about the li-cense manager 110. For example, the metadata can in-clude information identifying the software programs 120 managed by the license manager 110, and the author-ized users of these programs 120.

[0036] The dynamic data section 310 contains data that the license manager 110 needs to perform its func-tions. This data is dynamic, meaning that its value chang-es during execution of the license manager 110. For

(4)

ex-5 10 15 20 25 30 35 40 45 50 55

ample, this data can include a counter value that counts the number of times a software program 120 has been executed.

[0037] The static code section 320 contains code that is required by the software programs 120 to run. The static code section 320 also contains configuration data that is required by the license manager 110. For example, the configuration data may indicate which network port and which host address (e.g., license.xxx.com) will be used by the license manager 110. The static code section 320 can be partitioned into two subsections, one subsec-tion to store the software program code and the other subsection to store the license manager configuration data.

[0038] In one implementation, the license manager 110 is protected by one or more cryptographic keys. These keys are stored in a key container 400, shown in FIG. 4. The key container 400 contains a data key 410 that is used to encrypt the dynamic data section 310 of the license manager 110 and a code key 420 that is used to encode the static code section 320 of the license man-ager 120. The data key 410 and the code key 420 are different cryptographic keys.

[0039] The key container 400 also contains a cate 430 obtained from a certifying agency. This certifi-cate is used to authenticertifi-cate the static code section 320. The dynamic data section 310 is not authenticated be-cause the data stored in the dynamic data section 310 is expected to change.

[0040] The entire key container 400 is protected by a cryptographic key that will be referred to as the external key 440. The external key 440 is generated by the trusted platform module 220 and stored within the trusted plat-form module 220. If the host computer 140 is not running in a trusted state 150, the trusted platform module 220 will not release the external key 440.

[0041] In one implementation, the external key 440 is an asymmetric key whereas the data key 410 and code key 420 are symmetric keys. Alternatively, the data key 410 and code key 420 can also by asymmetric keys. In this specification, the data key 410 and the code key 420 will be referred to collectively as the internal keys.

[0042] FIG. 5 illustrates a process 500 for transferring the license manager 110 to the host computer 140. This process is performed only after the trusted state 150 has been established on the host computer 140.

[0043] Typically, this process is triggered by the user of the host computer 140 making contact with the man-ufacturer of the software program 120 to request that the license manager 110 for the software program 120 be transferred to the host computer 140.

[0044] Before allowing this transfer to occur, the man-ufacturer verifies the trustworthiness of the host compu-ter 140 using a remote attestation process 510. As part of the remote attestation process 510, the manufacturer’s computer sends a challenge to the host computer 140 (step 520).

[0045] In response to this challenge, the host computer

140 sends to the manufacturer’s computer a signed ver-sion of the system configuration data 240. The purpose of signing the data is to attest to the authenticity of the data. As part of the response, the host computer 140 also sends the external key 440 to the manufacturer’s com-puter (step 530). More specifically what is sent is only the public part of the external key 440. The private part is retained within the trusted platform module 220.

[0046] Upon receiving signed configuration data and the external key 440, the manufacturer verifies the trust-worthiness of the host computer 140, for example, by comparing the host computer’s system configuration to system configurations for computer systems known to be trusted.

[0047] Once the trustworthiness of the host computer 140 has been verified, the manufacturer’s computer gen-erates the internal keys (data key 410 and code key 420) (step 540) and encrypts the license manager 110 using the internal keys (step 550). The internal keys are gen-erated specifically for each installation of the license manager 110 and are different for each installation.

[0048] The manufacturer then stores the internal keys 410, 420 in the key container 400 and encrypts the key container using the external key 440 (step 560). The man-ufacturer then sends the encrypted key container 400 and the encrypted license manager 110 to the host com-puter 140 (step 570).

[0049] The host computer 140 unlocks the key con-tainer 400 using the private part of the external key 440 and retrieves the internal keys from inside the key con-tainer 400. The host computer 140 then unlocks the li-cense manager 110 using the internal keys and installs the license manager (step 580).

[0050] As previously mentioned, the external key 440 is bound to the trusted state 150. Thus, if the host com-puter 140 is no longer running in the trusted state 150, then the host computer 140 will be unable to unlock the key container 400 and gain access to the license man-ager 110.

[0051] The various implementations of the invention and all of the functional operations described in this spec-ification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structural means disclosed in this specification and structural equivalents thereof, or in combinations of them. The invention can be implemented as one or more com-puter program products, i.e., one or more comcom-puter pro-grams tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable proc-essor, a computer, or multiple computers. A computer program (also known as a program, software, software application, or code) can be written in any form of pro-gramming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing

(5)

5 10 15 20 25 30 35 40 45 50 55

environment. A computer program does not necessarily correspond to a file. A program can be stored in a portion of a file that holds other programs or data, in a single file dedicated to the program in question, or in multiple co-ordinated files (e.g., files that store one or more modules, sub-programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across mul-tiple sites and interconnected by a communication net-work.

[0052] The processes and logic flows described in this specification, including the method steps of the invention, can be performed by one or more programmable proc-essors executing one or more computer programs to per-form functions of the invention by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus of the invention can be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

[0053] Processors suitable for the execution of a com-puter program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Gener-ally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory de-vices for storing instructions and data. Generally, a com-puter will also include, or be operatively coupled to re-ceive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information car-riers suitable for embodying computer program instruc-tions and data include all forms of non-volatile memory, including by way of example semiconductor memory vices, e.g., EPROM, EEPROM, and flash memory de-vices; magnetic disks, e.g., internal hard disks or remov-able disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0054] To provide for interaction with a user, the inven-tion can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feed-back; and input from the user can be received in any form, including acoustic, speech, or tactile input.

[0055] The invention can be implemented in a comput-ing system that includes a back-end component (e.g., a data server), a middleware component (e.g., an applica-tion server), or a front-end component (e.g., a client

com-puter having a graphical user interface or a Web browser through which a user can interact with an implementation of the invention), or any combination of such back-end, middleware, and front-end components. The compo-nents of the system can be interconnected by any form or medium of digital data communication, e.g., a com-munication network. Examples of comcom-munication net-works include a local area network ("LAN") and a wide area network ("WAN"), e.g., the Internet.

[0056] The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communica-tion network. The relacommunica-tionship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

[0057] The invention has been described in terms of particular implementations, but other implementations are within the scope of the following claims. For example, the operations can be performed in a different order and still achieve desirable results. In certain implementations, multitasking and parallel processing may be preferable.

Claims

1. A system (100) comprising:

a host computer running (140) in a trusted state (150),

wherein the host computer is a TCPA (Trusted Computing Platform Alliance) enabled compu-ter and wherein the trusted state is established by booting the host computer using a secure boot process; and

wherein:

the host computer includes hardware com-ponents and software comcom-ponents, the soft-ware components including an operating system, the hardware components includ-ing a Core Root of Trust for Measurement (CRTM), the CRTM being a trusted compo-nent; and

the secure boot process involves using the trusted component to verify the trustworthi-ness of the hardware components before handing system control over to the operat-ing system, which then verifies the integrity of the software components; and

wherein:

the hardware components further include a Trusted Platform Module (TPM); and the trustworthiness of the hardware and software components is verified using sys-tem configuration data stored in the TPM;

(6)

5 10 15 20 25 30 35 40 45 50 55

and a license manager (110) installed on the host computer, the license manager configured to provide access to one or more software programs, the one or more soft-ware programs being accessible only through the license manager, the license manager being bound to the trusted state of the host computer, such that if the trusted state ceases to exist, then the license man-ager is not executable and the one or more software programs are not accessible, wherein the license manager is partitioned into a dynamic data section (310) and a static code section (320), the dynamic data section includ-ing data that changes durinclud-ing execution of the license manager and containing data that the license manager (110) needs to perform its func-tions, the static code section including data that does not change during execution of the license manager and containing code that is required by at least one of the one or more software pro-grams to run and configuration data that is re-quired by the license manager (110), wherein the static code section (320) is partitioned into two subsections, a first subsection that stores code for the software programs and a second subsection that stores configuration data for the license manager (110); and

the dynamic data section being protected by a cryptographic key (data key) (410), the static code section being protected by a different cryp-tographic key (code key) (420).

2. The system of claim 1, wherein the data key and the code key are protected by a different cryptographic key (external key) (440).

3. The system of claim 2, wherein the external key (440) is bound to the trusted state (150) of the host com-puter (140).

4. A computer program product, tangibly embodied in an information carrier, the computer program prod-uct being operable to cause data processing appa-ratus to perform operations comprising:

verifying that a host computer (140) is running in a trusted state (150);

receiving a first cryptographic key (410) from a host computer, the first cryptographic key being bound to a trusted state of the host computer; encrypting a license manager (110) using the first cryptographic key; and

transferring the encrypted license manager to the host computer;

wherein the license manager is partitioned into a dynamic data section (310) and a static code

section (320), the dynamic data section includ-ing data that changes durinclud-ing execution of the license manager and containing data that the license manager (110) needs to perform its func-tions, the static code section including data that does not change during execution of the license manager and containing code that is required by at least one of the one or more software pro-grams to run and configuration data that is re-quired by the license manager (110), wherein the static code section (320) is partitioned into two subsections, a first subsection that stores code for the software programs and a second subsection that stores configuration data for the license manager (110); and

wherein encrypting the license manager using the first cryptographic key (410) includes en-crypting the dynamic data section using a sec-ond cryptographic key (420), encrypting the stat-ic code section using a third cryptographstat-ic key (440), and encrypting the first and second cryp-tographic keys using the first crypcryp-tographic key.

5. The computer program product of claim 4, wherein verifying that the host computer is running in a trusted state includes performing a remote attestation proc-ess on the host computer.

6. The computer program product of claim 5, wherein performing a remote attestation process on the host computer includes:

receiving system configuration data from the host computer; and

comparing the received system configuration data to a set of known system configurations.

7. A method for transferring a license manager to a host computer, the method comprising:

verifying that a host computer (140) is running in a trusted state (150);

receiving a cryptographic key from a host com-puter, the cryptographic key being bound to a trusted state of the host computer;

encrypting a license manager (110) using the cryptographic key; and

transferring the encrypted license manager to the host computer;

wherein the license manager is partitioned into a dynamic data section (310) and a static code section (320), the dynamic data section includ-ing data that changes durinclud-ing execution of the license manager and containing data that the license manager (110) needs to perform its func-tions, the static code section including data that does not change during execution of the license manager and containing code that is required

(7)

5 10 15 20 25 30 35 40 45 50 55

by at least one of the one or more software pro-grams to run and configuration data that is re-quired by the license manager (110),

wherein the static code section (320) is parti-tioned into two subsections, a first subsection that stores code for the software programs and a second subsection that stores configuration data for the license manager (110); and wherein encrypting the license manager (110) using the first cryptographic key includes en-crypting the dynamic data section (310) using a second cryptographic key (410), encrypting the static code section (320) using a third crypto-graphic key (420), and encrypting the first and second cryptographic keys using the first cryp-tographic key (440).

8. The method of claim 7, wherein verifying that the host computer is running in a trusted state includes performing a remote attestation process on the host computer.

9. The method of claim 8, wherein performing a remote attestation process on the host computer includes:

receiving system configuration data from the host computer; and

comparing the received system configuration data to a set of known system configurations.

Patentansprüche

1. System (100), umfassend:

einen Hostcomputer (140), der in einem vertrau-enswürdigen Zustand (150) läuft,

wobei der Hostcomputer ein TCPA-fähiger (Tru-sted Computing Platform Alliance TCPA, Allianz für vertrauenswürdige Rechnerplattformen) Computer ist und wobei der vertrauenswürdige Zustand durch Booten des Hostcomputers unter Verwendung eines sicheren Bootprozesses hergestellt wird; und

wobei:

der Hostcomputer Hardwarekomponenten und Softwarekomponenten beinhaltet, die Softwarekomponenten ein Betriebssystem beinhalten, die Hardwarekomponenten ei-nen CRTM (Core Root of Trust for Measu-rement CRTM, Vertrauenskernpunkt zur Messung) beinhalten, der CRTM eine ver-trauenswürdige Komponente ist; und der sichere Bootprozess mit einer Verwen-dung der vertrauenswürdigen Komponente zum Verifizieren der Vertrauenswürdigkeit der Hardwarekomponenten vor einem

Wei-terreichen der Systemsteuerung an das Be-triebssystem, das sodann die Integrität der Softwarekomponenten verifiziert, einher-geht; und

wobei:

die Hardwarekomponenten des Weiteren einen TPM (Trusted Platform Module TPM, Modul für vertrauenswürdige Plattformen) beinhalten; und

die Vertrauenswürdigkeit der Hardware-und Softwarekomponenten unter Verwen-dung von in dem TPM gespeicherten Sy-stemkonfigurationsdaten verifiziert wird; und

einen Lizenzverwalter (110), der auf dem Hostcomputer installiert ist, wobei der Li-zenzverwalter dafür ausgelegt ist, einen Zu-gang zu einem oder mehreren Softwarepro-grammen bereitzustellen, das eine oder die mehreren Softwareprogramme lediglich durch den Lizenzverwalter zugänglich sind, der Lizenzverwalter an den vertrauenswür-digen Zustand des Hostcomputers gebun-den ist, sodass dann, wenn der vertrauens-würdige Zustand zu existieren aufhört, der Lizenzverwalter nicht ausführbar ist und das eine oder die mehreren Softwarepro-gramme nicht zugänglich sind,

wobei der Lizenzverwalter in einen dynami-schen Datenabschnitt (310) und einen stati-schen Codeabschnitt (320) partitioniert ist, der dynamische Datenabschnitt Daten, die sich während der Ausführung des Lizenzverwalters ändern, beinhaltet und Daten, die der Lizenz-verwalter (110) zur Durchführung seiner Funk-tionen benötigt, enthält,

der statische Codeabschnitt Daten, die sich während der Ausführung des Lizenzverwalters nicht ändern, beinhaltet und Code, der von we-nigstens einem des einen oder der mehreren Softwareprogramme zum Laufen benötigt wird, und Konfigurationsdaten, die von dem Lizenz-verwalter (110) benötigt werden, enthält, wobei der statische Codeabschnitt (320) in zwei Unterabschnitte partitioniert ist, nämlich einen ersten Unterabschnitt, der Code für die Soft-wareprogramme speichert, und einen zweiten Unterabschnitt, der Konfigurationsdaten für den Lizenzverwalter (110) speichert; und

der dynamische Datenabschnitt durch einen kryptografischen Schlüssel (Datenschlüssel) (410) geschützt ist, der statische Codeabschnitt durch einen anderen kryptografischen Schlüs-sel (CodeschlüsSchlüs-sel) (420) geschützt ist.

(8)

5 10 15 20 25 30 35 40 45 50 55

2. System nach Anspruch 1, wobei der Datenschlüssel und der Codeschlüssel durch einen anderen krypto-grafischen Schlüssel (externen Schlüssel) (440) ge-schützt sind.

3. System nach Anspruch 2, wobei der externe Schlüs-sel (440) an den vertrauenswürdigen Zustand (150) des Hostcomputers (140) gebunden ist.

4. Computerprogrammerzeugnis, das physisch in ei-nem Informationsträger verkörpert ist, wobei das Computerprogrammerzeugnis betreibbar ist, um ei-ne Datenverarbeitungsvorrichtung zu veranlassen, Operationen durchzuführen, die umfassen:

Verifizieren, dass ein Hostcomputer (140) in ei-nem vertrauenswürdigen Zustand (150) läuft; Empfangen eines ersten kryptografischen Schlüssels (410) von einem Hostcomputer, wo-bei der erste kryptografische Schlüssel an einen vertrauenswürdigen Zustand des Hostcompu-ters gebunden ist;

Verschlüsseln eines Lizenzverwalters (110) un-ter Verwendung des ersten kryptografischen Schlüssels; und

Übertragen des verschlüsselten Lizenzverwal-ters an den Hostcomputer;

wobei der Lizenzverwalter in einen dynami-schen Datenabschnitt (310) und einen stati-schen Codeabschnitt (320) partitioniert ist, der dynamische Datenabschnitt Daten, die sich während der Ausführung des Lizenzverwalters ändern, beinhaltet und Daten, die der Lizenz-verwalter (110) zur Durchführung seiner Funk-tionen benötigt, enthält,

der statische Codeabschnitt Daten, die sich während der Ausführung des Lizenzverwalters nicht ändern, beinhaltet und Code, der von we-nigstens einem des einen oder der mehreren Softwareprogramme zum Laufen benötigt wird, und Konfigurationsdaten, die von dem Lizenz-verwalter (110) benötigt werden, enthält, wobei der statische Codeabschnitt (320) in zwei Unterabschnitte partitioniert ist, nämlich einen ersten Unterabschnitt, der Code für die Soft-wareprogramme speichert, und einen zweiten Unterabschnitt, der Konfigurationsdaten für den Lizenzverwalter (110) speichert; und

wobei das Verschlüsseln des Lizenzverwalters unter Verwendung des ersten kryptografischen Schlüssels (410) ein Verschlüsseln des dyna-mischen Datenabschnittes unter Verwendung eines zweiten kryptografischen Schlüssels (420), ein Verschlüsseln des statischen Code-abschnittes unter Verwendung eines dritten kryptografischen Schlüssels (440) und ein Ver-schlüsseln der ersten und zweiten kryptografi-schen Schlüssel unter Verwendung des ersten

kryptografischen Schlüssels beinhaltet.

5. Computerprogrammerzeugnis nach Anspruch 4, wobei das Verifizieren, dass der Hostcomputer in einem vertrauenswürdigen Zustand läuft, ein Durch-führen eines Fernnachweisprozesses auf dem Host-computer beinhaltet.

6. Computerprogrammerzeugnis nach Anspruch 5, wobei das Durchführen eines Fernnachweisprozes-ses auf dem Hostcomputer beinhaltet:

Empfangen von Systemkonfigurationsdaten von dem Hostcomputer; und

Vergleichen der empfangenen Systemkonfigu-rationsdaten mit einer Menge von bekannten Systemkonfigurationen.

7. Verfahren zum Übertragen eines Lizenzverwalters auf einen Hostcomputer, wobei das Verfahren um-fasst:

Verifizieren, dass ein Hostcomputer (140) in ei-nem vertrauenswürdigen Zustand (150) läuft; Empfangen eines kryptografischen Schlüssels von einem Hostcomputer, wobei der kryptogra-fische Schlüssel an einen vertrauenswürdigen Zustand des Hostcomputers gebunden ist; Verschlüsseln eines Lizenzverwalters (110) un-ter Verwendung des kryptografischen Schlüs-sels; und

Übertragen des verschlüsselten Lizenzverwal-ters an den Hostcomputer;

wobei der Lizenzverwalter in einen dynami-schen Datenabschnitt (310) und einen stati-schen Codeabschnitt (320) partitioniert ist, der dynamische Datenabschnitt Daten, die sich während der Ausführung des Lizenzverwalters ändern, beinhaltet und Daten, die der Lizenz-verwalter (110) zur Durchführung seiner Funk-tionen benötigt, enthält,

der statische Codeabschnitt Daten, die sich während der Ausführung des Lizenzverwalters nicht ändern, beinhaltet und Code, der von we-nigstens einem des einen oder der mehreren Softwareprogramme zum Laufen benötigt wird, und Konfigurationsdaten, die von dem Lizenz-verwalter (110) benötigt werden, enthält, wobei der statische Codeabschnitt (320) in zwei Unterabschnitte partitioniert ist, nämlich einen ersten Unterabschnitt, der Code für die Soft-wareprogramme speichert, und einen zweiten Unterabschnitt, der Konfigurationsdaten für den Lizenzverwalter (110) speichert; und

wobei das Verschlüsseln des Lizenzverwalters (110) unter Verwendung des ersten kryptogra-fischen Schlüssels ein Verschlüsseln des dyna-mischen Datenabschnittes (310) unter

(9)

Verwen-5 10 15 20 25 30 35 40 45 50 55

dung eines zweiten kryptografischen Schlüs-sels (420), ein Verschlüsseln des statischen Co-deabschnittes (320) unter Verwendung eines dritten kryptografischen Schlüssels (420) und ein Verschlüsseln der ersten und zweiten kryp-tografischen Schlüssel unter Verwendung des ersten kryptografischen Schlüssels (440) be-inhaltet.

8. Verfahren nach Anspruch 7, wobei das Verifizieren, dass der Hostcomputer in einem vertrauenswürdi-gen Zustand läuft, ein Durchführen eines Fernnach-weisprozesses auf dem Hostcomputer beinhaltet.

9. Verfahren nach Anspruch 8, wobei das Durchführen eines Fernnachweisprozesses auf dem Hostcompu-ter beinhaltet:

Empfangen von Systemkonfigurationsdaten von dem Hostcomputer; und

Vergleichen der empfangenen Systemkonfigu-rationsdaten mit einer Menge von bekannten Systemkonfigurationen.

Revendications

1. Système (100) comportant :

un ordinateur hôte s’exécutant (140) dans un état sécurisé (150),

dans lequel l’ordinateur hôte est un ordinateur capable de fonctionner en TCPA (Alliance de plateformes informatiques sécurisées) et dans lequel l’état sécurisé est établi en démarrant l’or-dinateur hôte en utilisant un processus de dé-marrage sécurisé ; et

dans lequel :

l’ordinateur hôte inclut des composants ma-tériels et des composants logiciels, les com-posants logiciels incluant un système d’ex-ploitation, les composants matériels in-cluant une racine de noyau de mesure sé-curisée (CRTM), la CRTM étant un compo-sant sécurisé ; et

le processus de démarrage sécurisé impli-que l’utilisation du composant sécurisé pour vérifier la crédibilité des composants maté-riels avant de remettre la commande systè-me au systèsystè-me d’exploitation, qui vérifie en-suite l’intégrité des composants logiciels ; et dans lequel :

les composants matériels incluent de plus un module de plateforme sécurisée (TPM) ; et

la crédibilité des composants matériels et logiciels est vérifiée en utilisant des don-nées de configuration système mémorisées dans le TPM ; et

un gestionnaire de licences (110) installé sur l’ordinateur hôte, le gestionnaire de li-cences étant configuré pour fournir accès à un ou plusieurs programmes logiciels, le ou les programmes logiciels étant accessibles seulement par l’intermédiaire du gestion-naire de licences, le gestiongestion-naire de licen-ces étant restreint à l’état sécurisé de l’or-dinateur hôte, de sorte que si l’état sécurisé cesse d’exister, alors le gestionnaire de li-cences n’est pas exécutable et le ou les pro-grammes logiciels ne sont pas accessibles, dans lequel le gestionnaire de licences est par-titionné en une section de données dynamiques (310) et une section de code statique (320), la section de données dynamiques incluant des données qui changent durant l’exécution du gestionnaire de licences et contenant des don-nées dont le gestionnaire de licences (110) a besoin pour exécuter ses fonctions, la section de code statique incluant des données qui ne changent pas durant l’exécution du gestionnaire de licences et contenant du code qui est requis par au moins l’un du ou des programmes logi-ciels pour s’exécuter et des données de confi-guration qui sont requises par le gestionnaire de licences (110), dans lequel la section de code statique (320) est partitionnée en deux sous-sections, une première sous-section qui mémo-rise du code pour les programmes logiciels et une seconde sous-section qui mémorise des données de configuration pour le gestionnaire de licences (110) ; et

la section de données dynamiques étant proté-gée par une clé cryptographique (clé de don-nées) (410), la section de code statique étant protégée par une clé cryptographique différente (clé de code) (420).

2. Système selon la revendication 1, dans lequel la clé de données et la clé de code sont protégées par une clé cryptographique différente (clé externe) (440).

3. Système selon la revendication 2, dans lequel la clé externe (440) est restreinte à l’état sécurisé (150) de l’ordinateur hôte (140).

4. Produit de programme informatique, mis en oeuvre de manière tangible dans un support d’informations, le produit de programme informatique étant opéra-tionnel pour amener un dispositif de traitement de données à exécuter des opérations comportant :

(10)

5 10 15 20 25 30 35 40 45 50 55

la vérification qu’un ordinateur hôte (140) s’exé-cute dans un état sécurisé (150) ;

la réception d’une première clé cryptographique (410) depuis un ordinateur hôte, la première clé cryptographique étant restreinte à un état sécu-risé de l’ordinateur hôte ;

le cryptage d’un gestionnaire de licences (110) en utilisant la première clé cryptographique ; et le transfert du gestionnaire de licences crypté à l’ordinateur hôte ;

dans lequel le gestionnaire de licences est par-titionné en une section de données dynamiques (310) et une section de code statique (320), la section de données dynamiques incluant des données qui changent durant l’exécution du gestionnaire de licences et contenant des don-nées dont le gestionnaire de licences (110) a besoin pour exécuter ses fonctions, la section de code statique incluant des données qui ne changent pas durant l’exécution du gestionnaire de licences et contenant du code qui est requis par au moins l’un du ou des programmes logi-ciels pour s’exécuter et des données de confi-guration qui sont requises par le gestionnaire de licences (110), dans lequel la section de code statique (320) est partitionnée en deux sous-sections, une première sous-section qui mémo-rise du code pour les programmes logiciels et une seconde sous-section qui mémorise des données de configuration pour le gestionnaire de licences (110) ; et

dans lequel le cryptage du gestionnaire de licen-ces en utilisant la première clé cryptographique (410) inclut le cryptage de la section de données dynamiques en utilisant une deuxième clé cryp-tographique (420), le cryptage de la section de code statique en utilisant une troisième clé cryp-tographique (440), et le cryptage des première et deuxième clés cryptographiques en utilisant la première clé cryptographique.

5. Produit de programme informatique selon la reven-dication 4, dans lequel la vérification que l’ordinateur hôte s’exécute dans un état sécurisé inclut l’exécu-tion d’un processus d’attestal’exécu-tion à distance sur l’or-dinateur hôte.

6. Produit de programme informatique selon la reven-dication 5, dans lequel l’exécution d’un processus d’attestation à distance sur l’ordinateur hôte inclut : la réception de données de configuration systè-me depuis l’ordinateur hôte ; et

la comparaison des données de configuration système reçues à un ensemble de configura-tions système connues.

7. Procédé pour transférer un gestionnaire de licences

vers un ordinateur hôte, le procédé comprenant : la vérification qu’un ordinateur hôte (140) s’exé-cute dans un état sécurisé (150) ;

la réception d’une clé cryptographique depuis une ordinateur hôte, la clé cryptographique étant restreinte à un état sécurisé de l’ordinateur hôte ;

le cryptage d’un gestionnaire de licences (110) en utilisant la clé cryptographique ; et

le transfert du gestionnaire de licences crypté vers l’ordinateur hôte ;

dans lequel le gestionnaire de licences est par-titionné en une section de données dynamiques (310) et une section de code statique (320), la section de données dynamiques incluant des données qui changent durant l’exécution du gestionnaire de licences et contenant des don-nées dont le gestionnaire de licences (110) a besoin pour exécuter ses fonctions, la section de code statique incluant des données qui ne changent pas durant l’exécution du gestionnaire de licences et contenant du code qui est requis par au moins l’un du ou des programmes logi-ciels pour s’exécuter et des données de confi-guration qui sont requises par le gestionnaire de licences (110), dans lequel la section de code statique (320) est partitionnée en deux sous-sections, une première sous-section qui mémo-rise du code pour les programmes logiciels et une seconde sous-section qui mémorise des données de configuration pour le gestionnaire de licences (110) ; et

dans lequel le cryptage du gestionnaire de licen-ces (110) en utilisant la première clé cryptogra-phique inclut le cryptage de la section de don-nées dynamiques (310) en utilisant une deuxiè-me clé cryptographique (410), le cryptage de la section de code statique (320) en utilisant une troisième clé cryptographique (420), et le cryp-tage des première et deuxième clés phiques en utilisant la première clé cryptogra-phique (440).

8. Procédé selon la revendication 7, dans lequel la vé-rification que l’ordinateur hôte s’exécute dans un état sécurisé inclut l’exécution d’un processus d’attesta-tion à distance sur l’ordinateur hôte.

9. Procédé selon la revendication 8, dans lequel l’exé-cution d’un processus d’attestation à distance sur l’ordinateur hôte inclut :

la réception de données de configuration systè-me depuis l’ordinateur hôte ; et

la comparaison des données de configuration système reçues à un ensemble de configura-tions système connues.

(11)
(12)
(13)
(14)
(15)

REFERENCES CITED IN THE DESCRIPTION

This list of references cited by the applicant is for the reader’s convenience only. It does not form part of the European patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be excluded and the EPO disclaims all liability in this regard.

Patent documents cited in the description

References

Related documents

However, contrary to households in category 2, households in category 3 will only litter materials ranked to the left of & (once they have paid the fixed costs of dumping), and

The objective of this study is to determine the effectiveness of self-management interventions on hospital readmission rates, mortality, and health-related quality of life in

Guiding student learning in the development of the portfolio patient studies for formative assessment was less challenging for clinical educators than that of using the portfolios for

That means heart break and stupidity People do stupid things for love. But they never show that on Disney People get their hearts broken, But they never show that on Disney

We then started off with a phenomenally successful Garden Route tour and followed it up with the tour to the Wild Coast and the Eastern Cape and were blessed with full busses in

Below-right: Path (authentic).. Significant architectural elements: a) Building envelope (symmetrical pattern and horizontally curved mass with North-South axis, the

c, d QPCR experiments showing mRNA expression of Trpm5 in freshly isolated pancreatic islets from WT and db/db mice at several ages as indicated (c) or from WT and ob/ob mice at

Another review of artlculatory problems associated with cleft palate was presented in 1971 by Bzoch in which more specificity was added for some descriptions as fol- lows: