JP6982142B2 - Systems and methods for protecting data using cryptographic objects - Google Patents

Description

Cross-reference to related applications This application claims priority to US Provisional Patent Application No. 61 / 980,617 filed April 17, 2014, with priority in whole or in part. Given. The specification, drawings, and full disclosure of US Provisional Patent Application No. 61 / 980,617 are incorporated herein by reference in their entirety for all purposes.

The present invention relates to systems and related methods for protecting and controlling data, including, but not limited to, the use of intelligent cryptographic transfer objects with and without self-encryption and self-control.

Current techniques for protecting data have certain drawbacks. Usually, information is often encrypted because other security measures, such as network IAM and PAC applications, can no longer control the use of information when the information is outside a trusted environment such as a secure network. Protected by. In the current technique, the encryption key must exist inside the application or be revealed or handed over by the user or through the application in order to use the encrypted data, thereby protecting and confidential. It can damage your sexuality. Cryptographic keys can be stolen by snooping or APT attacks, or compromised by social engineering or other means. Further, once the encryption key (ie, password) is shared and the data is unlocked, control of the data is lost. Even if the data is in a trusted environment, such as behind a firewall or something similar, the file is available to anyone with access to the storage location and is therefore vulnerable to attack or misuse. Traditionally, information protection requires a team of people with network, BYOD, telecommunications, server and application expertise, and a level of security that requires enterprise-wide efforts to align and coordinate them all. Achieved, but nevertheless can be compromised by exploiting the flaws and inconsistencies inherent in complex integrity.

Typical data encryption relies on an algorithm that performs a predetermined procedure to encrypt and then reverses the procedure to decrypt. There could also be a process of moving pieces of data in a static pattern, cloaking the data, and then reversing the process to reveal a fully unencrypted file. Using this prior art method, an attacker who has learned the encryption algorithm used to encrypt data can break the encryption by reversing the encryption process.

Full homomorphic encryption attempts to remove the credibility of the relationship and make the credibility between the parties an irrelevant factor. For example, an outsourcer is only given access to an encrypted version of the data to perform processing that does not require decryption, so one party may be concerned about what the outsourcer will do with the data. You can send data to an outsourcer for storage or processing without having to trust it. However, fully homomorphic encryption is too cumbersome and impractical.

Another traditional technique for protecting data is the use of dynamic control. Dynamic control is application-dependent, such as password-protected PDF files generated and used by document viewing and editing software, generated by Adobe® or the like. Traditional dynamic control is application dependent or exists within the application. The rule is executed by the application. In addition to relying on key (password) exchange as described above, another drawback of this method is that application dependency rules may be overridden (in Adobe® Acrobat®). It is possible for the developer to write an application that ignores the rules imposed by the authoring application) or (as in the example of an open protected PDF).

Therefore, what is needed is a self-protecting and self-controlling data assurance method for both stationary and transmitting data, while maintaining functionality and efficiency both inside and outside a secure environment, for authentication. Less dependent on keys and passwords, less dependent on reversible cryptographic procedures for predictable protection, and less dependent on external applications for execution Is.

This overview is provided to introduce a simplified concept, further explained in the detailed description below. This summary is not intended to identify important features of the claimed object, nor is it intended to be used as a reference in determining the scope of the claimed object.

In some exemplary embodiments, the invention comprises a self-protecting, self-regulating intelligent cryptographic transfer object (ICTO), which can be stored on a computer-readable medium. The ICTO includes a set of participants including a portable set of dynamic rules (PDRS). PDRS receives a request from an agent for access to one, but not limited to, a part of a set of participants in response to execution by one or more processors or microprocessors of a computing device. Verify that you have permission to access the requested part of the participant, and the requested part of the agent without providing the agent with access to other parts of the participant set. Have the computing device perform actions, including providing access to. Also provided are computer implementation methods for creating such ICTOs and computing devices configured to execute the executable parts of such ICTOs.

In an exemplary embodiment, the invention is an ICTO recognition application, operating system, or similar, but not limited to, a computer chip, switch, control panel, FPGA, which activates the ICTO in response to an access request. Includes devices including things. ICTO includes, but is not limited to, a set of participants including owner data and PDRS. When the Dynamic Participant Controller (DPC) in the ICTO is activated remotely or locally, the PDRS in the ICTO takes control of the ICTO and the protected object is closed (ie, inactive or dormant). Maintain control until). PDRS is authorized through the dynamic participant controller to allow agents to access all or part of the genuine and protected dataset in response to agent access requests to all or part of the participant data. Verify that you are. Once validated, the agent can only access the authorized parts of the protected dataset, while the remaining protected datasets in the ICTO remain inaccessible to the agent. A computer implementation method for creating such an ICTO using an ICTO-aware application, operating system or device that activates such an executable portion of the ICTO is also provided.

In a further embodiment, a computer implementation method is provided that protects the set of participants. The computing device provides a set of participants to protect. One or more cloaking patterns are determined to protect the set of participants. The first cloaking pattern is used to protect or mix the first subset of the participant set, and the second cloaking pattern, which is different from the first cloaking pattern, protects the second subset of the participant set. Or used to mix. The determined cloaking pattern is applied to the participant set by the computing device to create a cloaking or mixed participant set. A set of cloaked participants is added to the ICTO by the computing device. Also, there is a computer executable instruction that causes a computing device to perform such a method in response to a computing device configured to perform this method or execution by one or more processors of the computing device. Computer-readable media stored therein are also provided.

In a further embodiment, the invention includes an ICTO recognition application, operating system or device that facilitates the method for protecting a set of participants. Participant sets are collected via an ICTO-aware application, operating system or device to create an intermediate pattern ICTO, which is a crypto engine or operation until the participant set and the ICTO are fully implemented. Includes a tentative or "starter" rule set provided by the Target Participant Controller. The intermediate pattern ICTO is cloaking by one or more cloaking patterns that are dynamically selected or created by the dynamic participant controller and applied. The tentative rule set is subsequently replaced with one or more specific or unique rule sets specified by the owner, and PDRS within the ICTO dynamically causes one or more cloaking patterns for each ICTO. And randomly selected or created. Cloaking patterns can be randomly applied to all or part of a participant, while additional cloaking patterns can be applied to all or part of a participant, with a unique cloaking part set for each ICTO. create.

In another embodiment, a computing device configured to access data protected or controlled by an ICT is provided. The computing device receives an access request from an agent attempting to access a portion of a participant stored or mixed within 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 permissible, access to the part of the participant requested by the agent is provided without providing access to the other part of the participant.

In yet another embodiment, the invention includes an ICTO-aware application, operating system or device that activates the ICTO upon receiving an access request from an agent. The dynamic participant controller in the ICTO is activated and the embedded PDRS acquires and maintains control of the ICTO in response. At least one rule of PDRS is enforced to evaluate whether the agent's access to all or part of the protected data is genuine and authorized. Even if the agent is authorized to access all or part of the protected data, the protected data that is not authorized to access remains protected and is not visible to the agent. An inactive ICTO cannot be accessed without an ICTO-aware application, operating system or device.

Many of the aforementioned aspects and accompanying benefits of embodiments of the present disclosure are easier to understand by reference in conjunction with the accompanying drawings, as the same is better understood by reference to the following detailed description. Will be recognized by.

FIG. 1 is a schematic diagram illustrating exemplary embodiments of data control according to various aspects of the invention. FIG. 2 is a flowchart illustrating an exemplary embodiment of a method of constructing an ICTO according to various aspects of the invention. FIG. 3 is a flowchart illustrating an exemplary embodiment of a method of accessing data protected by an ICTO according to various aspects of the invention. FIG. 4 is a schematic diagram showing an exemplary use case for an embodiment of the present invention. FIG. 5 is a schematic diagram showing an exemplary workflow mode for an embodiment of the present invention. FIG. 6 is a block diagram illustrating an exemplary hardware architecture of a computing device suitable for use in embodiments of the present invention. FIG. 7 is a schematic diagram illustrating an exemplary embodiment of data control according to another exemplary embodiment of the invention. FIG. 8 is a flowchart illustrating an exemplary embodiment of a method of creating an ICTO according to another exemplary embodiment of the invention. FIG. 9 is a flowchart illustrating an exemplary embodiment of access to an ICTO according to another exemplary embodiment of the invention. FIG. 10 is a diagram illustrating a portable identity appliance system according to another exemplary embodiment of the invention. FIG. 11 is a schematic diagram of a portable identity appliance used to create protected objects. FIG. 12 is a schematic diagram of a portable identity appliance used to facilitate the secure transmission of protected data. FIG. 13 is a schematic representation of a portable identity appliance used to guard access to websites, portal sites, networks, or other resources.

In some exemplary embodiments, the invention comprises a self-sufficient, self-protecting, self-regulating intelligent cryptographic transfer object (ICTO), which can be stored on a computer-readable medium. The ICTO includes a set of participants with a portable set of dynamic rules (PDRS). Computer implementation methods for creating, accessing, and using such ICTOs and computing devices configured to perform the executable parts of such ICTOs are also provided.

In various embodiments, the present invention addresses significant flaws in conventional data protection systems and methods. The existing scheme addresses perimeter defense, user access (both the user and the user's device) and anomaly detection, but since it is not attached to the data itself, the invention compensates for the flaws in the existing protection system. When prior art encryption is used, the burden of keycode management can reduce productivity, or its flaws can lead to further vulnerability by exposing keys that need to be protected as well. be.

The embodiments of the present disclosure provide a self-sufficient, self-protecting, self-dominant data-centric solution, which is part of a data set grafted with controls for data management, protection and operation. Means to directly monitor the access and use of the dataset. In some embodiments of the disclosure, certain data may be excluded from protection for analysis or use by authorized agents, but the exclusion method reverses one or more protection mechanisms. It is not predictable because it is not. The present invention includes unpredictable and irreversible systems and related methods for maintaining dynamic, portable, independent, persistent and intelligent data control over the lifetime of data. The system can protect data whether it is being stored or transmitted, and in the hands of trusted or untrusted data users.

In some embodiments of the disclosure, the data protection scheme is embedded within the dataset, grafted onto the dataset, and maintained within the dataset. Data protection schemes can also create an audit trail of data access attempts. While known or authorized users of the data are logged in the embedding log, attempts by unknown parties or other unauthorized access to the data are also logged in the embedding log and possess the data in real time. Can be sent and displayed to a person. When an unauthorized party attempts to access the data, self-protecting data defends itself, takes attack measures against intrusions, warns the data owner of unauthorized attempts, and / or any other appropriate. Can perform actions.

Data owners use protection schemes as a simple and lightweight management tool to continually verify a party's relationship to data. From the attacker's point of view, the system is unpredictable because all authorized parties have established identities built into the protection scheme. A unique protection scheme can be provided for each combination of owner, user and dataset, which means that the method by which the data is disclosed to the authorized party A is that the data is disclosed to the authorized party B. It means it's not a method.

Moreover, the unique protection schemes provided for combinations of owners, users, datasets and rule sets are also unique to themselves each time the same combination is later protected. That is, whenever a combination of owner, user, dataset and rule set is protected as described herein, the ICTO is uniquely protected, whether it is the same combination or a different combination. It becomes an ICTO.

In some embodiments, different techniques can be used to protect or access protected data. For example, irreversible protection schemes can be used to combine multiple pieces of data into a single digital mixture, while selective recovery means can be used to access other protected data in the digital mixture. Fragments of data can be selectively restored from a single digital mixture without obtaining it. In such an embodiment, when the data is properly accessed, the data is selectively disclosed based on the owner's intention to the authorized recipient. The information disclosure path has nothing to do with going back to the original step, and the original protection scheme used to combine multiple pieces of data is only for individually requested pieces of data. , Can be reversible. In other words, you can access the pieces of data stored by the protection scheme, but not the entire digital mixture in a way that allows you to reconstruct the entire original content. The embodiments of the present disclosure are configured to ensure that the identity of any user or entity is identified, whether or not it is included as a genuine participant, and the data owner is the identified authenticity. It controls which parts or pieces of data the user gains access to. Unauthorized parties may never access data in unprotected form, whether inside or outside the intended recipient or recipient's network. Embodiments of this disclosure clearly identify the identities of trusted parties before providing access to ensure the security of the data. Retrograde or reverse engineering of protection schemes will not give the original results.

In some embodiments of the disclosure, the rules are enforced by the executable portion of the digital mixture, with the absolute intent of the data owner without resorting to third parties or outsiders, applications, or operating systems. Guarantee that it will be executed. The protection scheme is not application or operating system dependent to protect and unprotect the data, i.e. the data is self-protecting and self-controlling. The protection scheme is independent of the operating system, environment, and applications (ie, external, centralized, or server key management, password management, and identity management applications). The method in the protocol is implemented in executable code stored in the data mixture and executed in response to the detection of the user's request to access the data through the constructed API. Moreover, the data can be of any type (eg, text, audio, video, or a combination thereof) and of any type of container, database or environment (eg, buffer, directory, file, or combination thereof). obtain. Any attempt to access data other than the API or other means described herein will be blocked by the applicable cloaking pattern, which is external to the component that implements the API. Or it cannot be weakened by any other component. When attempting to access data via API or other means described herein, the protection scheme ensures that only genuine users can access the data authorized by the data owner.

Other methods or other ICTO-aware applications, devices or operating systems initiated via the API first validate the ICTO. Subsequently, the outer cloaking technique finds an executable code, crypto engine or mixer stored within the digital mixture. The access request is received by the executable code via the API or other ICTO-aware application, device or operating system for the agent. When the executable code is activated or "awakened", the portable dynamic rule set gains control and retains control until the self-dominated data object is closed or hibernated. Any attempt to access a self-protecting, self-regulating digital mixture without invoking executable code will fail.

FIG. 1 is a schematic diagram illustrating exemplary embodiments of self-dominant data according to various aspects of the invention. The dynamic participant controller 110 or "mixer" is a digital component, including a description of authorized agents, device locations, rules for using data and / or other components, as further discussed below. Identify set 101 of (“participants”). By mixing these components, the mixer 110 creates a cloaked entity, the Intelligent Cryptographic Transfer Object (ICTO) 115. ICTO 115 is also referred to as a "digital mixture". As discussed herein, one of ordinary skill in the art will appreciate that the terms "ICTO", "digital mixture" and "self-dominated data" can be used interchangeably. To an unauthorized entity or third party viewing the ICTO 115 directly, the ICTO 115 will only look like a dataset. ICTO 115 appears externally as a homogeneous mixture without resembling or exposing the original ingredients. However, when accessed through an application that implements the API (such as mixer 110, ICTO-aware client application (not shown) and / or the like), the executable portion of ICTO 115 is accessed and ICTO 115 Can provide access to protected data controlled by.

In some embodiments, the executable portion of the ICTO 115 can be stored in a decidable location within the ICTO 115 so that the application implementing the API can easily find the executable portion. In some embodiments, additional protection is applicable to the ICTO 115 by storing one or more executable parts of the ICTO 115 in a displaceable location within the ICTO 115. These variable locations make it extremely difficult for unauthorized users to find the executable part of ICTO 115, but ICTO-aware applications that implement APIs to access ICTO 115 are based on the characteristics of ICTO 115. A variable location can be calculated for a given ICTO 115. For example, a secure application can read ICTO 115 attributes such as file size, creation time and / or similar, and use the attributes as seeds to perform calculations to determine location. By keeping the details of the calculation secret, the location of the executable part of ICTO 115 can be kept secret as well.

Participant set 101 may include object description 102, mixture metadata 104, owner data 106, cloaking pattern 107, identity module 109, and intelligence module 111. In some embodiments, the combination of the identity module 109 and the intelligence module 111 can be considered together as a portable dynamic rule set 108. The object description 102 may include owner-defined earmarks and owner-specific earmarks, data identifiers and / or characteristics. Owner data 106 may include data to be 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, for example, if the ICTO 115 is used only for signature verification methods that are not associated with the underlying signed data. In some embodiments, multiple fragments of owner data 106 can be included in a single ICTO 115. In some embodiments, owner data 106 from multiple owners can be included in a single ICTO 115.

The cloaking pattern 107 specifies various combinations of data protection and access techniques supported by the mixer 110. The data protection and access techniques included in Cloaking Pattern 107 may include industry standard validated encryption, compression, randomization, normalization and / or other techniques. Techniques suitable for use as the cloaking pattern 107 are not limited to currently known techniques, but any currently known or future developed privately or publicly available encryption and / or decryption. Techniques can also be included. The use of a cloaking pattern 107 for data protection and / or data access can be accompanied by applying a combination of data protection and / or access techniques identified in the cloaking pattern 107 to that data.

Mixture metadata 104 provides systematic information about the digital mixture 115, such as directories, keycodes, user files, signatures and / or virtual file system data including similar.

Identity module 109 may include a dynamic identity attribute that uniquely identifies the protection agent in a transaction. In some embodiments, the identity module 109 may include data representing the configuration of a computing device that has been given certain privileges to the protected object. The identity module 109 may include specific information about the hardware or software configuration installed on the computing device that can be used to identify the computing device. Identity module 109 includes, but is not limited to, model number, number of cores, speed, and / or CPU information including, chassis serial number, manufacturer data, volatile memory capacity, non-volatile memory capacity, 1. It may contain data including one or more storage device serial numbers and / or model numbers, installed software titles and / or version numbers, and / or similar.

In some embodiments, a transaction is an atomic action using ICTO 115 in which one or more agents securely exchange data with a given intention within a given context. Authorized agents include human and non-human entities such as human users, unique mechanical objects, unique electronic objects, unique software or program objects and / or similar. obtain. The dynamic identity attributes contained in the ICTO 115 can be modified by the Intelligence Module 111 during or during the process of interaction with the ICTO 115, including application-specified identifiers, account identifiers, biometric signatures, devices and /. Or it may include location signatures, time data, encryption keys and / or similar. In some embodiments, the location signature may include data from geolocation techniques such as GPS, GSM network positioning, IP address positioning, dead reckoning and / or the like. The location signature may include longitude, latitude, altitude, approximate address and / or similar. Additional location data such as streets, cities, states, countries, zip codes and / or similar may also exist. In some embodiments, the time data may include a time stamp and / or the like, whereby the rule or other intelligent code implements a timer, deadline management, dynamic key and / or the like. Will be possible. Time data can include simple date / time values or complex schedules that include timestamp ranges and / or other scheduling guidelines.

In some embodiments, each ICTO 115 comprises at least one digital signature key. The digital signature key can be validated using an external digital certificate available for the mixer 110. Upon accessing the ICTO 115, the mixer 110 verifies the validity of the digital signature key using an external digital certificate, and confirms that the digital signature key is valid for the agent currently accessing the ICTO 115. Verify. In some embodiments, multiple agents can sign the ICTO 115. In such an embodiment, the ICTO 115 may include a chain of signature keys, where each signature key can be associated with a separate external digital certificate for validation. For example, ICTO 115 can be used by one owner to create a protected file for transfer to multiple agents, with each agent simultaneously or sequentially in different sections of the file rather than the entire file. Can be accessed. Both the owner and the agent may have to provide a valid digital signature to allow the transaction to proceed.

The intelligence module 111 may include a dynamic rule set capable of recording and transmitting access data and other related history, as well as intelligent code that provides configurable functionality to perform actions that protect the ICTO 115. Rules can be provided when the object is created. However, in some embodiments, the rule may have the ability to modify the rule itself or other rules against the previously created ICTO 115. In some embodiments, the rule may have the ability to create additional rules. For example, a rule can determine from identity data that additional protection is desirable for a given ICTO 115. The rule can then create additional encryption and / or decryption rules to apply. The rules are protected and contained within ICTO 115. In some embodiments, the rule may only be executable by the executable portion of intelligence module 111 and / or may be written in a proprietary language and stored in compiled or binary format. .. Based on the rules and requirements of the identity module 109, the intelligence module 111 operates according to the rules and requirements. The application-specified identifier can vary from access to access, and can vary depending on the type of agent. For example, for human users, application-designated identifiers can include account keys, transaction information, context keys, related purposes and / or the like. Also, for electronic objects, digital assets or any other potential agent, the application-designated identifier can include IP addresses, URLs, file specifications and / or the like.

In some embodiments, one or more embedded portable dynamic rule sets have read / write access to the embedded participant 101 even while the participant 101 is protected by the ICTO 115. In other words, the rule can read and write to the mixture metadata 104 and owner data 106 of ICTO 115. This helps record access information such as date, time, location and the like, and / or destroy data when an attack is detected. Some examples of decisions or actions made by intelligent code in rules are, but are not limited to, evaluating object content and context for validity, challenging agents for identity verification, client code and Interacting, contacting the server for validation, self-destructing ICTO 115, keeping a history of object access, sending historical information to the server, online and / or offline object access Allowing, creating new rules based on dynamic server updates, encrypting and decrypting data, mangling and unmangaling data, and / or similar. Can include things.

The use of portable dynamic rules can have various benefits. For example, pre-encryption and pre-decryption rules can provide dynamic salt and encryption keys based on participant specification criteria. Such dynamic keys may be based on time data, environmental data or any other algorithm specified in the pre-encryption rules. As another example, the rule can access the encrypted identity artifacts in ICTO 115 to validate the agent without exposing unprotected data to unauthorized users. Since the rules are portable and are therefore contained within the ICTO 115, the rules can be written to adequately protect the ICTO 115 from unauthorized access, even offline or outside the network. As yet another example, rules can add nested protection. If ICTO 115 protects a document that is to be read by one agent within one hour of creation, the rule can implement a timer to issue a self-destruction mechanism.

As mentioned above, the embedded mixer 110 uses the embedded portable dynamic rule set 108 to constitute the self-protecting, self-dominant ICTO 115 object description 102, mixture metadata 104, owner data 106, Create a mixture of cloaking pattern 107, identity module 109 and intelligence module 111. In some embodiments, the various components of ICTO 115 can be marked by a coded checksum to detect tampering. For example, the entire ICTO 115, rules, owner data and / or user data can each be validated by a checksum. The checksum can be a hash value generated based on the content subject to the checksum. In some embodiments, the algorithm used to generate the checksum is sensitive enough to reliably detect changes in its single bit value, even in large documents. Some suitable algorithms include MD5 and SHA, but any other suitable algorithm can also be used. To store each checksum, it may be added to the end or beginning of the checksum target, or it may be combined with the checksum target in other ways, or it may be stored in a separate location. good.

FIG. 7 is a schematic illustrating other exemplary embodiments of self-sufficiency, self-control, and self-dominant data protection according to additional embodiments of the invention. The API or other ICTO-aware application, device, or operating system protects the digital participant set 701 by initiating and activating a request to the dynamic participant controller or executable mixer 702. Digital participants use authorized agents, devices, locations, and data that are collected and contained in a self-protecting, self-dominant data object (ie, digital mixture, or ICTO) 710, but not limited to these. Includes rules for, and / or other digital components as further described below. When the dynamic participant controller is activated when the object is configured, it creates an intermediate cryptographic object 703 with a tentative or "starter" rule set. The intermediate cryptographic object 703 is cloaked using one or more outer cloaking patterns 704 selected, generated or created by the algorithm generated by the mixer 702.

In some cases, additional protection or function, or a combination thereof, may be applied by storing one or more executable parts of the ICTO 710 in a displaceable location within the ICTO 710. The first entry point of the executable part of the ICTO 710 can only be calculated and found by the ICTO-aware application, operating system or device. Once the viable part, DPC702, is found and triggered, a table of unique offsets becomes available to DPC702 and the portable dynamic rule set 711 in ICTO 710 can be found, which is the activity of ICTO 710. Get and maintain control inside.

The digital participant set 701 may include, but is not limited to, an outer cloaking pattern 704, a mixture metadata 705, an owner data 706, an inner cloaking pattern 707, an identity module 708, and an intelligence module 709. In some embodiments, the combination of the inner cloaking pattern 707, the identity module 708 and the intelligence module 709 can be considered together as the Portable Dynamic Rule Set (PDRS) 711. Owner data 706 that should be protected within the ICT 710 and controlled by PDRS 711 is, but is not limited to, images, videos, messages, emails, documents, files, buffers, directories, pointers to remotely stored data, May include portals, and the like. In some embodiments, the owner data 706 is optional and may not be included, for example when the ICTO 710 is simply used as an irrefutable and reliable signature verification method. In some embodiments, multiple fragments of owner data can be mixed into a single ICTO. In other embodiments, owner data from multiple owners can be included in a single ICTO. In a further embodiment, a plurality of ICTOs can be mixed into a single ICTO.

The inner cloaking pattern 707 specifies various combinations of data protection and access techniques as determined by the owner rules set forth in the portable dynamic rule set 711 and supported by the dynamic participant controller or mixer 702. .. Data protection and access techniques included in the inner cloaking pattern 707 may include, but are not limited to, industry standard encryption, proprietary encryption, compression, randomization, normalization, and similar techniques. .. Suitable techniques for use as the inner cloaking pattern 707 are not limited to currently known techniques, but any privately or publicly available coding and / or currently known or future developed techniques. Decoding techniques can be included. The use of the inner cloaking pattern 707 for data protection and / or data access involves applying the combination of data protection and / or access techniques specified in Portable Dynamic Rule Set 711 to data and other participants. obtain.

The outer cloaking pattern 704 is selected via one or more algorithms calculated, used, or generated by the dynamic participant controller 702 that uses the intermediate rule set to create the intermediate cryptographic object 703. Specify various combinations of protection and access techniques. Data protection and access techniques included in the outer cloaking pattern 704 may include, but are not limited to, industry standard validated encryption, compression, randomization, normalization, and similar techniques. Techniques suitable for use as the outer cloaking pattern 704 are not limited to currently known techniques, but any privately or publicly available coding and / or decoding currently known or developed in the future. Techniques can also be included. The use of the outer cloaking pattern 704 for data protection and / or access may involve applying the combination of data protection calculated by the dynamic participant controller 702 and specified by the intermediate rule set. Mixture metadata 705 provides systematic information about the digital mixture 710, such as, but not limited to, directories, user files, and virtual file system data including the like.

The identity module 708 may include a dynamic identity attribute that uniquely identifies a legitimate agent in a transaction. Dynamic identity attributes can be, but are not limited to, learned information added to the identity module within the PDRS, such as location, device, and access behavior. The learned information is collected and used in future access request sessions to add additional intelligence and decision points. In addition, dynamic identity attributes may have volatile (ie, unpredictable) details. They may be presented during the authentication process, alone or with personal identity attributes, during the validation decisions of agents requesting access to the ICTO.

In some embodiments, the identity module 708 may include data representing the configuration of a computing device to which certain rights may be granted to the protected object. The identity module 708 may contain information about the hardware or software configuration installed on the computing device that can be used to identify the computing device. The identity module 708 is, but is not limited to, CPU information including model number, number of cores, speed, and / or similar, chassis serial number, manufacturer data, volatile memory capacity, non-volatile memory capacity, one or more. It may contain data including the serial number and / or model number of the storage device, the title and / or version number of the installed software, and / or the like.

In some embodiments, a transaction is an atomic action with ICTO 710 in which one or more legitimate authorized agents securely exchange data or information for a particular purpose in a given context. .. Legitimate authorized agents include human and non-human entities such as human users, unique mechanical objects, unique electronic objects, unique software or program objects, or the like. Can include. The dynamic identity attributes contained in the ICTO 710 can be modified by the Intelligence Module 709 within or during the process of interaction with the ICTO 710, and are not limited to, but are limited to, application-specified identifiers, accounts. It can include identifiers, biometric signatures, device and / or location signatures, time data, encryption keys or data, and the like. In some embodiments, the location signature may include data from geolocation techniques such as GPS, GSM network positioning, IP address positioning, dead reckoning, and the like. Location signatures can include longitude, latitude, altitude, approximate address and the like. Additional location data such as streets, cities, states, countries, zip codes and / or similar may also exist. In some embodiments, time data may include time stamps or the like, which allows rules or other intelligence codes to implement timers, deadline management, dynamic keys and the like. become. Time data can include simple date / time values or complex schedules that include timestamp ranges and / or other scheduling guidelines.

In some embodiments, each ICTO 710 comprises one or more human or non-human digital signature requirements. During authentication by ICTO 710, the boatable dynamic rule set 711 determines if a digital signature is valid for a legitimate agent requesting access to information controlled by PDRS711. In some embodiments, a plurality of legitimate agents can verify the permissions of other legitimate agents. In such an embodiment, PDRS711 implements a chain of digital signature requirements, where each digital signature is associated with a separate legitimate agent. For example, the ICTO 710 may be used by an owner to create a self-controlled file for approval, signing, and transfer to multiple legitimate agents, where each legitimate agent is a file. You can access different sections of the file simultaneously or sequentially, rather than the entire file. Both the owner and the legitimate agent may have to provide a valid digital signature to proceed with the transaction.

The intelligence module 709 may include a dynamic rule set capable of recording and communicating access data and other related events, as well as intelligent code that provides configurable functionality to perform the actions that govern the ICTO 710. Rules can be provided when the object is created. However, in some embodiments, the rules may modify themselves, or other rules of a given ICTO 710 instance. In some embodiments, the rule can create additional rules. For example, the rule can determine that additional protection is desirable for a given ICTO 710 when authenticating a legitimate agent. The rule may then create additional access, defense, cloaking and similar requirements. In some embodiments, the rule can only be executed in the dynamic participant controller 702, or can be stored in binary form as an ICTO participant or a combination thereof. Based on the rules and requirements of the Identity Module 708, the Intelligence Module 709 operates according to the rules and requirements as provided by the Owner Agent. The portable dynamic rule set 711 identifier can vary from access to access and from agent type. For example, for a human user, the portable dynamic rule set 711 designation identifier may include account keys, transaction information, context keys, related purposes and the like. Also, for electronic objects, digital assets or any other potential agent, the portable dynamic rule set 711 identifier may include IP addresses, URLs, file specifications and the like.

In some embodiments, the rule has read / write access to the digital participant 701 even while the digital participant 701 is protected by the ICTO 710. In other words, the rule can read and write to the mixture metadata 705 and owner data 706 of ICTO 710. This helps record access information such as date, time, location, and similar, and in some cases destroys data when an attack is detected. Some examples of decisions or actions made by the Intelligence Module 709 are, but are not limited to, assessing object content and context for effectiveness, challenging agents for identity verification, and interacting with client code. Acting, contacting the server for reliability verification, self-destructing the ICTO 710, maintaining a history of object access, sending history information to the server by email, SMS, FTP or ICTO 710 Store in, allow online and / or offline object access, create new rules based on dynamic server updates, perform data clogging and decroking, and data mangling and demangling. May include doing.

The use of the portable dynamic rule set 711 has various benefits and purposes. In one exemplary embodiment, access rules may utilize unique keys based on owner-designated criteria that are internally generated and managed internally. The unique key may be based on time data, environmental data, or any other algorithm specified by the owner rule set. As another example, the rule may access protected identity artifacts within ICTO 710 to authenticate and validate agents without exposing protected data to the public. As yet another example, since the rules are self-sufficient, portable, and platform independent, they are included in the ICTO 710, so that the rules are sufficient to take the ICTO 710 from unauthorized access even when offline. It can be described so that it can be protected.

As a further example, the rule may add nested protection. If the ICTO 710 protects one or more ICTO 710s within the current or outer ICTO 710, the outer ICTO 710 communicates with one or more ICTO 710s managed as part of each owner data 706. It can be possible. The outer ICTO 710 can enforce the rules managed within any ICTO 710 contained in the owner data 706 of the outer ICTO 710, or vice versa, or one or more ICTO 710s contained therein. You can create new rules as a result of the rules contained in. In another embodiment, the rules embedded in PDRS711 of ICTO710 are self-dominant. If the ICTO 710 protects a document that is supposed to be accessed by one legitimate agent within one hour of creation for up to one hour after access, the rule implements a timer and issues a self-destruction mechanism after the period expires. can do.

As mentioned above, the dynamic participant controller 702, or mixer, uses the portable dynamic rule set 711 to configure the outer cloaking pattern 704, mixture metadata 705, owner data 706, inner cloaking that make up the ICTO 710. Create a mixture of pattern 707, identity module 708 and intelligence module 709. In some examples, various components of the ICTO 710 may be combined for a coded checksum to detect tampering. For example, the entire ICTO 710, rules, owner data and / or participant data 712 can each be validated by a checksum 712. The checksum 712 can be a hash value generated based on the content of interest of the checksum 712. In some embodiments, the algorithm used to generate the checksum is sensitive enough to reliably detect changes in its single bit value, even in large documents. Some suitable algorithms include MD5 and SHA, but any other suitable algorithm can also be used. To store each checksum, it may be added to the end or beginning of the checksum target, or it may be combined with the checksum target in other ways, or it may be stored in a separate location. good.

FIG. 2 is a flow chart illustrating exemplary embodiments of method 200 for constructing ICTO 115 according to various aspects of the present disclosure. Although the method 200 shown describes the creation of a relatively simple ICTO 115, it will be appreciated by those skilled in the art that similar techniques can be used to create a much more complex ICTO 115. In some embodiments, the mixer 110 is configured to perform method 200. In some embodiments, the method 200 is performed by a computing device configured to provide the functionality of the mixer 110, as described below. To those skilled in the art, none of the construction and utilization of ICTO 115 will depend on the type of computing device or any operating system associated with the computing device, but instead of any suitable. It will be recognized that it can be constructed and utilized through means.

From the starting block, method 200 proceeds to block 202, where a set of common digital components or participants is obtained. The common participant is Participant 101, which can be used in multiple ICTOs 115 or have at least similar corresponding components in multiple ICTOs 115 and is mixed for inclusion in ICTOs 115. Designated and / or generated by vessel 110. For example, the object description 102, the mixture metadata 104, the cloaking pattern 107, the identity module 109 and the intelligence module 111 can all be common participants. Then, in block 204, the dynamic participant controller (“mixer”) 110 is initialized. In some embodiments, initialization of the mixer 110 may include verifying that the mixer 110 is being performed by an application that is expected or otherwise trusted. At block 206, the mixer 110 receives one or more pieces of owner data 106 to be protected. As discussed above, in some embodiments, the owner data 106 may be optional and uses the access protection feature of ICTO 115 to verify user identity and / or obtain a signature from the user. be able to.

Method 200 proceeds to block 208, where the mixer 110 causes the portable dynamic rule set 108 to run. At block 210, the intelligence module 111 of the portable dynamic rule set 108 determines one or more identity-based cloaking patterns to be used to protect the participant 101, and at block 212, the mixer 110 is one. Alternatively, a plurality of cloaking patterns are applied to Participant 101 to create a cloaking Participant set.

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 data to be protected. Different cloaking patterns can be applied to each participant 101. In addition, each Participant 101 can be protected using a separate cloaking pattern for access by different agents. In other words, the participant 101, such as the owner data 106, can be protected by the first cloaking pattern for access by the first agent and by the second cloaking pattern for access by the second agent. Can be protected. The choice of cloaking pattern may be based on the attributes of the participant 101 to be protected, the attributes of the agent to give access to the data, location, purpose and / or any other appropriate information. The choice of cloaking pattern may include choosing from existing cloaking patterns and / or creating new cloaking patterns from a combination of protection techniques supported by the mixer 110. A record of the applied cloaking patterns can be stored in the mixture metadata 104.

The cloaking pattern describes the transformations applied to Participant 101 to protect Participant 101 in ICTO 115 and how those transformations can be reversed to access Participant 101. .. Transformations can 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, which can improve transport time and bandwidth usage. Data compression can be performed by any suitable lossless compression algorithm, including but not limited to DEFLATE, LZW, LZR, LZX, JBIG, DjVu and / or the like. Data normalization is performed by any suitable process that puts the data in a format that can be processed efficiently. In some embodiments, the data can pass through a Base64 coding algorithm to convert the data into a normalized alphanumerical string, whether in binary or text format. This is just an example and should not be considered limiting. In other embodiments, other algorithms can be used to normalize the data.

In some embodiments, the cloaking pattern allows the identity module 109 and the intelligence module 111 to apply different cryptographic techniques to different components of the participant 101. For example, the first encryption rule, when implemented, identifies and encrypts the first part of the encrypted digital mixture 115 and leaves the second part of the encrypted digital mixture 115 unchanged. Can be. The second encryption rule, when implemented, uses different encryption algorithms, different encryption keys and / or similar to identify and encrypt the second part of the encrypted digital mixture 115. Can be converted.

In some embodiments, the cloaking pattern and / or portable dynamic rule set 108 can establish two or more nested layers of encryption. For example, the execution of the first encryption rule can encrypt the first part of the encrypted digital mixture 115. Execution of the second encryption rule, along with the first encryption rule and the corresponding first decryption rule, re-encrypts the encrypted first portion of the encrypted digital mixture 115. be able to. Therefore, in order to access the first part of the encrypted digital mixture 115 later, the second decryption rule corresponding to the second encryption rule is executed, and the encrypted digital mixture 115-2. The heavily encrypted first portion is decrypted to give the first decryption rule. The first decryption rule is then executed to decrypt the first portion of the encrypted digital mixture 115 and generate a plaintext version of the first portion of the digital mixture 115.

When the cloaking pattern is applied to the participant 101 to create a cloaked participant set, method 200 proceeds to block 214, where in block 214 the mixer 110 creates a digital mixture (ICTO) 115. , Add the cloaked participant set to the digital mixture 115. In some embodiments, additional protection such as data shuffling, additional encryption or digital signatures and / or the like can be applied to the entire digital mixture 115. Method 200 then proceeds to the end block and ends.

Those skilled in the art will appreciate that certain steps have been omitted from FIG. 2 for ease of discussion. However, other steps not explicitly shown in FIG. 2 can be included in Method 200 without departing from the scope of the present disclosure. For example, if an error is detected while applying the cloaking pattern or executing the rule, method 200 may stop and not generate the finished ICTO 115. As another example, in some embodiments, the owner data 106 may include one or more ICTOs as a method of providing nested protection. In some embodiments, the rules within the nested ICTO can provide access to the participant data 101 within the outer ICTO 115. In some embodiments, the rules within the first ICTO cause the second ICTO to be created so that the first ICTO is nested inside the second ICTO. Can be added to the ICTO of. Similarly, in some embodiments, the rules within the first ICTO cause the second ICTO to be created so that the second ICTO is nested inside the first ICTO. Can be added to the first ICTO.

FIG. 8 is a process flow illustrating alternative and exemplary embodiments of method 800 for constructing ICTO 710 according to various aspects of the invention. The illustrated method 800 illustrates the creation of a simple ICTO 710. However, similar techniques can be used to construct complex ICTO 710s. In some embodiments, an ICTO-aware application, device or operating system is configured to initiate and facilitate Method 800. Whether the ICTO is simple or complex, its construction and utilization is independent of any particular operating system or device.

From start 801 the method 800 begins with the dynamic participant controller 702 or mixer initialization 802. In some embodiments, the mixer initialization 802 is that the object is a genuine ICTO and / or the initialization request is from an ICTO-aware application, device, operating system and / or other ICTO-aware process. It may include confirming the validity of the thing. Proceeding to block 803, the digital participant set 701 is provided to the mixer 702 for inclusion in the ICTO 710. The digital participant set may be used in multiple ICTO 710s, or at least similar or common components may be in multiple ICTO 710s. For example, the outer cloaking pattern 704, the mixture metadata 705, the additional cloaking pattern 707, the identity module 708, and the intelligence module 709 can all be considered as a common digital participant set 701. Proceeding to block 804, the mixer 702 using one or more algorithms selects one or more outer cloaking patterns 704 and applies them to the digital participant set 701 to create an initial cloaking pattern for the ICTO 710. Create an initial intermediate cryptographic object 703 using the intermediate rule set. Proceeding to block 805, one or more owner data elements are added to the digital participant set for inclusion in the ICTO 710. In some embodiments, the owner data 706 may be optional and the access protection features of the ICTO 710 can be used to verify the legitimate agent identity and / or the legitimate agent signature.

Method 800 proceeds to block 806, where the owner rule is taken from PDRS 711 and utilized by the mixer 702 to replace the intermediate rule set used in the early creation of ICTO 710. Proceeding to block 807, the mixer 702 uses one or more algorithms to select one or more inner cloaking patterns 707 and is part of or a part of the digital participant set 701 including owner data 706. Apply to all. The algorithm further randomizes the inner cloaking pattern 707 using time and owner rules as unique numbers. The algorithm used is added to the identity module 708, managed internally by PDRS711 and not shared externally. Finally, at block 808, mixer 702 completes the construction of ICTO 710 to create a set of cloaked digital participants 720. While similar or common digital participant sets 701 can be used as provided in block 803, the method also creates a unique digital mixture 808 for each constructed ICTO 710.

The mixer 702, which uses one or more algorithms, randomly applies time as a unique number and other internal factors generated by the intelligence module 709, while which inner cloaking pattern is applied to each digital participant set 701. Decide if it should be applied. The algorithm used by the mixer 702 to select the inner cloaking pattern 707 is then added to the identity module 708, managed internally, and not shared / exchanged / exposed to the outside of the ICTO 710. Each participant 701 may be protected using one or more inner cloaking patterns 707 that may be uniquely different from the one or more inner cloaking patterns 707 that protect the other participants 701 of the digital mixture 710. .. For example, a participant such as owner data 706 may have one or more cloaking patterns and internals that are uniquely different from the one or more cloaking patterns 707 and internal rules used to protect the identity module 708. Can be protected by rules. In addition, the use of one or more inner cloaking patterns 707 and the use of time and internal rules as unique numbers creates unique cloaking patterns one after the other, which are added to the identity module 708 for each participant 701. Ru. Internal rules embedded in the Intelligence Module 709 are not limited to these, but may include location, time, certification requirements and the like.

The inner cloaking pattern 707 describes the transformations applied to the participants 701 in the ICTO 710 to protect them, and how to reverse those transformations to access some or all of the participants 701. Describe. Transformations can include, but are not limited to, data compression, data normalization and encryption. A given inner cloaking pattern 701 may include one or more of these techniques, and / or other techniques. Data compression can reduce the overall size of the ICTO 710, which in turn can improve transfer time and bandwidth usage. Data compression can be performed by any suitable lossless compression algorithm, including but not limited to DEFLATE, LZW, LZR, LZX, JBIG, DjVu and / or the like. Data normalization is performed by any suitable process that arranges the data in a format that can be processed efficiently. In some embodiments, the data can pass through a Base64 coding algorithm to convert the data into a normalized alphanumerical string, whether in binary or text format. This is just an example and should not be considered limiting. In other embodiments, other algorithms can be used to normalize the data.

The inner cloaking pattern 707 may also include one or more cryptographic techniques. The cloaking pattern specifies a method for deriving the encryption key, a specific encryption algorithm or key length, such as, but not limited to, NIST or FIPS or other proprietary encryption algorithms, and /. Alternatively, specify other configurable options such as time seeding, Xor coding, or other industry-standard coding and decryption techniques for generating elements of the cloaking scheme, or a combination thereof. be able to. In some embodiments, cryptographic techniques can perform non-encryption operations or calculations, such as deriving hash values for reference content or the like. In some embodiments, the inner cloaking pattern 707 is an encryption key used internally or not shared externally, either on the inner cloaking pattern 707 itself or elsewhere in the ICTO 710. A record of decryption keys can be stored (or include rules that require storage). When access to protection information is made using the inner cloaking pattern 707, the cloaking algorithm / decloaking algorithm and keys are managed internally and given to the dynamic participant controller 702 in the ICTO 710 to access the information. Is provided, but does not make it available to the ICTO 710's external requesting agent or any other agent, or application, device, or operating system. In other words, the cloaking / decloaking algorithms and keys are not stored or exposed outside the ICTO 710 and are not available to any agent, eliminating the need for external key management capabilities and therefore. There are no vulnerabilities from it, and their secrets are maintained.

In some embodiments, the rules presented in the intelligence module 709 allow the mixer 702 to apply the separate inner cloaking patterns 707 to the separate components of the participant 701. For example, the first rule, when implemented, can identify the first part of the protected digital mixture 710 and apply a cloaking pattern, leaving the second part of the protected digital mixture 710 unchanged. .. The second rule, when implemented, allows the cloaking pattern to be applied by identifying a second portion of the protected digital mixture 710 with different cloaking patterns having different patterns or the like.

In some embodiments, the intelligence module 709 of the portable dynamic rule set 711 can require two or more nested layers of cloaking part or all of the participant 701. For example, execution by the mixer 702 of the first rule can cloak the first part of the protected digital mixture 710. Execution by the mixer 702 of the second rule, along with the first rule and the corresponding first cloaking rule, uses a different inner cloaking pattern 707 to cloak the first part of the protected digital mixture 710. You can cloak it again. Therefore, in order to later access the first part of the protected digital mixture 710, a second decloaking rule corresponding to the second rule is implemented and the protected digital mixture 710 is nested and cloaked. The first part is decloaking and the first decloaking rule is obtained. The first decloaking rule is then implemented to decloak the first portion of the protected digital mixture 710 and generate a plaintext version of the first portion of the digital mixture 710.

When the cloaking pattern 707 is applied to the participant 701 to create the cloaked participant set 720, method 800 proceeds to block 808, where the mixer 702 is a digital mixture (ie, ICTO) 715. Complete the construction of. In some embodiments, additional protection such as data shuffling, additional cloaking or digital signatures and / or the like can be applied to the entire digital mixture 710. Method 800 then proceeds to the end block and ends.

Other steps not explicitly shown in FIG. 8 can be included in Method 800 without departing from the scope of the present disclosure. For example, if anomalies are detected while applying the cloaking pattern or executing the rule, Method 800 may stop and not generate the finished ICTO 710. As another example, in some embodiments, the owner data 706 may include one or more ICTOs as a method of providing nested protection. In some embodiments, the rules within the nested ICTO can provide access to the participant data 701 within the outer ICTO 710. In some embodiments, the rules within the first ICTO cause the second or more ICTOs to be created so that the first ICTO is nested inside the second ICTO. Can be added to the second ICTO. Similarly, in some embodiments, the rules within the first ICTO cause the second ICTO to be created so that the second ICTO is nested inside the first ICTO. Can be added to the first ICTO.

FIG. 3 is a flow chart illustrating exemplary embodiments of method 300 for accessing data protected by ICTO 115, according to various aspects of the present disclosure. After invoking the ICTO 115, the ICTO 115 validates and validates its current environment, access attempts, authorized agents and other conditions as specified in the rule set contained in the portable dynamic rule set 108. Start sexual confirmation. This validation and validation is performed once at startup, consecutively during the active period, periodically during the active period, or at any other appropriate interval or in response to any appropriate state change. be able to. If the rules and agent identities are positively confirmed, the ICTO 115 grants access to authorized parts of the ICTO 115 itself, while maintaining the homogeneous nature of the mixture and the protection of the remaining data.

Similar to the method 200 described above, in some embodiments, the mixer 110 is configured to perform method 300. In some embodiments, if one or more processors of the computing device execute a computer executable instruction that causes the computing device to do so, method 300 is performed by the computing device. As will be appreciated by those skilled in the art, neither the construction and utilization of ICTO 115 will depend on the type of computing device or any operating system associated with the computing device. The data protection protocol is embedded in the dataset. The activated ICTO 115 can communicate with the data owner over the years of use of the data (information such as access attempts, alerts to unauthorized locations or unauthorized agents, self-destruction or self-renewal notifications, etc. ). In addition, the rules within ICTO 115 can update the rules themselves and other parts of ICTO 115, so ICTO 115 learns from its environment and changes its future behavior based on that learning. Can be done. Protection protocols can be customized and are specific to each owner, dataset and user combination, as specified in the cloaking pattern.

From the start block, method 300 proceeds to block 302, where the portable dynamic rule set within the digital mixture 115 is activated in response to the agent's request for access to the digital mixture 115. In some embodiments, the superidentity is embedded in the ICTO 115 and is an intelligent criterion for verifying the identity of the agent attempting to access the ICTO 115, verifying the validity of the agent, and determining the current state of the data. Includes dynamic rules to provide recognition and algorithms for data cloaking as specified in cloaking patterns. Verification criteria such as challenge / response pairs, digital signatures, biometric information and / or similar can be used to verify the agent's identity. At block 304, the portable dynamic rule set 108 is performed to verify that the agent is granted the requested access to the digital mixture 115 within the relevant context. When activated, the identity module 109 and the intelligence module 111 evaluate the current access attempt by the validated agent and establish a trust level. In some embodiments, this evaluation is a continuous process in that there is continuous validation and validation of each Participant 101, i.e., the data owner, agent (data user) and the data itself. In some embodiments, the pre-access rules from the portable dynamic rule set 108 are for internal use by the mixer 110, without allowing access to the decrypted data by agents other than the mixer 110, ICTO. It can be performed on the mixer 110 to decrypt at least some parts of the 115. Pre-access rules include the ability to have access to Participant 101, test identity artifacts, and evaluate owner and agent data. If the confidence level drops, the protocol re-evaluates Part 101. In some embodiments, defense or aggression can be triggered if agents attempting to access ICTO 115 are unable to reestablish their legitimacy. If the agent can meet the new challenge set, access will be allowed to proceed or continue.

In some embodiments, the pre-access rule only allows read access to identity or authentication data, but in some embodiments, the pre-access rule opens (or opens, for example, ICTO 115). It may also have write access that can be used to record the access attempt attributes.

Method 300 proceeds to block 306, where the portable dynamic rule set 108 determines the cloaking pattern used to protect the requested data. The portable dynamic rule set 108 examines the mixture metadata 104 to determine which cloaking pattern 107 was applied based on the agent's identity, data request, context in which the data is requested and / or similar. do. Once the cloaking pattern 107 used has been determined, method 300 proceeds to block 308, where cloaking pattern 107 is used to provide the requested access to the agent. Cloaking pattern 107 is used to reconstruct the requested data from the protected version stored in ICTO 115, similar to the method by which cloaking pattern 107 indicates the set of techniques used to protect the requested data. It also shows a series of techniques. The method 300 then proceeds to the end block and ends.

FIG. 9 is a processing flow showing an alternative embodiment of method 900 for accessing data protected by ICTO 710. After launching the ICTO 710, the PDRS 711 initiates verification and validation of the ICTO 710's current environment, access attempts, legitimate agents and other conditions, as specified by the PDRS 711. This validation and validation process is inherently efficient and ensures data integrity, once at startup, consecutively during the active period, periodically during the active period, or elsewhere. Can be performed at any suitable interval or in response to any suitable state change. Upon positive confirmation of the rules and the identity of the legitimate agent, PDRS711 grants access to the authorized parts of the ICTO 710 while maintaining the homogeneous nature of the mixture and the protection of the remaining participants. In some embodiments, an ICTO-aware application, device or operating system is configured to initiate and facilitate Method 900.

From the start block 901, method 900 proceeds to block 902, where the dynamic participant controller 702 in the protected digital mixture or ICTO 710 recognizes the ICTO in response to an agent requesting access to the digital mixture or ICTO 710. It is powered by an application, device, or operating system. In some embodiments, the owner / agent identity and / or the identity of one or more agents is contained in an identity module 708 embedded within the ICTO 710, which is an agent attempting to access the ICTO 710. Data as specified in cloaking patterns, dynamic rules that provide criteria for verifying identity, authenticity and legitimacy, and intelligent awareness for verifying agent legitimacy and determining the current state of data. Includes algorithms for cloaking. Verification criteria such as challenge / response pairs, external permissions, digital signatures, biometric information and / or similar can be used to authenticate, verify and / or verify the agent's identity. At block 903, the portable dynamic rule set 711 is used to validate the request agent in an efficient, sufficient, complete and relevant context and grant access to the digital mixture 710.

Method 900 proceeds to block 904, where the portable dynamic rule set 711 is based on the agent's identity, data request, data requested context and / or similar to the dynamic participant controller 702. It provides one or more cloaking patterns 107 that have been used to protect the requested data. Proceeding to block 905, the DPC or mixer 702 responds to instructions from the portable dynamic rule set 711 with the data owner's rules for legitimate agents, data requests, the context in which the data is requested, and /. Or decloak some or all of the protected data inside the ICTO 710 based on something similar managed by the portable dynamic rule set 711.

Other steps not explicitly shown in FIG. 9 can be included in Method 900 without departing from the scope of the present disclosure. For example, if anomalies are detected while applying the decloaking pattern or executing the rule, Method 800 can be stopped and deprived of access to the protected ICTO 710. As another example, Method 900 determines the legitimacy of a requesting agent for ICTO 710, which may give rise to the need for external authorization prior to the completion of legitimate agent authorization. Further, an alarm may be sent as a result of a legitimate and authorized access to the ICTO 710. As another example, in some embodiments, the method 900 causes PDRS711 in the ICTO 710 to send an alarm, record an access attempt, and / or determine that unauthorized access is being attempted. You can do the same thing. As another example, in some embodiments, Method 900 enables access to false data in the ICTO and records activity when it determines that an unauthorized access attempt is currently underway. Send an alert and / or do the same. Alerts include, but are not limited to, failed access attempts, unrecognized access addresses (which may include device and location details), schedule violations, unauthorized movement of the ICTO, and the like.

Therefore, the present invention results in self-sufficient, self-regulating and self-dominant ICTOs. All access rights, engagement rules, legal compliance rules, audit requirements, and similar rules and restrictions as determined by the data owner are contained in the PDRS and embedded in the ICTO, thus the data owner's by PDRS. Controlled (whether online or offline, control is maintained from within the ICTO) and executed by PDRS. PDRS is a means for self-dominance and control from the time of ICTO creation throughout survival. It travels with the ICTO, always follows the rules established by the data owner, and is based on information learned based on the environment (such as location, time, and device), but not limited to. It is adaptive (ie, dynamic) to self-manage and determine. PDRS does not require any external resources (eg, IAM or SIEM system) or specific operating environment to maintain control and control. PDRS maintains the integrity of ICTO management from within the ICTO. PDRS is permanently embedded in the ICTO and moves with the ICTO to create self-fulfilling, self-regulating, self-dominant entities.

FIG. 4 is a schematic diagram showing an exemplary use case for the embodiments of the present disclosure. Those skilled in the art will appreciate that this use case is merely exemplary and is described to demonstrate certain features of the present disclosure, but this use case also demonstrates utilizing all the features of the techniques disclosed herein. It will be understood that they will not do it. In FIG. 4, the first user 418 uses the first computing device 416 to use the embodiments of the present disclosure to provide a first fragment of data (data 1 404) and a second piece of data. Protect the fragment (Data 2 406). An ICTO 408 is created that includes a protected version 410 for data 1 and a protected version 412 for data 2. When creating the ICTO 408, the first user 418 specifies that the second user 422 can access data 1 404, but does not specify that the second user 422 can access data 2 406. Therefore, the ICTO 408 includes a rule in the portable dynamic rule set 108 that allows the user 2 422 to access the data 1 404 at the time of verification.

The first computing device 416 transmits the ICTO 408 to the second computing device 420 used by the second user 422 via a network such as LAN, wireless network, internet and / or the like. .. The second user 422 launches ICTO 408 and submits a request 424 to access data 1 404. The ICTO 408 verifies the identity of the second user 422, which verifies that the second user 422 is the person in question, processing the challenge / response pair stored in the ICTO 408 and / Or may include examining trusted services 409 (such as certificate servers, RADIUS or other authentication servers and / or the like). When the identity of the second user 422 is verified, ICTO 408 examines the cloaking pattern used to create protection data 1410 and uses that cloaking pattern to access data 1 404 for the second time. To the user 422 of. The second user 422 can also submit a request 426 to access data 2 406. However, the ICTO 408 does not allow the second user 422 to access the data 2 406 because the ICTO 408 has not been instructed to provide access to the data 2 406 to the second user 422. ..

In an alternative processing flow, the first computing device 416 is a second computing device used by a second user 422 over a network such as a LAN, wireless network, the Internet, and / or the like. Send ICTO 408 to 420. The second user 422 uses the ICTO recognition application, device or operating system to awaken the ICTO 408 and receive a request to access the protected data 1 in the ICTO 408. ICTO 408 verifies the identity of the second user 422, which verifies the multiple pairs of challenges / responses and responses stored in ICTO 408 to verify that the second user 422 is legitimate and authorized. / Or may include processing external permission or the like. In addition, trusted service 409 can be used to further verify time, physical location and the like, based on the access rules set by the owner. At the time the identity of the second user 422 was verified (ie, established to be genuine and legitimate), the ICTO 408 was used to create the protection data 1 410, one or more. The cloaking pattern is determined, the protection data 1 410 is decloaked, and the data 1 404 is disclosed to the second user 422. The second user 422 can also request access to the protected data 2412. However, since the second user 422 is not allowed to access the protected data 2 in the ICTO 408, the second user 422 is not allowed to access the protected data 2412.

Although a trusted service 409 that provides an authentication service is described, other types of trusted services can also be used. For example, if the ICTO 408 includes a rule that allows access only for a given time, then a trusted service 409 that provides a trusted date / time value can be used. As another example, the trusted service 409 can solicit input from other users while the ICTO 408 decides whether to grant access to the agent. As shown, trusted service 409 notifies first user 418 about an access attempt via email, SMS or any other suitable technique, and the corresponding consent from first user 418. You can wait for the attempted access to be granted until you receive.

This use case demonstrates some of the advantages of the present disclosure. Once the ICTO 408 is created, the protected data 1410 and the protected data 2412 cannot be accessed without invoking the ICTO 408 process for requesting access. Thus, when the ICTO 408 is stored on the first computing device 416, when the ICTO 408 is being transmitted over the network 402, and when the ICTO 408 is stored on the second computing device 416. , Data is protected. Also, if ICTO 408 provides a second user 422 with access to data 1 404, data 2 406 is nevertheless protected from access.

This brief use case exhibits some features of the present disclosure, but much more complex use cases are possible. For example, FIG. 5 is a schematic diagram illustrating an exemplary workflow mode for embodiments of the present disclosure. The first user (“User A”) is confidential throughout the transaction by the second user (“User B”), the third user (“User C”) and the fourth user (“User D”). You may have a set of documents (“Documents X, Y and Z”) that should be approved and signed while preserving. Document X needs to be signed by user B. Document Y needs to be signed by User B and User C, but only after Document X has been signed. Document Z needs to be signed by User D, but only after Documents X and Y have been signed. In addition, Document X and Document Y must be signed during working hours (between 9 am and 5 pm) to comply with local company policy, while Document Z (Draft Working Document Y). ) Shall be signed and audit logged when documents X and Y are approved and signed, after which document Z is destroyed but also audit logged.

The embodiments of the present disclosure support such a workflow. User A creates an ICTO that includes documents X, Y, and Z. User A creates an access rule for Document X that allows User B to review and sign Document X. The user A creates an access rule for the document Y so that the user B and the user C can review and sign the document Y when the signature in the document X is obtained. User A can create an access rule for Document X that allows User C to review and check the signature of Document X, or the access rule for Document X has the signature applied to Document X. The access rules for document Y can be dynamically updated to detect and allow the signature to be signed when the signature is detected. User A checks the signatures in Documents X and Y and creates access rules for Document Z that allow User D to sign Document Z as soon as such signatures are detected. Each of these rules also implements the relevant time requirement and does not allow access if the time requirement is not met. User A can also create a rule that returns a report to User A for any access to any document, so that User A can monitor the process. Each of the rules can specify how to identify each user, related privileges, devices on which the user is allowed to access the document, and where the user is allowed to access the document.

For example, when User B receives the ICTO, User B invokes an application configured to invoke executable code within the ICTO. The executable code determines User B's identity by examining the trusted identity service, checking the response to the challenges contained in the rule, or by any other method. When the identity, time, place, and other requirements are met, User B is granted access to Document X, but not any other document. After User B signs Document X, the ICTO is transferred to the next user to perform document protection as the ICTO passes through the rest of the workflow.

Alternatively, for example, user B receives the ICTO, and user B activates the ICTO recognition application to activate PDRS in the ICTO. The executable code uses identity credentials provided within the ICTO that provide multiple pairs of challenge / response and / or external authorization codes to determine User B's identity. When the identity, time, place, and other requirements are met, User B is granted access to Document X, but not any other document. After User B signs Document X, the ICTO is transferred to the next user to perform document protection as the ICTO passes through the rest of the workflow.

In another exemplary embodiment, the protection protocol is enacted in the form of a portal identity appliance (PIA). The PIA uses intuitive and autonomous authentication methods to define portable and discrete digital identities. The PIA is the ultimate implementation of the embedded ICTO protocol, which is the intelligent object itself. In some embodiments, the PIA is an ICTO that does not include owner data (eg, files, images and the like). The PIA consists of an ICTO that uses PDRS with additional publicly available information about the owner (similar to the information available on a business card or public address book), not necessarily the owner data. It does not have to be included. Thus, the PIA is a self-protecting, self-regulating, self-dominant ICTO with the purpose of reliably presenting the identity of the owner.

As shown in FIGS. 10-13, when a protected PIA is created, it is combined with the data to create a protected data object 703 that facilitates the transmission of secure messages between one or more parties (eg,). A secure and reliable identity that can be used to verify and maintain the legitimacy of senders and recipients and the integrity of data) and to guarantee or guard websites, portals, networks or other resources. I will provide a.

As such, PIA offers numerous advantages over existing signing techniques. Existing signing techniques are usually based on certificates purchased from certificate authorities. The authenticity of a certificate is estimated based on the holder of the certificate and the issuer of the certificate. However, certificates can be stolen or spoofed and are not based on a uniquely defined identity.

In this way, the ICTO can be used for reliable verification of identity, which requires a "signature". The signature ICTO can be used as an external identity verification in conjunction with an ICTO containing legal documents that require absolute verification of identity. The signature ICTO can be a (embedded) part of the "final" legal document contained within the original ICTO. In addition, the signature ICTO can be included within the ICTO (ie, nested) as an additional protected data element in addition to the owner document that requires a signature, thus providing the required signer to travel with the document. Pre-defined and pre-verified can be provided. The signature ICTO can be used as a reliable verification of identity in a document contained in an ICTO recognition application rather than in the ICTO. For example, they can be used to provide electronic acceptance of terms and conditions or confirmation of privacy notices.

The signature ICTO in the context of document signing can be seen as a digital version of the "legally verified and certified" owner, yet is certain. Each signature ICTO is just as unique as an ICTO with owner data and therefore cannot be "spoofed" by a person or entity pretending to be the actual owner of the signature ICTO. In addition, the signature ICTO does not necessarily have to represent a human. It can represent a machine, which requires an intermediate signature (verification) to verify the validity of the permit in order for the digital processing flow to proceed. And this signature must be documented. Signature ICTOs can be used wherever standard digital is currently required, but their use is not limited to current ones. As mentioned above, in some embodiments, the presence of ICTO recognition is essential for its use.

Those skilled in the art will recognize that the above use cases are merely exemplary and that many other use cases for the objects disclosed herein are possible. For example, since the portable dynamic rule set contains executable code, the ICTO can protect executable content only if it meets the ICTO's security checks. Also, because the ICTO can execute such content in response to the success or failure of any rule, the ICTO owns the data as soon as it records a successful access or detects an unauthorized access attempt. It can perform actions such as warning a person, starting a self-destruction sequence, or other actions.

Alternatively, there are many other use cases for the objects disclosed herein. For example, because the ICTO contains executable code for independent self-management, the ICTO protects content that is accessible only when it meets the security checks and rules indicated by the data owner contained within the ICTO. Can be done. The ICTO will also record such access in response to the success or failure of any rule, or warn the data owner as soon as it detects an unauthorized access attempt, initiating a self-destructing sequence. Alternatively, other operations such as operations can be performed.

FIG. 6 is a block diagram illustrating an exemplary hardware architecture of a computing device 500 suitable for use in the embodiments of the present disclosure. For those of skill and others, the computing device 500 is, but is not limited to, desktop computers, server computers, laptop computers, embedded computing devices, application-specific integrated circuits (ASICs), smartphones, tablet computers. It will be appreciated that it can be any one of a number of devices currently available or not yet developed, including and / or similar. In its most basic configuration, the computing device 500 includes at least one processor 502 connected by a communication bus 506 and system memory 504. Depending on the exact configuration and type of device, the system memory 504 may be volatile or non-volatile, such as read-only memory (“ROM”), random access memory (“RAM”), EEPROM, flash memory or similar memory technology. It can be memory. Those skilled in the art and others will recognize that the system memory 504 typically stores data and / or program modules currently in operation by the processor 502 that is readily accessible and / or by the processor 502. In this regard, the processor 502 functions as the arithmetic center of the computing device 500 by supporting the execution of instructions.

As further shown in FIG. 6, the computing device 500 may include a network interface 510 comprising one or more components for communicating with other devices on the network. In the embodiments of the present disclosure, since communication is performed using a common network protocol, it is possible to access a basic service using the network interface 510. In the exemplary embodiment depicted in FIG. 6, the computing device 500 also includes a storage medium 508. However, the service can be accessed using computing devices that do not include the means to keep the data on the local storage medium. Therefore, the storage medium 508 depicted in FIG. 6 is represented by a dotted line to indicate that the storage medium 508 is of arbitrary choice. In any event, the storage medium 508 is, but is not limited to, hard drives, solid state drives, CD-ROMs, DVDs, other disk storage devices, magnetic cassettes, magnetic tapes, magnetic disk storage devices and the like. It can be implemented using any technology that is volatile or non-volatile, removable or non-removable, and capable of storing information.

As used herein, the term "computer-readable medium" is implemented in any manner and technology capable of storing information such as computer-readable instructions, data structures, program modules or other data, volatile. And includes non-volatile, removable and non-removable media. In this regard, the system memory 504 and storage medium 508 depicted in FIG. 6 are merely exemplary computer-readable media.

Suitable implementations of computing devices, including processor 502, system memory 504, communication bus 506, storage medium 508 and network interface 510, are known and commercially available. FIG. 6 does not show some of the typical components of many computing devices, for ease of illustration and not important for understanding the claimed object. In this regard, the computing device 500 may include input devices such as keyboards, mice, microphones, touch input devices and / or the like. Similarly, the computing device 500 may also include output devices such as displays, speakers, printers and / or the like. All of these devices are well known in the art and are not described further herein.

Thus, the embodiments and examples described herein best illustrate the principles of the invention and its practical applications, with various modifications made by those of skill in the art in various embodiments intended for a particular application. It should be understood that it has been selected and described so that the present invention can be best utilized. Although specific embodiments of the invention have been described, those embodiments should not be construed as exhaustive. There are a number of variants that will be apparent to those skilled in the art.

Claims (21)

A computer-implemented method of protecting data,
Provides a computer-based intelligent cryptographic transfer object with a portable dynamic rule set containing machine executable code protected by one or more outer cloaking patterns.
Restoring the machine executable code by reversing the outer cloaking pattern
By executing the machine executable code
The portable dynamic rule set was used to validate the identity of the external agent and
Once the identity of the external agent is verified, data indicating the identity of the external agent is stored in the computer-based intelligent cryptographic transfer object.
A method comprising protecting data indicating the identity of said external agent using one or more inner cloaking patterns. The method of claim 1, wherein the intelligent cryptographic transfer object comprises a portable identity appliance. The intelligent cryptographic transfer object is configured to allow access to authorized parts of the protected data set, while not allowing access to unauthorized parts of the protected data set. Method. The intelligent cryptographic transfer object comprises a digital participant containing the portable dynamic rule set, and the intelligent cryptographic transfer object is randomly applied to all or part of the digital participant. The method of claim 1, comprising a cloaking pattern. The method of claim 4, wherein each time the cloaking pattern is applied to a digital participant, the cloaking pattern is randomly applied to provide a unique protection scheme. The method of claim 1, wherein the intelligent cryptographic transfer object comprises owner data protected by the one or more inner cloaking patterns. The method of claim 1, wherein the inner cloaking pattern is used to cloak at least a portion of the portable dynamic rule set. The intelligent cryptographic transfer object is configured to be accessed by at least one of an application, an operating system, a computer chip, a switch, a control panel, or an FGPA that recognizes the intelligent cryptographic transfer object. Method. By using the intelligent cryptographic transfer object, at least one of verifying the signature, facilitating the secure transmission of protected data, and guarding access to a website, portal or network. The method of claim 1. The method of claim 9, wherein the certificate obtained from the certificate authority is not used when verifying the signature. The method of claim 1, further comprising creating an audit trail of an attempt to access the intelligent cryptographic transfer object. Creating the audit trail prevents (i) recording access attempts to the intelligent cryptographic transfer object in the embedded log, and (ii) preventing unauthorized access attempts to the intelligent cryptographic transfer object. The method of claim 11, comprising at least one of (iii) warning the data owner of an unauthorized access attempt to the intelligent cryptographic transfer object. A system with one or more processors programmed to perform an operation.
The above operation is
To provide a computer-based intelligent cryptographic transfer object with a portable dynamic rule set containing machine executable code protected by one or more outer cloaking patterns.
Restoring the machine executable code by reversing the outer cloaking pattern,
By executing the machine executable code
Verifying the identity of an external agent using the portable dynamic rule set,
When the identity of the external agent is verified, data indicating the identity of the external agent is stored in the computer-based intelligent cryptographic transfer object.
A system comprising protecting data indicating the identity of said external agent using one or more inner cloaking patterns. 13. The system of claim 13, wherein the intelligent cryptographic transfer object comprises a portable identity appliance. 13. The intelligent cryptographic transfer object is configured to allow access to authorized parts of the protected data set, while not allowing access to unauthorized parts of the protected data set. system. The intelligent cryptographic transfer object comprises a digital participant containing the portable dynamic rule set, and the intelligent cryptographic transfer object is randomly applied to all or part of the digital participant. The system of claim 13, comprising a cloaking pattern. The system of claim 13, wherein the intelligent cryptographic transfer object comprises owner data protected by the one or more inner cloaking patterns. The operation further comprises verifying the signature, facilitating the secure transmission of protected data, and guarding access to a website, portal or network by using the intelligent cryptographic transfer object. 13. The system of claim 13, comprising doing one. 13. The system of claim 13, wherein the operation further comprises creating an audit trail of an attempt to access the intelligent cryptographic transfer object. Creating the audit trail prevents (i) recording attempts to access the intelligent cryptographic transfer object in the embedded log, and (ii) preventing unauthorized access attempts to the intelligent cryptographic transfer object. The system of claim 19, comprising at least one of (iii) warning the data owner of an unauthorized access attempt to the intelligent cryptographic transfer object. A non-transitory computer readable medium having computer-readable instructions are stored,
The computer-readable instruction causes the computer processor to perform an operation when executed by one or more computer processors.
The above operation is
To provide a computer-based intelligent cryptographic transfer object with a portable dynamic rule set containing machine executable code protected by one or more outer cloaking patterns.
Restoring the machine executable code by reversing the outer cloaking pattern,
By executing the machine executable code
Verifying the identity of an external agent using the portable dynamic rule set,
When the identity of the external agent is verified, data indicating the identity of the external agent is stored in the computer-based intelligent cryptographic transfer object.
A non-transitory computer-readable medium comprising protecting data indicating the identity of said external agent using one or more inner cloaking patterns.

Images