NZ763404A - System and methods for using cipher objects to protect data - Google Patents

Abstract

A system for improved security of computer systems, comprising a computer-readable medium having computer-executable instructions stored thereon, the instructions comprising a computer-based intelligent cipher transfer object comprising a digital mixture of a set of participants, said set of participants comprising owner data, one or more outer cloaking patterns configured to be applied to the set of participants such that an interim cipher object is created; and a portable dynamic rule set, said portable dynamic rule set comprising an identity module, an intelligence module, and one or more inner cloaking patterns, each inner cloaking pattern including (i) a transformation to be applied to some participants of the set of participants and (ii) a description for reversing the transformation; wherein, in response to execution by one or more processors of the system, the instructions cause the intelligent cipher transfer object to internally perform the steps of: receiving, from an external agent, a request to access some or all of the set of participants; attempting to verify that the external agent is authorized to access some or all of the set of participants as requested; and upon verifying that the external agent is authorized, providing access to some or all of the set of participants for which the external agent has been verified for access, without providing access to unauthorized portions of the set of participants.

Description

SYSTEM AND METHODS FOR USING CTPHER OBJECTS TO PROTECT DATA This application is a divisional ofNZ No. 726067 which claims priority of US.

Provisional Application No. ,617, filed April 17, 2014. The specifications, figures and complete disclosures of US. Application No. 61/980,617 and NZ 726067 are incorporated herein by this cross reference.

HELD 013‘ iNVEls-TTTGN This invention relates to a system and related s for protecting and controlling data using self—encryption and self~governaiice, including, but not limited to, the use of an intelligent cipher transfer object.

BACKGROUND 0? THE TNVENTEON Current techniques for protecting data have certain cks. When information is outside of a trusted environment, like a secure k, it is lly protected by tion in large part because other security measures, such as network 1AM and PAC applications, no longer govern use of the information. In current techniques, encryption keys must be present within an ation, or revealed or traded by users or via an application, for encrypted data to be useful, thereby ially compromising protection and confidentiality. Encryption keys can be stolen in a discovery or APT assault, or can be compromised via social engineering or other means, Further, once an encryption key (or rd) is shared and the data unlocked, control of the data is lost. Even when data is within a trusted nment, such as behind a firewall or the like, it is vulnerable to attack or misuse, as files are available to anyone with access to their storage location. Protecting information traditionally requires teams of people with expertise in networks, BYOD, telecommunication, servers and applications, integrating them all and coordinating efforts on an enterprise scale to achieve a level of security which nevertheless can be compromised by exploiting flaws and gaps inherent in complex integrations. l data encryption relies on algorithms that run in a predetermined sequence to encrypt and then run in the reverse sequence to decrypt. There may also be a process ofmoving pieces of data in a static pattern to cloak it, and then reversing the process to reveal the complete, unencrypted file. With this prior—art method, an attacker who understands the encryption algorithm used to encrypt data can break the encryption by reversing the encryption process.

Fully homomorphic encryption attempts to remove the trust aspect of a relationship, making trust between parties an irrelevant factor. For example, one party can send their data to an rcer for storage or processing Without ng what the outsourcer might do with it, as the outsourcer is only give-n access to an encrypted version of the data to perform processing that does not require decryption. However, fully homomorphic encryption is too cumbersome to be practical.

Another traditional que for protecting data is the use of dynamic controls. c controls are application dependent, such as rd protected PDF files generated and used by document viewing and editing software produced by Adobe®, or the like. Traditional dynamic controls are ent on the application or reside within an ation. Rules are executed by the application. While also ent on a key (password) exchange as given above, another drawback to this method is that application—dependent rules may be overridden (as in the example of a protected PDF opened with Adobe® Acrobat®) or, a developer could write an application that ignores the rules imposed by the authoring application.

Accordingly, what is needed is a data assurance solution that is rotecting and self—governing, that is less dependent on keys and passwords for authentication, on predictable reversible encryption sequences for protection, and on external applications for execution While remaining functional and efficient both Within and outside the secure environment, both for data at rest and in transit.

SUMMARY OF INVENTION This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This summary is not intended to identify key es of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed t matter.

In several ary embodiments, the present invention comprises a self- protecting, self—controlling intelligent cipher transfer object (ICTO), which may be stored on a er—readable medium. The ICTO comprises a set of participants ing portable dynamic rule set (PDRS). The PDRS, in response to execution by one or more processors or microprocessors of a computing device, causes the computing device to perform actions, ing, but not limited to, the following: receiving, from an agent, a t for access to a portion of a participant of the set of participants; verifying that the agent is authorized to access the requested participant portion; and ing access to the requested participant portion for the agent without providing access to other portions of the set of ipants for the agent. A er—irnplemented method of creating such an ICTO and a computing device configured to execute the executable portions of such an ICTO are also provided.

In one exemplary embodiment, the present invention comprises an lCTO— aware application, operating system, or device, including, but not limited to, computer chips, switches, controls , FGPAS, and the like, that activates the ICTO in response to a request for access. The ICTO comprises a set of participants including but not limited to owner data, and a PDRS. Upon activation of the dynamic participant controller (DPC) within the lCTO, remotely or locally, the PDRS within the ICTO takes and maintains control of the ICTO until the protected object is closed (i.e., inactive or asleep). The PDRS, responding to the agent access request, through the dynamic participant controller, to all or some of the participant data, verifies the agent is authentic and authorized to access all, some, or none of the ted data set. Upon verification, the agent can only access authorized portions of the protected data set while the remaining protected data within the ICTO remains inaccessible to the agent. A computer—implemented method of creating such an ICTO utilizing an ware application, operating system or device to activate the executable portions of such an ICTO is also provided.

In a further embodiment, a computer—implemented method of protecting a set of participants is provided. A set of participants to be ted is obtained by a computing device. One or more cloaking patterns for protecting the set of participants are determined. A first ng pattern is used to protect or mix a first subset of the set of participants, and a second cloaking pattern different from the first cloaking pattern is used to protect or mix a second subset of the set of participants. The ined cloaking patterns are applied by the computing device to the set of participants to create a set of cloaked or mixed participants. The set of cloaked participants are added by the computing device to an ICTO. A computing device configured to perform this method and a computer—readable medium having er—executable instructions stored thereon that, in response to execution by one to perform or more processors of a computing , cause the computing device such a method are also provided.

In yet another embodiment, the present invention comprises an ICTOv'iware application, operating system7 or device that facilitates this method for protecting a set of participants, A set of participants is gathered through an iCTQ-vaware appiication, operating system, or device to create an interim n ICTO, which includes a set of participants and a temporary or "starter" ruie set provided by the cipher engine or dynamic participant controiler until the ICTO is fully implemented. The interim pattern 31333:} is chaired by one or more ng ns dynamically selected or produced and applied by the dynamic participant controiler. The temporary rule set is subsequently replaced with one or nor" specific or unique rule sets as defined by the owner, one or more cloaidng patterns are dynamicaily and randomly selected or ed for each ECTO by the PDRS Within the HITS. Cioaldng patterns may be appiied ly to all or some n of the participants while additionai cloeiciig patterns may be applied randoniily to all or some portion of the participants to create a. unique cloaked set of participants for each iCTO. in another embodiment, a computing device configured to access data protected W‘s or governed by an lCTO is provided. An access request from an agent to access a portion of a participant stored or mixed in the lCTO is received by the computing device. A PDRS within the lCTO is activated by the computing . At least one rule in the PDRS is executed by the computing device to evaluate the access request. In response to determining that the access request is permissible, access to the n of the participant requested by the agent is provided without providing access to other participant portions.

In yet another embodiment, the present invention ses an [CFO—aware appiication. operating system or device. that activates the lCTO upon receiving an access Av-.vm_u4v,c‘v.uu 7‘7. request from an agent. The dynamic participant ccntroiler within the {CFO is activated, and upon activation the embedded PDRS takes and maintains control oi" the lCTO. At least one rule is of PDRS is executed to te the authenticity and authorization of the agent to recess all, some or none of the protected data. If the agent is granted access to ali or some of the protected data, the protected data not ized for access remains protected and not visible to the accessing agent. The inactive lCTO is inaccessible without an. il—aware application, operating system or device.

BRIEF DESCRIPTION OF THE DRAWINGS The foregoing aspects and many of the attendant ages of embodiments of the present disclosure will become more readily appreciated as the same become better understood by reference to the following detailed description, When taken in conjunction with the accompanying drawings.

Figure 1 shows a schematic diagram that illustrates an ary embodiment of data governance according to various aspects of the present invention.

Figure 2 shows a art that illustrates an exemplary embodiment of a method of constructing an lCTO according to various s of the present invention.

Figure 3 shows a flowchart that illustrates an exemplary embodiment of a method of accessing data protected by an ICTO according to various aspects of the present ion.

Figure 4 shows a schematic diagram that illustrates an exemplary use case for an embodiment of the present invention.

Figure 5 shows a schematic diagram that illustrates aspects of an exemplary worldlow for an ment of the present invention.

Figure 6 shows a block diagram that illustrates an ary hardware architecture of a computing device suitable for use with embodiments of the present invention.

Figure 7 shows a schematic diagram that illustrates an exemplary embodiment of data governance ing to another exemplary embodiment of the present invention.

Figure 8 shows a flow chart that illustrates a exemplary embodiment of creating an ICTO according to another exemplary ment of the present invention.

Figure 9 shows a flow chart that rates a exemplary embodiment of accessing an ICTO according to another exemplary embodiment of the present invention.

Figure 10 shows a view of a portable ty appliance system in accordance with another exemplary embodiment of the present invention.

Figure ll shows a diagram of a portable identity appliance used to produce a protected object.

Figure 12 shows a diagram of a portable identity appliance used to facilitate secure messaging of protected data.

Figure 13 shows a diagram of a portable ty appliance used to guard access to websites, portals, networks, or other ces.

DETAELED DESCRIPTION OF EXEMPLARY MENTS In several exemplary embodiments, the present ion comprises a self— contained, self—protecting, self—controlling intelligent cipher er object (ICTO), which may be stored on a computer—readable medium. The ICTO comprises a set of participants including a portable dynamic 1ule set (PDRS). Computer—implemented methods of creating, accessing, and using such an ICTO, and a computing device configured to execute the executable portions of such an ICTO, als o are ed.

In various embodiments, the present invention addresses critical faults with previous data protection systems and s. The present invention fills a gap in existing protection schemes because existing schemes address perimeter defenses, user access (both users and their devices) and anomaly detection, but are not attached to the data . If prior—art encryption is utilized, the burden of key code ment may reduce productivity or flaws may create yet other vulnerabilities by exposing keys that likewise need to be protected.

Embodiments of the present disclosure provide a self—contained, self—protecting, overning, data—centric solution, meaning that the controls for data management, protection, and administration are grafted into, and become part of, each data set and directly oversee the data set's access and use. Though, in some embodiments of the present disclosure, some data can be removed from protection for analysis or use by an authorized agent, the method of removal from protection is not predictable because it is not a reversal of the protection ism or mechanisms. The present invention comprises an unpredictable and irreversible system and associated methods to retain c, portable, independent, persistent, intelligent governance of data over the life of the data's existence. This system is capable of protecting data while the data is stored or in transit, and in the hands of trusted data users or untrusted data users.

In some embodiments of the present disclosure, the data protection scheme is lO embedded , grafted to, and maintained within the data—set. The data tion scheme may also create an audit trail of attempts to access the data. Known or authorized users of the data are noted in an embedded log, while unknown parties or other unauthorized attempts to access the data are likewise noted in the embedded log and can be transmitted and displayed to the data owner in real time. if an unauthorized l5 party attempts to access the data, the self—protecting data can defend itself, take offensive action t the intrusion, alert the data owner to the unauthorized attempt, and/or take any other appropriate action.

The data owner utilizes the protection scheme as a simple and lightweight ment tool that continuously validates the relationship of the parties to the data. From an attacker's point of View, the system is unpredictable because every authorized party has its established identity incorporated into the tion scheme.

A unique tion scheme may be provided for eachcombination of owner, user, and dataset; this means that the method by which data is revealed to Authorized Party A would not be the way data is revealed to Authorized Party B.

Further, the unique protection scheme that may be provided for a combination of owner, user, data set and rule set will likewise be unique to itself when the same combination is protected subsequent times. That is, each time a ation of described herein, whether it is the owner, user, data set and rule set is ted as same combination or a different combination, the ICTO will be a uniquely protected ICTO.

In some embodiments, different techniques may be used to protect the data and to access the protected data. For example, an irreversible protection scheme may be used to e multiple pieces of data into a single digital mixture, such that a selective retrieval scheme may be used to selectively retrieve pieces of data from the single digital mixture without obtaining access to other protected data in the digital e. In such an embodiment, when the data is properly accessed, it is selectively revealed, based upon the owner's wishes for the authorized recipient. The path to reveal information is not a function of retracing the al steps, and the original protection scheme used to combine the multiple pieces of data may not be reversible other than with respect to individually requested pieces of data. In other words, even though pieces of data stored by the protection scheme may be accessed, the totality of the digital mixture is not accessible in such a way that allows the totality of the original contents to be reconstituted. Embodiments of the present disclosure are configured to vely identify any user or entity identity such that is included as a participant as legitimate or not, and the data owner controls which ns or pieces of data to which the identified legitimate users can gain . Unauthorized parties, whether inside or external to the intended ent or the intended recipients network, can never access the data in its unprotected form, Embodiments of the present disclosure unequivocally confirm the identity of a trusted party before providing access to ensure data security.

Reversing or reverse ering the protection scheme cannot yield the original results.

In several embodiments of the present invention, rules are executed by an executable portion of the digital mixture, ensuring the absolute wishes of the data owner are enforced t relying on a third party or an outside entity or application or operating system. The tion scheme is not dependent on an application or an operating system to protect/unprotect the data: the data is self protecting and self—controlling. The protection scheme is independent of ing system, environment, and application (i.e., external or centralized or server key management, password ment and identity management applications). s in the protocol are implemented in executable code stored in the data mixture, and are executed in se to detecting a request by the user to access the data through a structured API. Furthermore, the data can be of any type (e.g., text, audio, video, or combination thereof), and in any kind of container, database or environment: (e.g., , ory, file, or combinations thereof). Any attempt to access the data other than through the API or other means described herein will be foiled by the applied cloaking patterns, which will be undeterminable by any component outside of or other than the components implementing the APT. When attempting to access the data through the API or other means described herein, the protection scheme ensures that legitimate users are only able to access data as permitted by the data owner.

Other methods ted through the APT, or other ICTO—aware application, device or operating , initially te the ICTO. Subsequently, the outer cloaking technology locates the executable code, cipher engine, or mixer stored in the l mixture. A request for access is received by the executable code via the APT or other ICTO—aware application, device or operating system on behalf of the agent. The executable code is zed, or "awakened," at which point the le dynamic rule set takes and maintains control until the self—governed data object is closed or becomes inactive. Any attempt to access the self—protecting, self— controlling digital mixture without energizing the executable code will be unsuccessful. is a schematic diagram that illustrates an exemplary embodiment of self— governing data according to various aspects of the t invention. A c participant controller 110, or "mixer," identifies a set of digital ingredients ("participants") 101, including descriptions of authorized agents, device ons, rules- for using the data, and/or other ingredients as discussed further below. By mixing these ingredients, the mixer 110 forms a cloaked entity, the intelligent cipher transfer object, or ICTO 115. The ICTO 115 may also be called a "digital mixture." As discussed herein, one of ordinary skill in the art will recognize that the terms "ICTO" and "digital mixture" and "self-governing data" may be used interchangeably. To an unauthorized entity or third party viewing the ICTO 115 directly, the ICTO 115 may simply appear to be a set of data. The ICTO 115 appears to the outside as a homogenous mixture without resembling or ng the original ingredients. However, when accessed via an application implementing the APT (such as the mixer 110, an ICTO-aware client application (not illustrated), and/or the like), executable portions of the ICTO 115 are accessible to provide access to the data governed by the ICTO 115.

In some embodiments, the executable portions of the ICTO 115 may be stored at a determinable on within the ICTO 115 to allow an application implementing the API to easily find the executable portions. In some embodiments, additional protection may be applied to the ICTO 115 by storing one or more executable portions of the ICTO 115 at variable locations within the ICTO 115..

While these variable locations make the executable portions of the ICTO 115 exceedingly difficult for an unauthorized user to find, an ICTO—aware application enting the API for ing the ICTO 115 may be able to compute the variable locations for a given ICTO 115 based on a feature of the ICTO 115. For example, the secure application may read an attribute of the ICTO 115 such as a file size, a creation time, and/or the like, and may m a calculation that determines the location using the attribute as a seed. By keeping the details of the calculation secret, the on of the executable portions of the ICTO 115 can likewise be kept secret.

The set of participants 101 may include object descriptions 102, mixture metadata 104, owner data 106, cloaking patterns 107, an identity module 109, and an intelligence module 111. In some embodiments, a combination of the identity module 109 and the intelligence module 111 may be considered together as a portable c rule set 108. The object ptions 102 may include owner—supplied and owner— defined earmarks, ,data identifiers, andlor properties. Owner data 106 may includedata that is to be protected within the ICTO 115, such as a document, a file, a buffer, a directory, a pointer to remotely stored data, database, and/or the like, In some embodiments, owner data 106 may be optional, if the ICTO 115 is merely used, for example, for a signature verification method that is not associated with underlying signed data. In some embodiments, multiple pieces of owner data 106 may be included within a single ICTO 115. In some embodiments, owner data 106 from le owners may be included within a Single ICTO 115.

The cloaking ns 10'7 specify various combinations of data protection and access techniques supported by the mixer 110. The data protection and access A V4. VVHVAUI VA-(v'ruu techniques included in cloaking patterns 107 may include techniques such as industry standard verified encryption, compression, randomization, normalization, and/or other techniques. Techniques suitable for use as ng patterns 107 are not limited to currently known ques, but could e any privately or publicly available encoding and/or decoding que, known now or developed in the future. Use of a cloaking pattern 107 to protect and/or access data may involve applying the combination of data protection and/or access techniques specified in the ng pattern 107 to the data.

The mixture metadata 104- provides organizational infonnation for the digital mixture 115, such as virtual file system data containing directories, key codes, user files, signatures, and/or the like.

The identity module 109 may include dynamic identity attributes that ly identify protected agents in a transaction. In some embodiments, the identity module 109 may include data that represents a configuration of a computing device that may be given certain rights with respect to a protected object. The identity module 109 may contain specific information about hardware or software configurations installed on the computing device usable to identify the computing device. The identity module 109 may contain data including, but not limited to, CPU information including model numbers, number of cores, speed, and/or the like; a chassis serial number; cturer data; a volatile memory size; a non-volatile memory size; one or more storage device serial numbers and/or model numbers; led software titles and/or version numbers, and/or the like.

In some embodiments, a ction is an atomic action using the ICTO 115 in which one or more agents securely exchange data within a given context and with a specified intent, ized agents may include human and non—human entities, such as a human user, aunique mechanical object, a unique electronic object, a unique software or program object, and/or the like. Dynamic identity attributes contained in the ICTO 115 may be ed by the intelligence module 111 within or during the course of an interaction with the ICTO 115, and may include application— specified identifiers, account identifiers, biometric ures, device and/or location signatures, al data, cryptographic keys, and/or the like. In some embodiments, a location signature may include data from a ation logy, such as GPS, GSM network locating, IP address locating, dead reckoning, and/or the like. The location signature may e a longitude, latitude, an de, an approximate street address, and/or the like. Additional location data such as street, city, state, country, postal code, and/or the like may also be present. In some embodiments, the al data may include a timestamp and/or the like, which may allow rules or other intelligent code to enforce timers, expirations, dynamic keys, and/or the like. The temporal data may include a simple date/time value, or may include a complex schedule comprising timestamp ranges and/or other scheduling guidelines.

In some ments, each ICTO 115 includes at least one digital signature key. The digital signature key may be validated using an external digital icate available to the mixer 110. During access of the ICTO 115, the mixer 110 validates the digital signature key using the external digital certificate and verifies that the digital signature key is valid for an agent tly accessing the ICTO 115. In some embodiments, le agents nray sign off on the ICTO 115. In such an embodiment, the ICTO 115 may include a chain of signature keys, wherein each signature key may be associated with a separate external digital certificate for validation. For example, an ICTO 115 may be used by an owner to create a protected file for a transfer to multiple agents wherein each agent may access different ns of the file but not the entire file, either simultaneously or sequentially. Both the owner and the agents may have to provide valid digital sig— natures to allow the transaction to proceed.

The intelligence module 111 may include dynamic rule sets capable of recording and communicating access data and other relevant history; along with intelligent code that provides configurable functionality for performing actions to protect the ICTO 115.

Rules may be provided at object creation time. However, in some embodiments, a rule may have a capability to modify itself or other rules for a previously created ICTO 115. In some embodiments, a rule may have a lity to create additional rules. For example, a rule may determine, from identity data, that additional protection is desirable for a given ICTO 115. The rule may then create additional encryption and/or 3O decryption rules to be applied. The rules are protected and contained within the ICTO 115. In some embodiments, the rules may only be able by an executable portion of the intelligence module 111, and/or may be written in a proprietary language and stored in com— piled or binary form. Based on the rules and requirements of the identity module 109, the intelligence module 111 acts on its rules and requirements.

Application—specified identifiers may vary from access to access, and may vary depending on a type of agent. For example, for a human user, application-specified identifiers may include t keys, transaction information, context keys, associated intents, and/or the like. For an electronic object, a digital asset, or any other potential agent, application~specified identifiers may also include an IP address, a URL, a file specification, and/or the like.

In some embodiments, the embedded portable dynamic rule set or sets have read/write access to the embedded participants 101, even while the ipants 101 are ted by the ICTO 115. In other words, a rule may read and write data to the mixture nretadata 104 and the owner data 106 of the ICTO 115. This may be useful for recording access information such as date, time, place, and the like, and/or to destroy the data if an attack is detected. Some examples of decisions nrade or actions taken by intelligent code within rules may include, but are not limited to: evaluating object content and context for validity; challenging an agent for proof of identity; cting with client code; contacting a server for validation; causing the ICTO 115 to self—destruct; ining a history of object access and sending the history information to a server; allowing on—line and/or off—line object access; creating new rules based on dynamic server updates; encrypting and ting data; mangling and 111mlangling demand/gr the like.

The use of portable dynamic rules may have various benefits. For example, pre~ encryption and pre—decryption rules may provide dynamic salt and encryption keys based on participant—specified criteria. Such c keys may be based on al data, environment data, or any other algorithm specified in a pie—encryption rule. As another example, rules may access encrypted identity artifacts within the ICTO 115 in order to validate the agent without exposing unprotected data to unauthorized users. As yet another e, because the rules are le and are therefore included within the ICTO 115, rules may be n in such a way as to allow the ICTO 115 to be fully protected from unauthorized access even when ne or out—of—network. As a further example, rules may add nested protection. If the ICTO 115 protects a document that is meant to be read by a single agent within one hour of creation, a rule may implement the timer and issue a self—destruct mechanism.

As stated above, the embedded mixer 110 uses an embedded portable dynamic rule set 108 to form a mixture of the object descriptions 102, the mixture metadata 104, the owner data 106, the cloaking patterns 107, the ty module 109, and the igence module 111 that comprises a self—protecting, self—governing lCTO 115. In some embodiments, various components of the lC‘TO 115 may be marked by encoded checksums to detect tampering. For e, the entire ICTO 115, the rules, the owner data, and/or the user data may each be validated by an embedded checksum. The checksum may be a hash value generated based on the contents of the um . In some embodiments, the algorithm used to generate the checksum is sensitive enough to reliably detect a change of a single bit value of even a large data-set. Some suitable algorithms include MDS and SHA, though any other suitable algorithm may be used. Each checksum may be appended, prepended, or otherwise combined with the checksum target for storage, or may be stored in a separate location. is a schematic diagram that illustrates another exemplary embodiment of self-contained, self—controlling, self—governing data protection according to additional embodiments of the present ion. An AM or other lCTO—aware application, , or operating system initiates a request to the dynamic participant controller or executable mixer 702, thereby zing it, to protect a set of digital participants 701. Digital participants include, but are not limited to, authorized agents, devices? locations, rules for using the data, and/or other digital ingredients as discussed r below, gathered for inclusion in the self—protecting, overning data object (i.e., digital mixture, or ICTO) 710. The dynamic participant controller 702, when energized, creates an m cipher object 703 utilizing a temporary or "starter" rule set while said object is being ucted. The interim cipher object 703 is cloaked using one or more outer cloaking patterns 704 selected, created or produced by algorithms generated by the mixer 702. 3O In some cases, additional protection or functions, or combinations thereof, may be applied by storing one or more executable portions of the lCTO 710 at variable locations within the ICTO 710. The initial entry point for the executable portions of the ICTO 710 can only be calculated and located by an ICTO aware application, operating system or device. Once the executable or DPC 702 is located and awakened, a unique table of offsets is made available to the DPC 702 to locate the portable dynamic rule set 711 within the ICTO 710 which takes and maintains control while the ICTO 710 is active.

The set of digital participants 701 may include, but are not limited to, outer ~—*#mcloakingpattems 704‘, mixture metadata 705, owner data 706, inner cloaking patterns 707, an identity module 708, and an intelligence module 709. In some ments, a ation of the inner cloaking patterns 707, the identity module 708 and the intelligence module 709 can be considered together as the portable dynamic rule set (PDRS) 711. Owner data 706 that is to be protected within the ICTO 710 and governed by the PDRS 711, may include a number of data types, including, but not limited to, an image, a video, a message, an email, a nt, a file, a buffer, a ory, a pointer to remotely stored data, a portal, and the like. In several embodiments, owner data 706 may be optional and thus not included, such as when the ICTO 710 is merely used, for e, as an irrefutable and certain ure cation method. In some embodiments, multiple pieces of owner data may be mixed into a single ICTO 710. In other embodiments, owner data from multiple owners may be included in a single ICTO 710. In further embodiments, multiple ICTOs could be mixed into a single ICTO.

The inner cloaking patterns 707 specify various combinations of data protection and access techniques determined by the owner’s rules set forth in the portable dynamic rule set 711 and supported by the dynamic participant controller or mixer 702.

The data protection and access techniques included in the inner cloaking patterns 707 may include, but are not limited to, techniques such as industry rd encryption, proprietary encryption, compression, ization, normalization, and the like. Techniques suitable for use as inner cloaking patterns 707 are not d to currently known techniques, but could include any privately or publicly available encoding and/or ng techniques, known now or developed in the future. Use of an inner cloaking pattern 707 to protect and/or access data may involve applying the combination of data protection and/or access ques specified in the portable dynamic rule set 711 to the data and other ipants.

The outer cloaking patterns 704 specify various combinations of data protection and access techniques selected h one or more algorithms calculated, used, or d by the dynamic participant controller 702 utilizing the interim rule set to create the interim cipher object 703. The data protection and access techniques included in the outer cloaking patterns 704 may include, but are not limited to, techniques such as industry rd verified encryption, compression, randomization, ization, and the like. Techniques suitable for use as outer cloaking patterns 704 are not limited to currently known techniques, but could include any privately or publicly available encoding and/or decoding que, known now or developed in the future. Use of an outer cloaking pattern 704 to protect and/or access data may involve applying the combination of data tion ated by the dynamic participant controller 702 and specified by the interim rule set. The mixture metadata 705 provides organizational information for the digital mixture 710, such as, but not limited to, virtual file system data containing directories, user files, and the like.

The ty module 708 may include dynamic identity attributes that uniquely identify legitimate agents in a transaction. Dynamic identity attributes can be learned information that are added to the identity module within the PDRS such as, but not limited to, location, device, and access behavior. Learned information is ted and can be utilized in a future access request session, thereby adding additional intelligence and decision points. Additionally, dynamic identity attributes can also be iler(ie_a,,, unpredictable) details. They may be presented during the authentication process, alone or in conjunction with personal ty attributes, in the determination of mate identification of an agent requesting access to an lCTO.

In some embodiments, the identity module 708 may include data that represents a configuration of a computing device that may be given certain rights with respect to a protected object. The identity module 708 may contain specific information about hardware or re configurations installed on the computing device usable to identify 3O the computing device. The identity module 708 may contain data including, but not limited to, CPU information including model numbers, number of cores, speed, and/or the like; a chassis serial ; manufacturer data; a volatile memory size; a non— volatile memory size; one or more storage device serial numbers and/or model numbers; installed software titles and/or version numbers, and/or the like.

In several embodiments, a transaction is an atomic action using the ICTO 719 in which one or more mate and authorized agents securely exchange data or ation within a given context and with a ied intent.

Legitimate, authorized agents may include human and non~human entities, such as a human'user,auniquemechanical *objectfa unique electronic object, a unique software or program object, or the like. Dynamic identity attributes contained in the ICTO 718 may be modified by the intelligence module 709 within or during the course of an interaction with the ICTO 710, and may include, but are not limited to, application— specified identifiers, account identifiers, biometric signatures, device and/or location signatures, temporal data, crypto-graphic keys or data, and the like. In some embodiments, a location signature may include data from a geolocation technology, such as GPS, GSM network locating, IP address locating, dead reckoning, and the like.

The on signature may include a longitude, latitude, an altitude, an approximate street address, and the like. Additional location data such as street, city, state, country, postal code, and the like may also be present. In some embodiments, the temporal data may include a timestamp or similar information, which may allow rules or other intelligent code to e timers, expirations, dynamic keys, and the like. The temporal data may include a simple date/time value, or may include a complex schedule sing timestamp ranges and/orether scheduling guidelines, ,, In some embodiments, each ICTO ’710 may include one or more digital signature requirements, human or non—human. During authentication by the ICTO 710, the portable dynamic rule set 711 ines the digital signature to be valid for a mate, agent requesting access to information governed by the PDRS 711. In some ments, multiple legitimate agents may verify the authority of other legitimate agents. In such an embodiment, the PDRS 711 may enforce a chain of digital ure requirements, wherein each digital signature may be associated with a separate 3O legitimate agent. For example, an ICTO 710 may be used by an owner to create a self— ing file for als, ure and transfer to multiple legitimate agents wherein each legitimate agent may access different sections of the file but not the entire file, either simultaneously or sequentially. Both the owner and the legitimate agents may have to provide valid digital signatures to allow the transaction to proceed.

The intelligence module 709 may include dynamic rule sets capable of recording and communicating access data and other relevant events; along with intelligent code that provides configurable functionality for performing actions to govern the ICTO 710.

Rules may be provided at object creation time. However, in some ments, a rule may modify itself or other'mlespf a given ‘10instancet In some embodiments; a rule may create additional rules. For example, a rule may ine, during tication of a mate agent, that additional tion is desirable for a given ICTO 710. The rule may then create additional access, defensive, cloaking and the like requirements. In some embodiments, the rules may only be executable by the dynamic participant controller 702, or may be stored in a binary form as a participant of the ICTO, or a combination thereof. Based on the rules and requirements of the identity module 708, the intelligence module 709 acts on its rules and requirements as supplied by the owner agent. Portable dynamic rule set 711 identifiers may vary from access to access, and may vary depending on a type of agent. For e, for a human user, portable dynamic rule set 711 specified identifiers may include account keys, transaction information, context keys, associated intents, and the like. For an electronic object, a digital asset, or any other potential agent, portable dynamic rules set 711 identifiers may also e an IP s, a URL, a file specification, and the like.

In some embodiments, rules have read/write access to "the digital participants 701, even while the digital participants 701 are protected by the ICTO 710. In other words, a rule may read and write data to the mixture metadata 705 and to the owner data 706 of the ICTO 710. This may be useful for recording access information such as date, time, place, and the like, and, in some cases, to destroy the data if an attack is detected. Some examples of decisions made or actions taken by the intelligence module 709 may include, but are not limited to: evaluating object t and context for validity; challenging an agentfor proof of identity; interacting with client code; ting a server for verification of trust; causing the ICTO 710 to self~destiuct; maintaining a history of object access and sending the history information to a server, by email, SMS, FTP or stored with the ICTO 710; allowing on—line and/or off—line object access; creating new rules based on dynamic server updates; cloaking and de—cloaking data; and mangling and unmangling data.

The use of said portable dynamic rule sets 711 has various benefits and purposes, In one exemplary embodiment, access rules may utilize internally created, intern ally managed, unique keys based on owner~specified criteria. Said unique keys may be based on temporal data, environment data, or any other algorithm specified by an owner’srule set. As another example, said rules may access protected identity artifacts within the ICTO 7710 in order to authenticate and validate the agent without l0 ng the protected data to the world. As yet another example, because said rules are self—contained, portable, platform independent and are therefore included within the ICTO 710, rules may be written in such a way as to allow the ICTO 710 to be fully protected from unauthorized access even when off line.

As a further example, rules may add nested protection. If the ICTO 710 protects one or more lCTOs 710 within the current or outer ICTO 710, the outer ICTO 710 may be able to communicate with one or more of the ICTOs 710 d as part of the owner data 706 of each. Where the outer ICTO 710, or vice—versa, can cause the ion of rules managed within any of the ICTOs 710 included in the owner data 706 of the Outer ICTO 710 or create new rules as a result of rules contained in one or more of the included ICTOs 710. Another example, the rules self—contained within the PDRS 711 of an ICTO 710 are self—governing. If the ICTO 710 protects a document that is meant 'to be accessed__by a single legitimate agent one hour of creation, fora m of ,1, one hour after , a rule may ent the timer and issue a self—destruct mechanism after expiry.

As previously described, the c ipant ller 702, or mixer, utilizing a portable dynamic rule set 711 creates a mixture of the outer cloaking patterns 704, mixture ta 705, the owner data 706, the inner cloaking patterns 707, the identity module 708 and the intelligence module 709 that makes up the ICTO 710. In some embodiments, various components of the ICTO 710 may be combined for 3O encoded checksums to detect tampeiing. For example, the entire ICTO 710, the rules, the owner data, and/or the participant data may each be validated by a checksum 712., The checksum 712 may be a hash value generated based on the contents of the checksum ’712 targets. - In some embodiments, the thm used to generate the checksum is sensitive enough to reliably detect a change of a single bit value of even a large document. Some suitable thms include MDS and SHA, though any other suitable algorithm may be used. Each um 712 may be appended, prepended, or otherwise combined with the checksum target for storage, or may be stored in a separate location. ,,,,,7% FIG; 2 is a flowchart that illustrates an exemplary embodiment of a method 200 of constructing an ICTO 115 ing to various aspects of the present invention.

While the illustrated method 200 describes creation of a relatively simple ICTO 115, one of ordinary skill in the art will understand that similar techniques may be used to create much more complex ICTOS 115. In some embodiments, the mixer 110 is ured to perform the method 200. In some embodiments, the method 200 is performed by a computing device, as described below, that is configured to provide the functionality of the mixer 110. One of ordinary skill in the art will recognize that the construction and utilization of the ICTO 115 is neither dependent on the type of said computing device nor on any operating system associated with said computing device, but may instead by constructed and utilized via any suitable means.

From a start block, the method 200 proceeds to block 202, where a set of common digital ingredients or participants is obtained. The contmion participants are participants 101 which may be used in more than one ICTO 115, or may at least have similar corresponding ents in more than. one ICTO 115, and _.are_spe_cified... and/or generated by the mixer 110 for inclusion in the ICTO 115. For example, the object descriptions 102, the mixture metadata 104, the cloaking patterns 107, the identity module 109, and the intelligence module 111 may all be common participants. Next, at block 204, a c participant controller r") 110 is initialized. In some embodiments, initializing the mixer 110 may include verifying that the mixer 110 is being executed by an expected or ise trusted application.

At block 206, the mixer 110 receives one or more pieces of owner data 106 to be 3O protected. As discussed above, in some embodiments the owner data 106 may be optional, and the access protection es of the ICTO 115 may be used to verify user identities and/or obtain signatures from users.

The method 200 proceeds to block 208, where the mixer 110 causes a portable dynamic rule set 108 to be executed. At block 210, an intelligence module 111 of the portable dynamic rule set 108 determines one or more ty—based cloaking patterns to be used to protect participants 101, and at block 212, the mixer 110 applies the one or more cloaking patterns to the participants 101, creating a set of d participants.

The portable dynamic rule set 108 determines a cloaking n to be applied to each participant 101 based on the desires of the owner of the data to be protected.

Different cloaking patterns may be d to each participant 101. Further, each participant 101 may be protected using te cloaking patterns for access by different agents. In other words, a participant 101 such as owner data 106 may be protected by a first cloaking pattern for access by a first agent, and protected by a second cloaking pattern for access by a second agent. The selection of cloaking ns may be based on an attribute of the participant 101 to be ted, an attribute of the agent to be given access to the data, a location, an intent, and/or any other suitable piece of information. Selection of a cloaking pattern may include selecting from a pre— existing cloaking pattern, and/or may include creating a new cloaking pattern from a combination of protection techniques supported by the mixer 110. s of the applied ng patterns may be stored in the mixture metadata 104.

Cloaking patterns describe transformations applied to a participant 101 to protect the participant 101 within the ICTO 115, and how those transformations may be ed to access the participant 101. The transformations may include, but are not limited to, data ssion, data normalization, and encryption/decryption. A given cloaking n may include one or more of these techniques, or other techniques not listed here. Data compression may reduce the overall size of the ICTO 115, which may in turn improve transport times and bandwidth usage. Data compression may be performed by any suitable lossless compression algorithm including, but not limited to, DEFLATE, LZW, LZR, LZX, JBIG, DjVu, and/or the 3O like. Data normalization is performed by any suitable process that places the data in a form that may efficiently be processed. In some embodiments, the data may be passed through a Baseé4 encoding algorithm to convert the data, whether binary or text format, into a normalized alphanumeric string. This is an example only, and should not be seen as limiting. In other embodiments, other algorithms may be used to normalize the data.

In some embodiments, a cloaking pattern may cause the identity module 109 and the intelligence module 111 to apply separate encryption techniques to different components of the participants 101. For example, a first tion rule, when executed, may identify and encrypt a first portion of the encrypted digital mixture 115 while g a second portion of the encrypted l mixture 115 ged. A second encryption rule, when executed, may then identify and encrypt the second portion of the encrypted digital mixture 115 using a different encryption algorithm, a different encryption key, and/or the like.

In some embodiments, the cloaking patterns and/or the le dynamic rule set 198 may establish two or more nested layers of encryption. For example, execution of a first encryption rule may encrypt a first n of the encrypted digital mixture 115. Execution of a second encryption rule may then cause the encrypted first portion of the encrypted l mixture 115 to be encrypted again, along with the first encryption rule and a corresponding first tion rule.

Hence, to later access the first portion of the encrypted digital mixture 115, a second decryption rule corresponding to the second encryption rule is executed to decrypt the doubly encrypted first n of the ted digital e 115 and to obtain the first decryption rule. The first decryption rule is then executed to decrypt tliefifirst portion of the encrypted digital mixture 115 to generate a plaintext version of the first portion of the digital mixture 115..

Once the cloaking patterns have been applied to the participants 101 to create the set of cloaked participants, the method 200 proceeds to block 214, where the mier 110 creates a digital mixture (ICTO) 115 and adds the set of cloaked participants to the digital mixture 115. In some ments, additional protection may be applied to the digital mixture 115 as a whole, such as shuffling of the data, 3O additional encryption or digital signatures, and/or the like. The method 200 then proceeds to an end block and terminates.

One of ordinary skill in the art will understand that n steps have been omitted from for ease of discussion. However, other steps not explicitly illustrated in may also be included in the method 200 without departing from the scope of the present disclosure. For example, if any errors are detected while applying the cloaking patterns or executing rules, the method 200 may stop, and may not produce a completed ICTO 11§.As another example, in some ments, the owner data 106 may e one or more ICTOs as a way of providing nested ' protection? In some embodiments, ruleswithinea nested IGTO’ may be provided with access to participant data 101 within the outer ICTO 115. In some embodiments, a rule within a first ICTO may cause a second ICTO to be created, and cause the first ICTO to be added to the second ICTO such that the first ICTO is nested inside of the second ICTO. Likewise, in some ments, a rule within a first ICTO may cause a second ICTO to be created, and cause the second ICTO to be added to the first ICTO such that the second ICTO is nested inside of the first ICTO. is a process flow that illustrates an alternative ary embodiment of a method 800 of constructing an ICTO 710 according to various aspects of the t invention. The method 800 shown describes the creation of a simple ICTO 710', however, utilizing similar techniques one may construct a complex ICTO. In some embodiments an ICTO—aware application, device or operating system is ured to initiate and facilitate the method 800. The construction and utilization of an ICTO 710, simple or complex, is not dependent on a specific operating system or device.

From Start 801, the method 800 begins with initialization 802 of the Dynamic Participant ller 702 or mixer. In some embodiments, initialization of the mixer 802 may include validation that the object is an authentic ICTO and/or that the request to initialize is from an lCTO—aware application, device, operating system or other ICTO— aware process. Proceeding to block 803, a set of digital participants 701 is provided to the mixer 702 for inclusion in the ICTO 710. The digital participants 701 may be used in more than one ICTO 710, or may at least have similar or common components in more than one ICTO 710. For example, the outer cloaking patterns 704, the mixture 3O metadata 705, onal cloaking patterns 707, the identity module 708, and the intelligence module 709 may all be considered common l participants 701.

Proceeding to block 804, the mixer 702 utilizing one or more algorithms selects one or more outer cloaking patterns 704 to be applied to the set of digital participants 701 utilizing an interim rule set to create the initial cloaking patterns for the ICTO 710, creating the initial interim cipher object 703. Proceeding to block 805, one or more owner data ts are added to the digital participants set for inclusion in the ICTO 710. In some embodiments, owner data 706 may be optional, and the access protection functionality of the ICTO 710 may be ed to verify legitimate agent —--'—identities*and/or*for legitimate agent signatures.

The method 800 proceeds to block 806, Where the owner’s rules are obtained from the PDRS 711 and utilized by the mixer 702 to replace the interim rule set initially used in the creation of the ICTO 710. Proceeding to block 807, utilizing one or more algorithms the mixer 702 selects one or more inner cloaking patterns 707 to be applied to some or all of the digital ipant set 701, inclusive of the owner data 706. The algorithms utilize time as a unique number and owner rules to further randomize the inner cloaking patterns 707. The thms used are added to the identity module 708, managed internally by the PDRS 711 and not shared externally. y in block 808 the mixer 702 completes the construction of the lCTO 710 creating a set of cloaked digital participants 720. While similar or common digital participants 701 may be utilized as provided in 803, in combination, the method will create a unique digital mixture 808 for each ICTO 718 constructed.

The mixer 702 using one or more algorithms determines which inner cloaking patterns 5.707 are to be applied to each 7digital participant 701 "(1111931130 randomly applying time as a unique number and other internal factors generated by the intelligence module 709. The thms ed by the mixer 702 to select the inner cloaking patterns 707 are then added to the identity module 708, managed internally and not shared/exchanged/exposed externally of the ICTO 710. Each participant 701 may be ted utilizing one or more inner cloaking patterns 707 that may be ly different from one or more inner cloaking ns 707 protecting other participants 701 in the l mixture 710. For example, a participant such as the owner data 706 may be protected with one or more cloaking patterns and internal rules that are ly different than the one or more inner cloaking patterns 707 and internal rules utilized to protect the identity module 708. Further, utilization of one or more inner cloaking patterns 707 and the random use of time as a unique number and internal rules in turn creates unique cloaking patterns that are added to the identity module 708 for each participant 701, The internal rules embedded in the intelligence module 708 may include but are not limited to such things as location, time, authorization requirements, and the like.

The inner cloaking patterns 707 describe transformations applied to a ipant 701 to protect the participant 701 within the ICTO 710, and how some of ' access parts or all of the participant 701., The —-—-- —transformations may be ed to ormations may include, but are not limited to, data compression, data normalization, and tion. A given inner cloaking n 707 may include one or more of these techniques, and/or other techniques. Data compression may reduce the overall size of the ICTO 710, which may in turn improve transport times and dth usage. Data compression may be performed by any suitable lossless compression algorithm including, but not limited to, DEFLATE, LZW, LZR, LZX, IBIG, DjVu, and/or the like. Data normalization is performed by any suitable process that places the data in a form that may efficiently be sed. In some embodiments, the data may be passed h a Base64 encoding algorithm to convert the data, whether binary or text , into a normalized alphanumeric string. This is an example only, and should not be seen as limiting. In other ments, other algorithms may be used to normalize the data.

Inner cloaking patterns 707 may also include one 01' more encryption techniques.

The 91Oakillg patterns may, Spégify Illethods cf deriving encryption keys, may_s_p.e.cify..___...__.__ ,, particular encryption algorithms, such as, but not limited to, NIST or FIPS, other proprietary encryption algorithms, or key lengths, or may specify other configurable options such as time seeds, Xor encoding, or other industry standard encoding and decoding techniques for generating elements of the cloaking scheme, or combinations thereof. In some embodiments, tion techniques may perform operations or calculations other than encryption, such as deriving a hash value for the referenced t or the like. In some embodiments, the inner cloaking pattern 707 may store (or may contain rules that require storage of) a record of an encryption key or decryption key used, either in the inner cloaking pattern 707 itself or elsewhere within the ICTO 710, managed internally and not shared externally. When the inn er cloaking pattern 707 is used to access the protected information, the cloaking/de—cloaldng algorithm(s) and keys are maintained internally and provided to the c participant controller 702 within the ICTO 710 to provide access to the information, but are not available to the requesting agent or any other agent or application, device, operating system external to the ICTO 710. In other words, the ng/de—Cloaldng algorithms and keys are not stored or exposed outside of the ICTO 710, are not made available to any agents, and so there is no need for external key management functions, thus no vulnerabilities there from and their secrecy is maintained, In some embodiments, the rules set forth in the intelligence module- 709 may cause the mixer 702 to apply separate inner cloaking patterns 707 to separate components of the participants 701. For example, a first rule, when executed, may identify and apply a cloaking pattern to a first n of the protected digital mixture 710 While leaving a second portion of the protected digital mixture 710 unchanged. A second rule, when executed, may then fy and apply a ng pattern to the second portion of the protected digital mixture 716 using a different cloaking pattern with a different pattern, or the like.

In some embodiments, the intelligence module 709 of the portable c rule set 711 may e two or more nested layers of cloaking of some or all of the participants 701. For example, ion of a first rule by the mixer 702 may cloak a first portion of the ted digital mixture 710. Execution of a second rule by the 1mm "70291615! then cage the Olgalied firstpcrtign thlrernrgtected.digitalmixture .. 719 to be cloaked again using a different inner cloaking pattern 707, along with the first rule and a corresponding first cloaking rule. Hence, to later access the first n of the protected digital mixture 710 a second de—cloaking rule corresponding to the second rule is executed to de—cloak the nested cloaked first n of the protected digital mixture 710 and to obtain the first de—cloaking rule. The first de— cloaking rule is then executed to de—cloak the first portion of the protected digital mixture 710 to generate a plaintext version of the first portion of the digital mixture 3O 710.

Once the inner cloaking patterns 707 have been applied to the participants 701 to create the set of d participants 720, the method 800 proceeds to block 8%8, where the mixer 702 tes the construction of a digital mixture (Lei, ICTO) 710. In some embodiments, additional protection may be applied to the digital mixture 710 as a whole, such as shuffling of the data, additional cloaking and/or the like. The method 800 then ds to an end block and terminates.

Other steps not itly illustrated in may also be included in the method 800 without departing from the scope of the present disclosure. For example, if any anomalies are detected while applying the cloaking patterns or executing rules, the method 806 may stop, and may not produce a ted ICTO 7199 As another example, in some embodiments, the owner data 7&6 may include one or more ICTOs as a way of providing nested protection. In some embodiments, rules within a nested ICTO may be provided with access to participant data 701 within the outer ICTO 710. In some embodiments, a rule within a first ICTO may cause a second or multiple ICTO(s) to be created, and cause the first ICTO to be added to the second ICTO such that the first ICTO is nested inside of the second ICTO. Likewise, in some embodiments, a rule within a first ICTO may cause a second ICTO to be created, and cause the second ICTO to be added to the first ICTO such that the second ICTO is nested inside of the first ICTO. is a flowchart that illustrates an exemplary embodiment of a method 300 of accessing data protected by an ICTO 115 according to various aspects of the present sure. After the ICIQ 7115, is activated,_the ICTO 7115 beginsyerification if, and tion of its current environment, access attempts, authorized agents, and other conditions as specified in the rule set included in the portable dynamic rule set 108.

This verification and tion may be performed once upon p, continuously during an active period, periodically during an active period, or at any other suitable interval or in response to any suitable change in state. When rules and agent identity have been positively med, the ICTO 115 permits access to authorized portions of itself while maintaining the homogenous essence of the mixture and protection of the rest of the data.

As with the method 200 described above, in some embodiments the mixer 110 is configured to perform the method 300. In some ments, the method 300 is performed by a computing device if one or more sors of the computing device execute computer executable instructions that cause the computing device to do so. As understood by one of ordinary skill in the art, the construction and utilization of the ICTO 115 is neither dependent on the type of said ing s nor on any operating systems associated with said computing devices. The data protection protocol —~—-~—is—embedetedfl"n-the-data set. An activated ICTO 115 can communicateewith the data owner (information such as access attempts, alerts to unauthorized locations or unauthorized agents, notification of self-destruct or self—recreation) over the life of the data. Further, because the rules in the TCTO 115 may update themselves and other portions of the ICTO 115, the ICTO 115 may learn from its environment, and may change its future or based on that ng. The protection protocol can be customized and is unique to each owner, data set, and user combination, as specified in cloaking patterns.

From a start block, the method 300 proceeds to block 302, where a portable dynamic rule set 108 within a digital mixture 115 is activated in response to a request by an agent to access the digital mixture 115. In several embodiments, a super— ty is embedded in the TCTO 115 and includes ia to verify an identity of an agent attempting to access the ICTO 115, dynamic rules to provide an intelligent awareness that validates the agent and determines the data‘s current state, and algorithms for data cloaking as specified in cloaking patterns. Verification criteria such as nge/response pairs, l signatures, ric information, and/ or the like may be used to verify the identity of the agent. At block 304, the portable dynamic rule set 108 is executed to verify that the agent is allowed the requested access to the digital mixture 115 in a nt context. The identity module 109 and the intelligence module 111, when activated, assess the current access attempt by the verified agent and establish a level of trust. In some embodiments, this assessment is an on—going process, in that there is a continuous verification and validation of each participant 101: the data owner, the agent (data user) and the data itself. In some embodiments, pre access rules from the portable dynamic rule set 108 may be executed by the mixer 110 to decrypt at least some portion of the ICTO 115 for internal use by the mixer 11% without allowing access to the decrypted data to agents other than the mixer 110. Pre—access rules have access to the ipants 101, including the ability to test identity artifacts and evaluate owner and agent data. If the trust level goes down, the proto col reassesses the ipants 101. In some embodiments, if the agent attempting to access the ICTO 115 is unable to re— establish their legitimacy, defensive or offensive actions may be invoked. It the " WW *agen’risrableto-satisfy the new set of challenges, access will be d to proceed or continue.

In some embodiments, the pre—access rules are merely allowed read access to ty or authentication data, but in some embodiments, the pre—access rules may also have write access, which may be used, for example, to record access attempt attributes when opening (or attempting to open) the lCTO 115.

The method 300 proceeds to block 306, where the portable c rule set 108 determines a cloaking pattern used to protect the ted data. The portable dynamic rule set 108 consults the mixture metadata 104 to determine which cloaking pattern 1%7 was applied based on the identity of the agent, the data request, the t in which the data is being requested, and/or the like. Once the used cloaking pattern 107 is determined, the method 300 proceeds to block 308, where the cloaking pattern 107 is used to provide the requested access to the agent. Similar to how the cloaking n 107 indicated a set of techniques used to protect the requested data, the cloaking n 107 also indicates a set of techniques used to reconstruct the requested data from the protected version stored in the ICTO 115. The method 300 then proceeds to an end block and terminates. is a process flow that illustrates an alternative embodiment of a method 900 of accessing data protected by an ICTO 710. After the ICTO 710 is ted, the PDRS 711 begins verification and validation of the ICTO’s 710 current environment, access attempts, legitimate agents, and other ions as specified in the PDRS 711.

This verification and validation process is inherently efficient, ensures the integrity of the data and may be performed once upon startup, continuously during an active period, periodically during an active period, or at any other suitable al or in response to any suitable change in status or state. When rules and legitimate agent identity have been positively confirmed, the PDRS 711 permits access to authorized portions of ICTO 710 while maintaining the homogenous essence of the mixture and protection of the rest of the participants. In some embodiments, an lCTO-aware application, device or operating system is configured to initiate and facilitate the method 900.

From a start block 901, the method 900 proceeds to block 902, where the * dynamicparticipant'controilerqfii Within the protected digital mixture or ICTO 710 is energized by an ware ation, , or operating system in response to a t by an agent to access the l mixture or ICTO 710. In some embodiments, the owner/agent identity and/or one or more agent identities are included in the identity module 708 embedded in the ICTO '710 and includes criteria to verify the identity, authenticity and legitimacy of an agent ting to access the ICTO 710, dynamic rules to provide an intelligent awareness that tes the legitimacy of the agent and determines the data's current state, and algorithms for data cloaking as specified in ng patterns. Verification ia such as challenge/response pairs, external authorizations, biometric information, and/ or the like may be used to authenticate, validate and/or verify the identity of the agent. At block 903, utilizing the portable dynamic rule set 711, the requesting agents are verified in an efficient, 2O full, complete and relevant context and granted access to the digital mixture ’710.

The method 900 proceeds to block 904, where the portable dynamic rule set 777,11 provides the dynamic ipant cgntrcller 702 one or more cloaking patterns" used to protect the requested data based on the identity of the agent, the data request, the context in which the data is being requested, and the like. Proceeding to block 905, the DPC or mixer 702 on instruction from the portable dynamic rule set 711 de—cloaks some or all of the protected data within the ICTO 710 based on the data owner’s rules for the legitimate agent, the data request, the context in which the data is being requested, and/or the like managed by the portable dynamic rule set 711.

Other steps not explicitly illustrated in may also be included in the 3O method 900 without departing from the scope of the present disclosure. For example, if any anomalies are detected while applying the decloaking patterns or executing rules, the method 900 may stop, and may not allow access to the protected lCTO 710. Another example, the method 900 may determine legitimacy of a requesting agent to ICTO 710 which may cause external authorizations to be required prior to completion of authorization of the legitimate agent. Additionally, alerts may be sent as a result of legitimate and authorized access to the ICTO "710.

As another example, in some embodiments, the method 900 may determine that unauthorized access is being attempted which may cause the PDRS 711 within the lCTO 710 to send alerts, record access attempts and/or the like. In 'flllOtlISl"€X31IIPl€Tlfl‘SOIII6""’"7 * * ments, the method 900 may determine an unauthorized access attempt is underway, and enable access to false data in the ICTO 710, recording activity, g alerts and/or the like. Alerts include, but are not d to, failed access attempt, unrecognized access address (which can include device and on specifics), le violations, unauthon'zed movement of an ICTO, and the like.

Accordingly, the t invention results in an lCTO that is self—contained, self— controlling, and self—governing. All access rights, rules of ment, compliance rules, audit requirements, and similar iules and ctions as determined by the data owner are contained in the PDRS, and embedded in the lCTO, and thus lled on behalf of the data owner by the PDRS (whether online or offline, control is maintained from within the ICTO), and executed by the PDRS. The PDRS is the means for self—governance and control upon creation and throughout the life of the ICTO. It travels with the lCTO, complies at all times with the rules established by the data owner, and can be adaptive ,(i.e., dynamic), based on, but not limited to, the environment (such as place, time, and device), so to self manage and make decision based on learned information. The PDRS does not require any outside sources (cg, IAM or STEM systems) or specific operating environments to maintain control and governance. The PDRS controls the complete management of the ICTO from within the lCTO. The PDRS is permanently embedded in the ICTO and travels with the ICTO, thereby ng a self—contained, self—controlled, self—governing entity. is a tic diagram that illustrates an exemplary use case for an embodiment of the present disclosure. One of ordinary skill in the art will recognize that this use case is exemplary only and is described to show certain features of the disclosure, but that this use case does not utilize or describe every feature of the technology disclosed herein. In a first user 418, using a first computing device 416, uses an embodiment of the t disclosure to protect a first piece of data (data one 404) and a second piece of data (data two 406). An ICTO 408 is d that includes a protected version of data one 410 and a protected version of data two 412. In creating the lCTO 408, the first user 418 specifies that a second user 422 may access data one 404, but does not specify that the second user 422 may access data two 406. Hence, the 16176408 includes a rule inzits portable dynamic rule set 108 that allows user two 422, once verified, to access data one 404.

The first computing device 416 transmits the ICTC 408 to a second computing device 420 used by the second user 422 via a network, such as a LAN, a wireless network, the et, and/or the like. The second user 422 causes the ICTO 408 to be ted, and s a request 424 to access to data one 404. The ICTO 408 verifies the identity of the second user 422, which may include processing a challenge/ response pair stored in the ICTO 408 and/or consulting a trusted service 409 (such as a certificate server, a RADIUS or other authentication server, and/or the like) to verify that the second user 422 is who he purports to be. Once the identity of the second user 422 is verified, the ICTO 408 consults the cloaking pattern used to create protected data one 410, and uses the ng pattern to give the second user 422 access to data one 404. The second user 422 may also submit a request 426 to access data two 406. However, because the ICTO 408 has not been instructed to prOVide access to data two 406f9rt116 second user422, the S does not allow the second user 422 to access data two 406.

In an alternate process flow, a first computing device 416 transmits an ICTO 408 to a second computing device 420 used by the second user 422 via a network, such as a LAN, a wireless network, the internet, and/or the like. The second user 422 utilizing an ICTO aware application, device or operating system awakens the ICTO 408 which receives a request to access ted data one in the ICTO 408. The ICTO 408 verifies the identity of the second user 422, which may include processing of multiple pairs of challenge/ response stored in the ICTO 408 and/or external authorization or the like to verify that the second user 422 is valid and authorized.

Additionally a trusted service 409 may be used for further tion of time, physical location and the like based on the rules of access set forth by owner 418. Once the identity of the second user 422 is verified (i.e., established as authentic and legitimate), the ICTO 408 determines the one or more cloaking patterns used to create protected data one 410, and decloaks the protected data one 410 revealing data one 404- to the second user 422, The second user 422 may also request to access protected data two 412. However, because the second user 422 is not ized to access protected data two in the lCTO 408,. "the second user 422, is not granted access to theeprotecte‘d*data'tyvcr412."* Though a trusted service 409 that es authentication services is described, other types of trusted services may be used. For example, if a rule is included the ICTO 408 that only allows access during a given time period, a trusted e 409 that provides a trusted date—time value may be used. As another example, a trusted service 409 may seek input from other users while the ICTO 408 is determining whether to grant access to an agent. As illustrated, a trusted service 409 may notify the first user 418 of the access attempt via email, SMS, or any other suitable teclmique, and may wait to allow the attempted access until a corresponding approval is received from the first user 418.

This use case illustrates several advantages of the t disclosure. Once the ICTO 408 is created, protected data one 410 and protected data two 412 cannot be accessed without ng the processing of the ICTO 408 to request . ingly, the data is protected when the ICTO 408 is stored on the first computing device416, when the VICTVO 408 is in transit on the network 402, andwhenthe ICTO 408 is stored on the second computing device 416. Also, even though the ICTO 408 provides access to the second user 422 to data one 404, data two 406 is heless protected from access.

While this simple use case illustrates several features of the present disclosure, much more complex use cases are also possible. For example, is a schematic m that illustrates aspects of an exemplary workflow for an embodiment of the present disclosure. A first user ("User A") may have a set of documents ("Documents X, 3O Y, and Z") to be approved and signed, maintaining confidentiality throughout the transaction, by a second user ("User B"), a third user ("User C"), and a fourth user ("User D"). Document X needs to be signed by User B. nt Y needs to be signed by User B and User C, but only after Document X has been signed. nt Z needs to be signed by User D, but only after nts X and Y have been signed.

Further, Document X and nt Y must be signed during working hours (eg, between 9 AM and 5 PM) to ensure compliance with local corporate policy,, while Document Z (the working draft of Doc Y) must be signed immediately upon approved signatures of Doc X and Y, the audit logged, and then Doc Z destroyed, with the audit also logged. - - ---------—- Embodiments of the present disclosure will support such a ow, User A creates an ICTO that includes Documents X, Y, and Z. User A creates an access rule for Document X that allows User B to review and sign Document X. User A creates an access rule for Document Y that allows User B and User C to review and Sign Document-Y once the signature on Document X is obtained. User A may create an access rule for Document X that allows User C to review Document X to check for a ure, or the access rule for Document X may detect the signature applied to Document X, and may dynamically update the access rule for Document Y that allows it to be signed once the signature is detected. User A creates an access rule for Document Z that checks for signatures on Documents X and Y, and upon detecting such signatures, User D is allowed to sign Document Z. Each of these rules also enforces the associated time requirements, and does not allow access if the time requirements are not satisfied. User A may also create a rule that reports any access to any of the documents back to User A, so that User A mayflmonitor the process. Eachpf the rules _.___ _ may specify how each user is to be identified, the d privileges, devices from which the users are allowed to access the documents, and ons from which the users are allowed to access the documents.

Once, for example, User B receives the ICTO, User B invokes an application ured to activate the executable code within the ICTO. The executable code determines the identity of User B, either by consulting a trusted identity service, by checking the response to a challenge ed in a rule, or by any other method. Once 3O the identity, time, location, and other requirements are satisfied, User B is allowed to access Document X, but not any of the other documents. After User B signs Document X, the ICTO is transferred to the next user, and enforces the protections on the documents as the ICTO passes through the rest of the workflow.

Alternatively, for example, User B receives the ICTO, User B s an TCTO aware application, which activates the PDRS within the lCTO. The executable code determines the identity of User B by utilizing the identity credentials stored within the ICTO which presents le challenge/response pairs and /or external authorizations codes. Once the identity, time, location, and other requirements are satisfied,"User"B"iSWa’llowed *to 'aC'ceSS'"BO'crrment ' not *any of the other documents. After User B signs Document X, the ICTO is transferred to the next user, and es the protections on the nts as the ICTO passes through the rest of the workflow.

In another exemplary embodiment, protection protocol is uted in a portable ty appliance (PIA). The PTA s a le and discrete digital identity using an instinctive and autonomic authentication method. The PIA ultimately ents an incorporated lCTO ol, thus becoming an intelligent object itself. In several embodiments, the PTA is an ICTO that does not include owner data (e. g., files, images, and the like). The PIA comprises an ICTO that utilizes the PDRS along with additional publically available information (similar to the information available on a business card or in a public directory) about the owner, but without necessarily containing owner data. the PTA thus is a self—protecting, self—controlling, self~governing ICTO with the purpose of representing, iii'efutably, the owner identity.

As seenin Figures 107—173, e protected PTA is created, it can combine wit_1_i__ data to produce a protected data object, facilitate the transmission of secure message between one or more s (e. g., validating and maintaining sender and receiver legitimacy and data integrity), and provide a secure, trustworthy identity that can be used to assure or guard es, portals, networks, or other resources.

The PIA thus present numerous advantages over existing signature techniques.

Existing signature techniques are typically based on certificates that are purchased from a certificate authority. Certificates are presumed trustworthy based on who holds the cert and who issues the cert. However, certificates can be stolen, can he spoofed, and are not based on a uniquely defined identity, Thus, a lCTO may be used for irrefutable verification of identity where a "signature" is required Signature lCTOs can be ed as external identity verification in conjunction with an ICTO containing legal documents requiring absolute verification of ty. The ure lCTO(s) can become part (embedded) of the "final" legal documents contained within the original ICTO. Further, ure lCTOs can be included within the ICTO (i.e., nested) as additional protected data elements in addition to the owner documents requiring signature, thus pre—defining and providing rification of the required si-gners—tr‘aveling—withfihe—documentsfi—S’ignature'lCTOs also can be used as " irrefutable verification of ty in documents that are not included in an ICTO but rather in an ICTO aware application. For example, they can be used to provide acceptance of Terms and Conditions electronically, or acknowledgement of privacy notices.

Signature ICTOs in the context of document signing can be thought of as a digital version of the owner that has been "legally verified and notarized," but also is irrefutable.

Each Signature ICTO, just like an ICTO with owner data, is unique and therefore cannot be "spoofed" by a person or entity trying to pretend to be the actual owner of the Signature ICTO. Additionally, a Signature ICTO does not have to represent a human; it can represent a machine, whereby a digital process flow requires signatures (verifications) along the way in order to confirm the validity of the authorization to proceed; and this signature must be documented. Signature lCTOs can be used anywhere a rd digital signature is required today, but are not limited to just how digital signatures are used today, As sed above, in several embodiments there must be lCTO—awareness as a quisite for use.

One of ordinary skill in the art will recognize that the above use cases are exemplary only, and that many other use cases for the subject matter disclosed herein are possible. For example, because the portable dynamic rule sets include executable code, the ICTO may protect executable t that is only executable upon satisfying the security checks of the ICTO. Also, since the ICTO may execute such content in response to the success or failure of any rule, the ICTO may log 3D successful accesses or take action such as alerting a data owner, ting a self— destruct sequence, or other actions upon ing an unauthorized access attempt.

Alternatively there are many other use cases for the subject matter disclosed herein. For example, because an ICTO includes executable code for independent self—management, the ICTO may protect content that is only accessible upon satisfying the security checks and miles of access set forth by the data owner contained within the ICTO. Also, the lCTO, in response to the success or failure of any rule, may log such accesses and/or take action such as alerting a data owner, initiating a self~destnrct sequence, or other actions upon detecting an unauthorized access A _r_. _____ . . >-. ._. ____ _ _ ._. a ... a ,_ __a.ttempt. is a block diagram that illustrates an exemplary hardware ecture of a computing device 500 suitable for use with embodiments of the present disclosure.

Those of ordinary skill in the art and others will recognize that the computing device 500 may be any one of any number of currently available or yet to be developed devices including, but not limited to, desktop computers, server computers, lap top computers, embedded computing devices, application specific integrated ts ('ASle), srnartphones, tablet computers, and/or the like. in its most basic configuration, the ing device 500 includes at least one processor 502 and a system memory 5M: connected by a communication bus 506. Depending on the exact configuration and type of device, the system memory 504 rnay be volatile or nonvolatile memory, such as read only memory ("ROM"), random access memory ("RAM"), , flash memory, or similar memory technology. Those of ordinary skill in the art and others will recognize that system memory 504- typically stores data and/01' program modules that are immediately accessible to and/or tly being operated on by the processor 502. In this , the processor 502 serves as a computational center of the computing device 500 by sup porting the execution of instructions.

As further illustrated in the ing device 500 may include a network interface 510 comprising one or more components for communicating with other devices over the network. Embodiments of the present dis closure may access basic services that utilize the network interface 510 to perform communications using common net work protocols. In the ary ment depicted in the computing device 500 also includes a e medium 508. However, es may be accessed using a computing device that does not include means for persisting data to a local storage medium. ore, the storage medium 508 depicted in is represented with a dashed line to indicate that the e medium 508 is optional. In any event, the storage medium 508 may be volatile or atile, removable or nonremovable, implemented using any technology capable of storing information such as, but not limited to, a hard drive, solid state drive, CD ROM, DVD, or other disk storage, magnetic cassettes, ic tape, magnetic disk e, and the like.

As used herein, the term "computer readable media" includes le and ,7 *vewenonvolatiie and’removab'le*andnonrem'ovabl'e'media’implemented’in any method or" logy capable of storing information, such as computer readable instructions, data structures, program modules, or other data. In this regard, the system memory 504 and storage medium 508 depicted in are merely examples of computer readable media.

Suitable implementations of computing devices that include a sor 502, system memory 504, communication bus 506, storage medium 508, and network interface 510 are known and cially available. For ease of illustration and because it is not important for an understanding of the claimed subject matter, does not Show some of the typical components of many computing devices. In this regard, the computing device SM) may include input s, such as a keyboard, mouse, microphone, touch input device, and/or the like. Similarly, the computing device 5&0 may also include output devices such as a display, speakers, printer, and/or the like. Since all these devices are well known in the art, they are not fidescribed further herein. , Thus, it should be understood that the embodiments and es described herein have been chosen and described in order to best illustrate the principles of the invention and its practical applications to thereby enable one of ordinary skill in the art to best utilize the invention in various embodiments and with various modifications as are suited for particular uses contemplated. Even though specific embodiments of this invention have been described, they are not to be taken as exhaustive. There are several variations that will be apparent to those skilled in the art.

Claims (16)

1. A computer system having improved security of data, the system comprising: a k interface configured to communicate with at least one other computer system over a computing network and configured to receive a computer-based intelligent cipher transfer object comprising: a digital mixture of a set of ipants, said set of ipants comprising: owner data; one or more outer cloaking patterns configured to be applied to the set of participants such that an interim cipher object is created; and a portable dynamic rule set, said le c rule set comprising an identity module, an intelligence , and one or more inner cloaking patterns, each inner cloaking pattern ing (i) a transformation to be applied to some participants of the set of participants and (ii) a description for reversing the transformation; at least one processor coupled to the network interface and configured to cause the intelligent cipher transfer object to internally perform the steps of: receive, from an external agent, a request to access some or all of the set of participants; and , using the portable dynamic rule set, that the external agent is authorized to access some or all of the set of participants as requested; and upon verifying that the external agent is authorized, providing access to some or all of the set of participants for which the external agent has been verified for access, without providing access to unauthorized portions of the set of ipants.

2. The system of claim 1, wherein the portable dynamic rule set is located at variable locations within the intelligent cipher transfer object.

3. The system of claim 1, wherein the intelligence module is located at variable locations within the intelligent cipher transfer object.

4. The system of claim 1, wherein the portable dynamic rule set includes at least one rule that identifies which external agents may access some or all of the set of participants, and a context in which a particular external agent may access some or all of the set of participants.

5. The system of claim 4, wherein the context in which a particular external agent may access some or all of the set of participants comprise one or more of the following: a time period, a on, or an identity of a computing device.

6. The system of claim 1, wherein the set of participants further comprise mixture metadata.

7. The system of claim 6, wherein the e metadata includes ation which inner or outer cloaking pattern or patterns are used to access each participant of the set of participants.

8. The system of claim 1, further wherein the intelligent cipher transfer object internally ms the steps of: upon failing to verify that the external agent is authorized, executing at least one rule in the portable dynamic rule set, wherein the at least one rule causes one or more of: the intelligent cipher transfer object to self-destruct; a message or alert to be sent to the data owner; or a record of the access request to be stored in the intelligent cipher transfer object.

9. The system of claim 1, further wherein the igent cipher transfer object internally performs the steps of: upon providing access to some or all of the set of ipants for which the external agent has been verified for access, executing at least one rule in the le dynamic rule set, wherein the at least one rule causes one or more of: a message or alert to be sent to the data owner; a record of the access request to be stored in the intelligent cipher transfer objects; a signature of the requesting agent to be associated with the requested participant or participants; or at least one rule in the portable dynamic rule set to be added, ed, or deleted.

10. The system of claim 1, wherein the intelligent cipher transfer object is nested within a second intelligent cipher transfer object.

11. The system of claim 10, wherein the inner cloaking patterns are used to cloak the owner data, identity module, intelligence module, or ations thereof.

12. The system of claim 10, wherein the second intelligent cipher transfer object is nested within one or more additional intelligent cipher transfer objects.

13. A computer system having improved security using digital signatures or verifications, the system comprising: a network interface configured to communicate with at least one other computer system over a computing network and configured to receive a self-governing, self-controlling, self-protecting personal identity appliance, said personal identity appliance comprising a computer-based intelligent cipher transfer object comprising a digital mixture of a set of participants, said set of participants comprising: one or more outer cloaking patterns configured to be applied to the set of ipants such that an interim cipher object is created; and a portable dynamic rule set, said le c rule set sing an identity module, an intelligence module, and one or more inner cloaking patterns, each inner ng n including (i) a transformation to be applied to some participants of the set of participants and (ii) a description for reversing the transformation; at least one processor coupled to the network interface and configured to cause the igent cipher transfer object to internally m the steps of: receive, from an external agent, a t to access some or all of the set of participants; and verify, using the portable dynamic rule set, that the external agent is authorized to access some or all of the set of participants as requested; and upon verifying that the external agent is authorized, providing access to some or all of the set of participants for which the external agent has been verified for access, without ing access to unauthorized portions of the set of participants.

14. The system of claim 13, wherein the portable dynamic rule set is located at variable locations within the igent cipher transfer object.

15. The system of claim 13, wherein the intelligence module is located at variable locations within the intelligent cipher transfer object.

16. The system of claim 13, wherein the inner cloaking patterns are used to cloak the identity module, intelligence module, or combinations thereof.