Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
  • G06F21/101—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM] by binding digital rights to specific entities
  • G06F21/1011—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM] by binding digital rights to specific entities to devices
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
  • G06F21/107—License processing; Key processing
  • G06F21/1073—Conversion

Definitions

• Another example includes a manufacturer of set top boxes, such as Motorola, for instance, who may offer set top boxes that are capable of supporting a number of features in addition to simple cable programming.
• the direct customers of the manufacturer, who in the case of set top boxes are often service providers such as ComCast or Cox, for instance, may wish to obtain set top boxes with different combinations of these features in order to meet the varying needs of the end users.
• feature licensing provides a feature control mechanism that allows customers to obtain a license to enable only the product features that meet their specific needs.
• Feature licensing brings many benefits to both manufacturers and customers. For example, feature licensing allows manufacturers to have a single build of a product that incorporates all available features and rely on feature licensing to enable different combinations of features. In addition, customers can get the exact features for a product that meets their specific needs without having to pay for undesired features. Feature licensing also allows manufacturers and customers to manage product upgrades and downgrades through license changes, eliminating the need to deploy different product versions and reducing operational downtime.
• a generic feature licensing system can be provided that can support different product lines, which may include product lines from multiple manufacturers and not just from a single manufacturer.
• Such a generic feature licensing system may be operated and supported by a third party. Users of such a system may include users associated with the manufacturers, operators of the system who support and maintain the system, and customers who will be using the various features of a product for which licenses are being obtained. Customers may include, by way of example, service providers and/or the consumer end user.
• Figure 1 shows the logical architecture of one implementation of a
• Figure 2 illustrates one example of system components.
• Figure 3 illustrates an example physical deployment.
• One embodiment discloses a system for provisioning feature licenses that enable specified features in a device, the system including a central license server (CLS), a License Personalization Server (LPS) host in a factory location, a device programming station configured to provision device-unique licenses to devices, and a device configured to receive at least one feature license.
• CLS central license server
• LPS License Personalization Server
• the system can further include at least one of an LPS manager and a log collector.
• the system further comprises a remote server comprising at least one of a key receiving agent (KRA), a hardware security module (HSM) and an LPS.
• KRA key receiving agent
• HSM hardware security module
• the system further includes a remote client component comprising at least one of a Device Programming Station with License Loader, Device with license loading agent (LLA) and a License Storage.
• the system can also comprise a feature selection mechanism configured for selection and storage of features for a specific license configuration for a product, resulting in the CLS-generated non-device- unique license template, which comprises the product ID and a list of selected features.
• Another embodiment teaches a method for secure license signing key (LSK) provisioning, the method including configuring at least one of LPS host information and LSK information using an LPS manager, digitally signing the Licenses and License Templates for devices of a product type using the LSK tied to the product and identified by a Product ID, cryptographically wrapping the LSK and securely delivering to at least one target LPS(s) that is authorized to manufacture the particular product, such that it can only be unwrapped by the target LPS to its HSM.
• LSK license signing key
• Another embodiment includes a method for production license configuration, the method comprising configuring a product ID, LPS Host ID, and LSK at the CLS to bind the LSK to the product, through the Product ID, and the LPS Host, through the LPS Host ID, securely delivering the binding of the Product ID and LSK label to the target LPS; and loading a license template to the license loader of the device programming station.
• One or more different templates may be loaded to one or more different device programming stations, at the same time or at a different time, and configured to allow flexible license configurations.
• the secure delivery can be via the Internet or performed by CLS, or any combination of methods. In one embodiment, the secure delivery is performed by the CLS. In one embodiment, the secure device programming station is located in a factory.
• a further embodiment teaches a method for license request and generation, the method comprising sending a License Load Trigger message to an LLA of a device during the device manufacturing process, composing and signing a License Request message, which comprises at least a Product ID, its own Device Unique ID, and a License Template, signing the message by a device signing key which may be device- unique or global among the same product, and may include a corresponding digital certificate, forwarding the message to an LPS, verifying the request by checking a digital signature and the digital certificate of the request, verifying an embedded License Template by checking the digital signature, and that the Product ID matches that of the request, upon successful verification, generating a personalized License by the LPS by using the Product ID, Device Unique ID, and list of features from the request, signing the License using a LSK bound to the product, returning the License to the LLA of the device via the License Loader, verifying, by the LLA, the license by checking the signature using a Signature Verification Key embedded in the LLA; and upon successful verification, storing
• the license load trigger message includes at least a Product ID and a License Template.
• the license load trigger message can be sent by the license loader.
• a further embodiment teaches a method for device-to-license association replication, the method including sending device association data from an LPS to a log collector at a central location, forwarding the associations from the log collector to an LPS Manager; and forwarding the associations to a CLS, wherein, with this information, the CLS comes to know what license is loaded on which device during the manufacturing process, wherein the CLS can derive feature credits required for generating an upgrade license, based on the differences between the upgrade license and a license generated in the factory.
• performance of the method is required for the CLS to support license updates in the field which are subsequently sent to the CLS.
• the device association data can include at least license request and generation logs.
• CLS refers to a Central License Server.
• DPS refers to a Device Programming Station.
• HSM refers to a Hardware Security Module.
• ID refers to a Identifier
• KRA refers to a Key Receiving Agent
• LLA refers to a License Loading Agent
• LPS refers to a License Personalization Server.
• LSK refers to a License Signing Key
• LTP refers to a License Template
• PKI refers to a Public Key Infrastructure
• TLS refers to a Transportation Layer Security
• CRC32 refers to a 32-bit Cyclic Redundancy Check.
• Generic Product refers to a product that uses the generic feature license format.
• Non-generic Product refers to a product that does not use the generic feature license format.
• Feature Qualifier Type refers to one of Boolean type and Integer type.
• Feature Qualifier Value refers to a Boolean value that indicates whether a feature is enabled, or a positive integer value that specifies the capacity of a feature (e.g. the number of high-definition channels).
• Feature Value Limitation refers to a list or a range of valid feature qualifier values.
• Feature Type refers to the temporal attribute of a feature and is one of perpetual, subscription and trial.
• Feature Dependency refers to the dependencies among multiple features, either due to business rules or hardware limitations. For example, in a product with features A, B and C, feature B and C can only be enabled if feature A is enabled; and feature C cannot have a quantity more than 8 if feature B has a quantity more than 4.
• Feature Credit refers to an available quantity of a feature.
• Feature Credit Record refers to a record that contains the original feature credit established by a feature purchase and the remaining feature credit after a certain quantity of the feature is used.
• a feature credit record also contains information regarding the organization unit it belongs to.
• the term Device refers to a physical unit of a product.
• a device is a computer that runs the software.
• the term Device ID refers to a unique identifier of a device. If a device does not have an ID, or its ID is not considered secure enough to be used for feature licensing, the device ID may be provided by an expansion module, such as a secure USB token.
• the term Secure Device ID refers to a device ID that is not easily modifiable or falsifiable. The threshold of "easily modifiable or falsifiable" is established by manufacturers according to the value of the features in a product.
• Secure Storage refers to a persistent non-volatile memory in a device which is not easily modifiable.
• the threshold of "easily modifiable" is established by manufacturers according to the value of the features in a product.
• Private Key refers to the private key in an asymmetric cryptographic key pair that is usually used for generating a digital signature for a piece of data.
• Feature licensing is a way of controlling features of a device by using a license file that specifies the features to be enabled on the device and their attributes, such as quantity and expiration date.
• Patent Application No: 13/021,380 (the '380 application), filed on February 4, 2011 and which is incorporated by reference in its entirety, discusses in more detail the need for and the benefits of feature licensing.
• a generic feature licensing system is described herein that can support different product lines, which may include product lines from multiple manufacturers and not just from a single manufacturer.
• a generic feature licensing system may be operated and supported by a third party. Users of such a system may include users associated with the manufacturers, operators of the system who support and maintain the system, and customers who will be using the various features of a product for which licenses are being obtained. Customers may include, by way of example, service providers and/or the consumer end user.
• FIG. 1 shows a broad, logical architecture of one implementation of a feature licensing system.
• three categories of users are users 101A-101C (collectively, 101).
• Users 101 A are license users who are representative customers of the feature licensing system such as service providers who obtain products from their respective manufacturers on behalf of end users. Alternatively, the customers may be the end users themselves.
• Users 10 IB are manufacturer users who are representative of the manufacturers of the products for which feature licenses are being provided.
• Users 101C are system support users who are internal system administrative users who belong to the hosting organization that operates and maintains the licensing system. Certain advanced administrative functions may be limited to LAN access only and may not be exposed to a public network.
• the users 101 communicate with the system over the Internet 110 or any other packet-based wide area network.
• the users access and interact with the system through one or more web servers 120, which provides a single front-end interface that is accessed by a client-based application such as a conventional web browser.
• the feature licensing system typically includes one or more physical server computers with one or more physical storage devices and databases as well as various processing engines.
• the feature licensing system includes one or more service components 130 that typically reside on application servers which execute one or more applications that provide various feature licensing services to the clients 101.
• five logical service components or modules are shown: a feature definition component 131, a feature license management component 132, a feature credit management component 133, a user management component 134 and a non-generic product support module 135
• the feature licensing system also includes hardware security modules (HSMs) 145 in which cryptographic keys used to protect licenses may be stored for use by the system.
• the feature licensing system also contains a database 150 of records.
• the service components have access to user directories 155, which may be the internal enterprise user directories that belong to the various users.
• the service components also have access to order management systems 165, where sales orders for product features are maintained.
• the modules that make up the service component 130 provide the following functions and services.
• the feature definition module 131 stores the product feature information associated with the various product lines of the manufacturers who are supported by the feature licensing system. This module is structured so that it is generic enough to support commonalities among various feature licensing needs. At the same time it is extensible enough to be able to accommodate any peculiarities in the feature specification of certain product lines.
• the feature license management module 132 supports routine feature license management tasks such as license generation, updates, enforcement and revocation. This module should be able to carry out such tasks in a generic manner so that it can be shared among different product lines. In addition, because the scale of deployment and the update schedule can vary widely across different product lines, in some implementations the management tasks should support a batch mode of operation.
• the feature credit management module 133 obtains feature credit information from customer sales order systems, which manage feature sales orders for the respective customers. This module keeps track of any change in feature credits so that they are accurately accounted for during credit creation and adjustment, as well as license generation, update and revocation.
• the user management module 134 integrates with existing user directories of the various users so that the system can be accessed using a single sign-on interface and avoid duplicating user information. This module also manages user privileges so that they are properly authorized to perform certain tasks while being prohibited from performing other task.
• the non-generic product support module 135 allows legacy products that may be too difficult to migrate to the generic framework to nevertheless be integrated into the feature licensing system. Likewise, certain new products, which for various reasons may not be able to use the generic license format, can also be supported by the feature licensing system.
• the licensing system is flexible in its support for products with different levels of computing capabilities, device ID modifiability and storage security, as well as for different needs of license portability.
• the device license module is responsible for all feature license-related operations, such as license validation, feature attribute value reporting, license revocation confirmation generation, etc. It is integrated into product software, which communicates with the module through a programming interface.
• the general framework described in the '380 application contains a Feature License Management element (see Figure 1, element 132), which includes the generic feature license generation mechanism.
• This mechanism supports both single license generation and batch license generation for devices who's IDs are known beforehand.
• the same mechanism assumes that licenses are installed on such devices after the manufacturing process. Therefore, this mechanism works well for low volume products such as head-end devices because because such devices are typically assembled one at a time by a technician and a personalized feature license can be manually loaded onto a device after it is fully assembled.
• above mechanism is only feasible for low volume products such as head-end devices due to the time and effort required to manually install and verify the license.
• FIG. 2 The structure of the system, as well as the data flow, is illustrated in Figure 2.
• the system has components at the central location 201 and in multiple factories, for example 202. Within the factory, components reside on, for example, a device programming station 215 and a device 210. The connections between the central location and a factory can be over the Internet and secured by TLS.
• Central License Server (CLS) 205 is a software system that implements the generic feature license framework applicable to the Feature License Management 132 of Figure 1, along with additional functionalities described in this disclosure.
• a device 210 is a physical unit of a product. It is assumed that a device has a unique cryptographic signing key and a corresponding certificate.
• the Device ID is a unique identifier of a device.
• Device Programming Station 215 is a computer in a factory 202 that is responsible for configuring devices according to certain specifications.
• a device has a dedicated connection to the device programming station that is programming it.
• a Feature License is a file that contains the product features to enable on a specific device.
• Feature Specification 217 is a list of product features and their quantity to include in a feature license.
• Hardware Security Module 219 is a hardware component that securely stores cryptographic keys and other data, and performs certain cryptographic operations.
• Key Receiving Agent 221 is a software program that receives wrapped license signing keys and use a hard ware security module to unwrap and store the license signing keys.
• License Loader 223 is a software program that runs on a device programming station and coordinates the loading of personalized feature licenses onto devices that are connected to the device programming station.
• License Loading Agent 225 is a software program that runs on a device to receive, verify and store feature licenses personalized for the device.
• License Template 227 is a file that contains feature specification and other information to include in a feature license, such as product ID.
• License Signing Key 229 is a cryptographic key that is used to sign feature licenses.
• License Personalization Server 231 is a software program that generates feature licenses personalized for individual devices.
• License Personalization Server Host 230 is a computer in a factory that has a hardware security module and hosts license personalization server and key receiving agent.
• An Update License is a license that replaces the existing license on a device [0067]
• the CLS 205 is used to manage license templates and generate license request reports, and the LPS Manager is used to manage LPS host information and deliver wrapped license signing keys to LPS hosts in factories.
• the CLS gets LPS host information from the LPS Manager when a user wants to deliver the association between a product and its license signing key to an LPS host.
• the CLS also retrieves license request logs, along with LPS host information, from the LPS Manager for reporting purposes.
• the Log Collector periodically retrieves license request logs from the LPS and saves them into the LPS Manager.
• the LPS and the KRA run on LPS hosts, each having an HSM.
• the License Loader runs on DPS and the LLA runs on devices.
• the License Loader is responsible for coordinating the LLA and the LPS to generate and load personalized feature licenses onto the devices.
• the LPS Manager 235 stores information about all LPS hosts in factories. A record is created in the LPS Manager for every new LPS host deployed to a factory. The information about an LPS host includes, among others, its network address and its bootstrap key.
• a bootstrap key is a symmetric or asymmetric cryptographic key used for delivering other cryptographic materials. It is loaded into the HSM of an LPS host at the central location before the LPS host is shipped to and installed in a factory. When loading the bootstrap key to the HSM of an LPS host, the bootstrap key is set to be used for "unwrap" operation only. This is to ensure that any cryptographic material delivered to the HSM can only be unwrapped in the HSM, but cannot be decrypted as clear objects outside of the HSM.
• the LPS Manager also stores license request logs and the labels of LSKs on an LPS host.
• the LPS Manager is used to securely deliver a product's LSK to an LPS host.
• a user uses the LPS Manager to select a destination LPS host, load a product's LSK into the memory, and specify the key label under which the LSK is to be stored on the HSM of the LPS Host.
• the LPS Manager communicates with the KRA on the LPS host over a TLS-protected connection.
• the LPS Manager wraps it with the bootstrap key of the LPS host before sending it out. (See Key Receiving Agent for the unwrapping and storing of an LSK.)
• the Log Collector periodically collects new feature license personalization requests logged in the LPS and stores such request logs into the LPS Manager. During every collection run, the Log Collector first gets all active LPS hosts' address from the LPS Manager. Then it connects to each LPS host, in parallel or in sequence or in any combination thereof. Through each connection it retrieves the request logs previously not seen, associates them with their source LPS host, and saves them into the LPS Manager. Finally, it marks the retrieved request logs as seen so that they would not be retrieved again in subsequent collection runs.
• the Central License Server implements all the feature licensing functionalities described in Generic Feature Licensing Framework. It is extended to implement the following new functionalities:
• License templates creation This functionality allows an authorized user to create license templates for a product.
• a license template contains the following items: a. Feature specification.
• Product-LSK association delivery This functionality allows an authorized user to send the association between a product and its LSK to the LPS.
• the connection between the CLS and the LPS is protected by TLS.
• License request reporting This functionality allows an authorized user to generate various reports on license requests, based on the license requests logs collected by the Log Collector from the LPS.
• the default feature specification of a device is the feature specification in the license that is installed on the device in a factory.
• CLS 205 When the CLS 205 is used to generate the first update license after a device is deployed, CLS needs to know the default feature specification of the device in order to determine if the device is requesting a different feature specification than the one currently on the device.
• CLS searches the license request logs in LPS manager for the license request that contains the device's ID and extracts the license template from the license request. CLS then parses the license template to get the device's default feature specification.
• the Key Receiving Agent runs on an LPS host and waits for connection from the LPS Manager. After a TLS-protected connection is established, the KRA receives a wrapped license signing key from the LPS Manager. The KRA then passes the wrapped key to the LPS host's HSM and instructs it to unwrap the license signing key using the LPS host's bootstrap key and stores the unwrapped license signing key in it.
• the License Loader, License Loading Agent (LLA) and License Personalization Server (LPS) are the license generation and loading components. They work together to generate licenses personalized for devices and load them onto devices.
• the License Loader is responsible for starting the license generation and loading process and for passing license requests and responses between the LLA and the LPS.
• the LLA is responsible for generating license requests on devices and verifying and storing licenses on them.
• the LPS is responsible for generating licenses in response to license requests from devices.
• a license template for the batch is entered into the License Loader ( See Step 8 in Figure 2).
• the product's signature verification key which is the public key corresponding to the product's license signing key, is made available to the LLA ( See Step 9 in Figure 2).
• Each device is assumed to already have its unique signing key and certificate that have been provisioned in an earlier manufacturing step.
• the License Loader sends a license load trigger that contains the license template to the LLA (See Step 9 in Figure 2).
• the LLA verifies the signature of the license template using the signature verification key and composes a license request that contains at least the following items: a. Product ID.
• the LLA sends the license request to the License Loader (See Step 11 in Figure 2), which passes it to the LPS (See Step 12 in Figure 2).
• the LPS verifies the CRC32 value and the signature of the license request, the signature of the license template, and the matching between the product IDs in the license request and the license template.
• the LPS logs the license request and verification results.
• the LPS generates a license containing the features in the license template, the product ID, the device ID and a signature over these items by the product's LSK. (For more details on the content of a feature license, see the Generic Feature License Format in Generic Feature Licensing Framework?)
• the LPS composes a license response that contains the following items: a.
• the LPS sends the license response to the License Loader (See Step 13 in Figure 2), which passes it to the LLA (See Step 14 in Figure 2).
• the LLA verifies the CRC32 value and the signature of the license response, compares the product ID, device ID and nonce in the license response with those in the corresponding license request, and verifies the signature and format of the license.
• the LLA stores the license in the device's license storage.
• the LPS leverages the redundant configuration of LPS hosts.
• Each LPS host runs an independent instance of the LPS.
• Any factory has at least two LPS hosts, which are load-balanced and connected to multiple DPS.
• Each DPS runs an independent instance of the License Loader.
• a license request from any DPS may be served by any of the LPS hosts.
• the physical deployment of the KRA, the LPS, the License Loader and the LLA is illustrated in Figure 3.
• the system components as described above make up a coherent system that provisions feature licenses to devices in a way that addresses each of the five issues facing the system: Security, Flexibility, Scalability, Availability and Traceability, each of which is discussed below.
• the network communication channels among the components are protected by TLS and critical communication content, such as LSK, license templates, licenses, license requests and responses are all protected by either by a symmetric encryption key or a digital signature.
• LPS critical communication content
• the LPS as a local license issuer in factories with license authority delegated from the CLS, uses the HSM of an LPS host to protect license signing keys. All LPS hosts also have limited physical access.
• Flexibility The system is flexible to support multiple manufacturers, products and feature configurations, by allowing authorized users to create different license templates in the CLS for different products and even for different feature configurations of the same product. License templates containing different feature specifications can be used on any production lines making different batches of devices.
• Availability Redundant deployment of the LPS on multiple LPS hosts provides the level of availability needed by large volume license provisioning. Moreover, the delegation of license authority of the CLS to the LPS that local in factories eliminates the dependency on unreliable Internet connections, leading to higher availability.
• Traceability The collection of license request logs by the Log Collector from the LPS in factories to the central LPS Manager allows centralized reporting and analysis of license provisioning activities in factories and provides users with the capability of tracing the licenses provisioned in factories.
• a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer.
• an application running on a controller and the controller can be a component.
• One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers.
• the claimed subject matter may be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer to implement the disclosed subject matter.
• article of manufacture as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media.
• computer readable storage media can include but are not limited to magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips, etc), optical disks (e.g., compact disk (CD), digital versatile disk (DVD) , etc), smart cards, and flash memory devices (e.g., card, stick, key drive, etc).
• magnetic storage devices e.g., hard disk, floppy disk, magnetic strips, etc
• optical disks e.g., compact disk (CD), digital versatile disk (DVD) , etc
• smart cards e.g., card, stick, key drive, etc.
• flash memory devices e.g., card, stick, key drive, etc.

Landscapes

• Engineering & Computer Science (AREA)
• Software Systems (AREA)
• Theoretical Computer Science (AREA)
• Multimedia (AREA)
• Technology Law (AREA)
• Computer Hardware Design (AREA)
• Computer Security & Cryptography (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Applications Claiming Priority (2)

Publications (2)

Family

ID=45633109

Family Applications (1)

Country Status (1)

• 2011
  • 2011-09-21 EP EP11767344.2A patent/EP2606422A4/de not_active Withdrawn

Non-Patent Citations (2)

Also Published As

Similar Documents

Legal Events