TWI468969B - Method of authorizing access to electronic content and method of authorizing an action performed thereto - Google Patents

Description

Method of authorizing access to electronic content and method of authorizing action on the electronic content

The present invention relates to a digital rights management engine system and method.

In current computer systems, it is often desirable to limit access to electronic content, services, and/or processing resources, and/or only allow certain entities to perform certain actions. Various technologies have been developed or proposed for this control. These technologies are often referred to as Digital Rights Management (DRM) technology because, by name, the goal is to manage the rights of various entities in digital or other electronic content, services or resources. A number of prior art problems are that they are quite complex, limited, and inflexible, and thus fail to perform some of the original types of relationships and processing, and/or cannot interact with other DRM systems.

There are described systems and methods for improving DRM that can be used to improve some or all of the problems. It should be appreciated that the embodiments of the invention may be embodied in various forms, including a program, device, system, apparatus, method, computer readable medium, and/or combinations thereof.

Current systems for controlling access to content sometimes include components that access licenses for authorizing access to electronic content. However, such components typically perform an assessment of the rigidity of the link to the license management information, link or node, or chart. They often cannot be applied to be essentially different Authorization design and/or operation with certain DRM systems to authorize access to the content. Embodiments of the present invention overcome these shortcomings by storing, using, and/or executing other routines or control programs associated with the license, providing dynamic authorization features, performing decentralized authorization resources, and/or streamline access. Features.

Furthermore, many current systems only have information about maintaining simple authorization/status related information. The failure of these systems to access authorization may depend on the condition of most layers of data, for example, based on previously published material associated with other nodes. The present invention cooperates with the DRM control program to overcome these shortcomings through the implementation of a static database to provide secure state storage characteristics, provide continuous state information for generations, or perform read and write functions for improved control program execution, and/or execution. More efficient access authorization.

Other current systems may implement a DRM license or structure that includes components that involve the use of a public key to protect the license component. However, some of the shortcomings of these systems include that the hacker may falsify the digital signature required to access or execute the license, or explore the interrelationships that exist in the DRM license structure. One or more embodiments of the present invention may overcome these shortcomings by implementing digital and/or interlocking signatures that include license items that use a particular protection key. Advantages of these embodiments include preventing unauthorized access via a public key and related characteristics derived from the interdependencies of the license elements.

Other current systems include components that perform proximity decisions between the first entity and the second entity, such as proximity decisions between two equity management entities. Such systems may enforce rules such as performing a complex proximity check procedure to indicate that a protected content cannot be copied outside of an environment. however The disadvantage of these systems is that they do not provide security for the content being protected without compromising the effectiveness of proximity checks. Embodiments of the present invention overcome this and other shortcomings by providing a reduced proximity detection protocol that is preserved via characteristics relating to random and/or secret transmissions. Even if the request is intercepted, the related advantages of one or most of the embodiments include making it difficult for an attacker to obtain a password to determine the correct response.

To sum up, there is a need to properly authorize access to electronic content, as well as systems that are too complex, too restrictive, and/or inflexible, as well as systems that can perform certain types of relationships and procedures, and / or a system that can operate with other DRM systems.

A detailed description of the main body of the invention will be provided below. Although a few embodiments are described, it is to be understood that the subject matter of the invention is not limited to any embodiment, but includes various alternatives, modifications, and equivalents. In addition, although the various features are described in the description to provide a complete understanding of the subject matter of the present invention, some embodiments may be practiced without these or all details. Further, for the sake of clarity, the technical contents known in the art are not described in detail to avoid unnecessarily obstructing the subject matter of the present invention.

A. Group (Octopus) architecture

Groups are a simple, open and flexible digital rights management (DRM) engine that can be used by applications to implement core DRM functions. Groups are designed to seamlessly integrate into a networked service environment and any host environment or In the software architecture. In order to build a complete customer DRM with groups, these environments need to be implemented and integrated into the group engine. In the preferred embodiment, the group referencing is independent of the particular media format and encryption protocol, allowing the designer to flexibly use standard or proprietary techniques as desired. The management model used for the group engine is simple, but can be used to represent smart relationships and business models.

Information on the exemplary implementation of the group engine architecture is described below, including information and sample applications for reference implementations. These paragraphs are referred to as group objects, Plankton, and Scuba, and provide information about the group engine toolbox embodiments.

1 Introduction

Figure 1 shows how the group components act on the network using DRM. As shown in FIG. 1, in one embodiment, the group engine is built into the main application. It performs specific DRM functions and relies on the main application for these services, which can be effectively provided by the host, such as encryption, decryption and file management.

The group establishes DRM objects that together form a license condition for the content. It also delivers the key to the main application.

It should be noted that Figure 1 is an example of how group components may be used; group DRM systems are resilient. The engine can be implemented in a small footprint and can be easily integrated into various types of applications.

2. Understand DRM profiles and group objects

A group uses a set of content protection and management objects to represent entities in the system; protects the content; correlates the content with usage rules, and determines whether access is granted when requested. The noun DRAM profile is used to represent the semantic context in which these objects are defined in actual deployment.

2.1. Introduction to objects in the group

In one embodiment, the group engine uses the following items, which are described in more detail below:

2.2. Node objects

In an embodiment, each entity in the system may be represented by a node object. Only the entity needs to be referenced for the linked object, or the recipient of the encrypted target information that needs to have the corresponding node object. In fact, nodes typically represent users, devices, or a group. A node object also has associated properties that represent certain characteristics of the entity with respect to the node.

For example, Figure 2 shows two users (Xan and Knox), two devices (Mac and portable devices), and several entities representing groups (such as members of the Mariah Carey family and members of public libraries). , subscribers to specific music services, RIAA-licensed devices, and devices manufactured by specific companies). Each of these will have a node object associated with it.

2.3. Linked objects

The linked object is a signed object used by the group to show the relationship between the two nodes. For example, the link from the Mac node to Knox in Figure 2 shows ownership. As with the link from the Kelly family node to the music service user node, the link from Knox to the Kelly family node shows the membership. In one embodiment, because any of the linked objects are only represented in a relationship between the two nodes, ten linked objects will be used to describe the relationship as shown in FIG.

A chart can be used to represent the relationship between nodes. The link object representing the relationship between the Kelly family node and the music service node advocates that there is a pointing edge in the figure. The vertices in the figure are the Kelly family and the music service node. Knox and Xan are members of the Kelly family. Because Knox is linked to the Kelly family and the Kelly family to the music service, there is a path between Knox and the music service. When there is a path from another node to the music service, the group believes that the music service node can be reached by another node. This allows a control to be written that can be carried out according to the music service when the application requiring access (eg, a group DRM client main application) is executed. The condition that the device arrives, while allowing access to protected content.

The link object may also optionally include partially encrypted material that allows the group to use the link to derive the content key. As detailed below, this provides a flexible, decentralized approach to content keys.

In one embodiment, the group does not define how the linked object is signed or evaluated. Instead, it will ask the host system to verify the signature and any authentication systems that can be used. This allows the system architect or manager to define the life of the linked object, wake it up, and so on. In addition, it is also possible to define policies for managing the establishment and life of linked objects.

2.4. More about node objects

As previously mentioned, in an embodiment, the node object contains attributes that define the node. An example of a property is a node type. In addition to representing users, groups, or devices, node type attributes can also be used to represent other entities. In some embodiments, the node object may also contain keying information, such as a "dive" key information distribution system that uses group nodes and links. The diving key distribution system will be described as follows.

In some embodiments, the node object also includes a secret asymmetric key pair that is used to provide confidential information for the secondary system that has accessed the secure portion of the node object. This can also be an entity represented by the node (eg, a music service) or other entity responsible for managing the node (eg, an end user (eg, Knox) to be responsible for managing his portable device).

2.5. Obtain permission

When an application wants to perform an action on a particular piece of content, it first asks the group's client engine to check if it wants to perform an action on the content. In some embodiments, the group engine will load and execute a control program related to the content contained in the content contained in the content-licensed object, and allow the approval and rejection of the action according to the decision of the control program. . Allowing it is usually necessary to meet certain conditions, for example, a condition that a node must be reached by the requesting node.

In an embodiment, the node must obtain the content key if approval permits. The key is obtained from the licensed content key object, which is itself protected by an encryption system used to protect the content key object. For this purpose, several different encryption systems can be used, including a group's internal key distribution encryption system, which balances the keys contained in the nodes and the linked objects.

2.6. Content Protection and Management

In a typical scenario, a content provider uses an application that includes a group suite engine to create a set of objects that manage the use of the content and convey the information needed to obtain the content plus key. For ease of explanation, the term "license" is used to refer to the group of objects.

In an embodiment, the content is logically separated from the license, but tied together using an internal reference to the object ID. The contents and licenses stored together can also be stored separately if necessary. A license can be applied to more than one item, and more than one license can apply any single item.

In one embodiment, a license is a collection of objects, as follows:

‧Content key object (including keying information)

‧Protect object (bind content to content key object)

‧Control objects (including and protection control programs)

‧ control object (bind content key object and control object)

‧ Provide metadata about human readable information to describe the conditions required for the license.

Figure 3 shows the relationship of the items in the license and the content items in an exemplary embodiment. In the embodiment illustrated in Figure 3, both the control object and the control object are signed so that the group client engine can verify that the control information is from a trusted source before giving the main application permission to access the content.

As shown in FIG. 3, in one embodiment, the content is encrypted and represented as a content item. The used encryption key is represented by the content key object, and the constraint between the two is represented by the protector object. As shown in Figure 3, a unique ID is used to facilitate the bond between the content and the content key.

The rules governing the key used to decrypt the content are represented by the control object. The constraint between the content key and the control to manage its use is represented by the control object, and the ID associated with the object is again used to bind them.

2.6.1. Content objects

The content object represents the encrypted content. In one embodiment, the format and storage are defined by the content type and the main application. The suite application encrypts the content and creates and manages the content object. The group design allows the system architect or manager to choose the encryption system to use. In an embodiment, the content item must contain or reference a unique ID; the ID is used to place the content Tied to other items. In one embodiment, the packaged application must include the ability to recognize and process the content itself (or to obtain a service that can provide the functionality). In some embodiments, this is accomplished by a structural file format, such as the selection of MP4.

2.6.2. Content Key Objects

The content key object describes and optionally contains a key to encrypt the content. When the object contains content key material, the material itself is encrypted for confidentiality. In an embodiment, the content key object also specifies an encryption system for encrypting the content key material; whether the material is included in the content key object. The content key object is also indicated by a unique ID. In one embodiment, the content key object, and other objects described in paragraph 2.6, are created by the group suite engine.

2.6.3. Protector object

The protector object binds the content object to the content key object. It contains the ID of one or more content objects and the ID of the content key object to which it is applied. It also contains information on the encryption algorithm used to encrypt the content.

2.6.4. Control objects

The control object is a signature object that contains a control program. The control program indicates the conditions that must be met for certain actions of the content to be permitted. The control object also has a unique ID. As described above, the control object is signed so that the group can verify the control bit before making any decision. Whether the group code is valid and trusted. When information is available, the validity of the control object can optionally be derived via verification of a secure hash contained in the control object.

2.6.5. Control object

The control object is a signature object that references one or more content key objects and a control object. The group uses the information provided by the control object to find out which control manages the use of the content key object.

In an embodiment, since the control object also contains a hash value for each key material contained in the content key object to which it refers, the binding between the key material and the content key object cannot be quickly Tampering.

The control object also contains information that facilitates the verification of the integrity of the object. In one embodiment, the control object is signed so that the group can trust the binding validity between the content key and the control object that manages it, and the validity of the bond between the content key ID and the actual key data. . Alternatively, a hash of the referenced control object may also be included in the control object to allow the group to derive the validity of the control object without having to separately verify the signature.

2.6.6. Metadata

Some of the objects will contain metadata that will help the application know what controls to actually check.

2.7. About the control program

In one embodiment, the control program is included in the control object, and the group uses a virtual machine called a "Plankton VM" to execute the control programs. These control programs are in a bytecode format that facilitates interoperability between platforms.

In one embodiment, the plankton VM is designed to reside within the application without performing execution in a processor or as an integrated circuit. In an embodiment, the control program can be written as a combined language and converted to a bytecode for the planktonic combination language. In other embodiments, a template can be used and the right representation language can be used to match the group.

In one embodiment, a control program is supported that indicates permission based on relationship and date/time.

In one embodiment, the group specification determines the conditions that can be represented; the specific implementation of the actions that can be allowed. Both are represented in the control program. In one embodiment, the action is specific to the package interface by name (eg, "play").

The example of the control program represented by the combined language is as follows:

Additional information on plankton VM specifications and controls is provided below.

2.8. Implementation of the law

In an embodiment, when implemented according to a group DRM system, the DRM profile is defined to describe the manner in which the node object, the link object, and the license are used. Encryption systems are also defined to provide content protection and confidentiality. In addition, implement a suite and customer (consumer) application that uses the group engine. In some embodiments, a group engine for a particular application version of a particular hardware and/or software platform may also be implemented. Two examples Subsystems are provided below.

2.8.1. Example 1: Users, PCs and Devices

Suppose you want to implement a DRM system that binds power to the playback content for a particular user and wants to make the user play the content on all of the playback devices he owns. It is assumed that the user software is determined to be provided so that the user can add to the playback device (eg, a mobile player). However, suppose you want to set some policies to limit the number of times a user can transfer to a general purpose device, so that they do not have the ability to act as a distributor.

Depending on the needs of these systems, for example, it is possible to have a license established for the user useful and to establish a relationship between the user and the device with which it is used.

Therefore, in this example, it is first decided which node of the relationship needs to be established. For example, you need to define the following:

‧Users (persons who have the authority to use the content)

‧PC (software application that can play content and indicate other playback devices)

‧ Device (a combination of hardware and/or software that can play content).

A node type can be defined for each of these items. Each node object created may contain a type attribute indicating whether the object represents a user, a PC, or a device.

Assume, for example, that the number of PC node objects that can be established by any user is limited to four. As long as the number of PCs is limited, it is not necessary to limit the number of devices. If it is built between the user node and the node that requires access Once a relationship is established, the control program can be set up to allow access. The node can then be a PC or a device.

One way to accomplish this is to create a server that manages the user and creates a group object of the properties just defined. For each new user, the server will specify a user node object. For each PC, the server will specify a PC node object. At this point, the server will create a link object that links the user node object to the PC node object. The user can then request to add additional PCs, and the server will take effect a policy that limits the number of PC node objects per user to 4 (typically will provide the ability to remove the PC from its active list to the user. Once established, the items will be forwarded to the PC. As long as the items remain valid, the objects on the PC will use the items.

Suppose that the user can play any content on any device they own. It is also assumed that the user downloads the content to the PC that is executing the PC software, and the software provides the ability to play the content on the device. In order to accomplish this, the PC software needs to establish the ability of the new device node object and the link object to the device, the link object correlating the device node object to the user node object. In order to do this, the PC software needs to access the secret portion of the user node. The device retains the linked item and uses it only when it is active; that is, once the linked item is present, it is not necessary to create another linked item unless the item expires or becomes invalid.

In order to bind the content to the user, the package application selects a new ID for the content, and uses the current ID to create an encryption key and associated content key object, and a protector object to tie the content object to the content key object. The package program then creates a control object with a control program (eg, compiled in the plankton byte code) and allows "play" to occur only if the user node can be retrieved by the PC or device node requesting the playback action. action. Typically, the controls, control symbols, protectors, and content key objects are suitably embedded in the package content so that the PC and the device do not have to acquire them separately.

In an embodiment, when a device or PC wants to play content, the group looks for a protector object for the content ID of the content, and then the content key object is referenced by the protector, and then the control object reference The content key object, and finally, the control object is referenced by the control symbol. The group executes the control program of the control object to check if the user node is available. If the device or PC node has the necessary link object to verify that there is a path between its node and the user node, the condition is met and the control program allows the key present in the content key object to be used. The media rendering engine of the device or PC can then decrypt and play the content.

2.8.2. Example 2: Temporary Login

In this example, the same system as Example 1 is used, and a new feature is added: a policy that manages the establishment of the link object between the PC node object and the user node object, as long as the user is not Temporary login on another PC allows temporary logins of up to 12 hours. This feature will allow the user to bring their content to a friend's PC, log in to the PC for a while, and play the content on a friend's PC.

In order to perform this function, the link object will be added with a limited validity period. set up. In one embodiment, this will act as follows: For the sake of simplicity, we assume that the consumer soft system that needs to play DRM protected content is on the friend's PC. The file containing the content and license is sent to the friend's PC. When the user wants to play the content, the software believes that there is no valid link object to link the local PC node object with the user node object that owns the content. It prompts the user for credentials (possibly username/password, mobile phone authentication, smart card, or any authentication system that allows the system policy) and communicates with a backend system. The backend system checks the attributes of the user node object and the PC node object that are required for the link, and checks if there is a temporary login link object that is being activated. If the condition is met, the backend service creates a link object that links the PC node object to the user node object and limits the validity period to the required login period (eg, less than 12 hours to match the example) policy). The link object then allows the PC to play the user content until the link expires.

3. Reference architecture for content consumption and content suite

The following is a reference architecture description of the two main components. In some embodiments, it completes the deployment of the group application: ■ consumer applications (typically media players), consumer group package content; and ■ package applications The program (typically built into the server) is packaged and sent to the contents of the group consumer application.

3.1. Group DRM Customer Reference Architecture

The Group Customer Reference Architecture provides an example of the functionality that a group engine will perform, the main application for consuming content. The developed consumer application can also package a portion of the content for accessing the protected content or for the general purpose application of the user system. In various embodiments, the main application can perform some or all of the following: ‧ providing a user interface, the user requesting access to the protected content object can be completed by the user interface and creating an interface with the user To display meta-information about content or error information; ‧ manage the interaction with the file system; ‧ recognize the format of the protected content object; ‧ require the DRM engine to evaluate the DRM object (including the execution control program) that made the license, To check if access to the content can be approved; ‧ verify the required signature and handle any other general purpose encryption functions that the DRM engine needs to perform (for example, using cryptographic services); ‧ require the DRM engine to provide The key is to protect the content; and/or ‧ decrypt and interact with the media rendering service to depict the content.

In one embodiment, the DRM client engine evaluates the DRM object, confirms or rejects the license, and provides a key to the host application.

Figure 4 shows the components of a group-based consumer application in one embodiment. As shown in Figure 4, the main application is the logical center point of the customer. It is responsible for driving interactions with other modules and interacting with users via a user interface.

The main application provides a set of services to the group engine. Figure 4 shows the use To complete this interface "main service." The primary service allows the group engine to gain access to the data managed by the host application and certain database functions implemented for the host. In an embodiment, it is the only outbound interface of the group engine.

In an embodiment, the group engine does not directly interact with the multimedia content managed by the host application. The main application logically interacts with the content service to access the multimedia content and only transmits some of the data that must be processed by the engine to the group engine. Other interactions with the content will be performed by the multimedia rendering engine. The content service is responsible for obtaining content from the media server and storing and managing the content stored on the client's persistent storage.

In the embodiment illustrated in Figure 4, the media rendering engine is the secondary system responsible for accessing the multimedia content and rendering it (e.g., on video and audio output). The media rendering engine receives partial information (eg, content decryption keys) from the group engine, but in one embodiment, the group engine does not interact directly with it.

Some of the information required for the group DRM engine will be available for in-band access to multimedia content and will be accessed and managed through content services, but some of the information may need to be obtained through other service devices, such as personalized services or membership services. .

In the embodiment illustrated in Figure 4, encryption operations (e.g., encryption, signature verification, etc.) are handled by the cryptographic service block. The group engine does not interact directly with it, but via the host service that will deliver the request. The encryption service can also be used by the media rendering engine to perform content decryption.

3.1.1. The main application to the group engine interface

Although in the preferred embodiment there is no fixed API for the group engine, the following is a high-level description of the interface type provided by the group engine to the main application in an exemplary embodiment:

Octopus: CreateSession(hostContextObject)→Session

Establish a conversation to give a main application context. The context object is used by the group to enter the callback for the application.

‧Session::ProcessObject(drmObject)

When the main application encounters a type of object in the media file that can be specified to belong to the DRM subsystem, this function should be called by the main application. These objects contain content control programs, membership tokens, and more. The grammar and semantics of these objects are opaque to the main application.

‧Session::OpenContent(contentReference)→Content

The main application calls this feature when the main application needs to interact with the multimedia content file. The group engine sends back the subsequently available content objects to retrieve and interact with the DRM information about the content.

‧Content::GetDrmInfo()

Send back the DRM metadata about the content, otherwise the content cannot be used in the normal metadata of the file.

‧Content::CreateAction(actionInfo)→Action

The main application calls this feature when it wants to interact with content objects. The ActionInfo parameter indicates the type of action the application needs to perform (eg, play) and, if necessary, any relevant parameters.

‧Action::GetKeyInfo()

Send back the information needed to decrypt the content that decrypts the secondary system.

‧Action::Check()

Check if the DRM subsystem will authorize the execution of this action (ie if Action::Perform() will succeed).

‧Action::Perform()

Perform this action and perform the results (and their side effects) specified by the rules governing this action.

3.1.2. Group Engine to Main Service Interface

The following is an example of the type of main service interface required by the group engine of the main application in an exemplary embodiment: ‧HostContext::GetFileSystem(type)→FileSystem

Send back the virtual file system object dedicated to the DRM subsystem. This virtual file system will be used to store DRM status information. The data in this file system should be readable and writable by the DRM subsystem.

‧HostContext::GetCurrentTime()

Return to the current date/time maintained by the main system.

‧HostContext::GetIdentity()

Send back the unique ID of this host.

‧HostContext::ProcessObject(dataObject)

A data item is sent back to the host service, which has been built into the DRM object, but the DRM sub-system has been designated as host managed (eg, a certificate).

‧HostContext::VerifySignature(signatureInfo)

Check the validity of the digital signature on the data item. In one embodiment, the signatureInfo object retains information equivalent to the information found in the XMLSig component. The Host service is responsible for verifying the key and key certificates for the signature.

‧HostContext::CreateCipher(cipherType,keyinfo)→Cipher

Establish a cryptographic object that the DRM subsystem can use to encrypt and decrypt the data. The most group of encryption types will be defined and used in each format described as the key information required for the encryption implementation.

‧Cipher::Encrypt(data)

‧Cipher::Decrypt(data)

‧HostContext::CreateDigester(digesterType)→Digester

Create a DRM sub-system to use the digested object to calculate a safe hash on some of the data. In an embodiment, a minimum group digestion type can be defined.

‧Digester::Update(data)

‧Digester::GetDigest()

3.1.3. UML timing diagram

Figure 5 shows the use of the instantiated API described in the preceding paragraphs, and in the illustrated embodiment, the interaction between the main application and the DRM client engine.

3.2. Package Reference Architecture

The Group Suite Reference Architecture provides an example of the functionality of the Group Suite Engine that can execute package content for the main application. The suite application can access protected content (local packages or elsewhere on the network) for the developed package or for general purpose applications that operate on the user's system.

In one embodiment, the host application is: ‧ provides a partial user interface, content and license information can be specified by the interface; ‧ encrypt content, and/or ‧ create a content object, which contains or references content and includes Or refer to a license (after the set engine builds the DRM object that constitutes the license).

Figure 6 shows the components of the group-based package application in one embodiment. In an embodiment, the package engine is responsible for the package, such as the items described herein (referred to as group licenses). The license is related to the meta-data, which is interpreted in a way that the person can read.

As mentioned above, in one embodiment, the main application provides a user interface. It is responsible for obtaining information such as content references and actions that the user wants to perform (eg, who binds the content to whom). It also displays information about the packaged program, such as the license issuing text, and, if a failure occurs, the reason for the failure. In some embodiments, the information required for the main application may require the use of other services, such as authentication or authentication via a Service Access Point (SAP) and membership identification. Therefore, in some embodiments, the main application may need to perform some or all of the following services: • Media Format Service: This component is responsible for managing all media format operations. , for example, data format conversion and package. It is also responsible for content encryption, which can be done via a content encryption service.

‧General Purpose Encryption Service: This component is responsible for issuing/verifying signatures and encrypting/decrypting some of the information. The requirements for such operations may be issued by the service access point or by the group suite engine via the primary service.

‧ Content Encryption Service: This module is logically separate from the general purpose encryption service because it does not know the application. It is a media format service in the content package, driven by a set of keys issued in advance for the group package engine.

3.2.1. Main application to group package engine interface

This paragraph provides a high-level description of the instantiation API between the main application and the group suite engine. In one embodiment, the package and client engine use the same objects whenever possible.

Octopus: CreateSession(hostContextObject)→Session

Establish a conversation to give a main application context. The context object is used by the group suite engine to enter the callback for the application.

‧Session::CreateContent(ContentReferences[])→Content

The main application calls this function to establish content items related to the license object in subsequent steps. Once a content reference is exceeded in the content reference array, it means that the links are tied in a bundle (for example, an audio and a video track) and the issued license should be sent to these references as inseparable Cut the group.

‧Content::SetDrminfo(drmInfo)

The drumInfo parameter indicates the metadata of the license to be issued. The structure will be read and used as a guide to calculate the license to become a byte code for the plankton VM.

‧Content::GetDRMObjects(format)→drmObjects

This feature is called when the main application is ready to get the drmObjects created by the suite engine. The format parameters will indicate the format XML or binary primitives that are expected to be used for these objects.

‧Content::getKeys()→keys[]

When the main application requires a key, this feature is called by the main application to encrypt the content. Each content reference has a key.

3.2.2. Group Suite Engine to Main Service Interface

The following is an example of the type of interface that the group suite engine needs to provide for the main application in one embodiment.

-HostContext::GetFileSystem(type)→FileSystem

A virtual file system object is returned, which is specifically accessed by the DRM subsystem. This virtual file system will be used to store DRM status information. The data in this file system should only be read and written by the DRM system.

-HostContext::GetCurrentTime()→Time returns the current date/time maintained by the main system -HostContext::GetIdentify()→ID Send back the unique ID of this host.

-HostContext::PerformSignature(signatureInfo,data)

Some DRM objects created for the group suite engine will be trusted. This service provided by the host will be used to sign the object specified.

-HostContext::CreateCypher(cipherType,keyInfo)→Cipher

Create an encrypted object that can be used by the suite engine to encrypt and decrypt data. This can be used to enhance the content key material within the ContentKey object.

-Cipher::Encrypt(data)

-Cipher::Decrypt(data)

-HostContext::CreateDigester(digesterType)→Digester

Create a digested object that can be used by the set engine to calculate a safe hash of some of the data.

-Digester::Update(data)

-Digester::GetDigest()

-HostContext::GenerateRadomNumber()

A random number is generated that can be used to generate a key.

3.2.3. UML sequence diagram

Figure 7 shows the use of the instantiated API described in the preceding paragraphs and the interaction between the main application and the suite engine.

B. Submarine key distribution

Diving is a key distribution system that naturally fits into the group architecture described above, and/or can be used in other contexts.

In this way, in addition to the main purpose of establishing a relationship between node objects, group link objects can also be used to assign keys. A group of control objects includes a control program that determines if a required action should be approved. The control program often checks if a particular group of nodes can be completed via a set of group links. Diving makes it possible to utilize a bunch of links to facilitate the assignment of keys so that they can be used by the group engine that is performing the control.

In one embodiment, each group node object for deployment using a group of the diving key distribution system has a diving key. These keys are used to decrypt the content key and the dive keys of other nodes. Each group link object created for the same deployment contains a portion of the encrypted dive data payload, which allows the key information to be derived when the chain of links is processed by the group engine.

In the case of a node and a link carrying the dive key in this manner, assuming that the node A to the set of links of the node Z, any entity accessing the private key of A (for example, a group engine of a client main application) is also accessed. Z's public diving shared key. Once Z's private dive shared key is accessed, the entity is made to access any content key encrypted with these keys.

1. Node, entity and diving key 1.1. Entity

In an embodiment of the group system, the node is a data item, not an active participant in the system. In this context, the active participant is called real body. Examples of entities are media players, devices, content sets, and the like. An entity typically has a group node associated with it. The entity that consumes the content uses the group engine and manages at least one node object that constitutes the group personality. In this embodiment, an entity is assumed to have access to all of the material of the node object it manages, including private information for all of these objects.

1.2. Node

The node object participating in the diving key distribution system contains the diving key system as part of the data. In one embodiment, there are two general types of diving keys: a shared key and a security key. The following paragraphs list the different key types that diving can use in various embodiments. However, it can be understood that the special deployment of the technology uses only these keys of the group once. For example, a system can be actuated by the architecture only with the pairing keys, omitting the use of other secret symmetric keys. Alternatively, if the system only needs to use the shared key, the system can be deployed without providing a security key to the node.

1.2.1. Shared key

The shared key is a pairing key and/or a symmetric key, which is shared by all nodes of a node, and includes a diving key derivation extension.

‧Diving shared public key

Kpub-share[N]

This is the public part of a pair of public/private keys as public key encryption. This key typically has a certificate so that its credentials can be verified by the entity that wants to encrypt the secret information.

‧Diving shared private key

Kpriv-share[N]

This is the private part of the public/private key pair. The real system that manages this node is responsible for ensuring that this private key remains secret. To this end, this private key will be stored and transmitted separately from other node information. This private key will be shared by other downstream nodes through the link's key derivation extension.

‧Diving shared symmetric key

Ks-share[N]

This key is used with a symmetric cipher. As for the private key, this key is confidential, so the real system of the management node is responsible for keeping this key secret. This key will be shared by other downstream nodes through the link's key derivation extension.

1.2.2. Security key

The security key is a pairing key and/or a symmetric key, which is known only to the entity that manages the node to whom they belong. The difference between these keys and the shared keys is that they will not be shared by other nodes through the dive key derivation extensions in the link.

‧Diving secret public key

Kpub-conf[N]

This is the public part of the public/private key used for one of the public key ciphers. This key typically has a certificate so that its credentials can be verified by the entity that wants to encrypt the secret information encrypted.

‧Diving secret private key

Kpriv-conf[N]

This is the private part of the public/private key pair. The real system that manages the node is responsible for keeping the secret of this private key. For this reason, this private key will be stored and transmitted separately from other node information.

‧Diving secret symmetry key

Ks-conf[N]

This key can be used with a symmetric cipher. As for the private key, this key is kept secret, so that the key managing the node is responsible for keeping the key secret.

2. Encryption component

Diving can be implemented using different encryption algorithms. Diving is not limited to any particular chosen encryption algorithm. Furthermore, for a given deployment or distribution, all participating entities generally need to cooperate with a set of supported algorithms. In an embodiment, the deployment includes support for at least one public key cryptographic (eg, RSA) and a symmetric key cryptographic (eg, AES).

The following notation will be used to refer to the encryption function: ■ Ep (Kpub[N], M) means "signal M encrypted with the public key Kpub of node N using the public key cipher"

■ Dp (Kpri[N], M) means "signal M decrypted with the public key Kpriv of node N using the public key cipher"

■ Es(Ks[N], M) means "using the symmetric key cipher, the information M encrypted with the symmetric key Ks of the node N"

■ Ds(Ks[N], M) means "using the symmetric key cipher, the information M decrypted by the node N against the key Ks"

3. The target of the content key

There are two types of encryption targets for diving. Aligning a content key to a target group node The shared key representation makes the key available to all entities to share the private key of the target node. Aligning a content key with a node's security key indicates that the key is only used by the node. Aligning the target is accomplished by using one or two of the following methods to load the key CK carried in the ContentKey object.

‧ Male bondage: Create a ContentKey object that contains Ep (Kpub[N], CK)

‧ Symmetrical Binding: Create a ContentKey object containing Es(Ks[N], CK)

In a preferred embodiment, symmetric binding is used as much as possible because it uses less computationally intensive algorithms and, therefore, has less of a problem for the receiving entity. However, entities that create ContentKey objects (typical content packages) do not always access Ks[N]. In this example, public binding is used because Kpub[N] should be available because it is not confidential. Kpub[N] will be used by the entity that needs to target the content key, followed by a certificate that can be examined by the entity to determine if Kpub[N] is actually the key of the trusted node to process according to the partial consent policy. content.

4. Derivation of the diving key using the link

In order to allow the entity to obtain the dive shared key of all nodes by the personality node, the link object contains a dive extension payload. The payload allows any The "by" node accesses the private/dense key of the link to the visited node private/dense key "to" node. In this way, an entity can decrypt any content key for a node reachable by a sexual node (if the target uses the shared key of the target node).

When the group engine processes the linked objects, it processes the dive payload of each link to update the internal chain of the dive key to its visited.

In one embodiment, the dive extension payload of a link L from node F to node T consists of: ‧ public derivation information: Ep (Kpub-share [F], {Ks-share[ T], Kprive-share [T]}) or ‧ symmetric derivation information: Es (Ks-share [F], {Ks-share [T], Kpriv-share [T]}) where {Ks-share [T] Kpriv-share [T]} is a data structure containing Ks-share [T] and Kpriv-share [T].

The public derivation information is used to convey the private diving shared key Ks-share [T] and Kpriv-share [T] of the node T to any entity of the private diving key Kpri-share [F] that has accessed the node F.

The symmetric derivation information is used to convey the private diving shared key Ks-share [T] and Kpriv-share [T] of the node T to any entity of the symmetric diving shared key Ks-share [F] that has accessed the node F.

As for aligning the content key to the node, it is preferred that the payload contained in the link be symmetrically derived information. This is when the link builder has access to Ks-share [F 〕 is possible. If not, the link builder will drop to the dive payload containing the public derivation information as a link.

Suppose that the group engine that handles this link already has Ks-share[F] and Kpriv-share[F] in its internal diving key chain. After processing the link L[F->T], it will be in the key chain. It has Ks-share [T] and Kprive-share [T].

In an embodiment, because the group links can be processed in any order, the group engine may not be able to make key derivation calculations when the link L is processed. This is because at this time, the diving key chain may not contain the diving key of the "self" node of the link. At this point, when the new information becomes available to the group engine, the link is remembered and processed again. The new information is usually available after processing the new link P. The key derivation step adds the private dive shared key of the "self" node of the link L to the key link (this occurs when the "to" node and link of the link P The "self" nodes of L are the same, and the "self" of the link P is the reachable node).

Figure 8 shows the derivation of the diving key using the link in one embodiment.

5. Sample data structure 5.1. Dive Key

6. Signature

The dive key can appear in different contexts. E.g:

- Node: The dive key contains a flat text key and needs to be signed as part of the node object (if it is contained in the internal extension). Note that in an embodiment, the dive private and key are never included in the node's internal extension, but are included in the outer extension.

- Link: The dive key contains the shared key of the "to" node. In an embodiment, in this context, the dive key extender is not signed as part of the object (if carried in the internal extension), and if carried in the outer extension, the extension is not signature.

C. Group objects

This paragraph describes the basic items, which are the building blocks of the exemplary implementation of the group. First, a fairly high-level diagram shows the types of objects that the group uses to protect and manage content, and how they relate to each other. Furthermore, a more detailed description of these objects is provided along with the information they transmit. Finally, an illustration of the objects used in the embodiments for rule condition, identity, and key management is provided.

1. Content protection and management of objects

Figure 9 is a diagram of various content protection and management objects in accordance with an embodiment of the group. The content management object is an object for protecting the content from the usage rules (control) related to the protected content.

The data represented by the content object is encrypted by a key. The key is represented by a content key object, and the constraint between the content and the key used for encryption is represented by a protector object. The rules governing the key to decrypt the content are represented by the control object, and the binding between the content key and the controls used to manage its use is represented by the control object. In an embodiment, all trusted systems will use the content decryption key only under the management of the rules represented by the byte code in the control object.

1.1 common components

In an embodiment, all group objects share a common basic trait: they may individually have an ID, a list of attributes, and a list of extensions.

1.1.1.ID

Objects that can be referenced for other objects have a unique ID. In one embodiment, the ID is a simple URI, and the habits in the group are URI and URN.

1.1.2. Properties

The attribute is a categorical value. Attributes can have names or no names. The name of a named attribute is a simple string or URI. Value or attribute is a simple type ( String, integer and byte array) or a mixed type (list or array).

The attribute of the type "list" contains an unordered name attribute. The attribute of type "array" contains the unnamed attribute of the sorted array.

The "property" column of the object is (possibly empty) the name attribute of an unsorted collection.

1.1.3. Extension

Extensions are components that can be added to an item to carry additional information that is selected or prepared. The extensions are categorized and have a unique ID. The extension can be internal or external.

1.1.3.1 Internal extension

Internal extensions are included in the objects they extend. They have an "important" flag indicating whether the particular extended data type for the extension needs to be known by the implementation of the object. In one embodiment, if an implementation encounters an object with an important extension and a type of material that it does not understand, they must return the entire object.

In one embodiment, the ID of the internal extension symbol needs to be internal: an object cannot contain two extensions of the same ID, but it is possible that two different objects contain an extension of the same ID as the other object extension.

The "extension" column of the object (which may be empty) is an unordered collection of internal extensions.

1.1.3.2. External extensions

External extensions are not included in the object they extend. They appear outside of the object and have a "subject" column that contains the ID of the object they extend. In an embodiment, the internally extended ID needs to be unique to the world.

1.2. Content

In an embodiment, the content item is an "external" item. The format and storage are not controlled by the group, but are controlled by the content management subsystem of the main application (eg, possibly MP4 movie files, MP3 music tracks, etc.). In an embodiment, the format of the content needs to provide support for correlating the ID to the content payload data. The content payload is encrypted in a format-dependent manner (typically with a symmetric cipher such as AES).

1.3. Content Key

The content key object represents a specific encryption key and is associated with it by an ID. The purpose of the ID is to make the protector object and the control object refer to the content key object. The actual key data contained in the content key object is itself encrypted so that it can only be read by the recipient authorized to decrypt the content. The content key object indicates which encryption system is used to encrypt the key material. The encryption system used to protect the content key material is called a key distribution system. Different key distribution systems can be used. An example of a key distribution system is the above-described diving key distribution system.

1.4. Protector

The protector object contains information that allows the group to find out which key was used to encrypt the content of the content object. It also contains information on which encryption algorithm is used to encrypt the data. In an embodiment, the protector object contains one or more IDs that are referenced by the content object, and the reference content key object represents the key used to encrypt the material. If the protector points to more than one content object, then these content objects represent material that has been encrypted using the same encryption algorithm and the same key.

1.5. Control

When required by the main application, the control object contains information to allow the group to make a decision as to whether certain actions on the content should be allowed. In one embodiment, the rules governing the use of the content key are encoded in the control object as a plankton byte code. The control object has a unique ID at the same time so that it can be referenced for the control object. In an embodiment, the control object is signed such that the group can verify that the control byte code is valid and trusted before any decision is made. When this information is available, the validity of the control object is also optionally derived by verifying the secure hash contained in the control object.

1.6. Control character

The control object contains information that allows the group to find out which control management is used by one or most of the keys represented by the content key object. It contains information to bind it to the content key object and the control object it references. In one embodiment, the control object is signed (by the suite application, It has a certificate to allow it to sign the control object) so that the group can trust the validity of the binding between the content key and the control object that manages it, and the binding between the content key ID and the actual key data is valid. Sex. The signature of the control object can be a public key signature or a symmetric key signature, or a combination of the two. At the same time, when the digestion of the control object referenced for the control object is included in the control object, the validity of the control object can be derived without having to separately verify the signature of the control object.

1.6.1. Symmetric key signature

This is the most common type signature for control objects. In one embodiment, this type of signature is implemented by computing the MAC (Information Authentication Code) of the control object, and is keyed with the same key as the content key object. In one embodiment, the standard method of this MAC uses the HMAC of the same hash algorithm as the other encryption algorithms selected for the same group deployment.

1.6.2. Public Key Signature

This type of signature is used when the identity of the signer of the control object needs to be known. This type of signature is implemented by a public key signature algorithm, signed by the private key of the person claiming the validity of the object. In an embodiment, when using this type of signature, a symmetric key signature will appear, and the signature control object and the public key signature, so that it can be guaranteed that the person with his private key signature has been authorized to carry The actual value of the content key in the content key object.

2. Rule conditions, identity and key management objects

Figure 10 shows various rule conditions, identity and key management objects in accordance with a group embodiment. The node object represents the entity in the DRM profile. In an embodiment, the group does not have a hint or explicit semantics represented by the node object. A given deployment (DRM profile) of a system using a group will define what type of person exists and what role and identity the different node objects represent. Semantic information is typically represented using the attributes of the node object.

The link object represents the relationship between the nodes. The link object can optionally contain other encrypted material to allow the group to use the link for content key derivation calculations. As in the case of a node, in an embodiment, the group does not imply or expressly mean the meaning of the link relationship. Depending on the "self" and "to" links, the nodes represent a given DRM profile, and the meaning of the link relationship can be expressed as membership, ownership, association, and many other types of relationships. In a typical DRM profile, some node objects represent users, other nodes represent devices, and some nodes represent user groups or authorized domains (AD). In this case, the link between the device and the user may represent a proprietary relationship, and the link between the user and the user community or AD may represent a membership relationship.

2.1. Node

A node object represents an entity in the system. The attributes of the node object define certain aspects of the node object representation, such as the role or identity represented by the node object in the context of the DRM profile. Node object also has There is a secure asymmetric pairing key that is used to target confidential information as a secondary system for confidentiality of an already accessed node object (typically, the entity represented by the node, or the entity responsible for managing the node). The secret information of the target for a node will be encrypted with the secret public key of the node. Alternatively, when the system uses a content key derivation system for, for example, content key distribution as described above, a content protection asymmetric pairing key and a content protection symmetric key can be used in conjunction with the chained object.

2.2. Linkage

The link object is a signature claim, wherein there is a pointing edge in the figure, and the top node is a node object. For a given set of nodes and links, if there is a pointing path between the node X vertex and the node Y vertex in the figure, it is considered that there is a path between node X and node Y. When there is a path between node X and node Y, node Y is considered to be reachable by node X. Therefore, these claims represented by the link objects are used to indicate which nodes are reachable by other nodes. Controlling the management of the content object before allowing the action to be performed may check if certain nodes are reachable by the node having the entity that performed the action. For example, if node D indicates that a device wants to perform a "play" action on a content object, then control of managing the content object can test whether a node U can be reached by node D on behalf of a user. In order to determine if node U is reachable, the group will check if there is a set of link objects that can be established between the node D and the node U.

In one embodiment, before the group uses the linked object, the group first validates it to determine the existence of the path in the node map. Depends on the signature The specific characteristics of the certificate system of the linked object (eg, x509v3), the linked object can be given a limited lifetime, abolished, and the like. In one embodiment, policies governing which entities can sign the link object, which link objects can be established, and the life of the link object are not directly handled by the group. Conversely, policies that exist outside the group will have an impact on node attribute information. In order to facilitate the task of enhancing certain policies, in one embodiment, the group provides a way to extend the standard certificate format with other limitations checks. These extensions may indicate the validity of the certificate on the signature of the signature link, such that the type of node and other attributes of the node to which the link is connected may be checked before the link is considered valid by the group.

In an embodiment, the link object can include a control object that can be used to limit the effectiveness of the link. Additionally, in an embodiment, the link object may contain diving encryption material that provides the user with a node's content protection key for key distribution. In addition to the metadata, the encrypted material will contain the private and/or symmetric content protection keys of the "from" node, which are encrypted with the content protection public key and/or content protection symmetric key of the "to" node.

3. Usage mode

In an embodiment, because the group does not express or imply semantics attached to the basic objects, the system using the group will need to participate in one or more usage patterns for the objects, which will place the objects in semantics. In the context. We call these semantic contexts DRM profiles. At this point, we believe that the group object is a DRM LEGO building block, which is used to build a DRM system.

4. Data structure

The following paragraphs describe in more detail an exemplary object model for the above objects, defining the fields owned by each type of object in an exemplary embodiment.

These data structures are described using a fairly simple object description syntax. Each item type is defined by a class that can extend a parent class (ie, a "one" relationship). The class description is represented by a simple abstract type "string" (character string), 'int' (integer value), 'byte' (8-bit byte value), and 'boolean' (true or false), but Any specific encoding of these data types is not defined, or synthetic structures of these types are included. The manner in which an object is encoded, or rendered, may vary depending on the implementation of the engine. Typically, a given pattern used by a group will indicate how the field is rendered (eg, using an XML design).

In an exemplary embodiment, the following notation is used:

4.1. Common structure

In an exemplary embodiment, the following common structure is used:

4.1.1. Properties

In one embodiment, there are four attributes: an integer attribute, a string attribute, a byte array attribute, and a list attribute, each having a name and a type.

4.1.2. Extensions

In one embodiment, there are two extensions:

■Internal extension: carried in the group

■External extension: carried outside the group

It is important to be able to verify the signature of Octojbect if a particular type of extension is not known to a given implementation. This is why in one embodiment a step is added indirectly related to the data digestion field. If the specification of the extended material indicates that the data is part of a signature within a particular Octobject context, the data digestion column will appear. Understanding the implementation of this extended data can therefore calculate its standard representation and verify the digest. In this embodiment, if the specification of the extended data indicates that the data is not part of the signature, the data digestion field does not appear.

4.2. Node objects

4.3. Linked objects

4.4. Control objects

4.5. Content key object

In one embodiment, each key has a unique id, format, usage (which may be empty), and data. If the Usage column is not empty, it indicates the purpose for which the key can be used. For normal content keys, this field is empty. For diving, this column indicates whether this is a key shared key or a security key. The "Format" column indicates the format of the 'Data' column (for example, 'RAW' indicates a symmetric key, or 'PKCS#8' indicates an RSA private key, etc.). The 'Data' column contains the physical key data formatted according to the 'Format' field.

For the key of one part of the pairing key (for example, the RSA key), the extra column 'pairId' gives the pair a unique identification code so that the pair can be referenced by other data structures.

In one embodiment, the data field in the key object is the plaintext value of the actual key, even if the presentation of the piece contains an encrypted copy of the key.

4.6. Control object

D. Plankton virtual machine

Plankton is a virtual machine (VM) used by the group engine embodiment to execute a control program that manages access to content. As will be explained below, an exemplary sample version of the plankton VM will explain some of the design decisions and the plankton VM with the group architecture, then describe the basic components of the VM, followed by other details and instruction sets about the memory model. Finally, explain how the program is packaged in the code module and provide the system call group that can be used by the program.

1. Design basic principles

In one embodiment, the Plankton Virtual Machine (VM) is a traditional virtual machine that is designed to be easily implemented using a variety of programming languages with minimal code footprint. It is based on a stack-oriented instruction set that can be called TISC (Simple Instruction Set Computer). This instruction set is designed to be the minimum requirement and is not related to execution speed or code density. Execution speed is non-targeted, and code density is orthogonal: when microcode is needed, data compression techniques are used to compress the planktonic code without designing the bytecode to be smaller.

Plankton should be suitable for low or high level programming languages. At a minimum, virtual machines should essentially support combined languages, C, and FORTH. It should be possible to implement compilers for other languages, such as Java or proprietary languages, without much difficulty.

Finally, in one embodiment, the plankton VM is designed to be within the host environment and is not directly executed on the processor or integrated circuit. The natural host environment for plankton is the group engine.

2. Architecture

Figure 11 shows the operating environment of an exemplary implementation of plankton VM. The plankton VM executes within the context of its host environment, and when the host environment executes the program, it implements the functions required by some of the VMs. Typically, a plankton VM is executed within a group engine that implements its host environment.

The VM executes the program by executing instructions stored in the code module. Some of these commands can be called by the system, and the call is implemented outside the program itself. System calls are either implemented by the plankton VM itself or assigned to the host environment.

3. Basic VM components 3.1. Execution model

In one embodiment, the plankton executes the instructions stored in the code module as a byte stream carried in the memory. The VM maintains a virtual scratchpad called a program counter (PC) that is incremented when the instruction is executed. The VM executes the instructions sequentially until it encounters an OP_STOP instruction, an OP_RET instruction encounters an empty call stack, or an exception occurs. The hopping is indicated as a relative hop (a byte offset indicated as the current value leaving the PC), or an absolute address.

3.2. Memory model

In an embodiment, the plankton VM has a simple memory model. The VM memory is divided into a data memory space and a code memory space.

The data memory is a uniform adjacent memory space starting from address 0. The data memory is typically one of the array bytes allocated in the main application or in the main environment. For a given VM implementation, the size of the memory space will be fixed to the specified maximum, and any memory accesses that would otherwise be outside the space will cause a failure and will terminate the program execution. The data memory may be shared among several code modules that are simultaneously loaded by the VM. The data in the data memory can be accessed by a memory access instruction, which can be accessed as 32-bit or 8-bit. The 32-bit memory access is done sequentially using big-endian bytes. No assumptions have been made regarding the alignment between VM visibility and host management memory (primary CPU virtual or physical memory).

The code memory is a uniform adjacent memory space, starting with address 0. The code memory is typically an array of bytes in the main application or in the stacked memory of the main environment.

If the VM loads several code modules, all code modules share the same data memory (however, each module's data is carried on a different address), but each has its own code memory (this means that for A jump instruction of a code module cannot cause a jump directly to a code from another code module).

3.3. Data stacking

The VM has a representation of the data stack that represents the 32-bit data unit stored in the data memory. The VM maintains a virtual scratchpad called a Stack Indicator (SP). After resetting, the SP points to the end of the data memory, and the stack grows downwards (when the data is pushed onto the data stack, the SP register is decremented). Depending on the instruction to reference the stacked data, the 32-bit value on the stack is interpreted as a 32-bit address, or a 32-bit signed integer.

3.4. Call stacking

The VM manages the call stack used to complete the nested subprogram call. The value pushed onto this stack cannot be directly read or written by any memory access instruction, but is indirectly used by the VM when the OP_JSP and OP_RET instructions are executed. For a given VM profile, the size of this return address stack will be fixed to a maximum value that allows a certain amount of nested calls to not be exceeded.

3.5. Pseudo-register

The VM reserves a small space at the beginning of the data memory to map the pseudo-scratchpad. The memory addresses of these pseudo scratchpads are fixed.

3.6. Memory map

The layout of the data memory and code memory space is shown below.

3.6.1. Data Memory

3.6.2. Code Memory

4. Instruction set

In an embodiment, the plankton VM uses a very simple instruction set. The number of instructions is very limited and should be sufficient to represent a simple program. The instruction set is mainly stacked: except for the OP_PUSH instruction, these instructions have no direct operands. All arithmetic components are read by the data stack and the results are pushed onto the data stack. VM is a 32-bit VM: All instructions operate on a 32-bit stacked operand, representing a memory address or a signed integer. The signed integer is represented by a two's complement binary code.

In the following table, the stacking operands for instructions with two operands are listed as A, B, to the top of the stack (B).

5. Code module 5.1. Module format

The code modules are stored in a primitive-based format. The primitive is equivalent to the primitive structure used in the MPEG-4 file format: a primitive consisting of a 32-bit size, stored as a 4-octet in the order of the big endian, followed by There are 4-octet types (usually octets corresponding to the ASCII value of the letters) followed by primitive payloads (size -8 octets). Figure 12 shows the format of the illustrated planktonic code module.

5.2.pkCM primitive

The pkCM primitive is the top-level code module primitive. It contains a sequence of secondary primitives. In an embodiment, the primitive must contain exactly one pkDS, one pkCS, and one pkEX primitive. It can also contain a pkRQ primitive. In an embodiment, any number of other primitives that should be ignored may be included, if any.

5.3.pkDS primitive

The pkDS primitive contains a data section of a memory image that can be loaded into the data memory. The payload of the primitive is an order of octet values. The first octet of the memory image contains a version number indicating the format of the following octet.

In one embodiment, only the DataSegmentFormatVersion=0 is defined: the following octets in the sequence form an original image to be loaded into the memory. VM carrier only needs Load the payload of the data section instead of the header byte.

5.4.pkCS primitive

The pkCS primitive contains a code segment of a memory image that can be loaded into the code memory. The primitive's payload is a sequence of octet values. The first octet of the memory image contains a version number indicating the following octet format.

In one embodiment, only CodeSegmentFormatVersion=0 is defined, as follows: The next octet contains a version number to indicate the following byte encoding of the octet. ByteCodeVersion=0 indicates that the byte code value is as described below. The following octet contains the byte code. The VM carrier only needs to load the payload of the code segment, not the two header types.

5.5.pkEX primitive

The pkEX primitive contains a list of export inputs. Each exit entry contains a name that is encoded as an 8-bit name size, followed by a character with a name that terminates at 0; followed by a 32-bit integer representing the byte offset of the input point for that name (This is offset from the beginning of the data stored in the pkCS primitive).

5.6.pkRQ primitive

The pkRQ primitive contains the requirements that need to be met for the virtual machine implementation to execute this code. This primitive is optional. If there is no such primitive in this code module, the VM will use the preset implementation settings, which can be the implementation profile. Defined.

This primitive consists of an array of 32-bit integer values, each value for a required field:

5.7. Module carrier

The plankton VM is responsible for loading the code module. When the code module is loaded, the data segment image encoded in the pkDS primitive is loaded into the memory address in the data memory. The address is selected by the VM carrier and stored in the DS pseudo register. The address selected for the carrier needs to be large enough to not overlap the payload data with the pseudo scratchpad and preserve the address range.

The code segment memory image encoded in the pkCS primitive is loaded into the memory address in the code memory. This address is selected by the VM carrier and stored in the CS pseudo register.

When the code module is loaded, if the "Global.OnLoad" special routine is found in the entry of the exit table, the routine is executed. This routine does not take the arguments on the stack and returns an integer state when sent back. 0 means Gong, negative numbers indicate error status.

When the code module is unloaded (or when the VM loaded into the module is discarded), if the "Global.OnUnload" special routine is found in the exit table, the routine is executed. This routine does not take arguments on the stack and returns an integer state when sent back. 0 indicates success and negative indicates error status.

6. System call

The plankton program can call the function implemented outside the code segment of its code module. This is done by the use of the OP_CALL instruction, which uses an integer stacking operand to indicate the number of system calls. Depending on the system call, the implementation may be a plankton byte code routine in a different code module (eg, an application-enabled repository), either directly by VM in the VM's native implementation format, or assigned to An external software module, such as the main environment of a VM.

6.1. System Call Number Configuration

In the illustrative embodiment discussed, plankton reserves the number of system calls 0 to 1023 for fixed system calls (these system calls will be the same on all VM implementations). The number of system calls 16384 to 32767 can be dynamically assigned by the VM (for example, the number of system calls sent back for System.FindSystemCallByName can be dynamically configured for the VM, so in all VM implementations, it is not necessary to have the same number ).

In an embodiment, the following fixed system call numbers are indicated:

6.2. Standard system call

In one embodiment, a small number of standard system calls are included, which can be used to write control programs. These calls contain fixed number system calls listed in the above table, as well as dynamically determined system calls (ie, their system calls are retrieved by the System.FindSystemCallByName system call, with the name as an argument).

6.2.1.System.NoOperation

Input: none Output: none

Description: This call is a no-computing call. It is sent back (nothing). Mainly used to test VMs.

6.2.2. System.DebugPrint

Input: Stack top:

Information: The address of the memory location containing a null-terminated string. Description : Print text string to debug output.

6.2.3.System.FindSystemCallByName

Input: Stack top:

Name: The address of the null-terminated string containing the name of the system call being sought.

Output: Stack top:

Id: If the number of system calls for a system call with this name is implemented, if not, then -1.

Description: Find the ID of the system call with its name.

6.2.4.System.Host.GetLocalTime

Input: none

Output: stack top

Local time: The current value of the local time of the host.

Description:

The local time is expressed as a 32-bit integer equal to the number of minutes since January 1, 1970, 00:00:00.

6.2.5.System.Host.GetLocalTimeOffset

Input: none

Output: stack top

Local time offset: The current time offset of the host (open UTC time).

Description:

The time offset is expressed as a 32-bit signed integer equal to the number of minutes between the local time and the UTC time (ie, local time - UTC).

6.2.6. System.Host.GetTrustedTime

Input: none

Round out: Stack top

Trust Time: The current value of the trust clock, or a negative error code if there is no trust time. This value is represented as a signed 32-bit integer equal to the number of minutes elapsed from January 1, 1970 at 00:00:00 UTC.

Flag: The flag byte further defines the current state of the trust clock. If an error occurs (the trust time value is a negative error code), the flag value must be 0.

Defined with the following flags

Description:

The system call is only for the system that implements the trust clock, which is synchronized with the trust time source and holds a monotonic time counter. The trust time value is not always guaranteed to be correct, but in an embodiment, the following characteristics are required to be true:

‧ The trust time value is expressed as the UTC time value (the trust time is not the local time zone, because the local is not safely determined).

‧ Trust time will not go back.

‧ Trust clocks don’t go faster than real time.

Therefore, the trust time is always between the last synchronization time (synchronized with the trusted time source) and the local real time. If the system can determine that its trust clock has been operated and is continuously updated continuously, without interference, and the last synchronization with the trusted time source, it can be determined that the trust time value is not an evaluation, but an accurate value, and the TIME_IS_ESTIMATE flag is set to zero.

In an embodiment, if the trust clock detection fails (hardware or software), and even cannot return the evaluation value of the trust time, it must send back an error code, and the value of the returned flag must be set to 0. .

6.2.7.System.Host.GetObject

Input: Stack top:

Mother: 32-bit handle of the parent container

Name: The address of the null termination containing the path to the requested object, related to the parent container

Return buffer: Address of the memory buffer to store the value of the object

Return buffer size: The size of the memory buffer to store the value of the object (in bytes)

Output: Stack top:

Type Id: Object type id, a negative error code if the call fails. If no object is requested, the error is returned to ERROR_NO_SUCH_ITEM. If the buffer returned value is too small, the error returned is ERROR_INSUFFICIENT_SPACE. If the accessed object is accessed and the calling program does not obtain the object permission, it will be returned to ERROR_PERMISSION_DENIED. Other error codes can also be sent back.

Size: The size (in bytes) of the data sent back to the buffer supplied by the caller, or the size required if the caller provides a buffer that is too small.

Description: The system call is a generic interface that allows the program to access the objects provided for the VM Host.

6.2.7.1. Object type

In one embodiment, there are three types of primary objects: strings, integers, byte arrays, and containers.

6.2.7.1.1. Byte array

The byte array object value is an array of 8-bit bytes. The object type Id for the byte array is 3

6.2.7.1.2. String

The value of the string object is a simple null-terminated sequence of 8-bit characters. The object type Id used for the string is 2.

6.2.7.1.3. Integer

The value of an integer object is a normal plankton 32-bit signed integer value. The object type Id for an integer is 1.

6.2.7.1.4. Container

A container is a general purpose container that contains any number of items in any combination of any order. The item contained in the container is referred to as the child of the container. The container is a 32-bit container handle, which is unique in a given VM instance. The object type Id for the container is 0.

6.2.7.2. Object Name

The namespace used for the primary object is the underlying namespace, where the name of the child of the container is constructed by appending the name of the child to the name of the parent container, separated by a "/" character. Characters and integer objects have no children. For example, if the container is referred to as 'node/attribute' and has the string subname 'type', then 'node/attribute/type' represents a substring.

The root of the namespace is ‘/’. All absolute names begin with ‘/’. Names that do not start with ‘/’ are relative names. The relative name is relative to a parent container. For example, the name 'attribute/type' with respect to the parent '/Node' is an object having an absolute name of '/Node/Attributes/Type'. The root container '/' has a fixed value of zero.

6.2.7.2.1. Virtual Names and Virtual Objects

Container objects can have real and virtual sub-objects that are accessed by using virtual names. The virtual name is a name that is not attached to the main object, but is used to indicate a sub-object with no name, a sub-object with a different name, or a virtual sub-object (a sub-object that is not the real parent of the container but is automatically created when required) ).

For any object, the following virtual name is defined as the virtual child object name:

For any container, define the following virtual name as the virtual child object name:

6.2.7.2.2. Examples

For example, the hierarchy of the main object:

Call System.Host.GetObject (mother=0, name='node') to return the type id0 (container) and write the value 1 to the buffer supplied by the caller (the size of the value is 4 bytes) ).

Call System.Host.GetObject (parent=0, name='node/attribute/domain') to return type id2 (string) and write the string "top level" in the buffer supplied to the caller (value The size is 9 bytes).

Call System.Host.GetObject (parent = 1, name = 'attribute / @1') to return the type id1 (integer) and write the integer 78 in the buffer supplied to the caller (the value is 4 bits) Tuple).

Call System.Host.GetObject (parent=0, name=‘nothing') to return the error code ERROR_NO_SUCH_ITEM.

6.2.8.System.Host.SetObject

Input: Stack top:

Mother: 32-bit mother container

Name: The address containing the null-terminated string to the object path, relative to the parent container.

Object Address: The address of the memory buffer stored by the object value. If the address is 0, the call is interpreted as a request to destroy the object. The information on the address depends on the type of object.

Object Type: The type Id of the object.

Object Size: The size of the memory buffer (in bytes) stored by the object value. In the illustrated embodiment, the size must be set to 4 for integer objects. For a string object, the size is the size of the memory buffer and contains a null termination code. For a byte array object, the size is the number of octets in the array.

Output: Stack top:

Result code: If the call is successful, it is 0, or if the call fails, it is a negative error code. If the requested object does not exist, the error is returned to ERROR_NO_SUCH_ITEM. If the positive access portion of the object tree is accessed and the calling program does not permit access to the object, return it ERROR_PERMISSION_DENIED. Other error codes can also be sent back.

Description:

This system call is a generic interface that allows programs to create, write, and destroy objects provided by the VM Host. The description of the object name and type is the same as System.Host.GetObject.

Not all primary object support is written or carried, and not all container support with child objects is created. When the set object call for an object that does not support the operation is completed, an ERROR_PERMISSION_DENIED is sent back.

When an object refers to a container, there is a special case, and the object address is not 0: the object size parameter must be set to 0. The value of the object address is ignored. If the container already exists, you don't have to do anything to send back a successful result code. If there is no container and the parent of the container is writable, an empty container is created.

6.2.9.Octopus.Links.IsNodeReachable

Input: Stack top:

Node Id: The address of the null-terminated string containing the ID of the target link to be tested for reachability.

Output: Stack top:

Result code: an integer value. If the node is reachable, the result is 0, if not, it is a negative error code.

Status block indicator: The address of the standard extended status block, or 0 if the status block is not returned.

Description:

This system call is used by the control program to check if a given node can be reached by a node associated with the entity hosting the plankton VM.

6.2.10.System.Host.SpawnVm

Input: Stack top:

Module Id: The Id of the code module that should be loaded into the VM.

Output: Stack top:

Result code: an integer value. If the call is successful, the result value is 0, and if it fails, it is a negative error code.

Vm puts: an integer value. The VM instance is established (this is set to 0 if the call fails). This is only guaranteed to be unique in the current VM.

Description:

This system call is used by the control program to request the established plankton virtual machine, and the code module is loaded.

The host that newly creates the VM should present the same host object as the host object presented to the caller, with the exception that the host object "/Octopus/Runtime/Parent/Id" is set to the identity of the caller.

When the VM for the caller's code is being terminated, the generated VM that was not explicitly released by calling System.Host.ReleaseVm is automatically released for the system as if it were calling System.Host.ReleaseVm.

6.2.11.System.Host.CallVm

Input: Stack top:

Vm puts: an integer value. The handle of the VM created by calling System.Host.SpawnVm.

Input Point: The address of the null-terminated string indicating the name of the input point. This name needs to match one of the input points in the output table of the code module, which is loaded with the VM instance corresponding to the Vm parameter.

Parameter Block Address: The address of the memory block containing the data to be delivered to the callee. If no parameters are sent to the callee, it is set to 0.

Parameter block size: The memory block size (represented by a byte) in the address parameter block address, or 0 if the parameter block address is 0.

Return Buffer Address: The address of the memory buffer received by the caller from the callee. This is set to 0 if the caller does not expect to return data from the callee.

Return buffer size: The size (in bytes) of the memory buffer returned to the buffer address at the address, or 0 if the return buffer address is 0.

Output: Stack top:

System result code: an integer value. The result is 0 if the call is successful and a negative error code if it fails. This value is determined by the system, not the callee. Success only means that the system can successfully find the routine of the call, execute the routine and get the return value from the routine. The return value from the routine is sent back to the CalleeResultCode value.

Callee result code: integer value. This is the value returned by the callee.

Return Block Size: The size (in bytes) of the data in the buffer supplied to the caller, or the size required if the caller provides a buffer that is too small. If the callee does not return the data, the value is 0.

Description:

The system call is used by the control program to call the routine executed in the code module, and the code module is loaded in the VM instance established for the System.Host.SpawnVm system call.

In the illustrated embodiment, the called routine needs to cooperate with the following interface habits: when the routine is called, the stack contains the value parameter block size provided for the caller, indicating the size of the parameter block at the top, followed by the data. The parameter block size byte. If the size is not a multiple of 4, the data on the stack will be added with a 0-valued byte to ensure that the stacking indicator remains a multiple of 4.

Stack top:

When returning, the routine must be on the stack and provide the following return values: Stack Top:

Return Block Address: The address of the memory block containing the data to be sent to the caller. If there is no data to send back, it is set to 0.

Return Block Size: The size (in bytes) of the memory block that returns the block address at the address. If the block address is 0, it is 0.

6.2.12.System.Host.ReleaseVm

Input: Stack top

Vm puts: an integer value. The handle of the VM created for calling System.Host.SpawnVm.

Output: Stack top:

Result code: an integer value. If the call is successful, the result value is 0, and if it fails, it is a negative error code.

Description:

The system call is used by the control program to require a new instance of a plankton virtual machine to be created and a code module to be loaded.

The host that newly creates the VM should present the same primary object as the one presented to the caller, except for the primary object "/Octopus/Runtime/Parent/Id" set to the identity of the caller.

6.3. Standard data structure

The following is the standard data structure used for some standard system calls. They can also be used for other customer system calls.

6.3.1. Standard parameters

Parameter block:

Name: Parameter name

Value: parameter value

Extend the parameter block:

Flag: Brin flag vector

Parameters: simple name / value parameter block

Name block:

Size: A 32-bit integer equal to the 8-bit byte size of the subsequent character field. If this value is 0, the character field is empty (it is empty afterwards).

Character: null terminated UTF-8 string value block:

Type: 32-bit byte identification code. In an embodiment, the following types are defined:

Size: A 32-bit integer equal to the size of the 8-bit byte in the subsequent asset column. If the value is 0, the data field is empty (no value after it).

Data: An 8-bit byte array represents a value. The actual byte is encoded by the data represented by the type column.

List of values:

Value Count: The 32-bit integer is equal to the number of subsequent value block structures. If the value is 0, there is no value block after it.

Value 0, value 1, ...: indicates the order of 0 or greater value block structure

6.3.2. Standard extension status

The standard extended status block is a data structure that is typically used to transmit extended information as a return status from a call to a routine or system call. This is a generic data structure that can be used in a variety of contexts with different possible value ranges for its fields.

Extended status block:

Universal flag: Brin flag, regardless of the category bar, the semantics are the same. The location and meaning of the flag is defined by the profile of the standard extended status block.

Category: An integer-specific identifier for the category to which the status belongs. The category identifier value is defined by the profile using the standard extended status block.

Sub-category: An integer identification code (specific to this category) that is further classified as a sub-category of the status type described in this block.

Local flag: Brin flag, whose meaning is limited to the category and sub-category of this status block. The location and meaning of the flag is defined by the profile that defines the semantics of the category.

Cache time: Indicates when this state can be cached (ie, remains valid). See the cache time block definition for the actual value of time.

Parameters: A list of 0 or more value blocks. Each value block contains a parameter, It is encoded as a value of a type parameter or an extended parameter. Each parameter binds a name to a category value and is used to encode elastically variable data describing the status block and is more detailed than the category, subcategory, cache time, and flag.

Cache time block:

Type: An integer identifier for the value type.

The following types are available:

Value: 32-bit integer. The meaning of this value depends on the type column.

6.4. Standard result code

Some standard result codes are used in various APIs. Other result codes can be defined for use in more specific APIs.

7. Combiner syntax for plankton combiner

In one embodiment, the plankton combiner reads the source file containing the code, data, and processing instructions, and the processing instructions, and generates a secondary input module that can be loaded for the plankton VM. In an embodiment, the plankton combiner is operable to establish a control program from a combined language file. Additional information regarding an exemplary embodiment of a plankton combiner is provided below.

In an exemplary embodiment, the combiner processes a source file sequentially, row by row. Lines can be zero or more characters followed by new lines.

Each line can be one of the following:

‧ a blank line (only blank space)

‧ Section guidelines

‧Information Guide

‧Combiner guidelines

‧ code instruction

‧label

‧ Export guidelines

Each line can end with a command that begins with a ";" character and continues until the end of the line.

The data and instructions read by the source have a hint destination segment (where they end with one of the VM loads). At any point in the profiling process, the combiner will have an "current" section, which is the implied destination section of the material and the instruction. The current section can be changed using the section guidance.

7.1. Section guidelines

The segment guide changes the current section of the profiler. In an embodiment, the supported segment guidelines are:

‧.code

The code segment holds a byte code instruction

‧.data

The data section holds general variables

7.2. Information Guidelines

The data guide indicates the data (integer and string) that will be loaded into the data section of the VM.

.string "<some chars>"

Indicate a string of characters. The combiner will add an octet value of 0 to the end of the string.

‧.byte<value>

Indicates 8-bit. <value> can be expressed as a decimal number, or a hexadecimal number (suffixed with 0x().

.long<value>

Indicates 32 bits. <value> can be expressed as a decimal number, or a hexadecimal number (with a suffix plus 0x).

7.3. Combiner guidelines

In an embodiment, the combiner is directed to: .equ<symbol>, <value>

The setting symbol <symbol> is equal to the value <value>. Symbols are typically used as operands or code instructions.

7.4. Label

The tag is a symbol that points to a location within the segment. The tag that points to the instruction in the code section is typically used for the hop/branch instruction. Tags that point to data in the data section are typically used to represent variables.

The syntax for labels is: <LEBEL>:

Note that it is blank after ":", except for the command. The tag points to the next item or instruction. It can have more than one tag pointing to the same address.

7.5. Export guidelines

The export guide is used to create an entry in the "export" section of the code module produced by the combiner. Each entry in the exit paragraph is a (name, address) pair. In the illustrated embodiment, only the address within the code segment can be indicated in the exit paragraph.

The syntax for export guidelines is: .export<label>

This will exit the address pointed to by <label> with the name <label>.

7.6. Code instructions

When compiling the data assigned to the code segment, the combiner reads directly, between The instruction to map to the byte code. Most plankton byte codes do not have direct operands, and a simple mnemonic appears on a single line. In order to make the combiner syntax more reliable, some instructions accept pseudo-operands, which looks like they are byte-command elements, but they are not really; at this point, the combiner produces one or more bytecode instructions. To produce a function like a direct operand as an instruction. For example, branch instructions use pseudo-operands.

7.6.1. Branch operands

The branch instruction can be a specific representation (without any operands) or have an optional operand that will be converted to the corresponding bytecode order by the combiner. Use the operand as one of the following:

‧ integer constant

‧symbol

When the operand is a symbol, the combiner calculates the correct integer relative offset such that the branch ends at the address corresponding to the symbol.

7.6.2. Pushing the operand

In one embodiment, the push command always takes an operand. The operand can be one of the following:

‧ integer constant

‧symbol

‧Front ‘@’ followed by the tag name

When an operand is a symbol, the value pushed in is always a direct value of the symbol, whether the symbol is a label or a .equ symbol (this value does not increment a segment offset).

When the operand is a tag name prefixed with ‘@’, the value pushed in depends on what the tag points to. The value pushed into the stack is the absolute address represented by the tag (ie, the local tag value that is added to the segment offset).

7.7. Examples

7.8. Command line syntax

In an embodiment, the combiner is a command line tool that can be invoked with the following syntax:

E. Object storage

The following describes the secure object storage that can be used to provide a secure state storage mechanism for the group engine implementation. This facility has a repository for the control program to read and write to the protected state, which is continued from one call to another. This state database can be used to store state objects such as number of games, first use date, cumulative progress time, and/or the like.

1. Database object

The "shell" database contains objects. The object is arranged in a logical hierarchy, wherein the container object is the mother of the child object. In one embodiment, there are four types of items. Each item has associated metadata and a type. An object can also have a value depending on its type.

Shell objects can be accessed by the plankton program using the System.Host.GetObject and System.Host.SetObject system calls. Object metadata can be accessed using a virtual name as detailed below. In one embodiment, some of the metadata columns can be changed by the client of the shell database, but some of the metadata columns are read-only (they are managed entirely by the database implementation method).

1.1. Object metadata

1.2. Object type 1.2.1. String

The value of the string object is a UTF-8 encoded character string.

1.2.2. Integer

The integer object value is a 32-bit plus or minus integer value.

1.2.3. Byte array

The value of the byte array object is an array of octet bytes.

1.2.4. Container

The container item contains zero or more items. The container object is called the mother of the object. The included object is called a child of the container. All the objects of the parent and the mother of the object, and the like of the chain, are called the ancestors of the object. . If an object has another object as its ancestor, the object is referred to as the grandchild of the ancestor.

2. Object life

The life of an object in a shell database follows a number of rules. Objects can be explicitly destroyed or impliedly destroyed. Objects can be destroyed by repository garbage collection.

Regardless of how the object is destroyed, in one embodiment, the following rules are always applied:

• The modification date of the parent container used for the item is set to the current local time.

‧If the object is a container, all its children are destroyed.

2.1. Explicit object destruction

Explicit objects destroy the client that occurred in the database and requested to remove an object (see Object Access, how this is done using the Host.SetObject Plankton system call).

2.2. Implied object destruction

The implied object destruction occurs when the object is being destroyed because one of the objects in its ancestors is being destroyed.

2.3. Garbage collection

The shell object database can destroy objects that have expired. When on the system When the local time implementation database is larger than the expiration date column of the object metadata, an object is considered to be due. Until the database implementation method determines when and how to perform the collection of expired items.

Note that when the container object is destroyed due to expiration, even if the child object has not expired, the child object (and its child objects, and so on) is destroyed.

3. Object access

Objects in the shell data can also be accessed by the plankton program via a pair of system calls. The two system calls are: System.Host.GetObject reads the value of the object, and System.Host.SetObject creates, destroys, or sets the value of an object.

In order to look like a tree of main objects, a shell database needs to be "installed" under a name in the main object tree. In this way, the repository can be viewed as a secondary tree in the more general tree of the primary object. To accomplish this, in one embodiment, all of the shell repositories contain a top-level built-in root container object that is always present. This root container is basically the name of the database. All other objects in the repository will be descendants of the root container. Multi-shell databases can be installed in different places in the main object tree (both databases need to be installed under the same main container, they need to have different names in their root container). For example, if a shell database with a root container name of 'Library 1' contains a single integer child container object whose name is 'Sub 1', the data can be installed in the main object container "/shell", where 'Sub1 'The object will be considered 'shell 1 / data 1 / sub 1'.

In an embodiment, all access to the object is an access policy management.

3.1. Reading objects

The value of the object can be read by calling System.Host.GetObject using the system. The four object types (integer, string, byte array, and container) that can exist in the database are directly mapped to the corresponding parts of the Plankton Virtual Machine Specification. Object values are accessed in the normal way and standard virtual names are implemented.

3.2. Create an object

Objects can be created by calling an object name that System.Host.SetObject does not already exist. Object creation is done according to system call specifications. When the object is created, the shell database:

‧Set the owner column of the object metadata to the ID of the identity of the executing program. This ID is URN. This is a true model specification for executing the system, which indicates how to determine the identity. Usually, it is tied to a digital signature, which is related to the code module, and the program is loaded by the code module.

‧ Set the metadata column to the current local time.

‧ Set the revision date column of the metadata to the current local time.

‧ Set the expiration date column of the metadata to 0 (not expired).

‧ Set the revision date of the parent container to the current local time.

When an object is created in a path that is deeper than the current container hierarchy, in one embodiment, the shell database would need to imply the creation of a container object that needs to be present to establish a path to the created object. Implicit container object creation Follow the same rules as explicitly stated.

For example, if there is a container "A" without a child, the requirement to set "A/B/C part of the object" before the establishment of "A/B/C part of the object" will imply the establishment of the container "A/B" and " A/B/C".

3.3. Write objects

The value of the object can be changed by calling an object that already exists in System.Host.setObject. If the specified object type does not match the type Id of the current object, then ERROR_INVALID_PARAMETER is returned. If the type Id is OBJECT_TYPE_CONTAINER, you do not need to specify any value (the object address should not be zero, but its value will be ignored).

When the current object is set, the date of modification of the shell data setting object is the current local time.

3.4. Destroy objects

An object can be explicitly destroyed by calling an object that has an object address value of 0 already present in System.Host.SetObject.

When the object is destroyed, the shell database:

‧ Set the modification date of the parent container to the current local time.

‧ If the destroyed object is a container, destroy all its sub-objects.

3.5. Object Metadata

Metadata for shell objects is called by using System.Host.GetObject and System.Host.SetObject systems with virtual names Access it.

The following table lists the standard and extended virtual names that can be used for objects in the Shell Database embodiment and how they are mapped to the Metadata column.

The metadata column is read-only and cannot be written.

4. Object ownership bar and access control

As long as a read, write, build, or destroy request is completed, the shell database implementation first checks if the caller has permission to perform the request. The policy governing access to objects is based on the identity of the person and the concept of delegation. In order to implement the policy, it is necessary to trust the representation of the model support authentication control program operated by the implementation method. This is typically done by having the planktonic code module include a digital signature of a private key of the PKI key pair and having a name certificate associated with a personal name associated with a signature key; however, there is still There may be different ways to determine the identity of the control program.

The access policy for objects in the shell database contains a few simple rules:

• If the identity of the caller is the same as the owner of the object or one of the object ancestor containers, the value of the read and write access object is approved.

‧ If the identity of the caller is the same as the owner of the container for the child, then the access is authorized to be established or destroyed.

‧ Reading and writing access to the metadata of the object (using the virtual name) follows the same policy as reading and writing access to the object value. It has other restrictions. It is a read-only column and cannot be Write.

When the database is created, the root container of the shell database is preferably fixed. When an object is created, its owner's metadata column is set to the identity of the caller. The ownership of an object can change. To change the ownership of an object, the value of the owner's metadata column can be set by calling the System.Host.SetObject system to call the object's '@Owner' virtual name.

Because, in an embodiment, the control program cannot access the object owned by the owner who is performing the identity of a control program, the control program needs to delegate access to the 'foreign' object to the code mode. The program loaded by the group, the code module has the ability to execute under the identity of the 'foreign' object owner. To do this, the control program can be called using the System.Host.SpawnVm, System.Host.CallVm, and System.Host.ReleaseVm systems in the plankton virtual machine.

Although the foregoing has been described in some detail in detail, it will be understood that It should be noted that there are various ways to implement the processes and apparatus described herein. Therefore, the present embodiments are to be considered as illustrative and not restrictive.

Figure 1 shows the group (Octopus) digital rights management (DRM) How the engine component acts within the network using DRM.

Figure 2 shows an example of a group node.

Fig. 3 is a view showing the relationship of the contents of the exemplified embodiment in the relationship between the articles in a license.

Figure 4 shows, in one embodiment, the components that make up the group as the main consumer application.

Figure 5 shows the use of an exemplary group API and the interaction between the host application and the DRM client engine that occur in the illustrated embodiment.

Figure 6 shows the components of a packaged application that is group-based in one embodiment.

Figure 7 shows the use of an exemplary API and the interaction between the host application and the suite engine.

Figure 8 shows the derivation of the diving key using the link in one embodiment.

Figure 9 shows various content protection and management objects in accordance with a group embodiment.

Figure 10 shows the various rule pieces, identity and key management objects.

Figure 11 shows the operating environment for an exemplary implementation of plankton VM.

Figure 12 shows the format of the illustrated planktonic code module.

Claims (12)

A method of authorizing access to an electronic content stored in a memory in a host computer system, the host computer system including a user interface, the memory, a processor, and a digital rights management engine loaded In the memory and executed on the processor, the method includes the steps of: receiving, from the user interface, a request from the user of the host computer system to access the electronic content of the piece; recovering from the memory a license for the electronic content, the license comprising a control object, a control object, a protector object, and a content key object; recovering a first control program from the control object; loading the first control program For the memory controlled by the digital rights management engine; and using the digital rights management engine to execute the first control program to determine whether the request can be approved, wherein executing the first control program includes evaluating the storage in the main One or a plurality of linked objects in the memory of the computer system, wherein each of the linked objects represents a relationship between two entities, wherein at least one or more of the linked objects Include a second control program, and evaluating the one or more linked objects includes: loading the second control program into a memory controlled by the digital rights management engine, the second control program indicating that the second control program must be implemented One or more conditions such that the link is considered valid; and using the digital rights management engine to execute the second control program to determine whether the link is valid, including determining whether the one or more conditions are full And wherein at least one of the one or more conditions comprises requiring that the counter stored in the memory does not exceed a predetermined value. The method of claim 1, wherein the control object is operable to securely bind the control object to the content key object. The method of claim 1, wherein the protector object is operable to securely bind the content key object to the piece of electronic content. The method of claim 1, wherein at least one of the one or more conditions comprises requiring the current time to be before a predetermined time. The method of claim 1, wherein at least one of the one or more conditions comprises requiring the current time to be after a certain time. The method of claim 1, wherein at least one of the one or more conditions comprises requiring the second control program to have not been previously executed for more than a predetermined number of times. The method of claim 1, wherein at least one of the one or more conditions comprises requiring a predetermined event not to have occurred previously. The method of claim 1, wherein at least one of the one or more conditions comprises requiring the host computer system to have one or more predetermined features. The method of claim 1, wherein at least one of the one or more conditions comprises requiring execution on the host computer system The software that depicts the piece of electronic content cannot output the piece of electronic content to a predetermined interface. A method of authorizing execution of a given action of electronic content stored in a memory in a host computer system, the host computer system including a user interface, the memory, a processor, and a digital rights management engine Loaded in the memory and executed on the processor, the method comprising the steps of: using the digital rights management engine to execute a first control program operable to determine whether to give The fixed action can be performed on the piece of electronic content, wherein the first control program is operative to evaluate one or more conditions of the first set, which must be satisfied such that execution of the given action is authorized, and wherein the first At least one of the set of one or more of the conditions includes a requirement, wherein the memory of the host computer system includes one or more linked objects, the one or more linked object links representing a first node of the first entity To a second node representing the second entity; retrieving one or more linked objects from the memory, each linked object representing a relationship between the two entities, and at least one linked object comprising a second a program, wherein the second control program is operative to evaluate one or more conditions that the second set must satisfy such that the at least one linked object is considered valid; and using the digital rights management engine to perform The second control program, wherein at least one of the first set of conditions or the second set of conditions comprises a counter that is required to be stored in the memory does not exceed a predetermined value. The method of claim 10, wherein the method One or more conditions of a group contain a time-based condition. The method of claim 10, wherein the one or more conditions of the second group comprise a time-based condition.