Payload assurance method and system, derived control system, computing device, network

Abstract

A payload assurance method and system, a derived control system, a computing device, and a network are provided. A method and apparatus for payload assurance of a payload to be transmitted across a network boundary via any of a plurality of predetermined boundary control devices, which can be grouped together, each predetermined boundary control device having dedicated permanent identity information. A first electronic entity provides an electronic authorization token for defining the characteristics of the payload and determines a temporary ID array based on the permanent identity information and authorization token of each boundary control device in the boundary control group. An electronic release token to be forwarded to a second electronic entity is generated based on the temporary ID array and the authorization token; the release token is valid when used with the boundary control devices provided in the defined boundary control group.

Description

Technical Field

[0001] This invention belongs to the field of data assurance at multiple network boundaries or gateways, and specifically provides assurance of suitability and authorization for transmitting payloads between networks with different levels of trust. Background Technology

[0002] One of the most significant risks in high-trust networks is the leakage of data into low-trust networks, leading to a breach of confidentiality. In many cases, outbound paths from high-trust networks will be shaped by high-guarantee boundary controls, such as data diodes.

[0003] Because boundary control acts as the "gatekeeper" of a high-trust network, any processing used by this boundary control must be highly guaranteed—that is, provide control with a high degree of determinism in making the correct decision in all possible situations. This requirement for high guarantee limits the possibilities of hardware boundary control. For example, highly complex data (or information) formats require complex algorithms and processing to guarantee them, and it is difficult to obtain a high guarantee of the correctness of implementations of complex algorithms. Furthermore, some information formats are not specificationally explicit and change over time, making it impractical to keep any algorithm both highly guaranteed and up-to-date. This can even be demonstrated when considering very simple control criteria related to payload content, where the criterion response changes over time; for example, in determining whether a particular sequence of bytes represents a valid Unicode character, the answer will change depending on when the query is made.

[0004] Public Key Infrastructure (PKI) is commonly used to facilitate the secure electronic transfer of data over a network. PKI is used when a more robust authentication method is required to verify the identities of the parties involved and to authenticate data being transferred across network / domain boundaries. However, the multiple elements required to manage digital certificates and public key encryption need to be configured and updated regularly to maintain the desired level of system security.

[0005] In our co-pending UK application no. GB2010968.2, a payload assurance system and method are described that uses separate electronic entities to ensure the payload (by using an entropy element in an authorization token to provide ephemeral authorization at a network boundary device based on a permanently shared secret), and permits the transmission of the payload across the network boundary once predetermined test criteria specified in various tokens, including an derived header, are met at the predetermined network boundary device. Hereinafter, this application will be referred to as Version 1.

[0006] The created exported header is only valid for a single gateway, which, while providing security and guarantee advantages, also has disadvantages in terms of scalability and data throughput. Therefore, there is a need to achieve resilience without sacrificing security, so that the same payload can be sent multiple times via different gateways (and to enable the ability to handle the arrival of multiple identical payloads to the destination).

[0007] Because all forms of gateways are physically limited in size, existing solutions are also limited in the size of their acceptable payloads, a limitation stemming from the need to keep the entire payload within the gateway for assurance. For efficient, simple, and secure services, it is desirable that any consumer of the service is not bound by these internal limitations and can send any file of any size via a BCD-based service.

[0008] The lack of release / import metadata in the export header of the version 1 payload assurance scheme means that although the requirement to move the payload across the security boundary was successfully achieved, the header does not indicate the appropriateness of the release / import to that particular destination, nor does it provide a method for such an intention.

[0009] Therefore, a scalable cross-domain payload guarantee method and system is needed that provides payload guarantees related to the suitability of outgoing data at cross-domain boundaries, and that features improved security, proper authorization for cross-domain transmission, provision of temporary authorization, flexibility for time variations, utilization of multiple boundary control devices across a single boundary, freedom from the inherent payload size limitations of boundary control devices, and the ability to provide centralized management and control. Summary of the Invention

[0010] Therefore, a method is provided for ensuring the payload X to be transmitted across a network boundary via any of a plurality of predetermined boundary control devices, the method comprising the following steps:

[0011] Provided at the first electronic entity upon request:

[0012] An electronic authorization token used to define the characteristics of the payload X to be transmitted;

[0013] A boundary control group is defined at the network boundary, the boundary control group comprising at least two boundary control devices, each of which has a dedicated permanent identity associated with it.

[0014] A temporary ID array is determined based on the permanent identity information and authorization tokens of each border control device in the border control group; and

[0015] An electronic release token is generated based on the temporary ID array and the authorization token to be forwarded to the second electronic entity. The release token is valid when used with the boundary control device provided in the defined boundary control group.

[0016] The first electronic entity is the Central Release Authority (CRA) located on the trusted side of the network boundary. Within the CRA, each permanent identity value K... G Each entity is assigned a unique, arbitrary label. A gateway group is a managed set of these labels, where each border control device (BCD) within the set is associated with the same destination and requires the same authorization. When a second entity (the signing entity) requests authorization for the destination, a single, suitable authorization token A is generated. t The CRA then resolves the destination into a list of associated gateway tags, and subsequently associates the gateway tags with a single authorization token A. t Together they are used at the destination to compare with K for each BCD storage. G The value is used to perform calculations, thereby creating session IDs for each BCD, and finally compiling these session IDs into a session ID array. Therefore, the method may include the following steps: from the gateway key and authorization token A... t Generate a session ID array {S i}, where the gateway key is generated from all gateways in the gateway group.

[0017] The method may further include the step of generating at least one entropy element to form part of an electronic authorization token, so as to ensure that multiple electronic authorization tokens authorizing the same payload characteristics are unique.

[0018] During the validity period of the release token, an authorization request is sent to one or more payloads to apply the release token. Specific parameters can be assigned to a given signer, thereby restricting the content they can sign off.

[0019] The validity period of a released token can depend on a predetermined period defined by the first electronic entity within the authorized token. Specific parameters given to the signer limit what they can sign.

[0020] Upon receiving a release token and in accordance with a payload transmission request, the second electronic entity can create file tokens for each boundary control device in the gateway group based on a temporary array, a local token including parameters remotely defined from the first entity, and a hash digest of the payload X to be transmitted, to provide a file token array {F}. t By using hash digests, the signer can sign a file without ever having to look at the full payload, making signing more efficient.

[0021] The hash digest can be provided as follows: before payload X is received by the second entity as part of a payload transmission request, payload X is passed through a one-way function. Upon reception, the hash digest in the header is accessed by one or more boundary control devices in the boundary control device group to determine the validity of the header before payload X arrives at one or more predetermined boundary control devices. This allows for more efficient criterion checking at the BCD, as it does not require waiting for the entire payload.

[0022] Local tokens can include entropy elements.

[0023] At least one parameter of the local token is provided by a third electronic entity to verify the expected payload parameters for payload transmission across network boundaries. The third electronic entity is the orchestrator entity that provides payload verification against criteria.

[0024] The fourth electronic entity can act as the payload sender entity and the sole electronic entity communicating with the boundary control device in the boundary control group, and can define at least one parameter of the local token's parameters. With a predetermined selection of the local parameter L' used to define a portion of the local token's input parameters, the fourth electronic entity can send the payload X to the third electronic entity.

[0025] According to the method for payload assurance of payload X according to the present invention, a third electronic entity verifies the payload against predetermined rules provided upon receiving a payload transmission request and / or the expected payload transmission destination, and provides a verified evidence object to be included in a local token. The evidence may be an array of assertions claiming that a portion of the payload X1 with a digest #(X1) can be transmitted. The compiler sends back a signed object (e.g., a JWT) to the sender, which claims that a payload with a digest = #(X) and a local header L' has been approved. The sender sends the evidence (not the payload) to the signer, who (because it can check the signature on the JWT) can be assured that the authorizing entity created the signature and that the evidence is being transmitted by the entity that derived the approval.

[0026] The payload name will be J||n (e.g., file001), where the payload will be a fixed padding pattern used for all exports.

[0027] The second entity can be configured to subsequently generate a payload header based on an authorization token, a local token, a file token array, and a hash digest of the payload. In the case of payload derivation, if the second electronic entity (the signing entity) has or acquires a valid release token and the evidence is provided by a third electronic entity (the compiling entity), the signing entity creates the exported payload header and forwards it to the sender. The signing entity creates the header based on the release token for the payload it requests to authorize for transmission across the network boundary. An array of exported headers (each exported header having an associated hash table) is provided to satisfy the various BCDs in the boundary control group.

[0028] Before the fourth entity forwards payload X to one or more boundary control devices in the boundary control group, the payload header may be placed before payload X. The fourth entity is the sending entity and is communicatively connected to the signing entity to make a payload transmission request and to receive the payload header (e.g., derive the header). Specifically, the elements of the payload header may be created by the first, second, third, and fourth electronic entities. This provides a point of failure, thus requiring all four electronic entities to provide appropriate headers for the payload to be transmitted.

[0029] When at least a portion of a payload with payload header E arrives at a boundary control device, the boundary control device can regenerate a session ID (S) using the boundary control device's permanent ID information and the authorization token from the header. i ) g .

[0030] At the boundary control device, the file token F can be calculated using the session ID along with the parameters in the header. t The file token generated at the border control device is F. t '=#(#(X),L,J,HMAC(K G ',A)), except for the value K, which serves as the permanent identity information for the boundary control device. G Apart from that, all quantities are obtained from the header. The session ID is HMAC(K). G ',A).

[0031] Boundary control devices can handle file tokens F t 'With the file token array {F located in header E t} compare to determine if the file token matches the file token array {F t If one of the values ​​in} is the same, and a match exists, a first positive event result identifier can be subsequently generated.

[0032] Boundary control devices can enable payload transfer via a unidirectional function to provide #(X) from X. g And for #(X) g It is compared with #(X) in header E, and if a match is found, a second positive event result identifier is then generated.

[0033] The boundary control device can also compare other control criteria included in the export or import header to ensure that the other control criteria are within predetermined limits, and provide a third positive result identifier if the other control criteria are within predetermined limits.

[0034] The boundary control device can identify the first positive result identifier, the second positive result identifier, and the third positive result identifier, and then determine the positive boundary control result.

[0035] When the positive boundary control result has been satisfied, the boundary control device transmits the payload X with header E across the network / domain boundary.

[0036] Boundary control devices can be configured to prohibit file transfer across network / domain boundaries if a positive boundary control result has not yet been satisfied, and / or enable file discarding.

[0037] One or more boundary control devices in a boundary control group can block invalid exported headers and incompatible payloads with valid headers based on authorization tokens and temporary ID arrays.

[0038] The payload can be divided into chunks smaller than the maximum size obtainable from the boundary control devices in the boundary control group. Advantageously, the size restrictions on the boundary control devices in the boundary control group are removed, and any payload size can be forwarded through a flexible set of boundary control devices without the sender knowing which boundary control devices are available.

[0039] The method may further include the following steps: creating a payload header array based on an authorization token, a file token, a local token, and a hash table of the payload, wherein each payload block in the payload block corresponds to a payload header.

[0040] Subsequently, the method may further include the following steps: placing the payload header of the block before the corresponding payload divided into blocks, and forwarding the resulting signed payload block to one or more boundary control devices in the boundary control group.

[0041] In an alternative embodiment of the invention, a payload assurance system is provided for a payload X to be transmitted across a network boundary via at least one predetermined boundary control device. The system includes a first electronic entity having at least one computer processor and at least one data storage device. The at least one data storage device includes instructions executable by the at least one computer processor to:

[0042] Generate an electronic authorization token to define the characteristics of the payload X to be transmitted;

[0043] A boundary control group is defined at the network boundary, the boundary control group comprising at least two boundary control devices, each of which has a dedicated permanent identity associated with it.

[0044] A temporary ID array is determined based on the permanent identity information and authorization tokens of each border control device in the border control group; and

[0045] An electronic release token is generated based on the temporary ID array and the authorization token to be forwarded to a second electronic entity in the system. The release token is valid when used with the boundary control device provided in the defined boundary control group.

[0046] The first electronic entity is the Central Release Authority (CRA) located on the trusted side of the network boundary, and the permanent identity information value K of each boundary control device (BCD) G Each entity is assigned a unique, arbitrary label. A boundary control group is the managing set of these labels, where each BCD in the set is associated with the same destination and requires the same authorization. When a second entity (the signing entity) requests authorization to transmit the payload to the destination, a single, suitable authorization token A is generated. t The CRA can then resolve the destination into a list of associated border control device (BDC) tags, and subsequently associate the BDC tags with a single A. t Together they are used at the destination to compare with K for each BCD storage. G The values ​​are calculated to create session IDs for each BCD, and finally these session IDs are compiled into a session ID array.

[0047] Electronic authorization tokens may also include at least one entropy element to ensure that multiple electronic authorization tokens authorizing the same payload characteristics are unique.

[0048] Multiple separate and distinct electronic entities include at least one authorizing entity, at least one sending entity, at least one signing entity, and at least one payload verification entity (i.e., compiler). The roles of the signing entity, sending entity, and compiler do not need to be separated, but can be combined into various unified roles. For example, the roles of i. sending entity and compiler, ii. sending entity and signing entity, and iii. all three roles can be collapsed / combined.

[0049] The system may also include a signing entity configured to sign any number of payloads using the release token during the validity period of the release token.

[0050] Upon receiving a release token and a payload export request, the signing entity can be configured to compute file tokens for each boundary control device in the gateway group based on the ephemeral array, local tokens, and a hash digest of the payload to be transmitted, to provide a file token array {F}. t The use of #X allows the signer to sign payload transmissions without actually receiving the payload and therefore without checking it.

[0051] The hash digest can be provided as follows: the payload X is passed through a one-way function before being forwarded to the signing entity. To avoid ambiguity, the hash digest in the header allows the boundary control device to determine the validity of the header before the payload X reaches one or more predetermined boundary control devices.

[0052] The local token defines parameters associated with the payload, the payload delivery destination, and / or parameters defined by the sending entity. Advantageously, the local token does not contain information about the number of gateways, parts, actual size, or classification. Therefore, the system is configured to check the content of the authorized token and alternative release criteria provided by, for example, the local token.

[0053] Local tokens may also include entropy elements.

[0054] The parameters of the local token can be provided by the payload verification entity and / or the sender entity.

[0055] The payload verification entity is configured to verify the payload against predetermined rules of the requester and / or the payload destination, and is configured to provide evidence objects for verification to be included in the local token.

[0056] The object of evidence can be a claim that can send a digest #(X) n Partial effective load X nThe claim array is compiled. A signed object (e.g., a JWT) is sent back to the sender, claiming that the payload with digest = #(X) and local header L' has been approved. The sender sends the evidence (not the payload) to the signer when making a file transfer request. The signer entity can then be confident that the authorizing entity created the signature and that the evidence is being sent by the entity that derived the approval.

[0057] The signing entity is configured to subsequently generate a payload header based on the authorization token, local token, file token array, and a hash digest of the payload.

[0058] The signer creates a header based on the release token for the payload it requests to be authorized for transmission across network boundaries. In practice, it generates an array of exported or imported headers (each exported or imported header has an associated hash table). The header is then forwarded to the sending entity or other entity that made the payload transmission request.

[0059] Then, the header can be placed before the payload before the payload is forwarded to one or more BCDs in the gateway group.

[0060] The payload can be divided into blocks smaller than the maximum size that can be obtained from the boundary control devices in the gateway group.

[0061] Therefore, the size limit of the boundary control device is removed, and arbitrary files can be forwarded through a flexible set of gateways without the sender knowing which gateways are available.

[0062] The system may also include a signing entity configured to create a payload header array based on a hash table of authorization tokens, file tokens, local tokens, and payloads, with each payload block in the payload block corresponding to a payload header.

[0063] The system may further include: placing the payload header of the block before the corresponding payload divided into blocks, and forwarding the resulting signed payload block to one or more boundary control devices in the boundary control group.

[0064] When a payload is received at the border control device, the border control device can be configured to regenerate the gateway session ID (SID) using the border control device's permanent ID information and the authorization token from the header. i ) g .

[0065] At the boundary control device, the file token F can be calculated using the session ID along with the parameters in the header. t '.

[0066] The file token created at the border control device is F. t '=#(#(X),L,J,HMAC(K G ',A)), except for K obtained from the boundary control device G Apart from ', the value is taken from the header. The session ID is HMAC(K) G ',A).

[0067] Boundary control devices may include a comparator that can compare file tokens (F... t ) g Compare with the file token array located in header E to determine if the file token matches the file token array {F}. t If one of the values ​​in} is the same, and a match exists, the comparator is configured to generate the first positive event result identifier.

[0068] The boundary control device can be configured to transfer the payload through a one-way function to provide #(X) from X. g The comparator then applies #(X). g The comparison is performed against the #(X) in the header, and if a match is found, the comparator is configured to generate a second positive event result identifier.

[0069] The boundary control device can also compare other control criteria included in the export or import header to ensure that the other control criteria are within predetermined limits, and if the other control criteria are within predetermined limits, the comparator is configured to provide a third positive result identifier.

[0070] The boundary control device can be configured to identify a first positive result identifier, a second positive result identifier, and / or a third positive result identifier, and subsequently determine a positive boundary control result based on the first positive result identifier, the second positive result identifier, and the third positive result identifier.

[0071] The boundary control device can be configured to transmit payload X across network / domain boundaries after the positive boundary control result has been satisfied.

[0072] Boundary control devices can be configured to prohibit file transfer across network / domain boundaries if a positive boundary control result has not yet been satisfied, and / or enable the dropping of payloads.

[0073] The at least one sending entity may be a unique electronic entity communicating with at least one boundary control device.

[0074] The system may include a random number generator or a pseudo-random number generator, which is used to provide entropy elements of electronic authorization tokens and / or local tokens.

[0075] Alternatively, a derivation control system including the previously described payload assurance system may be provided.

[0076] In another embodiment of the invention, a computing device may be provided, comprising the payload guarantee system described above for guaranteeing the transmission of payloads from a less trusted network to a trusted network (or from a trusted network to a less trusted network).

[0077] In yet another embodiment of the invention, a network is provided that includes the payload guarantee system described above for ensuring the transmission of payloads from a less trusted network to a trusted network (or from a trusted network to a less trusted network).

[0078] In all cases, the boundary control device can be a gateway device, and the two terms can be used interchangeably.

[0079] Once the authorized payload characteristics are specified via the issuance of an authorization token, there is no option to change them. This means that the boundary control device does not need any knowledge of the details of the verification scheme, but rather the interrelationships between entities within that scheme. For example, the gateway only considers verifiable claims between headers, inherent characteristics of the payload (e.g., size, compliance with file types known to the boundary control device), and environmental factors (e.g., time constraints). In other words, the BCD does not have any prior knowledge of the specific values ​​of the authorized payload characteristics for a given payload, but it can determine the permitted characteristics of that payload from the derived headers.

[0080] This allows for the autonomous release decision using a sealed-for-life gateway. In this context, autonomy means making the decision without reference to other electronic entities. This maintains the isolation (or separation) between the determination of the authorization parameters (at the CRA) and the verification decision at the gateway regarding payload compliance with the parameters, and prevents the need to request authentication decisions from alternative electronic entities, thereby enhancing security at the gateway by eliminating the ability of third parties to compromise the decision information. Therefore, the boundary device can comprise the simplest possible device that never needs replacement or updating and never changes. However, the method of generating the derived header ensures that the determined authorization parameters cannot be altered by any intermediate system between the CRA and the BCD.

[0081] Only authorized payloads / exports can be allowed to cross domain boundaries. A good export scheme typically considers: content control, time-limited authorization, and ultimately stopping the transmission of unauthorized formats. Advantageously, the system can be configured to use electronic tokens to control authorization.

[0082] The computing device may include: a desktop or laptop computer, a tablet computer, a personal digital assistant (PDA), a mobile phone, a smartwatch, a hard disk, a solid-state drive or drive, a memory, or other smart or mobile device capable of storing and / or displaying data or otherwise acting as a data device. Alternatively, a display device is also disclosed, including a monitor, projector, screen, etc., capable of storing and / or displaying data or otherwise acting as a data device. For user convenience, it may individually and / or collectively include the devices outlined above.

[0083] The "derived payload" is formed by the header and the payload. However, it is important to note that the payload guarantee system and method can be used on data packets that also include a packet header and packet data, where a new packet is created using the derived header and the original packet content. It can also be used for streaming data, where the derived header is placed before the streaming data. This encapsulation of the original payload in the new packet is a common strategy in tunneling protocols and is known to those skilled in the art.

[0084] Although the invention has been described above, the invention extends to any inventive combination of features set forth in the above or below description and drawings. For example, any feature described with respect to any aspect of the invention should be understood as also disclosed with respect to any other aspect of the invention. Attached Figure Description

[0085] The invention will now be described by way of example only with reference to the accompanying drawings, in which:

[0086] Figure 1 This is a schematic diagram of a system for ensuring payload at network domain boundaries according to a first aspect of the present invention; and

[0087] Figure 2 The authorization token format according to the present invention is shown;

[0088] Figure 3 The release token format according to the present invention is shown;

[0089] Figure 4 The local token format according to the present invention is shown;

[0090] Figure 5 The payload release header format according to the present invention is shown;

[0091] Figure 6 This is a flowchart of a method for ensuring payload at network boundaries according to a first aspect of the present invention; and

[0092] Figure 7 This is a flowchart of a method for ensuring payload at network boundaries according to a second aspect of the present invention, wherein the payload is divided into blocks.

[0093] In the accompanying drawings, similar elements are indicated by similar reference numerals. A skilled reader will understand the complexity of implementing this method, and therefore the number of optional features will be driven by user requirements. Detailed Implementation

[0094] Reference Figure 1 A payload authorization control system 1 is provided for a payload X with header E, which is to be transmitted across network boundary 2 via a boundary control device 3 (e.g., a network gateway formed by hardware) as a device in a boundary control group 4. System 1 includes a computer processor 5 and a data storage device 6. For the payload assurance scheme to be operated, there are multiple roles or electronic entities that must assume specially assigned functions. Figure 1 The system is shown to contain five electronic entities. These electronic entities include the following:

[0095] • Sender 7: This entity communicates electronically with boundary control device 3, signer 8, and compiler 9. Sender entity 7 sends the payload based on a positive guarantee result provided by compiler 9 and subsequently a positive result provided by signer 8.

[0096] • Central Release Authority 10 (CRA): This entity manages access to exported gateway persistent identity blocks and the mapping of border control devices to destinations. It is also responsible for creating [the necessary information] based on queries from Signer 8. Figure 2 The authorization token. This entity only communicates electronically with the signing party 8.

[0097] The signatory 8 requests authorization appropriate to its role, which allows the signatory to create a exported or imported header for a given approved payload. The signatory 8 requests an authorization token from CRA 10, and approval for the export / import request based on evidence from compiler 9. In all cases, signing the payload refers to creating a header to be used with the payload to be transmitted across boundary control devices 3, 3'.

[0098] • The drafting party 9 evaluates the payload against the enterprise release guidelines (which, to avoid confusion, differ from the BCD release guidelines), and if satisfactory, provides evidence that the payload has been approved for export, along with additional information required by the signing party 8 entity to create the export / import header. The evidence will typically be an information structure (such as JSON or XML), although the exact format is not critical to the operation of the scheme. The evidence can be protected for integrity by being digitally signed (using conventional methods). The evidence can be passed to the signing party 8 directly or indirectly.

[0099] • Boundary control devices 3, 3' (BCD) (e.g., export gateways) have unique identity blocks 11, 11'. BCD 3, 3' is configured to block any payload with an invalid export header and will block any payload that is incompatible with the export header, even if the export payload is valid.

[0100] • Gateway / Border Control Group 4 - A group of one or more border control devices 3, 3' that allow exports to the same destination using the same authorization, in which the group is intended to be regarded as a single composite entity.

[0101] A standard network load balancer (not shown) will be used to route signed payloads from sender 7 to one or more BCDs 3, 3' based on a load balancing algorithm selected by a standard operator.

[0102] In a first embodiment of the invention, an authorization control and assurance system (hereinafter referred to as the assurance system) is configured to derive an authorized payload across one or more BCDs 3, 3'. The authorization system (which includes checks to be performed at the BCD itself) allows control over certain inherent characteristics of the payload (e.g., payload type), comparison of claimed characteristics (e.g., classification), addition of administrative features, and enabling the management of the lifetime of authorization via electronic tokens. This scheme creates and uses a payload-specific header comprising four independent sub-tokens preceding a specific payload. The payload will only be successfully delivered through BCDs 3, 3' as requested by the sending entity 7 if the information in the header is assured of its validity.

[0103] The header and its components have two representations—an informational representation (which may be included in a human-readable JSON or XML file) and a binary representation, which is how the binary representation is encoded in the header as a byte-level representation used in the functions supporting the scheme. For simplicity, both representations will be represented by a “token” (e.g., an “authorization token”), and where necessary, the form of the token (informational or binary) will be made explicit. Depending on the intended direction of transmission across BCD 3, 3', the header can be an export header or an import header.

[0104] Data storage devices include those capable of being run by a processor to provide authorization tokens A. t The instructions will describe the authorization token in more detail. This provides a consistent method for signing authorization requests by the authorizing entity, applicable to a variety of payload delivery authorization requests.

[0105] Boundary control devices 3 and 3' are network gateways located at the network domain boundary 2, i.e., at a location that enables transmission between the first network 12 and the second network 13 (or vice versa, depending on whether the payload needs to be exported or imported). For export, the network side where CRA is located is the trusted network 12, while the other network is the less trusted network 13.

[0106] As an example, in this implementation, the request to export the payload is made by the appropriate authorized party to compiler 9. In addition to accepting such a request, compiler 9 may use external or local services to determine the suitability of the payload for the requested export. These checks would resemble standard controls used by enterprises, such as data loss prevention (DLP), malware scanning, removal of hidden metadata, and other controls obvious to those skilled in the art. Compiler 9 compiles these services to obtain a status indicating approval or rejection of the export at compiler 9.

[0107] When an export is approved, the compiler 9 must compile evidence, which is a set of information related to the export, that allows the signer to create a file token array and thus create the export header of payload X.

[0108] In this implementation, the parts used by the signer 8, sender 7, and compiler 9 to each create the payload header (e.g., the derived header) ensure that defects or damages associated with one of the entities do not preclude misuse or accidental use of the system.

[0109] Although the signing entity 8 is configured to create a payload header by combining various tokens (described in more detail later) into a binary derived header, it is the sending entity 7 that: i. places the derived header before the relevant payload, and ii. sends the signed payload to the boundary control devices 3, 3'.

[0110] CRA 10 acts as the authorizing entity, thereby providing the release token R. t The release token is a unique token generated based on a query from the signing entity. It is a permanent identifier for the CRA 10 storage boundary control device and is responsible for obtaining the gateway key and authorization token A. t Generate a session ID array {S iThe gateway key is generated from all gateways in border control group 4. The session ID array includes moderately sensitive temporary values ​​(or temporary identities) that expire periodically, thus posing no long-term risk. Authorization token A t and Session ID Array {S i The pair is forwarded as a response to the query from the signing entity 8. This pair is defined as follows: Figure 3 The release token shown.

[0111] Signing entity 8 requests a release token from CRA10 and creates a header based on the release token for the payload it requests to authorize to be transmitted across network boundary 2.

[0112] An authorization token created by CRA 10 is an electronic token consisting of at least a first part related to the authorization characteristics of the payload and a second part used to provide entropy (or randomness) to the token; therefore, A t =<Entropy element> and <centrally specified parameter value>. The authorization token includes details about the CRA 10 authorization being transmitted over one or more BCDs 3, 3' and information about the authorization token itself (including its validity period). The entropy component is provided to ensure that multiple authorization tokens authorizing the same payload characteristics are unique. This allows for centralized control (e.g., on the trusted network side) of the specifications of characteristics and associated authorizations, and ensures that individual authorization requests and associated responses are distinguishable and equally auditable. In this implementation, the payload is the derived payload to be transmitted between the trusted network 12 and the less trusted network 13 across any one or more boundary control devices 3, 3' in the predetermined boundary control group 4.

[0113] The permanent identity information (e.g., identity block or other key type) associated with boundary control devices 3 and 3' is highly sensitive information and must be stored very securely. The permanent identity information will be referred to below as the permanent ID of the predetermined boundary control device 3 and denoted as K. G .

[0114] Permanent ID K associated with boundary control devices 3 and 3' in the system G It must be known at CRA10. Boundary control devices 3, 3' may: i. have a K created during manufacturing and securely presented to CRA10. G ii has K created by CRA 10 and loaded onto it. G , or iii has a K created by an independent source and loaded onto it. G And the same K G It was loaded onto CRA.

[0115] Within CRA 10, each KG Values ​​are assigned unique arbitrary labels. Boundary control group 4 is the managing set of these labels, where each BCD 3, 3' in this set is associated with the same destination and requires the same authorization. When the signing entity 8 requests authorization for the destination, a single suitable authorization token A is generated. t Then, CRA 10 resolves the destination into a list of associated gateway tags, and subsequently associates the gateway tags with a single A. t Together they are used at the destination to compare the K stored for each BCD 3, 3'. G The values ​​are calculated to create session IDs for each BCD3, 3', and finally these session IDs are compiled into a session ID array.

[0116] The authorization token can be mapped to a set of values ​​and used in the one-way function described below. It is assumed that all parts of the system use the same mapping; the details of the mapping are not important. The authorization token is a component of the exported header to be provided to the signing entity 8. To avoid confusion, the authorization token includes a central authorization control, which is a claim of permitted content exported across boundary control devices 3, 3'. For example, the authorization header includes:

[0117] • Version number - (i.e., version 2);

[0118] • Entropy (to ensure the uniqueness of each authorized header);

[0119] • Size - Maximum payload size (in bytes) (zero means no limit);

[0120] • File type - BMP, or other suitable file type as required (e.g., csv), or grouping type;

[0121] • Time - Provides "invalid before" or "invalid after" to control the token's lifespan;

[0122] • Payload claim (to be described below); and

[0123] • Destination identifier (to be described below).

[0124] The system is configured to check for alternative release criteria as well as for CRA-specified criteria. Alternative release checks are provided for local headers.

[0125] In contrast to version 1, the local header is not exclusively created by the sending entity 7; instead, the number of hashes in the hash table, the partial number, and the actual size of the payload are set by the compiler 9—all other fields are set by the sending entity 7. This provides the compiler 9 with a level of verification. The partial number can be combined with a UUID to uniquely identify the BCD.

[0126] like Figure 4 The local header (or local token) shown includes:

[0127] • Exported UUID - Generated by the compiler entity 9, this uniquely identifies each individual exported. It should be randomly generated as a type 4 UUID and also replaces the random transient value (nonce) of version 1.

[0128] • Time Limit - Generated by sender 7, during which time the authorized export file is allowed (which may be shorter than the validity period of the authorization token).

[0129] • Payload claim - as described below.

[0130] • Actual size - generated by compiler 9, this is the actual size of the exported payload (excluding the header) in bytes.

[0131] • Partial number - generated by compiler 9, and is usually 0 (zero) unless the payload is segmented.

[0132] • Number of file tokens (or hashes) - The number of file tokens generated by signer 8 and provided by signer 8 as part of the payload, i.e., the number of derived hashes in the hash table.

[0133] First, considering payload claims, in order to enable document classification authorization, the classification is transformed into a digital representation so that boundary control devices 3, 3' can check it. Users can use multiple schemes, and such schemes do not have an infinite lifespan.

[0134] One such scheme creates a new authorization token parameter called "Category," which can be used to describe the maximum category of a document that is allowed to leave the border control device. A typical scheme is Category (Official, Confidential, Secret, Top Secret). Similarly, for local tokens, this also has a qualifying parameter called Category, which has the same permitted value, which is the value of the category claimed by the sender.

[0135] These permitted values ​​are then mapped to values ​​in the respective headers. One such scheme is:

[0136] ·Official -100

[0137] ·Classified-200

[0138] ·Secret-300

[0139] Top Secret-400

[0140] To achieve this, the boundary control devices 3 and 3' must be instructed to compare the coded value pairs in the derived header using specific logical operations. In this case, A t Category >= L t :Classification.

[0141] Different logical operators can be used in the boundary control device to similarly handle other unique features of the protection tagging scheme to compare the mapping values ​​in the various tokens that make up the derived header.

[0142] The destination identifier allows routing and auditing systems to determine the expected gateway group 4 and thus the destination directly from the exported header.

[0143] Release token R, including authorization token and session ID array t Created by CRA 10 and provided to signing entity 8, it is used in the generation of every payload header until its validity period expires, or it is replaced by an updated release token in a subsequent request from signing entity 8 to CRA 10. Only the entropy element ensures a unique response to each authorization token request.

[0144] Release token R t Authorized sender 7 sends the payload. It is not a payload-specific authorization and can use the release token R during its validity period. t To sign any number of payloads.

[0145] CRA 10 creates an authorization response by first providing an intermediate value in the form of a session ID, which is formed by combining the authorization token and the selected gateway's persistent ID K using a one-way mathematical function. G And what is obtained is,

[0146] S i =f(K G A t ),in,

[0147] ·S i It is the session ID of a specific boundary control device;

[0148] ·K G It is a permanent ID for a specific gateway; and

[0149] ·A t It is an authorization token (in byte format).

[0150] In this embodiment, the process is repeated for each gateway 3, 3' in gateway group 4 to provide array {S i}

[0151] In this implementation, to allow the use of standard functions in standard HSM devices, an HMAC is used to compute a one-way mathematical function, which provides the session ID for a given gateway 3'.

[0152] S i =HMAC(K G A t ),in,

[0153] ·S i It is the session ID of a specific boundary control device;

[0154] ·K G It is a permanent ID for a specific gateway; and

[0155] ·A t It is an authorization token (in byte format).

[0156] For each gateway 3 and 3' in gateway group 4, repeat S i Create a process to provide array {S} i The associated secret key used in the HMAC function is formed from the permanent ID of the boundary control device 3, 3'. To avoid confusion, individual session IDs are created in CRA10, thus creating a session ID array, and the one-way mathematical function f is compatible with the predetermined boundary control device selected for payload transmission.

[0157] In this implementation, there is no signer access to K. G The stage of generating S. Conversely, generating S. i The steps effectively create an array of temporary identities derived from a shared permanent ID K. G This is derived and used by the signing entity 8 when forwarding files across network boundary 2, thus alleviating the need to send a permanent ID value. The permanent ID remains unknown to both the signing entity 8 and the sending entity 7. In fact, besides BCD 3 and 3', CRA10 is accessible to K. G The only other entity.

[0158] Based on the valid request from the signing entity 8 using the derived gateway G 3, 3', CRA 10 will calculate the HMAC and release the token R. T =(A t ,{S i}) is returned to the signing entity. It was used to create {S iThe HMAC calculation will be recreated at gateway 3' and 3' to ensure the associated A t It must be true, as will be discussed later.

[0159] When you have R t At that time, the signing entity 8 generates the file token as follows: F t =g(#(X),L t ,S i ), where #(X) is a hash digest of the payload X. As an alternative, the payload X can be used instead of #(X).

[0160] Authorization Token A t It does not need to be used directly in F t In the generation of - here it is used indirectly because it is S i The components of the calculation.

[0161] Function g is compatible with the predetermined boundary control devices 3 and 3', but function g does not need to be of the same function type as f mentioned earlier. In this example, g is a hash function, such that

[0162] F t =#(#(X),L t ,S i ).

[0163] If the boundary control device is required to use other parameters such as the payload name in the authorization decision, these parameters can be added to the hash calculation, provided that the boundary control devices 3 and 3' also have access to these parameters.

[0164] For example, to create a file token array {F} of payload named J t}, then when the sending entity signs the payload X using hash #(X) according to the request, it will calculate for each gateway 3, 3' in gateway group 4:

[0165] F t =#(#(X),L t ,J,S i )

[0166] in,

[0167] ○X is the byte stream of the payload;

[0168] ○S i The following are the session IDs (in byte format) of each gateway;

[0169] ○L t It is a local token;

[0170] ○J is the payload name; and

[0171] ○# indicates a suitable hash function that can also be used in boundary control devices.

[0172] J+ is the filename and is used as a parameter in the application to ensure that the filename remains unchanged through export control processing. For ease of use with calculations that form part of the export process, the filename can be expanded to a fixed predetermined size limit using standard padding characters, and the padded filename is represented as J.

[0173] To avoid confusion, a hash function for the digest of X and a hash function for F are provided. t The hash functions can be different.

[0174] Besides BCD 3 and 3', only CRA 10 knows K. G Therefore, only it can generate the session ID array {S} i Only the authorized signatory knows {S}. i}, and only when {S} is created i Only authorized signer 8 can generate {F} acceptable for all BCD 3' and 3' in a given gateway group 4 (e.g., the exported gateway group). t This provides the ability to add or remove BCDs from gateway group 4 after the array has been created, while ensuring that the file guarantee scheme will still operate on the original BCDs. However, note that due to the earlier generated {S i Due to incompatibility with}, it will not be able to use the subsequently added BCD.

[0175] The exported header is created at the signer's location and is constructed as follows:

[0176] Authorized header

[0177] Local masthead

[0178] • Payload hash

[0179] File token array

[0180] Therefore, file token F is not used. t Instead, it provides an array {F} containing multiple file tokens. t}

[0181] Calculate F t This method is highly efficient, therefore it is used to create file tokens {F}. t The overhead of covering each additional gateway 3, 3' is very low.

[0182] There is no specific upper limit to the number of file tokens in the exported header, as this will depend on the implementation and the choice will depend on the maximum payload size (including the header). This is achieved by using temporary identities {S} i If this is the case, there is no additional requirement for an HSM per payload, and the number of file tokens in the exported header does not need to be constrained by the HSM implementation.

[0183] The value in the file token table is F. t =#(#(X),L,J,S i ), where the separated S i Used for every potential gateway that can be used to reach the destination.

[0184] The payload hash #(X) is created by compiler 9 and provided to signer entity 8 as part of compiler evidence.

[0185] To avoid confusion and as Figure 5 As shown, the format of the exported header information created by the signing entity 8 is:

[0186] E = (A t ||L t ||#(X)||{F t}).

[0187] The components within the derived header are the information format of the token or array, or a hash digest. The information-formatted header is then forwarded to the sender entity 7, where it is converted to binary format and placed before the payload, thus giving a new signed payload P = E||X.

[0188] Then, the signed payload is forwarded to the system's boundary control devices 3, 3'.

[0189] At boundary control devices 3 and 3', a comparison is made between the effective load characteristics and the preset boundary control device parameter criteria. Additionally, a comparison is formed for A. t A portion of the payload characteristics are subject to compliance checks according to the CRA10 specification parameters.

[0190] The border control unit stores its key and is configured to verify the signed payload by checking that it has been directed as intended, and to check that the payload is compatible with both the local token and the authorization token. To ensure that the CRA specifies parameters are indeed authorization parameters, they are only accessible if the border control unit has performed multiple authorization criterion checks.

[0191] The calculations in the gateway are:

[0192] ●From the inside KG 'Generate S' i =HMAC(K) G ',A t )

[0193] • From the masthead and the S above i 'Generate F t =#(#(X) h ,L t ,J,S i ')

[0194] • Check F t = {F from the header} t The exact F in} t

[0195] Calculate #(X)g from X and check that #(X)g = #(X). h

[0196] • Compare the effective payload and A t and L t The header (which provides L) t Perform comparative checks, as described in our co-pending XXX.

[0197] Finally, by using A received from the sending entity t The value (i.e., header 1) and the local permanent identity information ID of the border control device 3, 3' (as previously mentioned, which is configured to be the same as the permanent identity information ID used by the CRA) are used to regenerate the session ID (or temporary identity) S at the border control device. i To provide the most important guidelines to be implemented.

[0198] Assuming the regenerated gateway session ID S i 'Can be used with parameters within the export header to generate a file token array {F t In the file token, one of the file tokens is the same as the gateway file token F. t If ' is true, then it is determined that the header parameters are validly authorized, and a payload compliance check is performed at boundary control devices 3 and 3'.

[0199] The boundary control device has a comparator configured to perform a simple comparison test of the payload content against CRA-specified parameter criteria, local criteria of the local token, and internal criteria specified at the boundary control device (which are pre-configured factory settings).

[0200] Importantly, CRA10 provides “critical” payload criteria, and these criteria must be met to effectively authorize payloads to be transmitted across network domain boundaries.

[0201] Only after all these tests have been performed can comparator 14 determine the payload delivery result to be applied. For example, if all test criteria have been met, the payload is released by boundary control devices 3, 3', i.e., transmitted across network boundary 2 from trusted network 12 to less trusted network 13. If any of the test criteria is marked as failed, payload X will not be allowed to be transmitted through boundary control devices 3, 3' between trusted network 12 and less trusted network 13. Therefore, in this case, there is no transmission of payload X across network domain boundaries.

[0202] Release token R provided at the boundary control device t If the release token generated by the sender entity 7 is different from the one generated by the sender entity 7, the boundary control device is not allowed to access the specified parameters and is not authorized to transmit payload X between the trusted network and the less trusted network via the boundary control devices 3 and 3'.

[0203] This condition criterion check effectively enables the boundary control device to autonomously guarantee the inherent characteristics specified by CRA10.

[0204] In this implementation, the sending entity 7 and / or the compiler reiterate additional local payload characteristic criteria inserted via a local token, which can be of the same type (e.g., time constraint) as the type specified by the CRA or a different type. This allows the sending entity to impose additional constraints on payload release decisions occurring at the boundary control device.

[0205] File token array {F t Therefore, it becomes {#(X,L t ,S i )}, where each entry corresponds to a S in the session ID array. i Then, export the header from (A) t ,L t ,#(X),{F t To provide. Again, the exported header is placed before the payload X before being forwarded from the sender entity 7 to the border control device. Therefore, an exported header is created for use with the payload X to be exported, wherein at least a portion of the exported header includes a file token F created for each BCD3, 3', or border control group 4. tThis enables a simple comparison test of the exported header, comparing it against the file, the gateway's environmental information (e.g., time), and internal information (which is the gateway's pre-configured factory settings or identity). To avoid confusion, comparator 14 can only determine the file delivery result to be applied if all these tests have been performed. For example, if all test criteria have been met, boundary control device 3 releases the file, i.e., the transfer across the network boundary from the trusted network to the less trusted network. If any of the test criteria is marked as failed, payload X will not be allowed to be delivered across the gateway between the trusted and less trusted networks. Therefore, in this case, there is no payload across the network domain boundary and its delivery.

[0206] This implementation effectively enables the boundary control device to autonomously guarantee its inherent characteristics, and this autonomous guarantee can also be applied to the local token L. t characteristic.

[0207] The authorization parameters can be guaranteed by providing authorization token A. t and local token L t As a series of paired constraints and claims to further reinforce each other, these constraints and claims are compared against each other using comparator functions located at boundary control devices 3, 3'.

[0208] Specifically, the boundary control device comparator 14 uses a local token L that specifies local criteria. t With the authorization token A as a parameter for central service authorization t Comparison of the corresponding values ​​between them.

[0209] It is important to reiterate that CRA 7 has knowledge of the unique permanent ID associated with the predetermined gateway from which payload X is to be derived, and that the signing entity 8 has a temporary ID and is unaware of the permanent ID of the boundary control devices 3 and 3'. The permanent ID is actually a secret key value that depends on the identity of the given gateways 3 and 3'.

[0210] Boundary control devices 3 and 3' are configured to check whether the payload sent to them has been ultimately authorized by CRA10. If the payload is authorized and compatible with predetermined criteria (stored in the payload header placed before the payload to be released), the payload is sent. If the check determines that the payload is unauthorized or incompatible with the exported header, the boundary control device discards the file.

[0211] Random number generator 15 is used by the CRA to provide authorization token A tThe entropy element. Permanent ID information is stored in secure storage area 16 within the CRA. Alternatively, a pseudo-random number generator can be used. Similarly, when generating elements for local tokens, the compiler uses a random number generator (not shown). Alternatively, a pseudo-random number generator can be used.

[0212] In practice, a method is provided for using the previously described system to ensure payload transmission across network boundary 2 via boundary control devices 3, 3'. To avoid confusion, only when the file token F... t The payload is released only when it is valid and all tests pass.

[0213] Placing #(X) in the header allows F to be calculated before all payloads arrive. t ', and therefore calculate the validity of the header. L t S in actual The parameter prevents the use of longer or shorter X values. Finally, this ensures that when the payload is split into chunks, the number of bytes in each chunk is easily auditable.

[0214] Creating an exported header that does not include #(X) is an alternative representation. As part of the normal comparator function of BCD 3,3', BCD 3,3' calculates #(X), but it cannot calculate F without #(X). t ', until all signed payloads arrive. In this mode, BCD 3, 3' will take longer to complete the comparator operation, thus reducing BCD throughput.

[0215] According to the design,

[0216] i. The sending entity 7 communicates with BCD 3, 3', but cannot sign the payload or verify the payload.

[0217] ii. Signing entity 8 can create exported headers but cannot create verification evidence for the payload, and is isolated from BCD3 and 3', therefore it cannot directly forward signed payloads to BCD; and

[0218] iii. The 9th entity provides independent verification of the payload, but is isolated from BCD 3, 3' and CRA 10, and is not configured to sign the payload.

[0219] Therefore, a three-step test is provided, which offers three independent failure points to provide an improved level of payload guarantee, while enabling scalability as will be discussed now.

[0220] In this usage, such as Figure 6As shown, the method includes the following steps: #(X) is generated by the compiler 9 instead of the signer 8. In a first embodiment of the invention, the following method steps are provided:

[0221] 1. External requesting entity 17 requests the compiler, which is configured to verify the transmission of the payload to a specific destination D, to send the payload X to D.

[0222] 2. The compiler 9 verifies the payload against the specific rules of the requester 17 and the destination D - for example, the requester 17 may only be allowed to send a specific file type, or a payload that matches a specific information filter (such as an XML schema).

[0223] 3. If the compiler rules are met, compiler 9 will generate a token L that appears locally. t The evidence object contains certain details of the payload (used by signer 8 to generate the derived header information)—these details typically include the payload hash #(X), actual size, and request UUID. To maintain the integrity of the evidence, the evidence object can then be digitally signed. Compiler 9 creates and ensures L... t The integrity of a subset of information prevents the sender from altering it.

[0224] 4. Next, the compiler 9 transmits the payload X and the evidence object to the sender 7. Alternatively, the compiler may transmit the evidence object directly to the signer, or transmit the object to a shared storage area with the signer 8, pending a request from the sender 7 to export the signature.

[0225] 5. Sender entity 7 receives payload X and evidence, and creates local token L. t Any final information required and any additional evidence and L t The information is passed to signer 8, who is authorized to sign the payload sent to the destination in order to create exported header information;

[0226] 6. If a valid release token is not available, the signing entity 8 requests an authorization token from CRA10 to transmit the payload across the required boundary control devices 3, 3'.

[0227] 7. CRA10 issues a release token R to the signing entity 8. t , including A t Authorization Token A t It is unique and used to create temporary identities S i This temporary identity was used to create the release token R. t The release token is forwarded to the signing entity 8 in response to the payload transmission authorization request.

[0228] 8. The signing entity 8 creates the exported header information and returns it to the sending entity 7.

[0229] 9. The sending entity 7 creates a binary exported header, places the binary exported header before the payload X, and sends the signed payload to each or any of the permitted BCDs 3, 3'.

[0230] At the boundary control devices 3 and 3', the contents of the header are then compared with the known local values ​​hard-programmed in the boundary control devices 3 and 3' and with the authorization parameters specified by CRA 10 along with the parameters in the local token.

[0231] Boundary control devices 3 and 3' store a permanent ID and are configured to access this permanent ID internally / locally to enable the computation of various functions. As previously mentioned, a secret copy of each boundary control device is stored using CRA 10. In one implementation, the permanent ID is determined during gateway manufacturing and never changes. The permanent ID of each gateway in the gateway group is used to generate session ID S. i Each session ID in the session ID must be included in the request token T. t The payload is then published to an authorized sender entity. This allows the sender entity to send the signed exported payload out via either of the border control devices 3 and 3'. The purpose is to enable sender entity 7 to generate a binary exported header based on the file token and authorization token, which is to be sent to border control devices 3 and 3' along with the payload X.

[0232] CRA 10 generates a 32-byte random value to be embedded in the authorization token, providing a unique authorization token for each request. For a token request to be considered a valid step, the sending entity 7 must request a time constraint T permitted by CRA 10. S1 and T S2 The maximum payload size S and file type F are values, or CRA 10 can impose predetermined values ​​on any or all of these fields. This can be achieved in two ways: the signer can request the values ​​and CRA 10 agrees, or the signer entity requests "use gateway" and CRA 10 delegates specific values.

[0233] In addition to the T provided by CRA 10 in the authorization token S1 and T S2 In addition, the sending entity provides T in the local token. M Yes. Session ID S i Validity window (based on T) S Time can be measured in days, and in TS Any payload arriving at boundary control devices 3 and 3' between time limits will be considered to have a valid A with respect to time. t However, for some applications, the message may have a much smaller size than the authorization token A. t The effective lifetime of the token. To allow messages to be rejected by the boundary control device when they are no longer valid (as opposed to being disallowed), the T token is... M Time is used to limit the "useful action window" of a message, and thus acts as a second time filter. Therefore, T M1 The signed payload can be considered "valid" from a certain point in time of the new epoch; therefore, if the new epoch time is earlier than that point, the derivation is not acceptable. Similarly, T M2 A signed payload can be considered "valid" up to a certain point in time, and therefore, if the new epoch time is after that point, the derivation is not acceptable. M1 =T M2 = 4 bytes.

[0234] Once the token information and session ID array {S i The request has been forwarded to signatory entity 8, and the local parameter T is being re-evaluated while considering CRA time constraints. M1 T M2 Then, the signing entity 8 continues to create the entity used to create A. t L t #X and F t Export header file token F t If possible Figure 5 As can be seen, empty padding is provided in the header (this is a manual operation to make the hash function more efficient). The derived header is placed before the payload X and then forwarded by the sending entity to the predetermined boundary control device.

[0235] In such Figure 7 In the second embodiment of the present invention shown, the method includes the following steps:

[0236] 1. External requester 17 sends a payload to compiler entity 9, the payload being greater than the maximum size capacity of boundary control devices 3, 3'.

[0237] 2. If the compiler 9 assesses the payload as suitable for the intended destination, the payload can continue to be processed in chunks.

[0238] 3. The payload is divided into blocks, each smaller than the maximum size obtainable from BCD 3, 3', thus allowing header export. Blocking can involve writing physical portions of the original payload to the storage medium, or it can involve algorithmic blocking, where all processing agrees on the blocking algorithm and can generate identical blocks from the original payload. The latter option achieves efficiency by eliminating storage medium write cycles.

[0239] a. The algorithm used for chunking will depend on the file type and must be compatible between the sender 7 and the compiler 9.

[0240] b. There must be a common naming convention for blocks.

[0241] 4. After the compiler 9 creates the segmented composite evidence for the signatory 8, the segmented composite evidence provides the signatory 8 with the information required for each block of the payload. For each block, there will be...

[0242] a. Partial numbering (from 1 to N, where N is the number of blocks).

[0243] b. The attributes of this section include: size; hash; and payload suffix (if applicable).

[0244] 5. In cases where efficiency is required, only the evidence and a reference to the original payload need to be sent to the sender 7.

[0245] 6. The sender 7 sends composite evidence to the signer 8 as part of a request to sign the payload.

[0246] 7. The signer 8 responds with an array of information export headers, each of which corresponds to a block in the block.

[0247] 8. Sender 7 runs the block partitioning algorithm independently, and for each block:

[0248] a. Generate the exported header of this block from the exported header array;

[0249] b. Generate block names based on a predetermined scheme using a partial number in the local token - for example, if the payload name is J, then block N will have payload name J||N, where N is a partial number that may be left-padded, for example, payload "File" will have block names "File001", "File002", etc.

[0250] c. Place the block's export header before the payload that was divided into blocks; and

[0251] d. Name the signed payload that will be divided into blocks with block names.

[0252] Sender 7 can use standard mechanisms to distribute the signed payload to gateway group 4. The result of this second implementation is that payloads of any arbitrary size can be sent on a single BCD 3, 3' through chunking. However, the size limit of BCD 3, 3' is only implemented at the block level (therefore, the inherent size control in the authorization token itself is useless in limiting the file size that will be the total size of all blocks).

[0253] The use of partial numbering ensures the local token L for each block. t The uniqueness of the UUID, combined with its uniqueness, ensures that the local token for each part of every export is unique. Furthermore, the use of a common UUID simplifies activities such as auditing and accounting by allowing individual parts to be immediately linked to their parent's complete payload. Separate and unique UUIDs can be used alternatively for individual blocks.

[0254] By combining the first and second implementation methods, any arbitrary payload can be properly authorized to be sent via any BCD in the flexible set of BCDs 3, 3' without the sending entity 7 knowing which BCDs 3, 3' are available, or the derived initiator needing not to first chunk the payload before sending it to the compiler 9.

[0255] Various modifications to the above principles will be enlightening to those skilled in the art. For example, an additional electronic entity, provided in the form of a requesting entity 17, could exist, which is an entity outside the export authorization control that wishes to send a payload. In this embodiment, the sender represents the requesting entity 17. This setup can be implemented for payload import.

[0256] The onboarding of a new BCD can be easily accomplished by updating the gateway group definition and issuing a new release token to the signer, or by waiting for a request from the signer for a new release token that includes the new BCD and deploying the new BCD only while updating all valid tokens.

[0257] The removal of BCDs from the service is handled transparently by removing them from the load balancer pool and ceasing the issuance of new release tokens with temporary IDs based on their permanent identity. Currently valid release tokens can be used without issuing new ones until they expire.

[0258] Alternatively, the exported header can be forwarded from the signer in binary format.

[0259] Additional authorization parameters can be added to the authorization token to claim when chunking is allowed, and potentially to claim the maximum number of authorized chunks and their maximum authorized size. This can be used as a general A to enforce the maximum payload size when such constraints are required.t Parameter substitution. Although added to A t It is not necessary, but it is useful because chunking is a powerful operation (in terms of risk, due to the amount of information that can be derived in a single transaction), so it is advantageous to be able to specify whether chunking is allowed, when chunking is allowed, and to what extent chunking is allowed.

[0260] By modifying the authorization scheme to be specific to expert use cases, such as TCP / IP packets (e.g., permitted source and destination IP address ranges, source and destination port ranges, packet characteristics), BCD can become a flexible Layer 4 packet authorizer similar to a firewall, but without requiring internal configuration when different packet characteristics need authorization, and furthermore, automatically applying such authorization characteristics across the entire BCD group. Other similar uses with strongly characteristic information formats are obvious to subject matter experts.

[0261] Alternatively, instead of using the HMAC function, this one-way mathematical function includes a hash, where the associated secret key is a permanent ID K of the boundary control device known to CRA 10. G Formed, that is, S i =#(K G A t The cryptographic hash function supported by any of these functions is not important, and any cryptographic hash function can be used. Furthermore, considerations of algorithm longevity and cryptographic strength encourage implementers to choose a suitable cryptographic hash algorithm.

[0262] In an alternative embodiment of the invention, the header may not provide a local token, and a local token L specifying local criteria may not be provided. t With the authorization token A as a parameter for central service authorization t Comparison of corresponding values ​​between them. Note that L is not used. t When generating headers, the random instantaneous values ​​and / or other entropy elements created by the compiler cannot be used to provide unique headers for each payload. Therefore, the unique payload header characteristics of duplicate payloads and potentially fragmented payloads are no longer guaranteed to be true, thus reducing the desirability of using this alternative implementation. That is to say, the lack of uniqueness is not necessary for the guarantee to work; that is, it cannot be derived if the signature is not valid, and it is outside the niche risk. However, once something has been derived once, it is not so bad to derive it again in terms of confidentiality.

[0263] In another embodiment of the invention, CRA 10 provides an authorization token A including additional information. t This additional information is not used for payload release guarantees or authorization, but rather to ensure efficient management of the program. For example, At It can include a reference to Quality of Service (QoS), which allows the selection of the most urgent exports to take precedence over less urgent exports.

[0264] Similarly, for similar purposes, management information can be added to L t Such as when the payload is divided into blocks with reference to the original accepted payload or the payload is otherwise changed.

[0265] Various alternative implementations are available, in which the roles of signer 8, sender 7, and compiler 9 do not need to be separated, but can be combined into various unified roles. For example, the roles of i. sender and compiler, ii. sender and signer, and iii. all three roles can be folded / combined.

[0266] Since a signed payload is essentially just another payload type, an already signed payload can be signed to create a multi-signed payload. This is useful when transmitting via a serially connected BCD gateway group 4. In this alternative implementation, different signers can be used for each signing layer.

[0267] Another alternative is to require multiple authorizations before granting release. This can be achieved, for example, by adding a parameter (called the weight W) to the authorization token A. t To achieve this, the sum of all weights of all authorized tokens must exceed a threshold. BCD is then configured to implement the chosen weighting scheme.

[0268] Alternatively, for the purpose of exporting, importing (i.e., payload transfer from a less trusted network to a more trusted network) can be considered as an export from the less trusted network. From the perspective of the more trusted network, the CRA used for importing resides in the less trusted network, and it is guaranteed that all imports originating from the less trusted network have been authorized for transmission to the more trusted network.

[0269] All BCD devices 3 and 3' in gateway group 4 do not need to reside at a single site. To achieve three-way resilience, BCD devices 3 and 3' in a single gateway group 4 can be scaled across three physical locations, and the load balancer located between the sender and the BCD can select a local gateway for optimal performance, or select a remote gateway if a local failure means those local gateways are unavailable. Similarly, the signer 8, compiler 9, CRA, and sender 7 can reside at more than one site to achieve full export guarantee scheme resilience.

[0270] The implementation methods mentioned above enable the establishment of assurance programs at the enterprise scale and enable the fulfillment of the following requirements:

[0271] 1. To achieve effective auditing, because:

[0272] a. All exported payloads are valid and identifiable;

[0273] b. All steps in the process use a common identifier;

[0274] c. The identifier for the exported payload is unique; and

[0275] d. The identifiers of the exported payloads that are divided into blocks are simple and explicitly associated with the original payload request;

[0276] 2. Achieve flexibility, performance, and scalability because:

[0277] a. All parts of the exported authorization control architecture must be able to be built in a resilient manner, where resilience includes both on-premises resilience and site resilience;

[0278] b. Export license control used with the chunking option allows increased bandwidth by enabling multiple BCDs to be used to transmit a single payload; and

[0279] c. When there are few dependencies on high-security but performance-limited components, the exported authorization control architecture can be highly scalable in terms of bytes and payload per unit time period.

[0280] 3. To achieve security, because:

[0281] a. The architecture can be deployed in a component configuration where, after the damage to a single component, the abuse of that component configuration (i.e., enabling the sending of normally prohibited payloads) becomes apparent.

[0282] 4. Simple management, because:

[0283] a. Export authorization control enables the embedding of management information in the export header, allowing the scheme and all electronic entities to operate efficiently.

Claims

1. A method for ensuring the payload X to be transmitted across a network boundary via any of a plurality of predetermined boundary control devices, the method comprising the steps of: When a request is received at the first electronic entity: Provide an electronic authorization token for defining the characteristics of the payload X to be transmitted; A boundary control group is defined at the network boundary, the boundary control group comprising multiple boundary control devices, each of which has a dedicated permanent identity associated with it. A temporary ID array is determined based on the permanent identity information of each boundary control device in the boundary control group and the electronic authorization token. as well as An electronic release token is generated based on the temporary ID array and the electronic authorization token to be forwarded to the second electronic entity. This electronic release token is valid when used in conjunction with the border control device provided in the defined border control group. The electronic release token is used to create a header that is appended to the payload X so that the boundary control device in the defined boundary control group can determine whether the signed payload has been authorized by the first electronic entity and whether the payload X is compatible with the header.

2. The method according to claim 1, further comprising the following steps: At least one entropy element is generated to form part of the electronic authorization token to ensure that multiple electronic authorization tokens authorizing the same payload characteristics are unique.

3. The method according to claim 1, wherein, During the validity period of the electronic release token, the electronic release token is applied to one or more payload transmission authorization requests.

4. The method according to claim 3, wherein, The effective period of the electronic release token depends on a predetermined period defined by the first electronic entity within the electronic authorization token.

5. The method according to claim 1, wherein, Upon receiving the electronic release token and in accordance with the payload transmission request, the second electronic entity creates file tokens for each boundary control device in the boundary control group based on the temporary ID array, a local token including parameters remotely defined from the first electronic entity, and a hash digest of the payload X to be transmitted, to provide a file token array {F}. t } 6. The method according to claim 5, wherein, The hash digest is provided as follows: before the payload X is received by the second electronic entity as part of the payload transmission request, the payload X is transmitted through a one-way function.

7. The method according to claim 5, wherein, The local token includes an entropy element.

8. The method according to claim 5, wherein, At least one of the parameters of the local token is provided by a third electronic entity to verify the expected payload parameters for payload transmission across the network boundary.

9. The method according to claim 8, wherein, A fourth electronic entity, which acts as the payload sender entity and the sole electronic entity communicating with the boundary control device in the boundary control group, limits at least one parameter of the local token.

10. The method according to claim 8, wherein, The third electronic entity verifies the payload against predetermined rules provided upon receiving the payload transmission request and / or the expected payload transmission destination, and provides evidence of the verification to be included in the local token.

11. The method according to claim 5, wherein, The second electronic entity is configured to subsequently generate a payload header based on the electronic authorization token, the local token, the file token array, and the hash digest of the payload.

12. The method according to claim 11, wherein, The payload header is placed before the payload X before the fourth electronic entity forwards the payload X to one or more boundary control devices in the boundary control group.

13. The method according to claim 12, wherein, When at least a portion of the payload with payload header E arrives at a border control device, the border control device regenerates a session ID (SID) using the border control device's permanent identity information and the electronic authorization token from the payload header. i ) g .

14. The method according to claim 13, wherein, At one of the plurality of boundary control devices, the session ID, along with parameters within the payload header, is used to calculate the file token F. t '.

15. The method according to claim 14, wherein, F t ’=#(#(X), L, J, HMAC(K G ’, A)), # represents the hash operation, #(X) is the hash digest of the payload X, and K G ' is the permanent identity information of the boundary control device, L is the local token, J is the name of the payload, and A is the electronic authorization token, where #(X), L, J, and A come from the payload header, and the session ID is HMAC(K). G ', A).

16. The method according to claim 15, wherein, The boundary control device uses the file token F t 'Compare with the file token array located in the payload header E to determine whether the file token matches the file token array {F t If the values ​​in} are the same, and a match exists, then a first positive event result identifier is generated.

17. The method according to claim 16, wherein, The boundary control device causes the payload to be transferred through a one-way function to provide #(X) from X. g And for #(X) g The result is compared with the #(X) of the payload header E, and if a match is found, a second positive event result identifier is subsequently generated.

18. The method of claim 17, wherein the boundary control device further compares other control criteria included in the export or import header to ensure that the other control criteria are within predetermined limits, and provides a third positive result identifier if the other control criteria are within the predetermined limits.

19. The method according to claim 18, wherein, The boundary control device identifies a first positive result identifier, a second positive result identifier, and a third positive result identifier, and then determines a positive boundary control result.

20. The method according to claim 19, wherein, When the positive boundary control result has been satisfied, the boundary control device transmits the payload X with header E through the boundary control device and across the network boundary.

21. The method according to claim 19, wherein, The boundary control device is configured to prohibit the transfer of payloads across network boundaries if a positive boundary control result has not yet been satisfied, and / or enable the payloads to be discarded.

22. The method according to claim 1, wherein, One or more boundary control devices in the boundary control group prevent invalid exported headers and incompatible payloads with valid headers based on the electronic authorization token and the temporary ID array.

23. The method according to claim 5, wherein, The payload is divided into blocks smaller than the maximum size obtainable from the boundary control device in the boundary control group.

24. The method according to claim 23, further comprising the following step: At the second electronic entity, a payload header array is created based on the hash table of the electronic authorization token, the file token, the local token, and the payload, with each payload block in the block corresponding to a payload header.

25. The method of claim 24, further comprising the step of: At the second electronic entity, the payload header of the block is placed before the corresponding payload divided into blocks, and the resulting signed payload block is forwarded to one or more boundary control devices in the boundary control group.

26. A payload assurance system for a payload X to be transmitted across a network boundary via at least one predetermined boundary control device, the payload assurance system comprising a first electronic entity having at least one computer processor and at least one data storage device, the at least one data storage device including instructions executable by the at least one computer processor to: Generate an electronic authorization token to define the characteristics of the payload X to be transmitted; A boundary control group is defined at the network boundary, the boundary control group comprising multiple boundary control devices, each of which has a dedicated permanent identity associated with it. A temporary ID array is determined based on the permanent identity information of each border control device in the border control group and the electronic authorization token; and An electronic release token is generated based on the temporary ID array and the electronic authorization token to be forwarded to a second electronic entity in the payload assurance system. This electronic release token is valid when used in conjunction with the boundary control device provided in the defined boundary control group. in, The electronic release token is used to create a header that is appended to the payload X so that the boundary control device in the defined boundary control group can determine whether the signed payload has been authorized by the first electronic entity and whether the payload X is compatible with the header.

27. The system according to claim 26, wherein, The electronic authorization token also includes at least one entropy element to ensure that multiple electronic authorization tokens authorizing the same payload characteristics are unique.

28. The system of claim 26, wherein the payload assurance system comprises a plurality of separate and distinct electronic entities, the plurality of separate and distinct electronic entities comprising at least one authorizing entity, at least one sending entity, at least one signing entity and at least one payload verification entity, wherein the at least one authorizing entity is the first electronic entity and the at least one signing entity is the second electronic entity.

29. The system according to claim 28, wherein, The at least one signing entity is configured to use the electronic release token to sign any number of payloads during the validity period of the electronic release token.

30. The system according to claim 29, wherein, Upon receiving the electronic release token and upon receiving the payload export request, the signing entity is configured to calculate a file token for each border control device in the border control group based on the temporary ID array, the local token, and the hash digest of the payload to be transmitted, to provide a file token array {F}. t } 31. The system according to claim 30, wherein, The hash digest is provided as follows: the payload X is passed through a one-way function before being forwarded to the signing entity.

32. The system according to claim 30, wherein, The local token defines parameters associated with the payload and payload delivery destination and / or parameters defined by the sending entity.

33. The system according to claim 30, wherein, The local token includes an entropy element.

34. The system according to claim 30, wherein, The parameters of the local token are provided by the payload verification entity and / or the sender entity.

35. The system according to claim 32, wherein, The payload verification entity is configured to verify the payload against predetermined rules of the requester and / or the payload delivery destination, and is configured to provide evidence objects for the verification to be included in the local token.

36. The system according to claim 30, wherein, The signing entity is configured to subsequently generate a payload header based on the hash digest of the electronic authorization token, the local token, the file token array, and the payload.

37. The system according to claim 36, wherein, The payload header is placed before the payload before it is forwarded to one or more boundary control devices in the boundary control group.

38. The system according to claim 28, wherein, The payload is divided into blocks smaller than the maximum size obtainable from the boundary control device in the boundary control group.

39. The system according to claim 38, wherein, The at least one signing entity is configured to create a payload header array based on a hash table of the electronic authorization token, file token, local token, and the payload, wherein each of the payload blocks corresponds to a payload header.

40. The system according to claim 39, wherein, The at least one signing entity is configured to place the payload header of the block before the corresponding segmented payload and forward the resulting signed payload block to one or more boundary control devices in the boundary control group.

41. The system according to claim 37, wherein, When the payload is received at a border control device, the border control device is configured to regenerate a session ID (SID) using the border control device's permanent identity information and the electronic authorization token from the payload header. i ) g .

42. The system according to claim 41, wherein, At the boundary control device, the session ID, along with parameters from the payload header, is used to calculate the file token F. t '.

43. The system according to claim 42, wherein, F t ’=#(#(X), L, J, HMAC(K G ’, A)), # represents the hash operation, #(X) is the hash digest of the payload X, and K G ' is the permanent identity information of the boundary control device, L is the local token, J is the name of the payload, and A is the electronic authorization token, where #(X), L, J, and A come from the payload header, and the session ID is HMAC(K). G ', A).

44. The system according to claim 42, wherein, The boundary control device has a comparator that compares the file token F. t 'Compare with the file token array located in the payload header E to determine whether the file token matches the file token array {F t If the values ​​in} are the same, and a match exists, the comparator is configured to generate a first positive event result identifier.

45. The system according to claim 44, wherein, The boundary control device is configured to transfer the payload through a one-way function to provide #(X) from X. g And the comparator then applies #(X). g The comparison is made with the #(X) in the payload header, and if a match is found, the comparator is configured to generate a second positive event result identifier.

46. ​​The system of claim 44, wherein the boundary control device further compares other control criteria included in the export or import header to ensure that the other control criteria are within a predetermined limit, and if the other control criteria are within the predetermined limit, the comparator is configured to provide a third positive result identifier.

47. The system of claim 44, wherein the boundary control device is configured to identify a first positive result identifier, a second positive result identifier, and / or a third positive result identifier, and subsequently determine a positive boundary control result based on the first positive result identifier, the second positive result identifier, and the third positive result identifier.

48. The system according to claim 47, wherein, The boundary control device is configured to transmit the payload X across the network boundary after the positive boundary control result has been satisfied.

49. The system according to claim 47, wherein, The boundary control device is configured to prohibit the transmission of the payload across the network boundary if the positive boundary control result has not been satisfied, and / or enable the payload to be discarded.

50. The system according to claim 28, wherein, The at least one sending entity is the only electronic entity communicating with the boundary control device.

51. The system of claim 30, wherein the payload guarantee system includes a random number generator or a pseudo-random number generator, the random number generator or pseudo-random number generator being used to provide the entropy element of the electronic authorization token and / or the local token.

52. An export control system, the export control system comprising the system according to any one of claims 27 to 51.

53. A computing device comprising the system according to any one of claims 27 to 51 to ensure the transmission of payload from a less trusted network to a trusted network or from a trusted network to a less trusted network.

54. A network comprising the system according to any one of claims 27 to 51 to ensure the transmission of payloads from a less trusted network to a trusted network or from a trusted network to a less trusted network.

Images