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

Abstract

Systems, methods, and apparatus configured to build and utilize an intelligent cipher transfer object are provided. An intelligent cryptographic transfer object contains a set of participants protected by cloaking patterns. A portable dynamic rule set comprising executable code for managing access to a set of protected participants is included in the intelligent password delivery object. For a given user, an intelligent cryptographic transfer object can provide access to some of the participants while barring access to others based on a portable dynamic rule set within it.

Description

SYSTEM AND METHODS FOR USING CIPHER OBJECTS TO PROTECT DATA

This application also claims priority to U.S. Provisional Application No. 61/980,617, filed on April 17, 2014, and is entitled in whole or in part as of the filing date for priority. The specifications, drawings, and complete disclosures of US Provisional Application No. 61/980,617 are incorporated herein by specific reference for all purposes.

field of invention

The present invention relates to systems and related methods for protecting and managing data using self-encryption and self-management, including but not limited to the use of an intelligent cryptographic transfer object.

Current data protection technologies have certain drawbacks. Once the information is outside a trusted environment, such as a secure network, the information is typically protected largely by encryption, as other security devices such as network IAM and PAC applications no longer manage its use. In current technologies, for encrypted data to be useful, encryption keys must reside within the application or be exposed or exchanged by or through the application, thus potentially compromising protection and confidentiality. Encryption keys may be discovered or stolen in an APT attack or may be negotiated through social engineering or other means. Moreover, once the encryption key (or password) is shared and the data is unlocked, control over the data is lost. Even if the data is within a trusted environment, such as behind a firewall, the files are available to anyone who has access to their storage location, making the data vulnerable to attack or misuse. Information protection typically involves teams of people with expertise in networks, BYOD, telecommunications, servers, and applications, unifying them all to achieve a level of security, and coordinating efforts at an enterprise scale. However, this level can be compromised by exploiting the flaws and gaps inherent in complex integrations.

Typical data encryption relies on algorithms operating in a predetermined sequence to encrypt and then operating in the reverse sequence to decrypt. There may also be a process that moves the data pieces in a fixed pattern for cloaking the data pieces, and then reverses the process to reveal the perfect decrypted file. In this prior-art method, an attacker who knows the encryption algorithm used to encrypt the data can crack the encryption by reversing the encryption process.

Fully homomorphic encryption attempts to remove the trustworthy aspect of a relationship, rendering trust between parties irrelevant. For example, one party may transmit their data to a fiduciary for storage or processing without trusting what the fiduciary can do with their data, which may cause the fiduciary to perform processing that does not require decryption. This is because only access to the encrypted version of the data is provided. However, fully homomorphic encryption is too cumbersome to implement.

Another conventional data protection technique is to use dynamic controls. Dynamic controls are application dependent, such as password protected PDF files created and used by document viewing and editing software created by ^{Adobe ® and the like.} Conventional dynamic controls are application dependent or exist within the application. Rules are executed by the application. Although it also relies on key (password) exchange as described above, another disadvantage of this method is that application-dependent rules can be overridden (as in the example of a protected PDF opened with ^{Adobe ®} Acrobat ^{®), or that the developer} It is possible to write applications that override the rules imposed by

Thus, while self-protecting, self-managing and maintaining functionality, it is less dependent on keys and passwords for authentication, on reversible encryption sequences for predictable protection, and on externally executing applications, There is a need for an efficient data assurance solution for data at rest and in transit within and outside a secure environment.

This summary is provided to introduce a selection of concepts in a simplified form that is further described below in the Detailed Description. This Summary is not intended to represent key features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

In some exemplary embodiments, the present invention comprises a self-protecting, self-controlling intelligent cipher transfer object (ICTO), which may be stored on a computer-readable medium. The ICTO includes a set of participants including a portable dynamic rule set (PDRS). In response to execution by the one or more processors or microprocessors of the computing device, the PDRS causes the computing device to perform operations including, but not limited to: from an agent, a set of participants. receiving a request for access to a portion of one of the entries; verifying that the agent is authorized to access the requested portion of the participant; and providing the agent access to only the requested portion of the participation, without providing the agent access to other portions of the set of participants. A computer-implemented method of generating such an ICTO and a computing device configured to cause executable portions of such an ICTO to be executed are also provided.

In one exemplary embodiment, the present invention provides an ICTO-aware application (ICTO), including but not limited to computer chips, switches, control panels, FGPAs, etc., that activates an ICTO in response to a request for access. -aware application), operating system, or device. ICTO includes a set of entries including but not limited to owner data and PDRS. When a dynamic participant controller (DPC) in the ICTO is activated remotely or locally, the PDRS in the ICTO takes and maintains control of the ICTO until the protected object is closed (i.e., deactivated or dormant). The PDRS, which responds to an agent access request to some or all of the participant data via the dynamic participant controller, verifies that the agent is genuine and authorized to access some or all of the protected data set or has no access to it. . Once verified, the agent can only access authorized portions of the protected data set, while the rest of the protected data in the ICTO remains inaccessible to the agent. A computer-implemented method of creating such an ICTO utilizing an ICTO-aware application, operating system, or device to activate 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. The set of participants to be protected is obtained by the computing device. One or more cloaking patterns for protecting the set of participants are determined. The first cloaking pattern is used to protect or blend a first subset of the set of participants, and a second cloaking pattern different from the first cloaking pattern is used to protect or blend a second subset of the set of participants . The determined cloaking patterns are applied to the set of participants by the computing device to produce a set of cloaked or mixed participants. The set of cloaked participants is added to the ICTO by the computing device. Also provided is a computing device configured to carry out the method and a computer-readable medium having stored thereon computer-executable instructions that, in response to execution by one or more processors of the computing device, cause the computing device to perform the method.

In another embodiment, the present invention includes an ICTO-aware application, operating system, or device that utilizes this method to secure a set of participants. A set of participants is assembled via an ICTO-aware application, operating system, or device to create an intermediate pattern ICTO, which, until the ICTO is fully implemented, is driven by a cryptographic engine or dynamic participant controller. It includes a set of provisional or “starting” rules and a set of entries provided. The intermediate pattern ICTO is clocked by one or more clocking patterns that are dynamically selected or created and applied by the dynamic participant controller. The temporary rule set is replaced with one or more specific or unique rule sets later defined by the owner, and one or more cloaking patterns are dynamically and randomly selected or generated for each ICTO by the PDRS within the ICTO. The cloaking patterns can be applied randomly to some or all of the parts of the participants while additional cloaking patterns are randomly applied to some or all of the parts to create a unique cloaked set of entries for each ICTO. can be applied as

In yet another embodiment, a computing device configured to access data protected or managed by an ICTO is provided. An access request is received by the computing device from an agent wishing to access a portion of an entry stored or mixed in the ICTO. The PDRS in the ICTO is activated by the computing device. 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 allowed, access to the part of the participant requested by the agent is provided without providing access to other parts of the participant.

In yet another embodiment, the present invention includes an ICTO-aware application, operating system, or device that activates an ICTO upon receipt of an access request from an agent. The dynamic participant controller in the ICTO is activated, and when activated, the embedded PDRS takes and maintains control of the ICTO. At least one rule in the PDRS is executed to evaluate the authentication and authorization of an agent, which may or may not have access to some or all of the protected data. Once an agent has been allowed to access some or all of the protected data, the protected data that is not authorized for access remains protected and is invisible to the accessing agent. A disabled ICTO is inaccessible without an ICTO-aware application, operating system, or device.

BRIEF DESCRIPTION OF THE DRAWINGS The preceding aspects and many attendant advantages of embodiments of the present disclosure will be more readily appreciated as they become better understood when taken in conjunction with the accompanying drawings with reference to the following detailed description.
1 is a schematic diagram illustrating an exemplary embodiment of data management in accordance with various aspects of the present invention;
2 is a flow diagram illustrating an exemplary embodiment of a method for configuring an ICTO in accordance with various aspects of the present invention.
3 is a flow diagram illustrating an exemplary embodiment of a method of accessing data protected by an ICTO in accordance with various aspects of the present invention;
4 is a schematic diagram illustrating an exemplary use case for an embodiment of the present invention;
5 is a schematic diagram illustrating aspects of an exemplary workflow for an embodiment of the present invention;
6 is a block diagram illustrating an exemplary hardware architecture of a computing device suitable for use with embodiments of the present invention.
Fig. 7 is a schematic diagram showing an exemplary embodiment of data management according to another exemplary embodiment of the present invention;
Fig. 8 is a flowchart showing an exemplary embodiment of generating an ICTO according to another exemplary embodiment of the present invention;
Fig. 9 is a flowchart illustrating an exemplary embodiment of accessing an ICTO according to another exemplary embodiment of the present invention;
Fig. 10 is a diagram showing a view of a portable identity appliance system according to another exemplary embodiment of the present invention;
11 shows a portable identity appliance used to create a protected object;
12 is a diagram illustrating a portable identity appliance used to facilitate secure messaging of protected objects;
13 illustrates a portable identity appliance used to monitor access to websites, portals, networks, or other resources.

In some exemplary embodiments, the present invention comprises a self-contained, self-protecting, self-controlling Intelligent Cryptographic Transfer Object (ICTO), which may be stored on a computer-readable medium. The ICTO includes a set of participants including a Portable Dynamic Rule Set (PDRS). Computer-implemented methods of creating, accessing, and using such an ICTO and a computing device configured to execute executable portions of such an ICTO are also provided.

In various embodiments, the present invention addresses critical deficiencies with conventional data protection systems and methods. Because existing protection schemes address premises defenses, user access (both users and their devices), and anomaly detection, but not the data itself, the present invention fills the gap in existing protection schemes. fill in When prior-art encryption is utilized, the burden on key code management reduces productivity, or defects in the exposure of keys that likewise need to be protected may create another vulnerability.

Embodiments of this disclosure provide a self-contained, self-protecting, self-managing, data-centric solution, in which controls for data management, protection, and management are grafted onto each data set and Being part of it means directly overseeing the access and use of data sets. In some embodiments of this publication, some data may be released from protection for analysis or use by an authorized agent, but since the method of releasing protection is not the protection mechanism or the reverse of the mechanisms, the prediction is unpredictable. impossible. The present invention encompasses unpredictable and irreversible systems and associated methods for maintaining dynamic, portable, independent, continuous, intelligent data management over the life of the data existence. The system can protect data when it is stored or in transit, and when it is in the hands of trusted or untrusted data users.

In some embodiments of the present invention, the data protection scheme is embedded, grafted, and maintained in the data-set. This data protection scheme can also create an audit trail for attempts to access data. Known or authorized data users are recorded in the embedded log, while unknown parties or other unauthorized attempts to access the data are likewise recorded in the embedded load but can be communicated and displayed in real time to the data owner. If an unauthorized party attempts to access the data, the self-protecting data will defend itself, take aggressive action against the intrusion, inform the data owner of the unauthorized attempt, and/or take any other appropriate action. can take

Data owners leverage this protection as a simple, lightweight management tool that continually examines the parties' relationships to their data. From the attacker's point of view, the system is unpredictable, as every authorized party has its own established identity integrated into the protection scheme. A unique protection scheme may be provided for each combination of owner, user, and data set; This means that the way data is disclosed to authorized party A may be different from the way data is disclosed to authorized party B.

Moreover, the unique protection schemes that can be provided to a combination of owner, user, data set, and rule set will be unique to themselves as well when the same combination is later protected. That is, each time a combination of owner, user, data set, and rule set is protected as described herein, the ICTO, whether the same combination or a different combination, will be a uniquely protected ICTO.

In some embodiments, different techniques may be used to protect data and access protected data. For example, an irreversible protection scheme may be used to assemble multiple pieces of data into a single digital mixture, and this selective retrieval scheme does not gain access to other protected data of the single digital mixture. It can be used to selectively retrieve pieces of data from a single digital complex without In such an embodiment, once data is accessed correctly, it is selectively disclosed based on the owner's wishes to authorized recipients. The path to disclosing information is not a function of tracing the original steps, and the original protection scheme used to assemble multiple data pieces may be irreversible except with respect to the individually requested data pieces. That is, even if pieces of data stored in a protected manner are accessed, the entire digital mixture is inaccessible in a way that reconstructs all of the original contents. Embodiments of this disclosure are configured to positively identify any user or entity identity included as or not a legitimate participant, the data owner controlling the portions or pieces of data to which the identified legitimate users may have access. Unauthorized parties, whether inside or outside the intended recipient or the intended recipient's network, cannot access data in unprotected form. Embodiments of this disclosure explicitly verify the identity of a trusted party prior to providing access to ensure data security. Reverse or reverse engineering of protection methods cannot achieve the original result.

In some embodiments of the present invention, the rules are executed by the executable part of the digital mixture, thus ensuring that the clear wishes of the data owner are enforced without dependence on a third party or external entity or application or operating system. This protection scheme does not depend on the application or operating system to protect/unprotect the data: the data is self-protecting and self-controlling. The protection scheme is independent of the operating system, environment, and application (ie, external or centralized or server key management, password management, and identity management applications). Methods within the protocol are implemented as executable code stored in a data mixture, and executed in response to detecting a request by a user to access data through a configured API. Moreover, the data can be of any type (eg, text, audio, video, or a combination thereof), and can be any kind of container, database, or environment (eg, buffer, directory, file, or combinations thereof). Any attempt to access data other than through the API or other means described herein will be thwarted by the cloaking patterns applied, which may be thwarted by any components outside or otherwise of those implementing the API. cannot be determined by When attempting to access data through APIs or other means described herein, the safeguards ensure that only legitimate users are permitted to access the data as authorized by the data owner.

APIs, or other methods initiated through other ICTO-aware applications, devices, or operating systems, initially examine the ICTO. An external cloaking technique then locates the executable code, cryptographic engine, or mixer stored within the digital mixture. The access request is received by the executable code through an API or other ICTO-aware application, device, or operating system on behalf of the agent. Until the self-managed data object is closed or deactivated, the executable code is energized or “awakened” as the portable dynamic rule set takes and maintains control. No attempt to access the self-protecting and self-controlling digital mixture can be successful without the executable code being activated.

1 is a schematic diagram illustrating an exemplary embodiment of self-managing data, in accordance with various aspects of the present invention. The dynamic participation controller 110 or “mixer” is a digital component ( Identifies a set of “participants”) 101 . By mixing these components, the mixer 110 forms a cloaked entity, an intelligent cryptographic transfer object, or an ICTO 115 . The ICTO 115 may also be referred to as a “digital hybrid”. As described herein, one of ordinary skill in the art will recognize that the terms "ICTO" and "digital mixture" and "self-managing data" may be used interchangeably. To an unauthorized entity or third party viewing the ICTO 115 directly, the ICTO 115 may be viewed simply as a data set. The ICTO 115 appears externally as an isomorphic mixture that does not resemble or expose its original components. However, to provide access to data managed by the ICTO 115 when accessed through an application implementing the API (such as mixer 110 , an ICTO-aware client application (not shown), and/or the like) executable portions of the ICTO 115 may be accessed for

In some embodiments, the executable portions of the ICTO 115 may be stored in an identifiable location within the ICTO 115 to allow an application implementing the API to easily find the executable portions. In some embodiments, additional protection may be provided to the ITO 115 by storing one or more executable portions of the ITO 115 in variable locations within the ITO 115 . Although these variable locations make executable portions of the ITO 115 very difficult for an unauthorized user to find, an ICTO-aware application that implements an API to access the ITO 115 is It is possible to compute variable positions of a given ICTO 115 . For example, a secure application may read attributes of the ICTO 115 such as file size, creation time, and/or the like, and may perform a location-determining calculation using those attributes as clues. By keeping the details of the computation secret, the location of the executable portions of the ICTO 115 can be kept secret as well.

The set of entries 101 will include object descriptions 102 , compound metadata 104 , owner data 106 , cloaking patterns 107 , an identity module 109 , and an intelligence module 111 . can In some embodiments, the combination of identity module 109 and intelligence module 111 together may be considered a portable dynamic rule set 108 . Object descriptions 102 may include owner-provided and owner-defined characteristics, data identifiers, and/or attributes. Owner data 106 may include data protected within ICTO 115 , such as documents, files, buffers, directories, pointers to remotely stored data, databases, and/or the like. In some embodiments, the owner data 106 may be optional if the ICTO 115 was only used, for example, for a signature verification method not associated with the signed data below. In some embodiments, multiple pieces of owner data 106 may be included in a single ICTO 115 . In some embodiments, owner data 106 from multiple owners may be included in a single ICTO 115 .

Clocking patterns 107 specify various combinations of data protection and access technologies supported by mixer 110 . The data protection and access techniques included in the cloaking patterns 107 may include techniques such as industry standard verified encryption, compression, randomization, normalization, and/or other techniques. Techniques suitable for use with the cloaking patterns 107 are not limited to currently known techniques, but may include any privately or publicly available encoding and/or decoding technique known now or to be developed in the future. . Using the cloaking pattern 107 to protect and/or access data involves applying a combination of data protection and/or access techniques specified in the cloaking pattern 107 to the data.

Composite metadata 104 provides organizational information for digital compound 115, such as virtual file system data including directories, key codes, user files, signatures, and/or the like.

Identity module 109 may include dynamic identity attributes that uniquely identify protected agents in a transaction. In some embodiments, the identity module 109 may include data representing the configuration of the computing device to which certain rights may be granted with respect to the protected object. The identity module 109 may include specific information about hardware or software configurations installed on the computing device, which may be used to identify the computing device. The identity module 109 may include CPU information including model numbers, number of cores, speed, and/or the like; chassis serial number; Date of Manufacture; volatile memory size; non-volatile memory size; one or more storage device serial numbers, and/or model numbers; data including, but not limited to, installed software names, and/or version numbers, and/or the like.

In some embodiments, a transaction is an atomic operation using the ICTO 115 in which one or more agents securely exchange data in a given context and with specific intent. Authorized agents may include human and non-human entities such as human users, unique machines, unique electronic devices, unique software or program objects, and/or the like. The dynamic identity attributes contained in the ICTO 115 may be modified by the intelligence module 111 during or during interaction with the ICTO 115 , including application-specific identifiers, account identifiers, biometric signatures, device , and/or location signatures, temporary data, cryptographic keys, and/or the like. In some embodiments, the location signature may include data from geolocation technologies such as GPS, GSM network location, IP address location, dead reckoning, and/or the like. The location signature may include longitude, latitude, altitude, approximate street address, and/or the like. Additional location data may also be present, such as road, city, state, country, zip code, and/or the like. In some embodiments, the temporary data may include a timestamp and/or the like that may cause rules or other intelligent code to enforce timers, expirations, dynamic keys, and/or the like. Temporary data may include a simple date/time value, or it may include a complex schedule that includes timestamp ranges and/or other scheduling announcements.

In some embodiments, each ICTO 115 includes at least one digital signature key. The digital signature key may be verified using an external digital certificate available to mixer 110 . During access of the ICTO 115, the mixer 110 uses the external digital certificate to verify the digital signature key and verifies that this digital signature key is valid for agents currently accessing the ICTO 115. In some embodiments, multiple agents may authorize the ICTO 115 . In such an embodiment, the ICTO 115 may include a chain of signing keys, where each signing key may be associated with a separate external digital certificate for verification. For example, the ICTO 115 may be used by a user to create a protected file for delivery to multiple agents, where each agent may simultaneously or sequentially access different file sections rather than the entire file. can Owners and agents may need to provide valid digital signatures to process a transaction.

The intelligence module 111 may include dynamic rule sets capable of recording and communicating access data and other relevant histories, along with intelligent code that provides configurable functionality to perform actions to protect the ICTO 115 . have. Rules can be provided at object creation time. However, in some embodiments, a rule may have the ability to modify itself or other rules of a previously created ICTO 115 . In some embodiments, a rule may have the ability to create additional rules. For example, a rule may determine, from identity data, that additional protection is needed for a given ICTO 115 . The rule can then create additional encryption and/or decryption rules to apply. The rules are protected and contained in the ICTO 115 . In some embodiments, the rules may be executed only by the executable portion of the intelligence module 111 and/or may be written in a proprietary language and stored in compiled or binary form. Based on the rules and requirements of the identity module 109 , the intelligence module 111 operates according to its own rules and requirements. Application-specific identifiers may vary by access and may vary by agent type. For example, for a human user, application-specific identifiers may include account keys, transaction information, context keys, associated intents, and/or the like. For an electronic device, digital asset, or any other potential agent, application-specific identifiers may also include an IP address, URL, file specification, and/or the like.

In some embodiments, the participants 101 are protected by the ICTO 115 , but the embedded portable dynamic rule set or sets have read/write access to the embedded participants 101 . That is, the rules can read and write data to the mixture metadata 104 and owner data 106 of the ICTO 115 . This can be useful for logging access information such as date, time, location, etc. and/or destroying data when an attack is detected. Some examples of decisions or actions made and taken by intelligent code within rules are: evaluating object content and context for validity; testing agents to prove their identity; interacting with client code; contacting the server for inspection; making ICTO 115 self-destructive; maintaining object access history and sending historical information to the server; allowing on-line and/or off-line object access; creating new rules based on dynamic server updates; encrypting and decrypting data; mangling and unmangling data; and/or the like.

The use of portable dynamic rules can have various advantages. For example, pre-encryption and pre-decryption rules may provide dynamic salt and cryptographic keys based on participant-specific criteria. These dynamic keys may be based on temporary data, environmental data, or any other algorithm specified in the pre-encryption rule. As another example, rules may access encrypted identity artifacts within the ICTO 115 to inspect an agent without exposing unprotected data to unauthorized users. As another example, rules can be written in such a way that they are portable and therefore included in the ITO 115 , completely protecting the ITO 115 from unauthorized access, even off-line or off-network. As a further example, rules may add nested protection. If the ICTO 115 is protecting a document that must be read by a single agent within one hour of being created, the rule may implement a timer and create a self-destruct mechanism.

As described above, an embedded mixer 110 uses an embedded portable dynamic rule set 108 to self-protect and self-manage an ICTO 115 , including object descriptions 102 , mixture meta It forms a mixture of data 104 , owner data 106 , cloaking patterns 107 , identity module 109 , and intelligence module 111 . In some embodiments, various components of the ICTO 115 may be marked with coded checksums to detect tampering. For example, the entire ICTO 115, rules, owner data, and/or user data may each be verified with an embedded checksum. The checksum may be a hash value generated based on the contents of the checksum target. In some embodiments, the algorithm used to generate the checksum is sensitive enough to reliably detect a change in the value of a single bit even among a large data-set. Some suitable algorithms include MD5 and SHA, although any other suitable algorithm may be used. Each checksum may be stored attached to, appended to, or otherwise combined with a checksum target, or may be stored in a separate location.

7 is a schematic diagram illustrating another exemplary embodiment of self-contained, self-controlling, self-managing data protection in accordance with further embodiments of the present invention. An API or other ICTO-aware application, device, or operating system initiates a request to the dynamic participant controller or executable mixer 702 to protect the set of digital participants 701 , thereby causing the dynamic participant controller or the executable mixer 702 is activated. Digital Participants include, but are not limited to, Authorized Agents, devices, locations, data usage rules, and/or other digital components, which are collectively self-protecting and self-protecting, as further described below. - Included in the managed data object (ie, digital composite or ICTO) 710 . The dynamic participation controller 702, when activated, creates an intermediate cryptographic object 703 utilizing a temporary or “start” rule set while the object is being constructed. The intermediate cryptographic object 703 is cloaked using one or more external cloaking patterns 704 selected, generated, or made by an algorithm generated by the mixer 702 .

In some instances, additional protection or functions or combinations thereof may be applied by storing one or more executable portions of the ICTO 710 in variable locations within the ICTO 710 . The initial entry point for executable portions of the ICTO 710 may only be computed and located by an ICTO-aware application, operating system, or device. Once the executable or DPC 702 is located and wakes up, a unique offset to locate the portable dynamic rule set 711 within the ICTO 710 that takes and maintains control while the ICTO 710 is active The table is made available to DPC 702 .

The set of digital participants 701 includes external cloaking patterns 704 , compound metadata 705 , owner data 706 , internal cloaking patterns 707 , an identity module 708 , and an intelligence module 709 . may include, but is not limited to. In some embodiments, the combination of internal cloaking patterns 707 , identity module 708 , and intelligence module 709 may together be considered a portable dynamic rule set (PDRS) 711 . Owner data 706 protected within ICTO 710 and managed by PDRS 711 includes images, videos, messages, emails, documents, files, buffers, directories, pointers to remotely stored data, portals, etc. However, it may include, but is not limited to, multiple data types. In some embodiments, owner data 706 may be optional, and thus, ICTO 710 is only not included, for example, when used with non-disputable and specific signature verification methods. 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 may be mixed into a single ICTO.

The internal clocking patterns 707 are determined by the owner's rules specified in the portable dynamic rule set 711 and specify various combinations of data protection and access technologies supported by the dynamic participant controller or mixer 702 . Data protection and access techniques included in internal cloaking patterns 707 may include, but are not limited to, such techniques as industry standard encryption, proprietary encryption, compression, randomization, normalization, and the like. Techniques suitable for use with internal clocking patterns 707 are not limited to currently known techniques, but may include any privately or publicly available encoding and/or decoding technique known now or to be developed in the future. have. Using the internal cloaking pattern 707 to protect and/or access data may involve applying a combination of data protection and/or access techniques specified in the portable dynamic rule set 711 to the data and other participants. can

External cloaking patterns 704 utilize an intermediate rule set to create an intermediate cryptographic object 703 to protect and access selected data via one or more algorithms computed, used, or generated by the dynamic participant controller 702 . Various combinations of techniques are specified. Data protection and access techniques included in external cloaking patterns 704 may include, but are not limited to, techniques such as industry standard verified encryption, compression, randomization, normalization, and the like. Techniques suitable for use with external clocking patterns 704 are not limited to currently known techniques, but may include any privately or publicly available encoding and/or decoding technique known now or to be developed in the future. have. Using the external cloaking pattern 704 to protect and/or access data may involve applying a combination of data protection computed by the dynamic participation controller 702 and specified by an intermediate set of rules. Composite metadata 705 provides organizational information for digital compound 710, such as, but not limited to, virtual file system data including directories, user files, and the like.

Identity module 708 may include dynamic identity attributes that uniquely identify legitimate agents within a transaction. Dynamic identity attributes may be learned information added to an identity module within the PDRS, such as, but not limited to, location, device, and access behavior. As the learned information can be gathered and utilized in future access request sessions, additional intelligence and decision points are added. Additionally, dynamic identity attributes may also be variable (ie, unpredictable) details. They may be presented alone or in combination with personal identity attributes during the authentication process when determining the legitimate identity of the agent requesting access to the ICTO.

In some embodiments, the identity module 708 may include data representing the configuration of the computing device to which certain rights may be granted with respect to a protected object. The identity module 708 may include specific information about hardware or software configurations installed on the computing device that may be used to identify the computing device. The identity module 708 may include: CPU information including model numbers, number of cores, speed, and/or the like; chassis serial number; Date of Manufacture; volatile memory size; non-volatile memory size; one or more storage device serial numbers, and/or model numbers; data including, but not limited to, installed software names, and/or version numbers, and/or the like.

In some embodiments, a transaction is an atomic operation using the ICTO 710 in which one or more suitable and authorized agents securely exchange data or information in a given context and with a specified intent. Suitable authorized agents may include human and non-human entities such as human users, unique machines, unique electronic devices, unique software or program objects, and/or the like. Dynamic identity attributes contained in the ICTO 710 may be modified by the intelligence module 709 during or during interaction with the ICTO 710 , including application-specific identifiers, account identifiers, biometric signatures, device , and/or location signatures, temporary data, cryptographic keys or data, and/or the like. In some embodiments, the location signature may include data from a location technology such as GPS, GSM network location, IP address location, dead reckoning, and the like. The location signature may include longitude, latitude, altitude, approximate street address, and the like. Additional location data such as road, city, state, country, zip code, etc. may also be present. In some embodiments, the temporary data may include a timestamp or similar information that may cause a rule or other intelligent code to enforce timers, expirations, dynamic keys, etc. Temporary data may include a simple date/time value, or it may include a complex schedule that includes timestamp ranges and/or other scheduling announcements.

In some embodiments, each ICTO 710 may include one or more digital signature requests, either human or non-human. During authentication by the ICTO 710 , the portable dynamic rule set 711 determines that the digital signature is valid for legitimate agents requesting access to information managed by the PDRS 711 . In some embodiments, multiple legitimate agents may verify the authorization of other legitimate agents. In such an embodiment, PDRS 711 may enforce a chain of digital signature requirements, where each digital signature may be associated with a separate legitimate agent. For example, the ICTO 710 can be used by an owner to create a self-managing file to be approved, signed, and transmitted to multiple legitimate agents, where each legitimate agent is a different but not the entire file. File sections can be accessed concurrently or sequentially. The owner and legitimate agents may have to provide valid digital signatures to process the transaction.

The intelligence module 709 may include dynamic rule sets capable of recording and communicating access data and other related events, along with intelligent code that provides configurable functionality to perform operations for managing the ICTO 710 . . Rules can be provided at object creation time. However, in some embodiments, a rule may modify itself or instead modify other rules of a given ICTO 710 . In some embodiments, a rule may create additional rules. For example, a rule may determine that additional protection is needed for a given ICTO 710 during authentication of a legitimate agent. The rule can then create requirements such as additional access, defense, cloaking, etc. In some embodiments, the rules may only be executed by the dynamic participant controller 702 , may be stored in binary form as a participant in the ICTO, or a combination of the two. Based on the rules and requirements of the identity module 708 , the intelligence module 709 operates according to its rules and requirements applied by the owner agent. The portable dynamic rule set 711 identifiers may vary by access, and may vary by agent type. For example, for a human user, portable dynamic rule set 711 specific identifiers may include account keys, transaction information, context keys, associated intents, and the like. For an electronic device, digital asset, or any other potential agent, the portable dynamic rules set 711 identifiers may also include an IP address, URL, file specification, and the like.

In some embodiments, the rules have read/write access to the digital participants 701 even while the digital participants 701 are protected by the ICTO 710 . That is, the rule can read and write data to and to the mixture metadata 705 and owner data 706 of the ICTO 710 . This can be useful for logging access information such as date, time, location, etc. and destroying data when an attack is detected. Some examples of decisions or actions made and taken by the intelligence module 709 include: evaluating object content and context for validity; testing agents to prove their identity; interacting with client code; Contacting the server for trust verification; making ICTO 710 self-destructive; maintaining object access history and sending the history information to the server by e-mail, SMS, FTP or storing with the ICTO 710; allowing on-line and/or off-line object access; creating new rules based on dynamic server updates; Cloaking and decloaking data; Data mangling and demangling may include, but are not limited to.

The use of the portable dynamic rule sets has various advantages and objectives. In one exemplary embodiment, access rules may utilize internally generated and internally managed unique keys based on owner-specific criteria. The unique keys may be based on temporary data, environmental data, or any other algorithm specified by the owner's rule set. As another example, the rules may access protected identity artifacts in the ICTO 710 to authenticate and inspect an agent without exposing the protected data to the world. As another example, rules are written in such a way that they are self-contained, portable, platform independent, and thus included in ICTO 710, so that ICTO 710 is completely protected from unauthorized access even off-line. can be

As a further example, rules may add nested protection. If the ITO 710 protects one or more ICTOs 710 in the current or external ITO 710 , then the external ITO 710 manages one or more ICTOs 710 as part of the respective owner data 706 . may be able to communicate with The external ITO 710 (or vice versa) causes the rules managed within any ICTOs 710 included in the owner data 706 of the external ITO 710 to be executed, or one or more included ITCOs 710 . ), new rules can be created as a result of the rules included in As another example, self-contained rules within PDRS 711 of ICTO 710 self-manage. If the ICTO 710 is protecting a document that must be accessed by a single legitimate agent within 1 hour of being created, up to 1 hour after being accessed, then the rule can implement a timer and create a self-destruct mechanism after expiration. have.

As described above, a dynamic participant controller 702 or mixer utilizing a portable dynamic rule set 711 can include external clocking patterns 704, compound metadata 705, owner data ( 706 , internal cloaking patterns 707 , an identity module 708 , and an intelligence module 709 . In some embodiments, various components of ICTO 710 may be combined for coded checksums to detect tampering. For example, the entire ICTO 710 , rules, owner data, and/or entry data may each be checked with a checksum 712 . The checksum 712 may be a hash value generated based on the contents of the checksum 712 goals. In some embodiments, the algorithm used to generate the checksum is sensitive enough to reliably detect a change in the value of a single bit even among large documents. Some suitable algorithms include MD5 and SHA, although any other suitable algorithm may be used. Each checksum 712 may be stored attached to, appended to, or otherwise combined with a checksum target, or stored in a separate location.

2 is a flow diagram illustrating an exemplary embodiment of a method for configuring an ICTO 115 in accordance with various aspects of the present invention. Although the method 200 shown describes the creation of relatively simple ICTOs 115 , one of ordinary skill in the art will appreciate that similar techniques may be used to create much more complex ICTOs 115 . In some embodiments, mixer 110 is configured to perform method 200 . In some embodiments, as described below, method 200 is performed by a computing device configured to provide the functionality of mixer 110 . Those skilled in the art will recognize that the configuration and utilization of ICTO 115 is not dependent on the type of computing device nor on the type of any operating system associated with the computing device, but may instead be configured and utilized via any suitable means. .

From the starting block, the method 200 proceeds to block 202 where a set of common digital components or participants is obtained. Common entries are entries 101 that can be used in more than one ICTO 115 , or can have at least similar corresponding components in two or more ICTO 115 , and are mixers 110 for inclusion in an ICTO 115 . ) specified and/or created by For example, object descriptions 102 , compound metadata 104 , cloaking patterns 107 , identity module 109 , and intelligence module 111 may all be common participants. Next, at block 204 , a dynamic participant controller (“mixer”) 110 is initiated. In some embodiments, initiating mixer 110 may include verifying that mixer 110 is running by an expected or otherwise trusted application. At block 206 , mixer 110 receives one or more pieces of owner data 106 to be protected. As noted above, in some embodiments, owner data 106 may be optional, and access protection features of ICTO 115 may be used to verify user identities and/or obtain signatures from users. .

Method 200 proceeds to block 208 where mixer 110 causes portable dynamic rule set 108 to be executed. At block 210 , the intelligence module 111 of the portable dynamic rule set 108 determines one or more identity-based cloaking patterns used to protect the participants 101 , and at block 212 , the mixer 110 . ) applies one or more cloaking patterns to the participants 101 to create a set of cloaked participants.

The portable dynamic rule set 108 determines the cloaking pattern to be applied to each participant 101 based on the wishes of the owner of the protected data. Different clocking patterns may be applied to each participant 101 . Additionally, each participant 101 may be protected using separate cloaking patterns for access by different agents. That is, a participant 101, such as owner data 106, may be protected with a first cloaking pattern for access by a first agent, and protected with a second cloaking pattern for access by a second agent. . The selection of cloaking patterns may be based on the properties of the participant 101 being protected, the properties of the agent given access to the data, location, intent, and/or any other suitable piece of information. Selection of a cloaking pattern may include selecting from an existing cloaking pattern and/or may include creating a new cloaking pattern from a combination of protection techniques supported by mixer 110 . Records of applied cloaking patterns may be stored in the mixture metadata 104 .

The cloaking patterns describe the modifications applied to the participant 101 to protect the participant 101 within the ICTO 115 , and how these modifications are reversed to access the participant 101 . Modifications may include, but are not limited to, data compression, data normalization, and encryption/decryption. A given cloaking pattern may include one or more of these techniques or other techniques not listed herein. Data compression can reduce the overall size of the ICTO 115, improving transmission time and bandwidth usage later. Data compression may be performed by any suitable lossless compression algorithm including, but not limited to, DEFLATE, LZW, LZR, LZX, JBIG, D _j V _{u , and/or the like.} Data normalization is performed by any suitable processing that places the data in a form that can be efficiently processed. In some embodiments, the data may be subjected to a Base64 encoding algorithm to convert the data in binary or text format to a normalized alphanumeric string. This is merely an example and should not be considered limiting. In other embodiments, other algorithms may be used to normalize the data.

In some embodiments, the 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 encryption rule, when executed, may identify and encrypt a first portion of the encrypted digital mixture 115 without altering the second portion of the encrypted digital mixture 115 . Accordingly, the second encryption rule, when executed, may identify and encrypt the second portion of the digital mixture 115 encrypted using a different encryption algorithm, a different encryption key, and/or the like.

In some embodiments, the cloaking patterns and/or portable dynamic rule set 108 may build two or more nested encryption layers. For example, execution of the first encryption rule may encrypt the first portion of the encrypted digital mixture 115 . Accordingly, execution of the second encryption rule may cause the encrypted first portion of the encrypted digital mixture 115 to encrypt again according to the first encryption rule and the corresponding first decryption rule. Thus, in order to later access the first portion of the encrypted digital mixture 115 , a second decryption rule corresponding to the second encryption rule decrypts the twice-encrypted first portion of the encrypted digital mixture 115 and Executed to obtain a decryption rule. A first decryption rule is then executed to decrypt the encrypted first portion of the digital mixture 115 to produce a plain text version of the first portion of the digital mixture 115 .

Once the cloaking patterns are applied to the participants 101 to create a set of cloaked participants, the method 200 allows the mixer 110 to generate a digital composite (ICTO) 115 and set of cloaked participants. Proceeds to block 214 , which adds to the digital mixture 115 . In some embodiments, additional protection such as data shuffling, additional encryption or digital signatures, and/or the like may be applied throughout the digital mixture 115 . The method 200 then proceeds to the end block and ends.

A person skilled in the art will understand that, for ease of explanation, certain steps are omitted in FIG. 2 . However, other steps not expressly shown in FIG. 2 may also be included in method 200 without departing from the scope of this disclosure. For example, if any errors are detected while applying cloaking patterns or executing rules, the method 200 may halt and may not generate a perfect ICTO 115 . As another example, in some embodiments, owner data 106 may include one or more ICTOs in a way that provides nested protection. In some embodiments, rules within a nested ITO may be provided with access to the participant data 101 within an external ITO 115 . In some embodiments, the first ICTO is nested within the second ICTO, as a rule in the first ICTO may create the second ICTO and add the first ICTO to the second ICTO. Similarly, in some embodiments, the second ICTO is nested within the first ICTO, as a rule in the first ICTO can create the second ICTO and add the second ICTO to the first ICTO.

8 is a process flow diagram illustrating an alternative exemplary embodiment of a method 800 for configuring an ICTO 710 in accordance with various aspects of the present invention. The method 800 shown describes the creation of a simple ICTO 710 ; However, it is possible to construct complex ICTOs using similar technologies. In some embodiments, an ICTO-aware application, device, or operating system is configured to initiate and utilize method 800 . The configuration and utilization of the simple or complex ICTO 710 is not dependent on a specific operating system or device.

From start 801 , method 800 begins with initiation 802 of a dynamic participant controller 702 or mixer. In some embodiments, initiation 802 of the mixer checks that the object is truly ICTO-aware and/or that the request to initiate is from an ICTO-aware application, device, operating system, or other ICTO-aware process. may include Proceeding to block 803 , the set of digital entries 701 is provided to the mixer 702 for inclusion in the ICTO 710 . Digital exhibits 701 may be used in more than one ICTO 710 , or may at least have similar or common components in two or more ICTOs 710 . For example, external cloaking patterns 704 , compound metadata 705 , additional cloaking patterns 707 , identity module 708 , and intelligence module 709 are all common digital participants 701 . can be considered. Proceeding to block 804 , the mixer 702 utilizing one or more algorithms utilizes the intermediate rule set to generate initial cloaking patterns for the ICTO 710 to apply to the set of digital participants 701 . One or more external cloaking patterns 704 are selected to create an initial intermediate cryptographic object 703 . Proceeding to block 805 , one or more owner data elements are added to the set of digital entries for inclusion in the ICTO 710 . In some embodiments, owner data 706 may be optional and the access protection function of ICTO 710 may be utilized to verify legitimate agent identities and/or for legitimate agent signatures.

The method 800 includes block 806 , where the owner's rules are obtained from the PDRS 711 and utilized by the mixer 702 to replace the intermediate rule set that was initially used in the creation of the ICTO 710 . proceeds with Proceeding to block 807 , utilizing one or more algorithms, the mixer 702 , including owner data 706 , applies one or more cloaking patterns 707 to some or all of the set of digital entries 701 . ) is selected. The algorithm utilizes owner rules and time as a unique number to further randomize the internal clocking patterns 707 . The algorithm used is added to the identity module 708 , managed internally by the PDRS 711 , and is not shared externally. Finally, at block 808 , mixer 702 completes the construction of ICTO 710 to create a set of clocked digital participants 720 . Although similar or common digital participants 701 , such as those provided in block 803 , may be utilized in combination, the method may also create a unique digital mixture 808 for each configured ICTO 710 . have.

Mixer 702, using one or more algorithms, randomly applying time as unique numbers and other internal components generated by intelligence module 709 determines which internal clocking patterns 707 each digital It is determined whether to apply to the participant 701 . The algorithms utilized by the mixer 702 to select the internal clocking patterns 707 are then added to the identity module 708 , managed internally, and shared/exchanged/exposed externally of the ICTO 710 . doesn't happen Each participant 701 utilizes one or more internal cloaking patterns 707 that may be fundamentally different from one or more internal cloaking patterns 707 protecting other participants 701 within the digital composite 710 . can be protected. For example, an entry such as owner data 706 may have one or more internal cloaking patterns and internal rules that are fundamentally different from the one or more internal cloaking patterns 707 and internal rules utilized to protect the identity module 708 . can be protected by In addition, the utilization of one or more internal cloaking patterns 707 , and the random use of time as internal rules and unique numbers, are unique that are later added to the identity module 708 for each participant 701 . Creates one clocking pattern. Internal rules embedded in intelligence module 708 may include, but are not limited to, such as location, time, authorization requirements, and the like.

The internal cloaking patterns 707 are variants applied to the participant 701 to protect the participant 701 within the ICTO 710 , and some of these variants may be applied to a portion of the participant 701 or its Describes a retrograde method to access all. Transformations include, but are not limited to, data compression, data normalization, and encryption. A given internal clocking pattern 707 may include one or more of these techniques and/or other techniques. Data compression can reduce the overall size of the ICTO 710, improving transmission time and bandwidth usage later. Data compression may be performed by any suitable lossless compression algorithm including, but not limited to, DEFLATE, LZW, LZR, LZX, JBIG, D _j V _{u , and/or the like.} Data normalization is performed by any suitable processing that places the data in a form that can be efficiently processed. In some embodiments, the data may be subjected to a Base64 encoding algorithm to convert the data in binary or text format to a normalized alphanumeric string. This is merely an example and should not be considered limiting. In other embodiments, other algorithms may be used to normalize the data.

Internal clocking patterns 707 may also include one or more encryption techniques. Cloaking patterns may specify methods for deriving encryption keys, or may specify particular encryption algorithms, such as, but not limited to, NIST or FIPS, other proprietary encryption algorithms, or key lengths, or time seeds (time seeds). seeds), Xor encoding, or other industry standard encoding and decoding techniques for generating components of cloaking schemes, or other configurable options such as combinations thereof. In some embodiments, encryption techniques may perform operations or calculations other than encryption, such as deriving a hash value or the like for referenced content. In some embodiments, the internal cloaking pattern 707 stores (or stores a record of) the encryption key or decryption key used in the internal cloaking pattern 707 itself or otherwise in the ICTO 710 . (including rules that require it), are managed internally and are not shared externally. Once the internal cloaking pattern 707 is used to access protected information, the cloaking/declocking algorithm(s) and keys are maintained therein, and a dynamic entry within the ICTO 710 to provide access to the information. provided to the controller 702, but not available to the requesting agent or any other agent or application, device, or operating system outside of the ICTO 710. That is, since the cloaking/decloaking algorithms and keys are not stored or exposed outside the ICTO 710 and cannot be used by any agents, external key management functions become unnecessary, security is not weakened, and their secrets are kept maintain.

In some embodiments, a rule specified in intelligence module 709 may cause mixer 702 to apply individual internal clocking patterns 707 to individual components of participants 701 . For example, a first rule, when executed, may identify and apply a cloaking pattern to a first portion of the protected digital compound 710 without altering the second portion of the protected digital compound 710 . . The second rule, when executed, may identify and apply a cloaking pattern to a second portion of the digital composite 710 protected using a different cloaking pattern having a different pattern and the like.

In some embodiments, the intelligence module 709 of the portable dynamic rule set 711 may require two or more nested cloaking layers on some or all of the participants 701 . For example, execution of the first rule by the mixer 702 may cloak the first portion of the protected digital mixture 710 . Thus, the execution of the second rule by the mixer 702 uses, according to the first rule and the corresponding first cloaking rule, an inner clocking pattern 707 in which the cloaked first portion of the protected digital mixture 710 is different. So it can be cloaked again. Thus, in order to later access the first portion of the protected digital mixture 710 , a second declocking rule corresponding to the second rule declocks the nested and cloaked first portion of the protected digital mixture 710 and , is executed to obtain the first declocking rule. A first declocking rule is then executed to declock the first portion of the protected digital compound 710 to produce a plain text version of the first portion of the digital compound 710 .

Once the internal clocking patterns 707 are applied to the participants 701 to produce a set of cloaked participants 720 , the method 800 indicates that the mixer 702 is a digital composite (ie, ICTO) 710 . ) proceeds to block 808, which completes the construction of . In some embodiments, additional protection such as data shuffling, additional cloaking and/or the like may be applied throughout the digital composite 710 . The method 800 then proceeds to the end block and ends.

Other steps not explicitly shown in FIG. 8 may also be included in method 800 without departing from the scope of this disclosure. For example, if any anomalies are detected while applying cloaking patterns or executing rules, the method 800 may halt and may not generate the perfect ICTO 710 . As another example, in some embodiments, owner data 706 may include one or more ICTOs as a method of providing nested protection. In some embodiments, rules within the nested ITO may be provided with access to the participant data 701 within the external ITO 710 . In some embodiments, the first ICTO is nested within the second ICTO, as a rule in the first ICTO may cause a second or multiple ICTO(s) to be created and the first ICTO added to the second ICTO do. Similarly, in some embodiments, the second ICTO is nested within the first ICTO, as a rule in the first ICTO may cause a second ICTO to be created, and the second ICTO to be added to the first ICTO.

3 is a flow diagram illustrating an example embodiment of a method 300 for accessing data protected by an ICTO 115 in accordance with various aspects of this disclosure. After the ICTO 115 is activated, the ICTO 115 examines its current environment, access attempts, authorized agents, and other conditions, as specified in the rule set included in the portable dynamic rule set 108 . and start to verify. This check and verification may be performed once per startup, continuously during an active period, periodically during an active period, or at any other suitable interval, or in response to any suitable change of state. If the rules and agent identity are positively verified, the ICTO 115 allows access to its authorized parts, while maintaining the isomorphic nature of the mixture and protecting the rest of the data.

As with method 200 described above, in some embodiments mixer 110 is configured to perform method 300 . In some embodiments, method 300 is performed by the computing device when one or more processors of the computing device execute computer-executable instructions that cause the computing device to do so. As will be appreciated by one of ordinary skill in the art, the configuration and utilization of the ICTO 115 is not dependent on the type of computing devices, nor on any operating systems associated with the computing devices. A data protection protocol is embedded in the data set. An activated ICTO 115 will communicate information (such as notifications of access attempts, alerts to unauthorized locations or unauthorized agents, notifications of self-destruction or self-renewal) with the data owner during the lifetime of the data. can In addition, the rules within the ITO 115 may update themselves and other parts of the ITO 115 so that the ITO 115 learns from its environment and changes its future behavior based on that learning. can The protection protocol can be customized and is unique to each owner, data set, and user combination as specified in the cloaking patterns.

From a starting block, the method 300 proceeds to block 302 where, in response to a request by an agent to access the digital mixture 115 , a portable dynamic rule set 108 within the digital mixture 115 is activated. . In some embodiments, a super-identity is embedded in the ICTO 115 , a criterion for verifying the identity of an agent attempting to access the ICTO 115 , examining the agent and determining the current state of the data. dynamic rules to provide intelligent recognition, and algorithms for cloaking data as specified in cloaking patterns. Verification criteria such as challenge/response pairs, digital signatures, biometric 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 the relevant context. The identity module 109 and intelligence module 111, when activated, evaluate current access attempts by verified agents and establish a trust level. In some embodiments, this evaluation is an ongoing process, ie, inspection and verification of each participant 101: data owner, agent (data user), and the data itself continues. In some embodiments, pre-access rules from portable dynamic rule set 108 are internal by mixer 110 without allowing agents other than mixer 110 to access the decrypted data. may be executed by mixer 110 to decrypt at least some portions of ICTO 115 for use. Pre-access rules have access to the entries 101 , including the ability to test for identity artifacts and evaluate owner and agent data. If the confidence level is lowered, the protocol re-evaluates the participants 101 . In some embodiments, if agents attempting to access the ICTO 115 are unable to re-establish their legitimacy, defensive or offensive actions may be invoked. If the agent is able to satisfy the new challenge set, access will be allowed to proceed or continue.

In some embodiments, the pre-access rules are only read access allowed to identity or authentication data, but in some embodiments the pre-access rules are, for example, when opening the ICTO 115 ( or when attempting to open it) may also have write access, which can be used to record access attempt attributes.

Method 300 proceeds to block 306 where portable dynamic rule set 108 determines a cloaking pattern used to protect the requested data. The portable dynamic rule set 108 consults the mixture metadata 104 to determine which cloaking pattern 107 to apply based on the agent's identity, the data request, the context in which the data is requested, and/or the like. Once the cloaking pattern 107 to be used has been 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 pattern 107 represents the set of techniques used to protect the requested data, the cloaking pattern 107 is also used to reconstruct the requested data from the protected version stored in the ICTO 115 . It represents a set of techniques. The method 300 then proceeds to the end block, where it ends.

9 is a flow diagram illustrating an alternative embodiment of a method 900 for accessing data protected by an ICTO 710 . After the ICTO 710 is activated, the PDRS 711 begins to inspect and verify the current environment of the ICTO 710, access attempts, legitimate agents, and other conditions, as specified in the PDRS 711 . do. This check and validation process is inherently efficient, ensures data integrity, and ensures data integrity, once per startup, continuously during an active period, periodically during an active period, or at any other suitable interval, or upon any suitable phase or change of state. It can be done in response. If the rules and the legitimate agent identity are positively verified, the PDRS 711 allows access to the authorized parts of the ICTO 710 while preserving the isomorphic nature of the mixture and protecting the remaining participants. In some embodiments, an ICTO-aware application, device, or operating system is configured to initiate and facilitate method 900 .

Starting at a start block 901 , the method 900 determines that, in response to a request by an agent to access the digital composite or ICTO 710 , the dynamic participation controller 702 within the protected digital composite or ICTO 710 is activated. Proceed to block 902 , activated by an ICTO-aware application, device, or operating system. In some embodiments, the owner/agent identity and/or one or more agent identities are included in an identity module 708 embedded in the ICTO 710 , including the identity, authentication, and authentication of an agent attempting to access the ICTO 710 , and criteria for validating legitimacy, dynamic rules for providing intelligent recognition for examining the legitimacy of an agent and determining the current state of the data, and an algorithm for cloaking data as specified in the cloaking patterns. Verification criteria such as challenge/response pairs, external authorizations, biometric information, and/or the like may be used to authenticate, check, 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, complete, complete, and relevant context, and access to the digital mixture 710 is granted.

Method 900 includes dynamic participant controller 702 , based on the agent's identity, data request, context in which the data is requested, etc. Proceed to block 904 provided to . Proceeding to block 905 , the DPC or mixer 702 based on the rules of the data owner on the command from the portable dynamic rule set 711 , the legitimate agent, the data request, the context in which the data is requested, and/or the like. By declocking some or all of the protected data in the ICTO 710 , it is managed by the portable dynamic rule set 711 .

Other steps not explicitly shown in FIG. 9 may also be included in method 900 without departing from the scope of this disclosure. For example, if any anomalies are detected while applying declocking patterns or executing rules, the method 900 may be halted and access to the protected ICTO 710 may not be allowed. As another example, the method 900 may determine the legitimacy of a requesting agent to the ICTO 710 , which may cause external authorizations to be required before the legitimate agent's authorization is complete. Additionally, alerts may be sent as a result of legitimate and authorized access to the ICTO 710 . As another example, in some embodiments, method 900 determines if unauthorized access is attempted, which PDRS 711 in ICTO 710 may transmit alerts, log access attempts, and the like. can In another example, in some embodiments, the method 900 determines that an unauthorized access attempt is in transit, and enables access to false data in the ICTO 710 to record the activity. , cause alerts to be sent, and so on. Alerts include, but are not limited to, false access attempts, unauthorized access addresses (which may include device and location specifications), schedule violations, unauthorized movement of the ICTO, and the like.

Thus, the present invention results in a self-contained, self-regulating, self-managing ICTO. All access rights, business rules, appliance rules, audit requirements, and similar rules and restrictions determined by the data owner are included in the PDRS and embedded in the ICTO, controlled by the PDRS on behalf of the data owner (online Whether or not offline, control remains in the ICTO), implemented by the PDRS. The PDRS is a means for self-management and control, at the time of creation and during the life of the ICTO. It moves with the ICTO, always obeys the rules established by the data owner, and can adapt (i.e. dynamic) based on the environment (such as, but not limited to location, time, and device) (i.e. it is dynamic), Self-manage and make informed decisions. PDRS does not require any external sources (eg, IAM or SIEM system) or specific operating environments to maintain control and management. The PDRS controls the complete management of the ICTO within the ICTO. The PDRS is permanently embedded in the ICTO and moves with the ICTO, creating a self-contained, self-controlled, self-managing entity.

4 is a schematic diagram illustrating an exemplary use case for an embodiment of this disclosure. Those of ordinary skill in the art will recognize that while this use case is illustrative only and is presented to illustrate certain features of the disclosure, this use case may not utilize or represent all features of the technology disclosed herein. In FIG. 4 , a first user 418 using a first computing device 416 is viewed to protect a first piece of data (data 1 404 ) and a second piece of data (data 2 406 ). Use the examples in the postings. An ICTO 408 is created that includes a protected version of data 1 410 and a protected version of data 2 412 . When creating the ICTO 408 , the first user 418 specifies that the second user 422 can access data 1 404 , but the second user 422 has access to data 2 406 . It is not certain that it can be done. Accordingly, the ICTO 408 includes in its portable dynamic rule set 108 a rule that the second user 422 is allowed to access data 1 404 once verified.

The first computing device 416 communicates the ICTO 408 to the second computing device 420 used by the second user 422 over a network such as a LAN, wireless network, the Internet, and/or the like. The second user 422 activates the ICTO 408 and submits a request 424 to access data 1 404 . The ICTO 408 verifies the identity of the second user 422 , for processing the challenge/response pair stored in the ICTO 408 and/or verifying that the second user is correct as to whether he or she asserts that it is. and referencing a trusted service 409 (such as a certificate server, RADIUS, or other authentication server, and/or the like). Once the identity of the second user 422 is verified, the ICTO 408 refers to the cloaking pattern used to generate the protected data 1 410 , and uses the cloaking pattern to send the data 1 to the second user 422 . Give access to (404). However, since the ICTO 408 has not been instructed to provide the second user 422 with access to the data 2 406 , the ICTO 408 will allow the second user 422 to access the data 2 406 . do not allow to

In an alternative processing flow, the first computing device 416 provides the ICTO 408 to the second computing device 420 used by the second user 422 over a network such as a LAN, wireless network, the Internet, and/or the like. ) is transmitted. A second user 422 utilizing an ICTO-aware application, device, or operating system wakes up the ICTO 408 receiving a request to access protected data 1 in the ICTO 408 . The ICTO 408 verifies the identity of the second user 422 , which processes the multiple challenge/response pairs stored in the ICTO 408 , and/or whether the second user 422 is valid and authorized. It may include authorization for verification, and the like. Additionally, the trusted service 409 may be used for further checking of time, physical location, etc. based on access rules specified by the owner 418 . Once the identity of the second user 422 is verified (ie, established as genuine and legitimate), the ICTO 408 determines one or more cloaking patterns used to generate the protected data 1 410 , and the protected data 1 410 is declocked to reveal data 1 404 to the second user 422 . Second user 422 may also request to access protected data 2 412 . However, second user 422 is not allowed to access protected data 2 412 because the second user is not authorized to access protected data 2 in ICTO 408 .

Although a trusted service 409 that provides authentication services has been described, other types of trusted services may be used. For example, if the ICTO 408 contains a rule to allow access only for a given period of time, then a trusted service 409 that provides a trusted date-time value can be used. As another example, the trusted service 409 may seek input from other users while the ICTO 408 is determining whether the agent is allowed access. As shown, the trusted service 409 may notify the first user 418 of the access attempt via email, SMS, or any other suitable technique, before a corresponding authorization is received from the first user 418 . It can wait until the attempted access is granted.

This use case illustrates some of the benefits of this posting. Once the ICTO 408 is created, protected data 1 410 and protected data 2 412 cannot be accessed without invoking the processing of the ICTO 408 to request access. Thus, the data is transmitted by the ICTO 408 to the second computing device 416 when the ICTO 408 is stored on the first computing device 416 , when the ICTO 408 is transmitting on the network 402 . When stored, it is protected. Also, although the ICTO 408 provides the second user 422 with access to data 1 404 , data 2 406 is nevertheless protected from access.

Although this simple use case represents some of the features of this post, much more complex use cases are also possible. For example, FIG. 5 is a schematic diagram illustrating aspects of an exemplary workflow for an embodiment of this disclosure. A first user (“User A”), while maintaining confidentiality throughout the transaction, provides access to a second user (“User B”), a third user (“User C”), and a fourth user (“User D”). may have a set of documents (“Documents X, Y, and Z”) to be approved and signed by Document X needs to be signed by user B. Document Y needs to be signed by user B and user C only after document X is signed. Document Z needs to be signed by user D only after documents X and Y have been signed. Additionally, Document X and Document Y must be signed during business hours (eg, 9:00 am to 5:00 pm) to ensure compliance with local company policies, and Document Z (working draft of Document Y) must be As soon as the signatures of X and Y are approved, they must be signed, the audit is loaded, after which document Z is destroyed if the audit is also logged.

Embodiments of this disclosure will support this workflow. User A creates an ICTO comprising 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 a signature for document X is obtained. user A creates an access rule on document X that allows user C to verify document X to verify a signature (or an access rule on document X may detect a signature provided on document X); When a signature is detected, it is possible to dynamically update the access rules for document Y that allow document Y to be signed. User A creates an access rule for document Z that checks signatures for documents X and Y, and if these signatures are detected, user D is allowed to sign document Z. Each of these rules also enforces the associated time requirements and disallows access unless the time requirements are met. User A can also create a rule to report any access to any documents to user A, so that user A can monitor the processing. Each of the rules may specify how each user is identified, associated privileges, devices from which users are permitted to access documents, and locations from which users are permitted to access documents.

For example, when user B receives an ICTO, user B invokes an application configured to activate executable code within the ICTO. The executable code determines the identity of user B by referencing a trusted identity service, verifying a response to a challenge contained in a rule, or in any other way. If identity, time, location, and other requirements are met, user B is allowed to access document X, but not to any other documents. After user B signs document X, the ICTO is passed on to the next user, and as the ICTO goes through the rest of the workflow, the protections for the documents are enforced.

Alternatively, for example, user B receives the ICTO, and user B invokes the ICTO-aware application that activates the PDRS in the ICTO. The executable code determines the identity of User B utilizing identity credentials stored in the ICTO, representing multiple challenge/response pairs and/or external authorization codes. If identity, time, location, and other requirements are met, user B is allowed to access document X, but not to any other documents. After user B signs document X, the ICTO is passed on to the next user, and as the ICTO goes through the rest of the workflow, the protections for the documents are enforced.

In another exemplary embodiment, a protection protocol is introduced into a portable identity appliance (PIA). PIA defines portable and discrete digital identities using reflective and automatic authentication methods. The PIA ultimately implements a unified ICTO protocol, thus becoming an intelligent object in itself. In some embodiments, the PIA is an ICTO that does not contain owner data (eg, files, images, etc.). PIAs include ICTOs that utilize PDRS based on additional publicly available information about the owner (similar to information on business cards or public directories), but do not necessarily include owner data. Thus, the PIA is a self-protecting, self-regulating, self-managing ICTO with the purpose of undisputed representation of the owner's identity.

10-13, once a protected PIA is created, it creates a protected data object, facilitates secure message transmission between one or more parties (e.g., enforces sender and receiver legitimacy and data integrity) data to provide a secure and trusted identity that can be used to endorse or monitor web sites, portals, networks, or other resources.

Thus, PIA provides significant advantages over existing signature technologies. Existing signature technologies are typically based on certificates purchased from a certificate authority. Certificates are considered worthy of trust based on who has the certificate and who issued the certificate. However, credentials may be stolen, spoofed, and not based on a uniquely defined identity.

Thus, the ICTO can be used for undisputed verification of the identity for which a "signature" is required. Signatory ICTOs can be used as external identity verifications associated with ICTOs, including legal documents requiring full identity verification. The signature ICTO(s) may be (embedded) part of the "final" legal documents contained in the original ICTO. Moreover, the signature ICTO(s) can be included (ie nested) within the ITO as additional protected data elements in addition to the owner documents requiring a signature, thus pre-pre-receiving the requested signers traveling with the documents. Define and provide pre-validation. The signature ICTO(s) can also be used as an irrefutable identity verification in documents that are not included in ICTO but are included in ICTO-aware applications. For example, they may be used to electronically provide for acceptance of conditions or to provide acknowledgment of privacy notices.

Signing ICTOs, in the context of document signing, can be considered "legally verified and notarized" but also the owners of the indisputable digital version. As with ICTOs with owner data, each signature ICTO is unique and therefore is not "spoofed" by a person or entity pretending to be the real owner of the signature ICTO. Additionally, the signature ICTO must not represent a person; As it may represent a machine, the digital processing flow requests signatures along the way to validate the authorization to be processed; This signature must be documented. Signature ICTOs can be used wherever standard digital signatures are required today, but are not limited to how digital signatures are used today. As mentioned above, in some embodiments it must be ICTO-aware as a prerequisite to use.

Those of 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, since portable dynamic rule sets contain executable code, an ICTO can protect executable, executable content only when it meets the security checks of the ICTO. In addition, since the ICTO can execute such content in response to success or failure to any rule, the ICTO can take actions such as logging successful accesses or alerting the data owner, so that when it detects an unauthorized access attempt, it can self - Initiate a destruction sequence or other actions.

Alternatively, there are many other use cases for the subject matter published herein. For example, since the ICTO contains executable code for independent self-management, the ICTO can only protect accessible content when it is included in the ICTO and meets the rules and security checks for access specified by the data owner. . In addition, in response to the success or failure of any rule, the ICTO may take actions such as logging such accesses and/or alerting the data owner to detect an unauthorized access attempt, a self-destructive sequence or other action. start them

6 is a block diagram illustrating an exemplary hardware architecture of a computing device 500 suitable for use with embodiments of this disclosure. Those skilled in the art and others will appreciate that computing device 500 may include, but is not limited to, desktop computers, server computers, laptop computers, embedded computing devices, application specific integrated circuits (ASICs), smartphones, It will be appreciated that it may be any one of any number of devices currently available or still in development, including table computers, and/or the like. In its most basic configuration, computing device 500 includes at least one processor 502 and system memory 504 coupled by a communication bus 506 . Depending on the exact configuration and type of device, system memory 504 may be either volatile or non-volatile memory, such as read-only memory (“ROM”), random access memory (“RAM”), EEPROM, flash memory, or similar memory technology. can Those of skill in the art and others will recognize that system memory 504 typically stores data and/or program modules that can be accessed immediately and/or are currently being operated on by processor 502 . In this regard, the processor 502 acts as the computational center of the computing device 500 by supporting the execution of instructions.

As further shown in FIG. 6 , computing device 500 may include a network interface 510 that includes one or more components for communicating with other devices over a network. Embodiments of this disclosure may access basic services that utilize network interface 510 to perform communication using common network protocols. In the example embodiment shown in FIG. 6 , computing device 500 also includes a storage medium 508 . However, services may be accessed using a computing device that does not include means for persisting data to a local storage medium. Accordingly, the storage medium 508 shown in FIG. 6 is dashed to indicate that the storage medium 508 is optional. In any event, storage medium 508 can be any storage medium 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, magnetic tape, magnetic disk storage, etc. It may be volatile or non-volatile, removable or non-removable, implemented using technology.

As used herein, the term "computer readable medium" refers to volatile embodied in any method or technology that can store information, such as computer readable instructions, data structures, program modules, or other data. and non-volatile and separable and non-removable media. In this regard, the system memory 504 and storage medium 508 shown in FIG. 6 are merely examples of computer-readable media.

Suitable implementations for computing devices including a processor 502 , system memory 504 , communication bus 506 , storage medium 508 , and network interface 510 are known and commercially available. For ease of illustration, and not so critical to understanding the claimed subject matter, some of the typical components of many computing devices are not shown in FIG. 6 . In this regard, computing device 500 may include input devices such as a keyboard, mouse, microphone, touch input device, and/or the like. Likewise, computing device 500 may also include output devices such as display devices, speakers, printers, and/or the like. Since all these devices are well known in the art, they are not further described herein.

Accordingly, the embodiments and examples described herein are in accordance with the principles of the present invention to enable those skilled in the art to best utilize the invention in various embodiments and with various modifications considered suitable for the particular use. and it is to be understood that it has been chosen and described to best represent its practical application. While specific embodiments of this invention have been described, they should not be considered exhaustive. There are several variations that will be apparent to those skilled in the art.

102: object description
104: mixture metadata
106: owner data
107: clocking patterns
109: identity module

Claims (21)

A computer-implemented method of data security comprising:
providing a computer-based intelligent cryptographic transfer object comprising a portable dynamic rule set comprising machine-executable code protected by one or more external cloaking patterns;
reversing external clocking patterns to retrieve the machine executable code;
Execute the machine executable code, in response to:
using the portable dynamic rule set to verify the identity of a foreign agent;
when verifying the identity of the foreign agent, storing data indicative of the identity of the foreign agent in the computer-based intelligent cryptographic transfer object; and
and protecting data indicative of the identity of the foreign agent using one or more internal cloaking patterns. 2. The method of claim 1, wherein the intelligent cryptographic transfer object comprises a portable identity appliance. The computer of claim 1 , wherein the intelligent cryptographic transfer object is configured to grant access to authorized portions of the protected data set while disallowing access to unauthorized portions of the protected data set. - Implemented data security methods. The intelligent cryptographic transfer object of claim 1, wherein the intelligent cryptographic transfer object comprises digital participants comprising the portable dynamic rule set, and wherein the intelligent cryptographic transfer object comprises cloaking patterns that are randomly applied to all or some of the digital participants. A computer-implemented method of data security. 5. The method of claim 4, wherein the random cloaking patterns create a unique protection scheme each time the cloaking patterns are applied to digital participants. 2. The method of claim 1, wherein the intelligent cryptographic transfer object comprises owner data protected by the one or more internal cloaking patterns. 2. The method of claim 1, wherein the internal cloaking patterns are used to clock at least a portion of the portable dynamic rule set. The method of claim 1, wherein the intelligent cipher transfer object is configured to be accessed by at least one of an intelligent cipher transfer object-aware application, an operating system, a computer chip, a switch, a control panel, or an FGPA. A computer-implemented method of data security. The intelligent cryptography of claim 1 , wherein the intelligent cryptography is for at least one of verifying signatures, enabling secure messaging of protected data, or guaranteeing access to at least one of web sites, portals, or networks. The computer-implemented method of securing data, further comprising using a forwarding object. 10. The method of claim 9, wherein verifying the signatures does not use a certificate obtained from a certificate authority. 2. The method of claim 1, further comprising generating an audit trail of attempts to access the intelligent cryptographic transfer object. 12. The method of claim 11, wherein generating the audit trail comprises: (i) recording attempts to access the intelligent password delivery object in an embedded log; (ii) responding to unauthorized attempts to access the intelligent password delivery object; and (iii) alerting a data owner to an unauthorized attempt to access said intelligent cryptographic transfer object. In the system:
providing a computer-based intelligent cryptographic transfer object comprising a portable dynamic rule set comprising machine-executable code protected by one or more external cloaking patterns;
reversing external clocking patterns to retrieve the machine executable code;
Execute the machine executable code, in response to:
using the portable dynamic rule set to verify the identity of a foreign agent;
when verifying the identity of the foreign agent, storing data indicative of the identity of the foreign agent in the computer-based intelligent cryptographic transfer object; and
and one or more computer processors programmed to perform operations comprising protecting data indicative of the identity of the foreign agent using one or more internal cloaking patterns. 14. The system of claim 13, wherein the intelligent cryptographic transfer object comprises a portable identity appliance. 14. The system of claim 13, wherein the intelligent cryptographic transfer object is configured to grant access to authorized portions of a protected data set while disallowing access to unauthorized portions of the protected data set. . 14. The method of claim 13, wherein the intelligent cryptographic transfer object comprises digital participants comprising the portable dynamic rule set, and wherein the intelligent cryptographic transfer object comprises cloaking patterns randomly applied to all or some of the digital participants. to do, system. 14. The system of claim 13, wherein the intelligent cryptographic transfer object includes owner data protected by the one or more internal cloaking patterns. 14. The method of claim 13, wherein the actions are for at least one of verifying signatures, enabling secure messaging of protected data, or ensuring access to at least one of web sites, portals, or networks. and using the intelligent cryptographic transfer object. 14. The system of claim 13, wherein the actions further comprise generating an audit trail of attempts to access the intelligent cryptographic transfer object. 20. The method of claim 19, wherein generating the audit trail comprises: (i) recording attempts to access the intelligent password delivery object in an embedded log; (ii) for unauthorized attempts to access the intelligent password delivery object; at least one of defending, or (iii) warning a data owner of an unauthorized attempt to access the intelligent cryptographic transfer object. A non-transitory computer-readable medium having instructions stored thereon:
When executed by one or more computer processors, the computer processors cause:
providing a computer-based intelligent cryptographic transfer object comprising a portable dynamic rule set comprising machine-executable code protected by one or more external cloaking patterns;
reversing external clocking patterns to retrieve the machine executable code;
Execute the machine executable code, in response to:
using the portable dynamic rule set to verify the identity of a foreign agent;
when verifying the identity of the foreign agent, storing data indicative of the identity of the foreign agent in the computer-based intelligent cryptographic transfer object; and
A non-transitory computer-readable medium having stored thereon instructions for performing operations comprising protecting data indicative of the identity of the foreign agent using one or more internal cloaking patterns.

Images