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

Abstract

Systems, methods, and devices configured to build and utilize an intelligent cipher transfer object are provided. The intelligent cryptographic delivery object contains a set of entries protected with cloaking patterns. A portable dynamic rule set containing executable code for managing access to a set of protected entries is contained in an intelligent cryptographic delivery object. For a given user, an intelligent cryptographic delivery object can provide access to some of the entries, while prohibiting access to other entries based on a portable dynamic rule set within it.

Description

Systems and methods of using cryptographic objects to protect data {SYSTEM AND METHODS FOR USING CIPHER OBJECTS TO PROTECT DATA}

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

Field of invention

This invention relates to a system and related methods for protecting and managing data using (but not limited to) self-encryption and self-management, including the use of an intelligent cryptographic transfer object.

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

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

Fully homomorphic encryption attempts to eliminate the trustworthy aspect of the relationship, making trust between the parties irrelevant. For example, a party could send their data to a trustee for storage or processing without trusting what the trustee can do with their data, which would allow the trustee to perform a process that does not require decryption. This is because only access to the encrypted version of the data is provided. However, fully homogeneous encryption is too cumbersome to implement.

Another conventional data protection technique is to use dynamic controls. Dynamic Control are application-specific, such as the PDF file protected by a password that is created and used by the document viewing and editing software made by Adobe ^®. Conventional dynamic controls are application dependent or exist within the application. Rules are executed by the application. As mentioned above, it is also dependent on key (password) exchange, but another drawback of this method is that application-specific rules can be overridden (as in the example of a protected PDF opened with Adobe ^® Acrobat ^® ), or the developer can You can write applications that ignore the rules imposed by it.

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

This summary is provided to introduce a selection of concepts in a simplified form that is further explained in the detailed description below. This summary is not intended to represent key features of the claimed subject matter, nor is it intended to be used to assist in determining the scope of the claimed subject matter.

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

In one exemplary embodiment, the present invention includes, but is not limited to, computer chips, switches, control panels, FGPAs, etc. that activate ICTO in response to a request for access. -aware application), operating system, or device. ICTO includes a set of entries, including but not limited to owner data and PDRS. When a dynamic participant controller (DPC) in ICTO is activated remotely or locally, the PDRS in ICTO takes and maintains control of the ICTO until the protected object is closed (i.e., deactivated or paused). The PDRS responding to an agent access request for some or all of the entry data through the dynamic entry controller verifies that the agent is genuine and authorized to access some or all of the protected data sets, or has no access . Once verified, the agent can only access the authorized portions of the protected data set, while the rest of the protected data in the ICTO remains inaccessible to the agent. Also provided is a computer-implemented method of generating such an ICTO utilizing an ICTO-aware application, operating system, or device to activate such executable portions of the ICTO.

In a further embodiment, a computer-implemented method of protecting a set of entries is provided. The set of entries to be protected is obtained by the computing device. One or more cloaking patterns are determined to protect the set of entries. The first clocking pattern is used to protect or mix a first subset of the set of entries, and a second clocking pattern different from the first clocking pattern is used to protect or mix a second subset of the set of entries . The determined clocking patterns are applied to the set of entries by the computing device to create a set of clocked or mixed entries. The set of clocked entries is added to the ICTO by the computing device. Also provided are a computing device configured to perform the method and a computer-readable medium having computer-executable instructions stored thereon, in response to execution by one or more processors of the computing device, that cause the computing device to perform the method.

In yet another embodiment, the present invention includes an ICTO-aware application, operating system, or device that utilizes this method to secure a set of entries. The set of entries is aggregated through an ICTO-aware application, operating system, or device to generate an intermediate pattern ICTO, which, until the ICTO is fully implemented, by a crypto engine or dynamic entry controller. Includes a set of provisional or "start" rules and entries provided. The intermediate pattern ICTO is clocked by one or more clocking patterns that are dynamically selected or generated and applied by the dynamic entry controller. The temporary rule set is later replaced by one or more specific or unique rule sets defined by the owner, and one or more clocking patterns are dynamically and randomly selected or generated for each ICTO by the PDRS within the ICTO. The cloaking patterns can be applied randomly to some or all of the parts of the entries, and at the same time, additional clocking patterns are randomized to some or all of the parts of the entries to create a unique clocked set of entries for each ICTO. Can be applied as

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

In yet another embodiment, the present invention includes an ICTO-aware application, operating system, or device that activates ICTO upon receipt of an access request from an agent. The dynamic entry controller in the ICTO is activated, and when activated, the embedded PDRS takes and maintains control of the ICTO. At least one rule of the PDRS is executed to evaluate the authorization and authorization of the agent, which can access some or all of the protected data, or none of them. If an agent is allowed to access some or all of the protected data, the protected data that is not authorized for access remains protected and is not visible to the accessing agent. Disabled ICTO is inaccessible without ICTO-aware applications, operating systems, or devices.

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

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

In various embodiments, the present invention addresses the fatal flaws of conventional data protection systems and methods. Existing protection schemes deal with premises defenses, user access (both users and their devices), and anomaly detection, but have no meaning to the data itself, so the present invention breaks through the gaps in existing protection schemes. Fill. If prior-art encryption is utilized, the burden on key code management may reduce productivity, or defects caused by exposure of keys that need to be protected likewise may create another vulnerability.

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

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

Data owners use this method of protection as a simple and lightweight management tool that keeps checking the parties' relationship to the data. From the point of view of the attacker, the system is unpredictable because all authorized parties have their own established identities integrated into the protection scheme. Unique protection schemes can be provided for each combination of owner, user, and data set; This means that the method by which data is disclosed to authorized party A may differ from the method by which data is disclosed to authorized party B.

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

In some embodiments, different technologies may be used to protect the data and to access the protected data. For example, an irreversible protection scheme can be used to combine multiple pieces of data into a single digital mixture, and this selective retrieve method does not gain access to other protected data in a single digital mixture. It can be used to selectively retrieve pieces of data from a single digital mix without having to. In this embodiment, if the data is accessed correctly, it is selectively published based on the owner's wishes for authorized recipients. The path for disclosure of information is not a function of tracking the original steps, and the original protection method used to assemble multiple pieces of data may be irreversible except with respect to the individually requested pieces of data. That is, even if pieces of data stored in a protected manner are accessed, the entire digital mixture is not accessible by a method of reconstructing all of the original contents. Embodiments of the present disclosure are configured to positively identify any user or entity identity that is included as a legitimate entry or not, and the data owner controls the pieces or pieces of data that the identified legitimate users may have access to. Unauthorized parties, whether inside or outside the intended recipient's or intended recipient's network, cannot access data in unprotected forms. Embodiments of this disclosure ensure that the identity of the relying party is verified prior to providing access to ensure data security. Retrograde or reverse engineering of the protection method cannot achieve the original result.

In some embodiments of the invention, the rules are enforced by the executable part of the digital mix, so it is certain that the data owner's obvious wishes are enforced without relying on a third party or external entity or application or operating system. This protection method does not depend on the application or operating system to protect/unprotect the data: the data is self-protected and self-controlled. The protection scheme is independent of the operating system, environment, and application (ie, external or centralized or server key management, password management, and identity management applications). Methods within the protocol are implemented with executable code stored in the data mix and executed in response to detecting a request by a user who wishes to access the data through the configured API. Moreover, the data can be of any type (e.g., text, audio, video, or a combination thereof), and can be of any kind of container, database, or environment (e.g., buffer, directory, file, Or combinations of them). Any attempt to access data other than through the API or other means described herein will be frustrated by the applied cloaking patterns, which will affect any components outside or outside the components implementing the API. It cannot be determined by. If an attempt is made to access the data through an API or other means described herein, the protection scheme ensures that only legitimate users are permitted by the data owner to access the data.

APIs, or other ICTO-aware applications, devices, or other methods initiated through the operating system initially check the ICTO. The external clocking technique then locates the executable code, crypto engine, or mixer stored within the digital mix. The access request is received by executable code through an API or other ICTO-aware application, device, or operating system on behalf of the agent. Until the self-managed data object is closed or deactivated, the executable code is energized or "wakened up" when the portable dynamic rule set takes and maintains control. No attempt to access a self-protecting and self-controlling digital mixture can be successful without the executable code being activated.

1 is a schematic diagram illustrating an exemplary embodiment of self-managing data, in accordance with various aspects of the present invention. The dynamic entry controller 110 or “mixer” includes digital components (including descriptions of authorized agents, device locations, data usage rules, and/or other elements, further described below). Identify the set of 101 "entities". By mixing these components, the mixer 110 forms a clocked entity, an intelligent cryptographic transfer object, or ICTO 115. ICTO 115 may also be referred to as a "digital mixture". As described herein, one of ordinary skill in the art will recognize that the terms “ICTO” and “digital mixture” and “self-managing data” may be used interchangeably. To an unauthorized entity or third party viewing ICTO 115 directly, ICTO 115 may simply be viewed as a data set. The ICTO 115 appears to the outside as a homogeneous mixture that resembles or does not expose its original components. However, to provide access to data managed by ICTO 115 when accessed through an application that implements an API (such as mixer 110, ICTO-aware client application (not shown), and/or etc.) The executable portions of the ICTO 115 may be accessed for this purpose.

In some embodiments, executable portions of ICTO 115 may be stored in a identifiable location within ICTO 115 to allow an application implementing the API to easily find the executable portions. In some embodiments, additional protection may be provided to ICTO 115 by storing one or more executable portions of ICTO 115 at variable locations within ICTO 115. These variable locations make executable parts of ICTO 115 very difficult for unauthorized users to find, but ICTO-aware applications implementing APIs to access ICTO 115 are based on the characteristics of ICTO 115. The variable locations of a given ICTO 115 can be computed. For example, a secure application can read attributes of ICTO 115 such as file size, creation time, and/or the like, and perform calculations to determine the location of those attributes as a clue. By keeping the details of the calculation secret, the location of the executable parts of ICTO 115 can likewise be kept secret.

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

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

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

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

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

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

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

In some embodiments, entries 101 are protected by ICTO 115, but the embedded portable dynamic rule set or sets have read/write access to the embedded entries 101. That is, the rule can read and write data for the ICTO 115's mixture metadata 104 and owner data 106. This can be useful for recording access information such as date, time, location, etc. and/or destroying data if an attack is detected. Some examples of decisions or actions made and taken by intelligent code within rules include: evaluating object content and context for validity; Testing agents to prove their identity; Interacting with the client code; Contacting the server to check; Causing ICTO 115 to self-destruct; Maintaining object access history and sending history information to the server; Allowing on-line and/or off-line object access; Creating new rules based on dynamic server updates; Data encryption and decryption; Mangling and unmangling data; And/or the like, but is not limited thereto.

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

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

7 is a schematic diagram illustrating another exemplary embodiment of self-contained, self-controlling, and self-managing data protection according to further embodiments of the present invention. The API or other ICTO-aware application, device, or operating system initiates a request to the dynamic entry controller or executable mixer 702 to secure the set of digital entries 701, whereby the dynamic entry controller Alternatively, the viable mixer 702 is activated. Digital exhibits include, but are not limited to, authorized agents, devices, locations, data usage rules, and/or other digital components, further described below, as they gather together to self-protect and self-protect. -Contained in the managed data object (i.e., digital mixture or ICTO) 710. The dynamic entry controller 702, when activated, creates an intermediate cryptographic object 703 using a temporary or "start" rule set while the object is being constructed. The intermediate cryptographic object 703 is clocked using one or more external clocking patterns 704 selected, generated, or created by an algorithm generated by the mixer 702.

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

The set of digital entries 701 includes external clocking patterns 704, mixture metadata 705, owner data 706, internal clocking patterns 707, identity module 708, and intelligence module 709. It may include, but is not limited thereto. In some embodiments, the combination of internal clocking patterns 707, identity module 708, and intelligence module 709 may together be considered a portable dynamic rule set (PDRS) 711. Owner data 706, protected within ICTO 710 and managed by PDRS 711, includes images, videos, messages, emails, documents, files, buffers, directories, pointers to remotely stored data, portals, etc. However, it is not limited thereto, and may include multiple data types. In some embodiments, owner data 706 may be optional, and thus, ICTO 710 is not included only when used, for example, in a non-retrospective and specific signature verification method. In some embodiments, multiple pieces of owner data may be mixed into a single ICTO 710. In other embodiments, owner data from multiple owners may be included in a single ICTO 710. In further embodiments, multiple ICTOs may be mixed into a single ICTO.

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

External clocking patterns 704 utilize an intermediate rule set for creating intermediate cryptographic objects 703 to protect and access selected data through one or more algorithms computed, used, or generated by dynamic entry controller 702. Specifies various combinations of techniques. The data protection and access techniques included in the external clocking patterns 704 may include, but are not limited to, techniques such as industry standard verified encryption, compression, randomization, normalization, and the like. Techniques suitable for use with the external clocking patterns 704 are not limited to currently known techniques, but may include any personally or publicly available encoding and/or decoding techniques known now or developed in the future. have. Using the external clocking pattern 704 to protect and/or access data may involve applying a combination of data protection calculated by the dynamic entry controller 702 and specified by an intermediate rule set. Blend metadata 705 provides organizational information for digital blend 710 such as virtual file system data including, but not limited to, directories, user files, and the like.

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

In some embodiments, the identity module 708 may include data representing the configuration of the computing device to which certain rights may be granted in relation to the protected object. The identity module 708 may contain specific information about hardware or software components installed on the computing device that may be used to identify the computing device. The identity module 708 includes CPU information including model numbers, number of cores, speed, and/or the like; Chassis serial number; Date of Manufacture; Volatile memory size; Nonvolatile memory size; One or more storage device serial numbers, and/or model numbers; It may include, but is not limited to, data including installed software names, and/or version numbers, and/or the like.

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

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

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

In some embodiments, even while digital entries 701 are protected by ICTO 710, rules have read/write access to digital entries 701. That is, the rule can read and write data for the mixture metadata 705 and owner data 706 of the ICTO 710. This can be useful for recording access information such as date, time, location, etc. and destroying data when an attack is detected. Some examples of decisions or actions made and taken by intelligence module 709 include: evaluating object content and context for relevance; Testing agents to prove their identity; Interacting with the client code; Contacting the server to verify trust; To cause ICTO 710 to self-destruct; Maintaining object access history and sending history information to the server by e-mail, SMS, FTP, or storing it with ICTO 710; Allowing on-line and/or off-line object access; Creating new rules based on dynamic server updates; Clocking and declocking data; It may include, but is not limited to, data mangling and demangling.

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

As a further example, rules can add nested protection. If the ICTO 710 protects one or more ICTOs 710 in the current or external ICTO 710, the external ICTO 710 is managed as part of each owner data 706. Can communicate with. The external ICTO 710 (or vice versa) allows the rules managed within any ICTOs 710 included in the owner data 706 of the external ICTO 710 to be executed, or one or more included ICTOs 710 New rules can be created as a result of the rules included in ). As another example, rules self-contained in PDRS 711 of ICTO 710 are self-managing. If the ICTO 710 is protecting a document that should be accessed by a single legitimate agent within 1 hour of being created, and up to 1 hour after being accessed, the rule can implement a timer and create a self-destructive mechanism after expiration. have.

As described above, the dynamic entry controller 702 or mixer that utilizes the portable dynamic rule set 711 is the external clocking patterns 704 that make up the ICTO 710, the mixture metadata 705, the owner data ( 706), internal clocking patterns 707, an identity module 708, and a mixture of intelligence module 709. In some embodiments, various components of ICTO 710 may be combined for coded checksums to detect tampering. For example, the entire ICTO 710, rules, owner data, and/or entry data may be inspected with a checksum 712, respectively. The checksum 712 may be a hash value generated based on the contents of the checksum 712 targets. In some embodiments, the algorithm used to generate the checksum is sensitive enough to reliably detect a change in a single bit value even in a large document. Any other suitable algorithm may be used, but some suitable algorithms include MD5 and SHA. Each checksum 712 may be stored attached to, appended to, or otherwise combined with a checksum target, or may be stored in a separate location.

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

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

The method 200 proceeds to block 208 where the mixer 110 causes the portable dynamic rule set 108 to be executed. At block 210, the intelligence module 111 of the portable dynamic rule set 108 determines one or more identity-based clocking patterns used to protect the entries 101, and at block 212, the mixer 110 ) Applies one or more cloaking patterns to the entries 101, creating a set of clocked entries.

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

The clocking patterns describe the variations applied to the entry 101 to protect the entry 101 within the ICTO 115, and how these modifications are reversed to access the entry 101. Transformations may include, but are not limited to, data compression, data normalization, and encryption/decryption. A given clocking 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, thereby improving transmission time and bandwidth usage in the future. Data compression can be performed by any suitable lossless compression algorithm including, but not limited to, DEFLATE, LZW, LZR, LZX, JBIG, D _j V _u , and/or the like. Data normalization is performed by any suitable processing that places the data in a form that can be processed efficiently. In some embodiments, the data may be subjected to a Base64 encoding algorithm to convert data in binary or text format into a normalized alphanumeric string. This is an example only and should not be considered limiting. In other embodiments, other algorithms may be used to normalize the data.

In some embodiments, the cloaking pattern may allow the identity module 109 and the intelligence module 111 to apply separate cryptographic techniques to different components of the entries 101. For example, the first encryption rule, when executed, can identify and encrypt the first portion of the encrypted digital mixture 115 without altering the second portion of the encrypted digital mixture 115. Thus, the second encryption rule, when executed, can identify and encrypt the second portion of the digital mixture 115 that is encrypted using different encryption algorithms, different encryption keys, and/or the like.

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

Once the cloaking patterns are applied to the entries 101 to create a set of cloaked entries, the method 200 is that the mixer 110 creates a digital mixture (ICTO) 115 and a set of hidden entries. Proceed to block 214, adding to the digital mixture 115. In some embodiments, additional protection, such as data shuffling, additional encryption or digital signatures, and/or the like, may be applied throughout the digital mixture 115. The method 200 then proceeds to the last block and ends.

Those of skill in the art will understand that some steps in FIG. 2 are omitted in order to facilitate explanation. However, other steps not explicitly shown in FIG. 2 may also be included in method 200 without departing from the scope of this disclosure. For example, if any error is detected while applying clocking patterns or executing rules, the method 200 may be stopped and may not generate a complete ICTO 115. As another example, in some embodiments, owner data 106 may include one or more ICTOs in a way that provides embedded protection. In some embodiments, rules within an embedded ICTO may be provided with access to entry data 101 within an external ICTO 115. In some embodiments, a rule in the first ICTO may generate a second ICTO and add the first ICTO to the second ICTO, so that the first ICTO is contained within the second ICTO. Similarly, in some embodiments, a rule in the first ICTO may generate a second ICTO and add a second ICTO to the first ICTO, so that the second ICTO is contained within the first ICTO.

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

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

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

Although randomly applying time as unique numbers and other internal components generated by intelligence module 709, mixer 702 using one or more algorithms, some internal clocking patterns 707 are It is determined whether it applies to the entry 701. Thereafter, the algorithms utilized by the mixer 702 to select the internal clocking patterns 707 are added to the identity module 708, managed internally, and shared/exchanged/exposed externally by the ICTO 710. It doesn't work. Each entry 701 utilizes one or more internal clocking patterns 707 that may be fundamentally different from one or more internal clocking patterns 707 that protect the other entries 701 in the digital mixture 710. Can be protected. For example, an entry such as owner data 706 may contain one or more internal clocking patterns and internal rules that are fundamentally different from the internal rules and one or more internal clocking patterns 707 utilized to protect the identity module 708. Can be protected with In addition, the use of one or more internal clocking patterns 707, and the random use of time as internal rules and unique numbers, is a unique addition to the identity module 708 for each entry 701 at a later date. Create a clocking pattern. The internal rules embedded in the intelligence module 708 may include, but are not limited to, location, time, authorization requirements, and the like.

The internal clocking patterns 707 are variations that are applied to the entry 701 to protect the entry 701 within the ICTO 710, and some of these variations are some of the entries 701 or Describes how to go back to access all. Transformations include, but are not limited to, data compression, data normalization, and encryption. A given inner clocking pattern 707 may include one or more of these techniques and/or other techniques. Data compression can reduce the overall size of the ICTO 710, thereby improving transmission time and bandwidth usage in the future. Data compression can be performed by any suitable lossless compression algorithm including, but not limited to, DEFLATE, LZW, LZR, LZX, JBIG, D _j V _u , and/or the like. Data normalization is performed by any suitable processing that places the data in a form that can be processed efficiently. In some embodiments, the data may be subjected to a Base64 encoding algorithm to convert data in binary or text format into a normalized alphanumeric string. This is an example only and should not be considered limiting. In other embodiments, other algorithms may be used to normalize the data.

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

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

In some embodiments, the intelligence module 709 of the portable dynamic rule set 711 may require two or more nested clocking layers for some or all of the entries 701. For example, execution of the first rule by mixer 702 may clock a first portion of protected digital mixture 710. Therefore, the execution of the second rule by the mixer 702 uses a different internal clocking pattern 707 in the clocked first part of the protected digital mixture 710 according to the first rule and the corresponding first clocking rule. You can make it cloaked again. Thus, in order to later access the first portion of the protected digital mixture 710, the second declocking rule corresponding to the second rule declocks the nested and clocked first portion of the protected digital mixture 710 and , Executed to obtain the first declocking rule. The first declocking rule is then executed to declock the first portion of the protected digital blend 710 to create a plain text version of the first portion of the digital blend 710.

If the internal clocking patterns 707 are applied to the entries 701 to create a set of clocked entries 720, the method 800 is that the mixer 702 is a digital mixture (i.e., ICTO) 710. Proceed to block 808, which completes the construction of ). In some embodiments, additional protections such as data shuffling, additional clocking and/or the like may be applied throughout the digital mixture 710. The method 800 then proceeds to the last block and ends.

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

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

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

From the start block, the method 300 proceeds to block 302 where the portable dynamic rule set 108 in the digital blend 115 is activated in response to a request by an agent wishing to access the digital blend 115. . In some embodiments, a super-identity is embedded in the ICTO 115, the criteria for verifying the identity of the agent attempting to access the ICTO 115, checking the agent and determining the current state of the data. Dynamic rules for providing intelligent recognition, and algorithms for clocking data as specified in clocking patterns. Verification criteria such as challenge/response pairs, digital signatures, biometric information, and/or the like can be used to verify the identity of the agent. At block 304, a portable dynamic rule set 108 is executed to verify that the agent is allowed the requested access to the digital mixture 115 in the relevant context. Identity module 109 and intelligence module 111, when activated, evaluate current access attempts by the verified agent and establish a trust level. In some embodiments, this evaluation is an ongoing process, ie, inspection and verification of each entry 101: data owner, agent (data user), and the data itself continues. In some embodiments, the pre-access rules from portable dynamic rule set 108 are internal by mixer 110 without allowing agents other than mixer 110 to access decrypted data. It may be implemented by mixer 110 to decrypt at least some portion of ICTO 115 for use. The pre-access rules have access to entries 101, including the ability to test identity artifacts and evaluate owner and agent data. When the confidence level is lowered, the protocol re-evaluates the entries 101. In some embodiments, if an agent attempting to access ICTO 115 cannot re-establish their legitimacy, defensive or offensive actions may be invoked. If the agent can satisfy the new set of challenges, then access will be allowed to proceed or continue.

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

The method 300 proceeds to block 306 where the portable dynamic rule set 108 determines the clocking pattern to be used to protect the requested data. The portable dynamic rule set 108 references the mixture metadata 104 to determine which clocking pattern 107 to apply based on the identity of the agent, the data request, the context in which the data is requested, and/or the like. Once the clocking pattern 107 to be used is determined, the method 300 proceeds to block 308 where the clocking pattern 107 is used to provide the requested access to the agent. Similar to how the clocking pattern 107 represents the set of techniques used to protect the requested data, the clocking pattern 107 is also used to reconstruct the requested data from the protected version stored in the ICTO 115. Represents a set of skills to be achieved. The method 300 then proceeds to the last block and ends.

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

From start block 901, method 900 responds to a request by an agent that wishes to access the digital mix or ICTO 710 by the dynamic entry controller 702 in the protected digital mix or ICTO 710. Proceed to block 902, which is activated by an ICTO-aware application, device, or operating system. In some embodiments, the owner/agent identity and/or one or more agent identities are included in the identity module 708 embedded in the ICTO 710, and the identity, authentication, and authentication of the agent attempting to access the ICTO 710. And criteria for validating the validity, dynamic rules for providing intelligent recognition for validating the agent and determining the current state of the data, and an algorithm for clocking data as specified in the clocking patterns. Verification criteria such as challenge/response pairs, external authorizations, biometric information, and/or the like may be used to authenticate, verify, and/or verify the identity of the agent. At block 903, utilizing portable dynamic rule set 711, requesting agents are verified in an efficient, complete, complete, and associated context, and access to digital mix 710 is allowed.

The method 900 includes one or more cloaking patterns used to protect the requested data by the portable dynamic rule set 711 based on the agent's identity, the data request, the context in which the data is requested, and the like. Proceed to block 904 to provide for. Proceeding to block 905, the DPC or mixer 702 is based on the data owner's rules for the legitimate agent, the data request, the context in which the data is requested, and/or the like on the command from the portable dynamic rule set 711. Thus, by declocking some or all of the protected data in ICTO 710, it is managed by portable dynamic rule set 711.

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

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

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

The first computing device 416 communicates the ICTO 408 to the second computing device 420 used by the second user 422 over a network such as a LAN, wireless network, Internet, and/or the like. The second user 422 activates the ICTO 408 and submits a request 424 to access data 1 404. ICTO 408 verifies the identity of the second user 422, which is to process challenge/response pairs stored in ICTO 408 and/or verify that the second user claims it is correct. Includes referencing a trusted service 409 (such as a certificate server, RADIUS, or other authentication server, and/or the like). When the identity of the second user 422 is verified, the ICTO 408 refers to the cloaking pattern used to generate the protected data 1 410, and uses the cloaking pattern to provide data 1 to the second user 422. Gives access to 404. However, since ICTO 408 is not instructed to provide access to data 2 406 to second user 422, ICTO 408 does not allow second user 422 to access data 2 406 Do not allow to do.

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

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

This use case demonstrates some of the advantages of this bulletin. Once ICTO 408 is created, protected data 1 410 and protected data 2 412 cannot be accessed without invoking the processing of ICTO 408 to request access. Accordingly, the data is transmitted to the second computing device 416 when the ICTO 408 is stored in the first computing device 416 and when the ICTO 408 is being transmitted over the network 402. When stored, it is protected. Also, although ICTO 408 provides access to data 1 404 to second user 422, data 2 406 is nevertheless protected from access.

While this simple use case represents some of the features of this posting, more complex use cases are also possible. For example, FIG. 5 is a schematic diagram illustrating aspects of an exemplary workflow for an embodiment of the present disclosure. The first user ("User A"), while maintaining a secret through the transaction, to the second user ("User B"), the third user ("User C"), and the fourth user ("User D") It can have a set of documents (“documents X, Y, and Z”) to be approved and signed by. Document X needs to be signed by User B. Document Y needs to be signed by user B and user C only after document X has been signed. Document Z needs to be signed by user D only after documents X and Y have been signed. In addition, Document X and Document Y must be signed during business hours (e.g., 9 am to 5 pm) to ensure compliance with local company policy, and Document Z (the working draft of Document Y) must be documented. The signatures of X and Y must be signed as soon as they are approved, and the audit is loaded, after which document Z is destroyed if the audit is also logged.

Embodiments of this publication will support this workflow. User A creates an ICTO containing documents X, Y, and Z. User A creates an access rule for document X that allows user B to review and sign document X. User A creates an access rule for document Y that allows user B and user C to review and sign document Y once the signature for document X is obtained. User A creates an access rule for document X that allows user C to verify document X to verify signature (or access rule for document X can detect the signature provided to document X), When a signature is detected, you can dynamically update the access rules for document Y that allow document Y to be signed. User A creates an access rule for document Z that verifies the signatures for documents X and Y, and if these signatures are detected, user D is allowed to sign document Z. Each of these rules also enforces the associated temporal requirements and disallows access if the temporal requirements are not satisfied. User A can also create a rule to report any access to certain documents to User A, so User A can monitor processing. Each of the rules may specify how each user is identified, associated privileges, devices that users are allowed to access documents, and locations where users are permitted to access documents.

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

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

In another exemplary embodiment, a protection protocol is introduced into a portable identity appliance (PIA). PIA uses a reflective and automatic authentication method to define portable and discrete digital identities. PIA ultimately implements the integrated ICTO protocol, so it becomes an intelligent object itself. In some embodiments, the PIA is an ICTO that does not contain owner data (eg, files, images, etc.). The PIA includes ICTOs that utilize PDRS with additional publicly available information about the owner (similar to information listed on a business card or public directory), but does not necessarily include owner data. Thus, the PIA is a self-protecting, self-controlling, self-managing ICTO with the purpose of undeniably representing the identity of the owner.

As shown in Figure 10-13, once a protected PIA is created, it creates a protected data object and facilitates secure message transmission between one or more parties (e.g. sender and receiver legitimacy and data integrity. Inspected and maintained), Web sites, portals, networks, or other resources can be combined with data to provide a secure and reliable identity that can be used to endorse or monitor.

Thus, PIA offers significant advantages over existing signature technologies. Existing signature techniques are typically based on certificates purchased from a certification authority. Certificates are considered to be of trustworthy value based on who has the certificate and who issued the certificate. However, certificates may be stolen, spoofed, and not based on a uniquely defined identity.

Thus, ICTO can be used for non-retrospective verification of the identity for which a "signature" is required. Signature ICTOs can be used as external identity verification related to the ICTO, including legal documents requiring full identity verification. The signature ICTO(s) may be the (embedded) part of the "final" legal documents contained in the original ICTO. In addition, the signature ICTO(s) can be included (i.e., nested) within the ICTO as additional protected data components in addition to the owner documents that require signature, thus pre-requiring the required signers to move with the documents. Define and provide pre-validation. The signature ICTO(s) can also be used as an indisputable identity verification within documents, not included in the ICTO but included in ICTO aware applications. For example, they can be used to electronically provide acceptance of conditions or to provide awareness of personal information notices.

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

Those of skill in the art will appreciate that the above use cases are merely exemplary, and that many other use cases for the subject matter published herein are possible. For example, portable dynamic rule sets contain executable code, so ICTO can protect executable content, which is executable only when it meets ICTO's security checks. In addition, since ICTO can execute such content in response to success or failure of any rule, ICTO can take actions such as logging successful accesses or alerting data owners to detect unauthorized access attempts. -Initiate a destruction sequence or other actions.

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

6 is a block diagram illustrating an exemplary hardware structure of a computing device 500 suitable for use with embodiments of the present disclosure. Those skilled in the art and others believe that 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, It will be appreciated that it may be any one of any number of devices currently available or still in development, including table computers, and/or the like. In its most basic configuration, computing device 500 includes at least one processor 502 and system memory 504 connected by a communication bus 506. Depending on the exact configuration and type of the device, system memory 504 may be volatile or nonvolatile memory, such as read-only memory ("ROM"), random access memory ("RAM"), EEPROM, flash memory, or similar memory technology. I can. Those of skill in the art and others will recognize that system memory 504 typically stores data and/or program modules that can be accessed immediately by processor 502 and/or are currently operating. In contrast, the processor 502 operates as a computerized center of the computing device 500 by supporting the execution of instructions.

As further shown in FIG. 6, computing device 500 may include a network interface 510 that includes one or more components for communicating with other devices over a network. Embodiments of this disclosure can access basic services that utilize network interface 510 to perform communication using common network protocols. In the exemplary embodiment shown in FIG. 6, computing device 500 also includes a storage medium 508. However, services may be accessed using a computing device that does not include means for persisting data to a local storage medium. Accordingly, the storage medium 508 shown in FIG. 6 is indicated by a dotted line to indicate that the storage medium 508 is optional. Anyway, the storage medium 508 is any storage medium capable of storing information such as, but not limited to, a hard drive, solid state drive, CD ROM, DVD, or other disk storage, magnetic cassettes, magnetic tape, magnetic disk storage, etc It can be volatile or non-volatile, separate or non-separable, implemented using technology.

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

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

Accordingly, the embodiments and examples described herein are the principles of the invention in order to enable those skilled in the art to best utilize the invention in various embodiments and with various modifications considered suitable for specific uses. And it is to be understood that it has been selected and described to best represent its practical application. While specific embodiments of this invention have been described, they should not be considered perfect. There are several variations that are obvious to those skilled in the art.

102: object description
104: mixture metadata
106: Owner data
107: clocking patterns
109: Identity module

Claims (16)

In a system for improved security of a computer system,
A computer-readable medium having computer-executable instructions stored thereon, the instructions comprising:
A computer-based intelligent cryptographic delivery object comprising a digital mixture of a set of entries, the set of entries:
Owner data;
One or more external clocking patterns configured to be applied to the set of entries such that an intermediate cryptographic object is created; And
An identity module, an intelligence module, and a portable dynamic rule set comprising one or more internal clocking patterns, each internal clocking pattern being (i) a transformation to be applied to some entries in the set of entries, and (ii) reversing the transformation. Include the portable dynamic rule set, including a description for,
In response to execution by one or more processors of the system, the instructions cause the intelligent cryptographic transfer object to:
Receiving, from an external agent, a request to access some or all of the set of entries;
Attempting to verify that the foreign agent is permitted to access some or all of the requested set of entries; And
If the foreign agent is verified to be authorized, it does not provide access to an unauthorized portion of the set of entries, and access to the external agent provides access to some or all of the set of entries that are verified. A system for improved security of a computer system, allowing the steps to be performed internally. 2. The system of claim 1, wherein the portable dynamic rule set is located at variable locations within the intelligent cryptographic transfer object. The system of claim 1, wherein the intelligent module is located at variable locations within the intelligent cryptographic transfer object. The method of claim 1, wherein the portable dynamic rule set comprises at least one rule identifying which foreign agents can access some or all of the set of entries, and a specific foreign agent of the set of entries. A system for enhanced security of computer systems, including a context in which some or all of them can be accessed. The enhanced security of a computer system according to claim 4, wherein the context in which a particular foreign agent can access some or all of the set of entries comprises one or more of: a time period, location, or identity of a computing device. System for 2. The system of claim 1, wherein the set of entries further comprises mixture metadata. 7. The system of claim 6, wherein the compound metadata includes information used to access each entry in the set of entries by internal or external clocking patterns or patterns. The method of claim 1, wherein the intelligent cryptographic transfer object further:
If it fails to verify whether the external agent is authorized, internally performing the step of executing at least one rule in the portable dynamic rule set,
The at least one rule is:
The intelligent cryptographic transfer object being self-destructive;
A message or alert being sent to the data owner; or
Causing one or more of causing a record of the access request to be stored in the intelligent cryptographic transfer object. The method of claim 1, wherein the intelligent cryptographic transfer object further:
If the external agent provides access to some or all of the set of entries for which access has been verified, internally executing at least one rule in the portable dynamic rule set,
The at least one rule is:
A message or alert being sent to the data owner;
Storing a record of the access request in the intelligent cryptographic delivery object;
The requesting agent's signature is associated with the requested entry or entries; or
A system for enhanced security of a computer system, causing one or more of adding, modifying, or deleting at least one rule in the portable dynamic rule set. The system of claim 1, wherein the intelligent password transfer object is nested in a second intelligent password transfer object. 11. The system of claim 10, wherein the internal clocking patterns are used to clock the owner data, identity module, intelligence module, or combinations thereof. 11. The system of claim 10, wherein the second intelligent cryptographic transfer object is contained in one or more additional intelligent cryptographic transfer objects. In a system for enhanced security using digital signatures or verifications:
A computer-readable medium having computer-executable instructions stored thereon, the instructions comprising:
A self-managing, self-controlling, self-protecting personal identity appliance, the personal identity appliance comprising a computer-based intelligent cryptographic delivery object comprising a digital mixture of a set of entries and ,
The set of entries, the personal identity appliance comprising one or more external cloaking patterns configured to be applied to the set of entries such that an intermediate cryptographic object is created; And
A portable dynamic rule set comprising an identity module, an intelligence module, and one or more internal clocking patterns, each internal clocking pattern:
A system for enhanced security, comprising the portable dynamic rule set, including (i) a modification to be applied to some of the entries in the set of entries, and (ii) a description to reverse the transformation. 14. The system of claim 13, wherein the portable dynamic rule set is located at variable locations within the intelligent cryptographic transfer object. 14. The system of claim 13, wherein the intelligent module is located at variable locations within the intelligent cryptographic transfer object. 14. The system of claim 13, wherein the internal clocking patterns are used to clock the identity module, an intelligence module, or a combination thereof.

Images