Payload assurance across multiple network boundaries

Abstract

A payload assurance method and apparatus for a payload to be transferred across a network boundary via any of a group of predetermined boundary control devices, each having its own permanent identity information, wherein a first electronic entity provides an electronic authorization token defining characteristics of the payload, and a temporary ID array is determined depending on the permanent identity information and authorization token of each boundary control device in the boundary control group, and an electronic release token to be transferred to a second electronic entity is generated according to the temporary ID array authorization token, the electronic release token being valid for use with the boundary control devices provided in the defined boundary control group.

Description

[Technical Field]

[0001] The present invention is in the field of data assurance at network boundaries or gateways, and more particularly, to ensuring the suitability and authorization of transfers of payloads between networks of differing degrees of trust. [Background technology]

[0002] One of the biggest risks in a trusted network is a breach of confidentiality due to data leaking to a less trusted network. Exit paths from a trusted network are often formed by high assurance boundary controls such as data diodes.

[0003] Any process used by boundary control must be high-assurance due to its status as the "gatekeeper" of a trusted network, i.e., provide control where there is a high degree of certainty that the correct decision will be made under all possible circumstances. The requirement for high assurance limits what is possible in hardware boundary control. For example, very complex data (or information) formats require complex algorithms and processes to ensure them, making it difficult to provide a high degree of assurance for the correct implementation of complex algorithms. Also, some information formats are poorly specified and change over time, making it impractical to keep any algorithm up to date with high assurance. This can be demonstrated even when considering very simple management criteria for payload content where the criteria response changes over time, such as determining whether a particular byte sequence represents a valid Unicode character, where the answer changes depending on when the query is made.

[0004] To facilitate the secure electronic transfer of data over a network, a public key infrastructure (PKI) is typically used. PKI is used when more stringent authentication methods are required to verify the identity of parties and validate data transferred across network / domain boundaries. However, the multiple elements required for managing digital certificates and public key cryptography require periodic configuration and updating to maintain a desired level of system security.

[0005] Our co-pending UK Patent Application No. 2010968.2 describes a payload assurance system and method in which an independent electronic entity is used to assure the payload (using an entropy element in the authorization token to provide temporary authorization at a network border device based on a permanent shared secret), and the transfer of the payload across the network boundary is permitted if predetermined test criteria specified in various tokens, including the export header, are met at a predetermined network border device. This application is hereinafter referred to as Version 1.

[0006] The export headers created were only valid for a single gateway, which provided security and assurance benefits but at the expense of data scalability and throughput. Therefore, there was a need to achieve resilience without sacrificing security, allowing the same payload to be sent multiple times through different gateways (and allowing the ability to handle multiple identical payloads arriving at the destination).

[0007] Previous schemes required the entire payload to be held within the gateway for guarantees, which physically limited the size of all existing gateways and therefore the size of the payload they could accept. For an effective, simple, and secure service, it would be desirable for any service consumer to be unconstrained by such internal limitations and be able to send any file of any size through a BCD-based service.

[0008] The absence of release / import metadata in the export header of the Version 1 payload assurance scheme meant that while the requirement to move a payload across a security boundary was successfully accomplished, neither the appropriateness nor the intended method of release / import for that particular destination was indicated in the header. Summary of the Invention [Problem to be solved by the invention]

[0009] Therefore, a need has been identified for a cross-domain payload assurance method and system that provides payload assurance related to the conformance of egress data at a cross-domain boundary, has improved security, is properly authorized for cross-domain transfers, provides ephemeral authorization, is agile with respect to time changes, can utilize multiple boundary controllers across a single boundary, is not constrained by inherent payload size limitations in the boundary controllers, and provides centralized administrative control. [Means for solving the problem]

[0010] Accordingly, there is provided a payload assurance method for a payload X to be transferred across a network boundary via any of a plurality of predetermined boundary controllers, the method comprising: At the first electronic entity, upon request, providing an electronic authorization token defining characteristics of a payload X to be transferred; defining a boundary control group located at a network boundary, the boundary control group including at least two boundary control devices each having dedicated persistent identity information associated therewith; Determining a temporary ID array according to the permanent identity information and authorization token of each border control device in the border control group; generating an electronic release token to be transferred to a second electronic entity according to the temporary ID array and the authorization token, the electronic release token being valid for use with the boundary control device within the defined boundary control group.

[0011] The first electronic entity is a Central Release Authority (CRA) located on the trusted side of the network boundary. Within the CRA, each permanent identity value K G are given unique arbitrary labels. A gateway group is an administrative collection of these labels, and each Border Control Device (BCD) in the collection requires the same authorization in relation to the same destination. When a second entity (the signer entity) requests authorization for a destination, it receives a single preferred authorization token A t The CRA then generates a single authorization token A for the destination after decomposing the destination into a list of associated gateway labels. t Using the gateway label, stored in BCD format, G A calculation is performed against the value to create a session ID for each BCD, and finally these session IDs are compiled into a session ID array. Thus, this method uses the gateway key and authorization token A t From the session ID array i}, and the gateway keys can be generated from all gateways in the gateway group.

[0012] The method may further include generating at least one entropy element forming part of the electronic authorization token to ensure that multiple electronic authorization tokens authorizing the same payload characteristic are unique.

[0013] A release token can be applied to one or more payload transfer authorization requests during the validity period of the release token. By assigning specific parameters to given signers, it is possible to restrict what these signers can sign.

[0014] The validity period of the release token may depend on a predetermined period set in the authorization token by the first electronic entity.Specific parameters of a given signer - restricting what a signer can sign.

[0015] When the second electronic entity receives the release token and is requested to transfer the payload, the second electronic entity creates a file token of each border control device in the gateway group depending on the temporary array, a local token including parameters remotely determined from the first entity, and a hash digest of the payload X to be transferred, and creates an array of file tokens {F t Using a hash digest allows the signer to sign the file without needing to see the entire payload, making signing more efficient.

[0016] The hash digest can be provided by passing payload X through a one-way function before it is received by the second entity as part of a payload transfer request. The hash digest in the header is accessed by one or more boundary controllers in the boundary controller group upon receipt to determine the validity of the header before payload X arrives at one or more predetermined boundary controllers. This allows for more efficient criteria checking in BCD, as it does not have to wait for the complete payload to arrive.

[0017] The local token may include an entropy component.

[0018] At least one of the local token parameters is provided by a third electronic entity that validates desired payload parameters for payload transfer across a network boundary, the third electronic entity being an orchestrator entity that validates the payload against criteria.

[0019] The fourth electronic entity may act as a payload sender entity and as the only electronic entity in contact with the boundary control devices of the boundary control group and may define at least one of the local token parameters. The fourth electronic entity may transmit payload X to the third electronic entity along with a predetermined selection of local parameters L' that define a portion of the local token input parameters.

[0020] In a payload assurance method for payload X as recited in claim 8 or 9, a third electronic entity validates the payload against predetermined rules and / or the intended payload destination provided upon receiving the payload transfer request and provides a validation evidence object for inclusion in the local token. The evidence can be an array of assertions that some payload X1 with digest #(X1) can be sent. The orchestrator returns a signed object (e.g., a JWT) to the sender asserting that the payload, including digest = #(X) and local header L', was authorized. The sender sends the evidence (but not the payload) to the signer, who can be confident that an authorized entity created the signature (because they can check the signature on the JWT) and that the evidence was sent by an entity authorized for export.

[0021] The payload name is J||n (e.g., file 001), and the payload is a fixed padding pattern for all exports.

[0022] The second entity can then be configured to generate a payload header dependent on the authorization token, the local token, the file token array, and the hash digest of the payload. For payload export, if the second electronic entity (signer entity) has or has obtained a valid release token and evidence is provided by a third electronic entity (orchestrator entity), the signer entity creates a payload export header and forwards it to the sender. The signer entity creates the header according to the payload's release token that it needs to authorize for transfer across the network boundary. An array of export headers (each with an associated hash table) is provided to satisfy each BCD in the boundary control group.

[0023] The payload header can be prepended to payload X before it is forwarded by a fourth entity to one or more border control devices in the border control group. The fourth entity is a sender entity that is communicatively coupled to the signer to make payload forwarding requests and to receive payload headers, such as export headers. Note that elements of the payload header can be created by the first electronic entity, the second electronic entity, the third electronic entity, and the fourth electronic entity. This provides points of failure where all four electronic entities must provide the appropriate header for the payload to be forwarded.

[0024] When at least a portion of the payload having the payload header E reaches the border controller, the border controller generates a session ID (S i ) g can be regenerated.

[0025] The boundary control unit uses the session ID and parameters in the header to generate a file token F tThe file token generated in the boundary control unit is F t '=#(#(X),L,J,HMAC(K G ',A)), and all quantities are represented by a value K, which is the permanent identity information of the boundary controller. G The session ID is obtained from the header, excluding '. G ',A).

[0026] The boundary controller uses the file token F t ' to the file token array {F t}, the file token is compared with the file token array {F t}, and if there is a match, then a first positive event result identifier can be generated.

[0027] The boundary controller passes the payload through a one-way function to convert X to #(X) g Provide #(X) g may be compared with #(X) in header E, and if a match exists, a second positive event result identifier may then be generated.

[0028] The boundary control device may further compare other control criteria contained in the export or import header to ensure that these are within predetermined limits and, if so, provide a third positive result identifier.

[0029] The boundary control device can identify the first positive outcome identifier, the second positive outcome identifier, and the third positive outcome identifier, and thereafter determine a positive boundary control outcome.

[0030] If a positive boundary control result is met, the boundary controller forwards payload X with header E through the boundary controller across the network / domain boundary.

[0031] If a positive boundary control result is not met, the boundary controller can be configured to prohibit the file from passing across the network / domain boundary and / or allow the file to be discarded.

[0032] One or more border control devices in the border control group can block invalid export headers and payloads that do not correspond to valid headers according to the authorization token and the temporary ID array.

[0033] The payload can be split into chunks smaller than the maximum size available from the boundary controllers in the boundary control group, with the advantage that the size limitations of the boundary controllers in the boundary control group are eliminated, the sender does not need to know which boundary controllers are available, and any payload size can be transferred through a resilient set of boundary controllers.

[0034] The method may further include creating an array of payload headers, one for each of the payload chunks, based on the authorization token, the file token, the local token, and the hash table of the payload.

[0035] Thereafter, the method may further include prepending the chunk's payload header to the corresponding chunked payload and forwarding the resulting signed payload chunk to one or more boundary control devices in the boundary control group.

[0036] In another embodiment of the present invention, there is provided a payload assurance system for a payload X to be transferred across a network boundary via at least one predetermined boundary control device, the 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 being configured by the at least one computer processor to: generating an electronic authorization token defining the characteristics of the payload X to be transferred; defining a boundary control group located at a network boundary, the boundary control group including at least two boundary control devices each having dedicated persistent identity information associated therewith; Determine a temporary ID array according to the permanent identity information and authorization token of each boundary control device in the boundary control group; and instructions operable to generate an electronic release token to be transferred to a second electronic entity in the system, the electronic release token being valid for use with a boundary control device in a defined boundary control group, according to the temporary ID array and the authorization token.

[0037] The first electronic entity is a central release authority (CRA) located on the trusted side of the network boundary, and provides each permanent identity information value K of the boundary control device (BCD). G are given unique arbitrary labels. A boundary control group is an administrative collection of these labels, and each BCD in the collection is associated with the same destination and requires the same authorization. When a second entity (the signer entity) requests authorization to forward a payload to a destination, it receives a single preferred authorization token A t The CRA then decomposes the destination into a list of associated boundary controller labels, and then generates a single A for the destination. t Using the boundary control label together with G A calculation can be performed against the values ​​to create a session ID for each BCD, and finally these session IDs are compiled into a session ID array.

[0038] The electronic authorization token may further include at least one entropy element that ensures that multiple electronic authorization tokens authorizing the same payload characteristic are unique.

[0039] The multiple separate and distinct electronic entities consist of at least one authorizer entity, at least one sender entity, at least one signer entity, and at least one payload validation entity, i.e., an orchestrator. The signer, sender, and orchestrator roles do not need to be separate, but can instead be combined into various integrated roles. For example, i. the sender role and the orchestrator role, ii. the sender role and the signer role, or iii. a decomposition / combination of all three is possible.

[0040] The system may further include a signer entity configured to sign any number of payloads using the release token during the validity period of the release token.

[0041] When the signer entity receives the release token and the payload export request, it calculates a file token for each border controller in the gateway group depending on the temporary array, the local token, and the hash digest of the payload to be transferred, and stores the file token array {F t}. Using #X allows the signer to sign the payload transfer without actually receiving the payload, and therefore no checking of the payload is done by the signer.

[0042] The hash digest may be provided by passing the payload X through a one-way function before forwarding it to the signer entity. For the avoidance of doubt, the use of a hash digest in the header allows the boundary controller to determine the validity of the header before payload X arrives at one or more predetermined boundary controllers.

[0043] The local token defines parameters related to the payload, payload destination, and / or defined by the sender entity. Advantageously, the local token does not include information about the number, parts, size, or classification of gateways. Therefore, the system is configured to perform checks on the authorization token contents and other release criteria provided by the local token, etc.

[0044] The local token may further include an entropy component.

[0045] The local token parameter may be provided by the payload validation entity and / or the sender entity.

[0046] The payload validation entity is configured to validate the payload against predefined rules for the requestor and / or payload destination, and is configured to provide a validation evidence object for inclusion in the local token.

[0047] The evidence object is a digest #(X n ) with partial payload X n The signature can be an array of assertions that the sender can send the payload containing the digest=#(X) and local header L'. The orchestrator returns a signed object (e.g., a JWT) to the sender asserting that the payload, including digest=#(X) and local header L', was approved. The sender sends the evidence (not the payload) to the signer when making the file transfer request. The signer entity can be confident that an authorized entity created the signature and that the evidence is being sent by an entity authorized for export.

[0048] The signer entity is configured to generate a payload header that depends on a hash digest of the authorization token, the local token, the file token array, and the payload.

[0049] The signer creates a header along with the release token of the payload that needs to be authorized for transfer across the network boundary. In effect, the signer generates an array of export or import headers (each with an associated hash table). The headers are then forwarded to the sender entity or other entity that made the payload transfer request.

[0050] A header may be prepended to the payload before it is forwarded to one or more BCDs in the gateway group.

[0051] The payload can be split into chunks smaller than the maximum size available from the border controllers in the gateway group.

[0052] Thus, size limitations on border controllers are eliminated and any file can be transferred through a resilient set of gateways without the sender needing to know which gateways are available.

[0053] The system may further comprise a signer entity configured to create an array of payload headers, one for each of the payload chunks, based on the authorization token, the file token, the local token and a hash table of the payload.

[0054] The system may further include prepending the chunk's payload header to the corresponding chunked payload and forwarding the resulting signed payload chunk to one or more boundary control devices in the boundary control group.

[0055] Upon receipt of the payload at the border controller, the border controller generates a gateway session ID (S i ) g can be configured to regenerate

[0056] The boundary control unit uses the session ID and parameters in the header to generate a file token F t ' can be calculated.

[0057] The file token created in the boundary controller is F t '=#(#(X),L,J,HMAC(K G ',A t )) and the value is K G The session ID is obtained from the header, excluding '. G ',A t )

[0058] The boundary controller uses a file token (F t ) g is compared with the file token array located in the header E, and the file token is t}, the comparator being configured to generate a first positive event result identifier if a match exists.

[0059] The boundary controller passes the payload through a one-way function to convert X to #(X) g and the comparator is configured to provide #(X) g with the #(X) in the header and generate a second positive event result identifier if a match exists.

[0060] The boundary control device further compares other control criteria contained in the export or import header to ensure that these are within predetermined limits, and if so, the comparator is configured to provide a third positive result identifier.

[0061] The boundary control device may be configured to identify a first positive result identifier, a second positive result identifier, and / or a third positive result identifier, and then determine a positive boundary control result according to the first positive result identifier, the second positive result identifier, and the third positive result identifier.

[0062] If a positive boundary control result is met, the boundary controller may be configured to forward payload X across the network / domain boundary through the boundary controller.

[0063] If a positive boundary control result is not met, the boundary controller may be configured to prohibit passage of the file across the network / domain boundary and / or allow the payload to be discarded.

[0064] The at least one sender entity may be the only electronic entity in communication with the at least one boundary control device.

[0065] The system may include a random or pseudo-random number generator that provides the entropy component of the electronic authorization token and / or the local token.

[0066] Alternatively, an export control system may be provided that includes a payload assurance system as described above.

[0067] In another embodiment of the present invention, a computing device may be provided that includes a payload assurance system for assuring a payload for transfer from an untrusted network to a trusted network (or vice versa) as previously described herein.

[0068] In yet another embodiment of the present invention, there is provided a network including a payload assurance system as hereinbefore described that assures payload for transfer from an untrusted network to a trusted network (or vice versa).

[0069] In all cases, the border control device may be a gateway device, and the two terms may be used interchangeably.

[0070] Once authorized payload characteristics are specified through the issuance of an authorization token, there is no option to change the authorized payload characteristics. That is, the boundary controller only needs to know the interrelationships between entities in the scheme rather than the details of the validation scheme; for example, the gateway only considers checkable assertions between headers, inherent characteristics of the payload (e.g., size, conformance to file types known to the boundary controller), and environmental factors (e.g., time restrictions). Or, in other words, the BCD has no a priori knowledge of the specific values ​​of authorized payload characteristics for a given payload; it can determine the payload's permitted characteristics from the export header.

[0071] This allows sealed-for-life gateways to make release decisions autonomously. Autonomous in this example means that the decision is made without reference to another electronic entity. This maintains isolation (or separation) between the determination of authorization parameters (at the CRA) and the decision to verify that the payload conforms to the parameters at the gateway, eliminating the need to request an authorization decision from another electronic entity and improving security at the gateway by eliminating the ability of this decision information to be misused by a third party. Thus, border devices can include the simplest devices that never need to be replaced or updated and never change. Meanwhile, the method of generating the export header ensures that no intermediate system between the CRA and the BCD can change the determined authorization parameters.

[0072] Only authorized payloads / exports can be allowed to be transferred across domain boundaries. A good export scheme typically considers content control, time-limited authorization, and ultimately blocking the passage of unauthorized formats. Beneficially, the system can be configured to control authorization with electronic tokens.

[0073] Computing devices may include desktop or laptop computers, tablets, personal digital assistants (PDAs), mobile phones, smart watches, hard disks, solid state disks or drives, memory, or other smart or mobile devices capable of storing and / or displaying data or otherwise functioning as data devices; display devices including monitors, projectors, screens, or the like capable of storing and / or displaying data or otherwise functioning as data devices are also disclosed, which may include such devices individually or collectively for the convenience of a user.

[0074] An "export payload" is formed by a header and a payload. However, the payload assurance system and method can also be used on packets of data where a new packet, still containing the packet header and packet data, is created with an export header and the original packet contents, or can be used with streaming data where an export header is prepended to the streaming data. Stuffing this new packet with the original payload is a tactic commonly used in tunneling protocols and is believed to be well known to those skilled in the art.

[0075] Although the invention has been described above, the invention also extends to any inventive combination of the features set out above or set out in the following description, drawings or claims. For example, any feature described in relation to any one aspect of the invention is understood to be disclosed in relation to any other aspect of the invention as well.

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

[0077] [Figure 1] 1 is a schematic diagram of a system for payload assurance at a network domain boundary according to a first embodiment of the present invention; [Figure 2]FIG. 2 illustrates an authorization token format according to the present invention. [Figure 3] FIG. 2 illustrates a release token format in accordance with the present invention. [Figure 4] FIG. 2 illustrates a local token format in accordance with the present invention. [Figure 5] FIG. 10 illustrates a payload release header format in accordance with the present invention. [Figure 6] 1 is a flow diagram of a method for ensuring payload at a network boundary according to a first aspect of the present invention; [Figure 7] FIG. 4 is a flow diagram of a method for ensuring payload at the network boundary, where the payload is chunked, according to a second aspect of the present invention; DETAILED DESCRIPTION OF THE INVENTION

[0078] In the figures, like elements are indicated by like reference numerals. Those skilled in the art will appreciate how complex the implementation of the method may be, and therefore the number of optional features present will be determined by the needs of the user.

[0079] Figure 1 shows a payload authorization control system 1 having a payload X and a header E to be transferred across a network boundary 2 via a boundary control device 3 (e.g., a hardware-implemented network gateway), which is one device in a boundary control group 4, and including a computer processor 5 and a data store 6. For the payload assurance scheme to operate, there are multiple roles or electronic entities that must perform specific assigned functions. Figure 1 shows five electronic entities in the system. These electronic entities include: Sender 7: This entity communicates electronically with the boundary controller 3, the signer 8 and the orchestrator 9. The sender entity 7 sends payloads based on the provision of a positive assurance result from the orchestrator 9 and the provision of a positive result from the signer 8. Central Release Authority 10 (CRA): This entity manages access to the export gateway's permanent ID blocks and the mapping of border controllers to destinations. It is also responsible for generating the authorization tokens in Figure 2 when queried by signers 8. This entity communicates electronically only with signers 8. The signer 8 requests authorization appropriate to its role to allow the creation of export or import headers for a given approved payload. The signer 8 requests an authorization token from the CRA 10 and requests approval of the request to export / import the payload based on evidence from the orchestrator 9. In all cases, signing a payload means creating a header to be used with the payload to be transferred across the boundary controller 3, 3'. The Orchestrator 9 evaluates the payload against the Enterprise release criteria (which, for the avoidance of doubt, are different from the BCD release criteria) and, if met, provides evidence that the payload has been approved for export, as well as any additional information the Signer 8 entity needs to generate the export / import headers. The evidence is typically an information structure (such as JSON or XML), although the exact format is not important to the operation of the scheme. The evidence may be digitally signed (using conventional means) to provide integrity protection. The evidence may be passed directly or indirectly to the Signer 9. A Border Control Device (BCD) 3, 3', such as an export gateway, possesses a unique identity block 11, 11'. The BCD 3, 3' is configured to block payloads with invalid export headers, and to block payloads that do not correspond to the export header, even if the export payload is valid. Gateway / Border Control Group 4 - a set of one or more border control devices 3, 3' that allow exports to the same destination with the same authorization, intended to be treated as a single composite entity within the scheme.

[0080] A standard network load balancer (not shown) is responsible for directing the signed payload from the sender 7 to one or more BCDs 3, 3' based on a standard operator selected load balancing algorithm.

[0081] In a first embodiment of the present invention, an authorization control and assurance system (hereinafter referred to as the assurance system) is configured to provide authorized payload export over a single or multiple BCDs 3, 3′. The authorization system (including the checks to be made in the BCDs) allows for control of some specific characteristics of the payload (e.g., payload type), comparison of asserted characteristics (e.g., classification), additional management capabilities, and also allows for authorization expiration to be managed via electronic tokens. The scheme creates and uses a payload-specific header containing four independent subtokens prepended to a particular payload. A payload can successfully pass through the BCD 3, 3′ as requested by the sender entity 7 only if the information in the header is guaranteed to be valid.

[0082] Headers and their constituent parts have two representations: an informational representation (as contained in a human-readable JSON or XML file), and a binary representation that is a byte-level representation of how they are encoded in the header for use by functions supporting the scheme. For simplicity, we will refer to either representation as a "token" (e.g., "authorization token"), clarifying the form of the token (informational or binary) when important. Headers can be export or import headers depending on the desired direction of transfer across BCD3,3'.

[0083] The data store contains an authorization token A, which will be described in more detail below. t The authorization token A includes instructions operable by a processor to provide the authorization token A. tprovides a means for authorized entities to sign a request that can be applied consistently across a variety of payload transfer authorization requests.

[0084] The border controllers 3, 3' are network gateways located at network domain boundaries 2, i.e., at positions that allow transit between a first network 12 and a second network 13 (or vice versa depending on whether payload export or import is required). In the export case, the network on which the CRA resides is the trusted network 12, and the other network is the less trusted network 13.

[0085] As an example, payload export requests in this embodiment are made to orchestrator 9 by a suitably authorized party. Orchestrator 9 not only accepts such requests, but may use external or local services to determine the suitability of the payload for the requested export. These checks are similar to standard controls used by enterprises, such as data loss prevention (DLP), malware scanning, hidden metadata removal, and others apparent to those skilled in the art. Orchestrator 9 orchestrates these services to obtain a status that approves or denies the export at orchestrator 9.

[0086] Once the export is approved, the orchestrator 9 must build evidence, a set of information about the export that allows the signer to create an array of file tokens and therefore an export header for payload X.

[0087] In this manner, the use of the signer 8, sender 7 and orchestrator 9 in this embodiment to create parts of the payload headers, such as export headers, ensures that the system is not misused or used unexpectedly if a flaw or misuse is associated with one of the entities.

[0088] The signer entity 8 is configured to create the payload header by combining various tokens (described in more detail below) into a binary export header, but it is the sender entity 7 that i. prepends the export header to the relevant payload and ii. transmits the signed payload to the boundary controller 3, 3'.

[0089] CRA10 generates a release token R, a unique token generated upon query of the signatory entity. t The CRA 10 acts as an authorization entity that provides the gateway key and authorization token A, as well as storing the permanent identifier of the boundary control device. t From the session ID array i}, and gateway keys are generated from all gateways in the boundary control group. The session ID array contains a moderately sensitive temporary value (or temporary identity) that poses no long-term risk because it expires periodically. Authorization Token A t and the session ID array {S i} is transmitted in a pair in response to the query of the signer entity 8. This pair defines a release token as shown in FIG.

[0090] The signer entity 8 requests a release token from the CRA 10 and creates headers for payloads that require authorization for transfer across the network boundary 2 according to the release token.

[0091] The authorization tokens created by the CRA 10 are electronic tokens formed of at least a first part relating to authorized payload characteristics and a second part for providing entropy (or randomness) to the token, and thus A t=<entropy element> and <centrally specified parameter value>. The authorization token contains details about what the CRA 10 is allowed to traverse one or more BCDs 3, 3', as well as information about the authorization token itself, including its validity period. The entropy portion is provided to ensure that multiple authorization tokens authorizing the same payload characteristics are unique. This allows for centralized control (e.g., at the trusted network) of the characteristic specification and associated authorizations, and ensures that each authorization request and associated response is distinguishable and therefore auditable. In this embodiment, the payload is an export payload that is transferred between the trusted network 12 and the less trusted network 13 across any one or more border controllers 3, 3' in a given border control group 4.

[0092] This permanent identity information, such as an identity block or other key type associated with the boundary controller 3, 3', is highly sensitive information and must be stored very securely. In the following, this permanent identity information will be referred to as the permanent ID of a given boundary controller 3, and K G It is expressed as:

[0093] Permanent ID K for the boundary control devices 3, 3' in the system G must be known in the CRA 10. The boundary control device 3, 3' uses the K created at the time of manufacture that is securely presented to the i.CRA 10. G ii. K created by CRA10 loaded into the boundary control device G or iii. K created by an independent source loaded into the boundary control device. G This same K G is loaded into CRA10.

[0094] Within CRA10, each K GThe values ​​are given unique arbitrary labels. The boundary control group 4 is a managed collection of these labels, and each BCD 3, 3' in the collection is associated with the same destination and requires the same authorization. When a signer entity 8 requests authorization for a destination, it receives a single preferred authorization token A. t Then, CRA10 resolves the destination into a list of associated gateway labels, and then generates a single A for the destination. t Using the gateway label with BCD3, K stored every 3' G A calculation is performed against the value to create a session ID for each BCD3,3' and finally these session IDs are compiled into a session ID array.

[0095] The authorization token can be mapped to a series of numbers and used in a one-way function as described below. The details of the mapping are not important as long as all parts of the assurance system use the same mapping. The authorization token is a component of the export header that should be provided to the signer entity 8. For the avoidance of doubt, the authorization token contains a central authorization control that is an assertion of what is allowed to be exported across the boundary control device 3, for example the authorization header could contain: version (i.e., version 2), Entropy (ensuring the uniqueness of each authorization header), size - the maximum size (in bytes) of the payload (zero means no limit), File type - BMP, or other specified preferred file type or packet type such as csv if required, Time - "Invalid before" or "Invalid after" to control token expiration, Payload assertions (described below), and · Destination identifier (described below).

[0096] The system is configured to check not only for the CRA specified criteria, but also for other release criteria: Another release check is performed in the local header.

[0097] In contrast to version 1, the local header is not created solely by the sender entity 7, but rather the number of hashes in the hash table, the part number and the actual payload size are set by the orchestrator 9, while all other fields are set by the sender 7. This provides a level of validation by the orchestrator 9. To uniquely identify a BCD, the part number can be used together with the UUID.

[0098] The local header (or local token) shown in FIG. 4 contains: Export UUID - Generated by the Orchestrator entity 9 and uniquely identifies each individual export. Should be randomly generated as a Type 4 UUID and also replaces the version 1 nonce. · Time Limit - The time limit allowed for exporting the file, generated by the sender (can be shorter than the authorization token's lifetime). Payload Assertion - See below. Actual Size - The actual size in bytes of the export payload (excluding headers) as generated by the orchestrator 9. Part Number - Generated by the orchestrator 9, typically 0 (zero) if the payload is not chunked. Number of File Tokens (or Hashes) - The number of File Tokens generated by Signer 8 for the payload provided by Signer 8, i.e., the number of export hashes in the hash table.

[0099] Considering payload assertions first, to enable authorization of document classification, the classification is converted into a numerical representation that can be checked by the boundary controller. Multiple schemes are available to users, and none of these schemes have an ambiguous lifespan.

[0100] One such scheme could create a new authorization token parameter called "classification" that can be used to describe the maximum classification of documents that can leave the boundary control device. A typical scheme is classification(OFFICIAL, CONFIDENTIAL, SECRET, TOP SECRET). Similarly, for local tokens, a parameter called classification is defined with the same allowed values ​​that are the classification values ​​asserted by the sender 7.

[0101] These allowable values ​​are mapped to numeric values ​​on a per-header basis. One such scheme is as follows: OFFICIAL-100 CONFIDENTIAL-200 SECRET-300 TOP SECRET-400

[0102] To implement this, the boundary controller 3, 3' must be instructed to compare the pair of coded values ​​in the export header with a specific logical operation. t :Classification≧L t :Classification.

[0103] Within the border controller, other characteristic features of protective marking schemes can be handled similarly, using different logical operators to compare the mapped values ​​in the various tokens that make up the export header.

[0104] The destination identifier allows the routing and auditing system to determine directly from the export header, the desired gateway group 4 and therefore the destination.

[0105] A release token R containing an authorization token and a session ID array t is created by the CRA 10, given to the signer entity 8, and used in the generation of all payload headers until it expires or is replaced by a renewed release token on a subsequent request from the signer 8 to the CRA 10. Only the entropy factor guarantees a unique response to each authorization token request.

[0106] Release Token R t authorizes the sender 7 to send a payload. This authorization is not payload-specific, but is valid for a period of time during which a release token R t Any number of payloads can be signed using

[0107] CRA10 is a one-way mathematical function, i.e., S i =f(K G ,A t ) to obtain the authorization token and the selected gateway permanent ID K G and creating an authorization response by first providing an intermediate value in the form of a session ID obtained by combining ·S i is the session ID of a particular border controller, ·K G is the permanent ID of a particular gateway, A t is the authorization token (in byte format).

[0108] In this embodiment, this process is repeated for each gateway 3, 3' in the gateway group 4, and the array {S i}.

[0109] In this embodiment, to enable the use of standard functions in standard HSM appliances, S is generated using an HMAC that provides a session ID for a given gateway 3, 3′. i =HMAC(K G ,A t ), where: ·S i is the session ID of a particular border controller, ·K G is the permanent ID of a particular gateway, A t is the authorization token (in byte format).

[0110] This S i The creation process is repeated for each gateway 3, 3' in gateway group 4 to create an array {S i}. The associated secret key used in the HMAC function is formed with the permanent ID of this boundary controller 3, 3'. For the avoidance of doubt, each session ID, and hence session ID array, is created in the CRA 10 and the one-way mathematical function f corresponds to a given boundary controller selected for payload transfer.

[0111] In this embodiment, at any stage, the signer is K G Instead, it accesses S i The step of generating a shared permanent ID K G , effectively creating an array of temporary identities that are derived from the signature and used by the signer entity 8 when transferring files for transfer across the network boundary 2, thereby alleviating the need to transmit permanent ID values. The permanent IDs remain unknown values ​​to the signer entity 8 and the sender entity 7. In effect, except for BCD3,3', the CRA 10 G is the only other entity with access to

[0112] CRA 10 receives a valid request from signer entity 8 to use export gateway G3,3' and computes an HMAC to generate a release token R T =(A t ,{S i}) is returned to the signer entity. i The HMAC calculation used to create the} is t is recreated in the gateways 3, 3' to ensure that it must be authentic.

[0113] The signatory entity 8 is R t If you have F t =g(#(X),L t ,S i ), where #(X) is the hash digest of payload X. Alternatively, payload X can be used instead of #(X).

[0114] Authorization Token A t is F t It does not need to be used directly in the generation of S i It is used indirectly because it is a component of the calculation of

[0115] The function g corresponds to a predetermined boundary control device 3, 3', but does not have to be of the same functional type as the function f described above. In this example, g is F t =#(#(X),L t , S i ) is a hash function such that

[0116] If other parameters such as the payload name need to be used in the authorization decision by the boundary controller, and the boundary controller 3, 3' also has access to these parameters, these parameters can also be added to the hash calculation.

[0117] For example, a signer entity may create a file token array {F t}, calculate the following for each gateway 3, 3' in gateway group 4 when requested to sign payload X containing hash #(X): F t =#(X,L t ,J,S i ) where: X is the payload byte stream, ·S i is also the session ID (in byte format) of each gateway, L t is the local token, J is the payload name, ·# is a suitable hash function that can also be used by the boundary control device, J+ is the filename, used as a parameter within the application to ensure that the filename remains unchanged throughout the export control process. To facilitate the calculations that are part of the export process, the filename may be extended to a fixed, predetermined size limit using a standard padding character; the padded filename is denoted as J.

[0118] For the avoidance of doubt, we consider a hash function that provides a digest of X and a hash function F t can be different from the hash function that provides

[0119] BCD3, excluding 3', K G Therefore, only CRA10 knows the session ID array {S i} can be generated. i}, and therefore only the authorized signer 8 knows {S i All BCDs 3, 3' that existed within a given gateway group 4, such as a group of export gateways, at the time of creation of} are acceptable {F tThis provides the ability to add or remove BCDs from Gateway Group 4 after the array is created, while ensuring that the file assurance scheme still works for the original BCD. However, the later added BCD will not be able to access the previously generated {S i}, so you cannot use these BCDs.

[0120] The export header is created at the signer and is structured as follows: Authorization header Local headers Payload hash File Token Array

[0121] Therefore, the file token F t Rather than using an array {F t} is provided.

[0122] F t The computation method of is very efficient, and therefore the file token {F t The overhead of creating a} is very low.

[0123] The number of file tokens in the export header is implementation-dependent, and the choice depends on the maximum payload size (including headers), so there is no specific upper limit. i By using}, no additional demands are placed on the HSM for each payload, and therefore the number of file tokens in the export header does not need to be constrained by HSM implementation limits.

[0124] The value in the file token table is F t =#(#(X),L,J,S i ) and is independent of all potential gateways that can be used to reach the destination. i is used.

[0125] Payload hash #(X) is created by the orchestrator 9 and provided to the signer entity 8 as part of the orchestrator evidence.

[0126] For the avoidance of doubt, as shown in Figure 5, the export header information format created by the signer entity 8 is as follows: E=(A t ||L t ||#(X)||{F t})

[0127] Here, each component in the export header is the information format or hash digest of that token or array. The information formatted header is then forwarded to the sender entity 7, which converts it to binary format and prepends the binary header to the payload to provide a new signed payload as P=E||X.

[0128] The signed payload is then forwarded to the boundary controller 3, 3' of the system.

[0129] In the boundary control device 3, 3', a comparison is made between the payload characteristics and the preset parameter criteria of the boundary control device. t Compliance checks are performed against the payload properties CRA 10 prescribed parameter criteria, which form part of the CRA 10.

[0130] The boundary controller holds the key and is configured to check the signed payload by checking that it is intended to be used and that it corresponds to the local token and authorization token. CRA-defined parameters are only accessible if the boundary controller has undergone various authorization criteria checks to ensure that they are indeed authorized parameters.

[0131] The calculation at the gateway is as follows: ·Internal K G ' to S i '=HMAC(K G ',A t ) Header and above S i ' to F t '=#(#(X) h ,L t ,J,S i '). F from the header t '=Strictly {F t}. X to #(X) g Calculate #(X) g =#(X) h Check. As described in our co-pending patent application XXX, t and (L t (if provided) t Perform a comparison check against the header.

[0132] Finally, the most important criterion to be achieved is that the A received from the sender entity at the boundary control unit t (i.e., Header 1) and the local permanent identity information ID of the border controller 3, 3' (configured to be the same as that used by the CRA as described above) to generate a session ID (or temporary identity) S i is provided by regenerating

[0133] Regenerated Gateway Session ID S i ' with parameters in the export header to create a file token array {F t Gateway file token F is identical to one of the file tokens in t' can be generated, the header parameters are determined to be validly authorized and a payload compliance check is performed in the boundary controller 3, 3'.

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

[0135] Importantly, CRA10 provides "critical" payload criteria that must be met in order for a payload to be validly permitted to be transported across network domain boundaries.

[0136] Only after all these tests have been performed can the comparator 10 determine the payload delivery outcome to be applied. For example, if all test criteria are met, the payload will be released by the border controller 10, i.e., forwarded across the network boundary 2 from the trusted network 12 to the less trusted network 13. If any of the test criteria are flagged as failed, the payload X will not be able to pass through the border controllers 3, 3' between the trusted network 12 and the less trusted network 13. Therefore, in this case, the payload X will not be forwarded across the network domain boundary.

[0137] A release token R provided at the boundary control unit t is not identical to that generated by the sender entity 6, the border controller will not have access to the specified parameters and will not be authorized to transfer the payload X between the trusted and untrusted networks via the border controller 3, 3′.

[0138] This conditional criteria check effectively allows the inherent properties specified by CRA 10 to be autonomously guaranteed by the boundary controller.

[0139] To reiterate, in this embodiment, the sender entity 7 and / or orchestrator inserts additional local payload characteristic criteria that can be of the same type (e.g., time constraints) or different types as specified by the CRA via the local token, allowing the sender entity to impose additional constraints on the payload release decision made in the boundary controller.

[0140] Therefore, the file token array {F t} is {#(X,L t ,S i )} and each S in the session ID array i This results in an export header containing the entry (A t ,L t ,#(X),{F t ,}). The export header is again prepended to the payload X before it is forwarded from the sender entity 7 to the boundary control device. Thus, an export header is created to be used with the payload X to be exported, and at least a part of the export header is stored in the file token F created for each BCD 3, 3' or boundary control group 4. tThis allows for a simple comparison test of the export header against both file and environmental information (e.g., time) and gateway internal information (pre-configured factory settings or gateway identity). For the avoidance of doubt, only after all these tests have been performed can comparator 14 determine the file delivery outcome to apply. For example, if all test criteria are met, the file will be released by the boundary controller, i.e., transferred across network boundary 2 from the trusted network to the less trusted network. If any of the test criteria are flagged as failed, payload X will not be allowed to pass through the gateway between the trusted and less trusted networks. Therefore, in this case, the payload and its associated components will not be transferred across the network domain boundary.

[0141] This embodiment effectively allows the unique properties to be guaranteed autonomously by the boundary controller, and the local token L t The same autonomous guarantees can be applied to properties.

[0142] The authorization parameter guarantees are expressed as an authorization token A as a series of paired constraints and assertions that are compared with each other using a comparator function located in the boundary controller 3, 3'. t and local token L t This can be further enhanced by providing (respectively).

[0143] Specifically, the comparator 10 of the boundary control device receives a local token L that specifies a local reference. t and an authorization token A, which is a parameter authorized by the central service. t Comparison of the respective values ​​is performed between

[0144] It is important to reiterate that the CRA 7 knows the unique permanent ID associated with a given gateway exporting payload X, and the signer entity 8 has a temporary ID and does not know the permanent ID of the border controller 3, 3'. In effect, the permanent ID is a secret key value that depends on the identity of a given gateway 3, 3'.

[0145] The boundary controller 3, 3' is configured to check that the payload sent to it is ultimately authorized by the CRA 10. If the payload is authorized and meets predetermined criteria (stored in a payload header prepended to the payload to be released), the payload is sent. If the check determines that the payload is not authorized or does not meet the export header, the boundary controller discards the file.

[0146] CRA issues authorization token A t The Orchestrator uses a random number generator 15 to provide the entropy element of the Persistent ID information. The Persistent ID information is stored in a secure storage area 16 within the CRA. Alternatively, a pseudo-random number generator can be used. Similarly, the Orchestrator uses a random number generator (not shown) to generate the elements of the local token. Alternatively, a pseudo-random number generator can be used.

[0147] In use, the system described above is used to provide a method of securing a payload for transfer across a network boundary 2 via a boundary controller 3, 3'. For the avoidance of doubt, the file token F t The payload is released only if is valid and all tests pass.

[0148] By placing #(X) in the header, the F t ', so the validity of the header can be calculated. t Inside S actual Parameter (S actualparameter) prevents a longer or shorter X from being used. Ultimately, this ensures that when the payload is split into chunks, the number of chunked bytes can be easily audited.

[0149] Creating an export header without #(X) is another way of expressing it. BCD3,3' calculates #(X) as part of the normal comparator function, but if #(X) is not present, F t In this mode, BCD3,3' takes longer to complete the comparator operation, thus reducing the throughput of BCD.

[0150] By design, i. The sender entity 8 is in communication with BCD 3, 3' but is unable to sign the payload and therefore unable to verify the payload. ii. The signer entity 8 can create export headers but cannot create validation evidence for the payload, and is separated from BCD 3, 3' so cannot transfer the signed payload directly to BCD. iii. The Orchestrator 9 entity independently verifies the payload, but is separate from the BCD 3, 3' and CRA 10 and is therefore not configured to sign the payload. Thus, a three-step test is provided that provides three independent points of failure to improve the level of assurance of the payload, while allowing for scalability as described below.

[0151] In this use, the method involves generating #(X) by the orchestrator 9 rather than the signer 8, as shown in Figure 6. In a first embodiment of the invention, the following method steps are provided: 1. An external requester entity 17 makes a request to an orchestrator configured to validate the sending of payloads to a particular destination D to send payload X to D. 2. The orchestrator 9 validates the payload against the specific rules of the requestor 17 and the destination D, for example the requestor 17 may only send payloads that match a specific information filter such as a specific file type or XML schema. 3. If the orchestrator rules are satisfied, the orchestrator 9 generates a local token L (used by the signer 8 to generate the export header information). t The Orchestrator 9 generates an evidence object containing certain specifications of the payload that appears in the L (typically these include the payload hash #(X), actual size, and request UUID). To preserve the integrity of the evidence, the evidence object can be digitally signed. t Creating a subset of the information and ensuring its integrity prevents the sender from modifying it. 4. The orchestrator 9 then passes the payload X and the evidence object to the sender 7. Alternatively, the orchestrator passes the evidence object directly to the signer, or passes the object in a common storage area shared with the signer 8 and awaits an export signature request by the sender 7. 5. The sender entity 7 receives the payload X and the evidence and generates a local token L t and submits the evidence and any additional L to a signer8 authorized to create any final information required for signing the payload for transmission to this destination. t Pass information to create export header information. 6. If the signer entity 8 does not have a valid release token, it requests an authorization token from the CRA 10 for transfer of the payload across the necessary boundary controller 3, 3'. 7.CRA10 is A t Release token R containing t to the signer entity 8. Authorization token A t is a unique release token R that is transferred to the signer entity 8 in response to the payload transfer authorization request. t The temporary ID S used to createi Used to create 8. The signer entity 8 creates export header information and returns it to the sender entity 7. 9. The sender entity 7 creates a binary export header, prepends it to the payload X, and sends the signed payload to each or any of the allowed BCDs 3, 3'.

[0152] Next, in the boundary controller 3, 3', the contents in the header, together with those in the local token, are compared with known local values ​​hard-programmed in the boundary controller 3, 3' and authorized parameters specified by the CRA 10.

[0153] The border controllers 3, 3' are configured to store a permanent ID and access it internally / locally to enable the calculation of various functions. As mentioned above, the CRA 10 is entrusted with a secret copy of each border controller. In one embodiment, the permanent ID is determined at the time of manufacturing the gateway and never changes. The permanent ID of each gateway in the gateway group is stored in a request token R issued to authorized sender entities. t Each contains a session ID S i This allows the sender entity 7 to export the signed export payload via one of the boundary controllers 3, 3'. The goal is for the sender entity 7 to generate a binary export header that depends on the file token and authorization token, which is sent to the boundary controller 3, 3' together with the payload X.

[0154] The CRA 10 generates a 32-byte random value that is embedded in the authorization token to provide a unique authorization token for each request. For a token request to be a valid step, the sender entity 7 must be able to request the token within the time constraint T S1 and T S2, maximum payload size S, and file type F must be requested, or CRA 10 may impose predetermined values ​​for any or all of these fields. There are two ways to accomplish this: the signer may request values ​​and CRA 10 may agree, or the signer entity may request "use of gateway" and CRA 10 may mandate specific values.

[0155] T provided in the authorization token by CRA10 S1 and T S2 Similarly, a local token is created by the sending entity. M Pairs are provided. (T S time-based) session ID S i The expiration time of can be measured in days, T S Any payloads arriving at the boundary controllers 3, 3' during the time limit are valid in time. t However, in some applications, the message is considered to have an authorization token A t may have a useful lifespan that is much shorter than the token lifespan of T M Time is used to define a "useful running window" for a message, allowing the boundary controller to reject the message when it is no longer useful (as opposed to being disallowed), thus acting as a second time filter. M1 can be considered a signed payload "valid since" the epoch time, and MUST NOT be accepted for export if the epoch time is earlier than this time. M2 can be considered a signed payload "valid until" a time in epoch time, and MUST NOT be accepted for export if the epoch time is later than this time. M1 =T M2 = 4 bytes.

[0156] Token information and session ID array {S i} is forwarded to the signer entity 8, it is then assigned a local parameter T M1 , T M2 is re-evaluated. Next, the signer entity 8 t , L t , #X and F t A file token F is used to create an export header containing t The header is provided with null padding (an artifact that makes the hash function more efficient) as shown in Figure 5. The export header is prepended to the payload X and forwarded by the sender entity to a given boundary control device.

[0157] In a second embodiment of the present invention shown in FIG. 1. An external requester 17 sends a payload to the orchestrator entity 9 that is larger than the maximum size capacity of the border controller 3, 3'. 2. If the orchestrator 9 assesses the payload as suitable for the intended destination, the payload can proceed to the chucking process. 3. The payload is split into chunks, each smaller than the maximum size available from BCD3,3', taking into account the export header. Chunking can involve writing physical portions of the original payload to the storage medium, or it can involve algorithmic chunking, where all processes agree on a chunking algorithm to generate identical chunks from the original payload. The latter option allows for more efficient implementation, as it eliminates storage medium write cycles. a. The chunking algorithm depends on the file type and must be common between the sender 7 and the orchestrator 9. b. There must be common agreement on the naming conventions for chunks. 4. Once chunked, the Orchestrator 9 creates a composite evidence for the Signer 8 that provides the information the Signer 8 needs for each chunk of the payload. For each chunk there is: a. Part number (1 to N, where N is the number of chunks) b. Attributes of this part: including size, hash, and (if applicable) payload suffix 5. For efficiency, only evidence and a reference to the original payload need be sent to the sender 7. 6. The sender 7 sends the composite evidence to the signer 8 as part of the request to sign the payload. 7. Signer 8 responds with an array of information export headers, one for each chunk. 8. The sender 7 runs the chunk algorithm independently for each chunk. a. Generate an export header for the chunk from the array of information export headers. b. Generate chunk names based on the part number in the local token based on a predetermined scheme, e.g. if the payload name was J then chunk N would have a payload name of J||N where N is the part number possibly left justified, e.g. payload "file" would have chunk names such as "file001" and "file002". c. Add a chunk export header to the beginning of the chunked payload. d. Name the chunked signed payload as chunk name.

[0158] The sender 7 can then route the signed payload to the gateway group 4 using standard mechanisms. The result of this second embodiment is that chunking allows any size payload to be sent via a single BCD3,3', although the size restriction on BCD3,3' is only enforced at the chunk level (so the inherent size control in the authorization token is not by itself useful in limiting the size of the file, which is the aggregate size of all chunks).

[0159] By using the part number, the local token L for each chunk tis guaranteed to be unique, which, combined with the uniqueness of the UUID, ensures that local tokens for every part of every export are unique. Using a common UUID also simplifies activities such as auditing and accounting by allowing each part to be immediately linked to its parent intact payload.

[0160] You can also use a separate unique UUID for each chunk.

[0161] Combining the first and second embodiments can suitably allow any payload to be sent via either of the resilient set of BCDs 3, 3′ without the sender entity 7 needing to know which BCDs 3, 3′ are available or without the export initiator needing to chunk the payload before entering the orchestrator 9.

[0162] Various modifications of the above principle will occur to those skilled in the art. For example, there may be a further electronic entity provided in the form of a requester entity 17, an entity external to the export authorization control, that wishes to send a payload. In this embodiment, the sender takes the place of the requester entity 17. Such a configuration may be implemented for the import of payloads.

[0163] Onboarding a new BCD can also be easily accomplished by updating the gateway group definition and issuing new release tokens to the signers, or by waiting for a new release token request from the signers containing the new BCD and only deploying the new BCD once all valid tokens have been updated.

[0164] Removing a BCD from service is handled transparently by removing it from the load balancer pool and stopping the issuance of new release tokens with temporary IDs based on the permanent identity. Currently valid release tokens can be used without issue until they expire.

[0165] Alternatively, the signer can transmit the export headers in binary format.

[0166] Further authorization parameters may be added to the authorization token to assert when chunking is allowed and potentially the maximum number of chunks allowed and their maximum allowed size. This parameter overrides the usual A request to enforce a maximum payload size when such constraints are needed. t It can act as a substitute for parameters. Chunking is a powerful behavior (risk-wise due to the amount of information that can be exported in a single transaction), so A t Although not a required add-on to , it is useful and therefore advantageous to be able to specify whether, when and to what extent chunking is allowed.

[0167] By modifying the authorization scheme to be specific to specialized use cases such as TCP / IP (e.g., source and destination IP addresses and ranges, source and destination port ranges, packet characteristics), BCD can become a flexible Layer 4 packet authorizer akin to a firewall, but without the need for internal configuration when different packet characteristics require authorization, and further, such authorized characteristics are automatically applied across the entire BCD group. Other similar uses for strongly characterized information formats will be apparent to those skilled in the subject matter.

[0168] Alternatively, instead of using an HMAC function, this one-way mathematical function may include a hash, and the associated secret key may be a boundary control device K known to the CRA 10. G formed with the permanent ID of i.e. S i =#(KG ,A t ) For all of these functions, the underlying cryptographic hash function is immaterial; any cryptographic hash function can be used. The implementor's choice of a preferred cryptographic hash algorithm is motivated by considerations of the algorithm's lifetime and cryptographic strength, among other things.

[0169] Another embodiment of the invention does not provide a local token in the header, but rather a local token L that specifies a local reference. t and the central service authorized parameter, authorization token A. t It is also possible to not compare the values ​​between L and t If a header is not used, then the nonce or other entropy element created by the orchestrator cannot be utilized to provide a unique header for each payload, and thus the property of unique payload headers for repeated and potentially chunked payloads is no longer guaranteed to be true, and therefore there is less benefit to using this alternative embodiment. That said, the lack of uniqueness is not necessary for the guarantee to work, i.e., you cannot export if the signature is not valid and outside of niche risks, but once you export something, exporting it again is not that bad in terms of confidentiality.

[0170] In yet another embodiment of the present invention, the CRA 10 generates an authorization token A that contains additional information that is not used to guarantee the release of the payload or to authorize, but is instead used to ensure efficient management of the scheme. t For example, A t may contain a reference to a Quality of Service (QoS) that allows the selection of a most preferred export to take precedence over less preferred exports.

[0171] Similarly, for similar purposes, tManagement information may also be added to the payload, for example, a reference to the original accepted payload may be added if the payload is chunked or otherwise modified.

[0172] Various alternative implementations may be provided in which the roles of signer 8, sender 7 and orchestrator 9 do not need to be separated, but can instead be combined into various unified roles, for example: i. the sender role and the orchestrator role, ii. the sender role and the signer role, iii. a decomposition / combination of all three is possible.

[0173] Since a signed payload is essentially another payload type, it is possible to sign an already signed payload to create multiple signed payloads, which is useful when sending through a group of serially connected BCD gateways. In this alternative embodiment, each layer of signature can use a different signer.

[0174] Another option is to require multiple authorizations before release is allowed. For example, this option can be implemented using authorization token A. t This can be implemented by adding a parameter called weight W to , where the aggregate weights of all authorization tokens must exceed a threshold. BCD is then configured to enforce the selected weighting scheme.

[0175] Instead of considering exports, we can also consider imports, i.e., transfer of payloads from a less trusted network to a more trusted network, as exports from the less trusted network. From the perspective of the more trusted network, the CRA for imports resides within the less trusted network and ensures that all imports from the less trusted network are authorized to be sent to the more trusted network.

[0176] Not all BCD devices 3, 3' in a gateway group 4 need to reside at one site; to achieve three-way resilience, the BCD devices 3, 3' in one gateway group 4 can be distributed across three physical locations, with a load balancer between the sender and the BCD selecting a local gateway for best performance, or a remote gateway if one is unavailable due to a local failure. Similarly, the signers 8, orchestrators 9, CRAs, and senders 7 can reside on multiple sites to achieve full export assurance scheme resilience.

[0177] The above described embodiment allows a guarantee scheme to be set up on an enterprise scale and allows the following requirements to be met: 1. It allows for effective audits because: a. all export payloads are effectively identifiable; b. All steps in the process use a common identifier; c. The identifier of the export payload is unique; and d. Chunked export payload identifiers are simply and explicitly related to the original payload request. 2. Enables resilience, performance and scale because: a. All parts of the export authorization control architecture must be built to be resilient, including local and site resilience; b. Export Admission Control used in conjunction with the chunking option allows for increased bandwidth by allowing multiple BCDs to be used in the transfer of a single payload; and c. The export authorization control architecture is highly scalable in terms of bytes per time and payload, due to reduced reliance on high-security but performance-limited components. 3. It enables security because: a. The architecture can be deployed with a configuration of components that have exploitable characteristics (i.e., allow for the delivery of normally prohibited payloads) following the compromise of a single component. 4. Simple management due to: a. Export authorization controls allow for the embedding of control information in export headers to enable efficient operation of the scheme for all electronic entities. [Explanation of symbols]

[0178] 1. Payload Authorization Control System 2. Network Perimeter 3, 3' Boundary control device 4. Boundary Control Group 5. Computer Processors 6 Data storage devices 7 Sender Entity 8 Signing Entity 10 Central Liberation Authority (CRA) 11, 11' identity block 12 The First Network 13 The Second Network 14 Comparator 15 Random Number Generator 16 Storage area 17 External Requester Entity

Claims

1. 1. A payload assurance method for a payload X to be transferred across a network boundary via any of a plurality of predetermined boundary control devices, the payload assurance method being executed by at least one data storage device with at least one computer processor in a first electronic entity; In the first electronic entity, upon request, generating an electronic authorization token defining characteristics of the payload X to be transferred; defining a boundary control group located at a network boundary, the boundary control group including at least two boundary control devices each having dedicated persistent identity information associated therewith; determining a temporary ID array according to the permanent identity information and the authorization token of each border control device in the border control group; generating an electronic release token to be transferred to a second electronic entity according to the temporary ID array and the authorization token, the electronic release token being valid for use with the boundary control device within the defined boundary control group; A method comprising:

2. The method further comprises generating at least one entropy element forming part of the electronic authorization token to ensure that multiple electronic authorization tokens authorizing the same payload characteristic are unique. The payload assurance method for payload X according to claim 1.

3. the release token is applied to one or more payload transfer authorization requests during the validity period of the release token; 3. A payload guarantee method for payload X according to claim 1 or claim 2.

4. the validity period of the release token depends on a predetermined period defined in the authorization token by the first electronic entity; The payload guarantee method for payload X according to claim 3.

5. When the second electronic entity receives the release token and is requested to transfer a payload, the second electronic entity creates a file token for each border control device in the gateway group depending on the temporary ID array, a local token including parameters remotely determined by the first electronic entity, and a hash digest of the payload X to be transferred, and stores the file token array {F t }, A payload guarantee method for a payload X according to any one of claims 1 to 4.

6. the hash digest is provided by passing the payload X through a one-way function before the payload X is received by the second electronic entity as part of the payload transfer request. The payload guarantee method for payload X according to claim 5.

7. the local token includes an entropy component; 7. A payload guarantee method for payload X according to claim 5 or 6.

8. at least one of the parameters included in the local token is provided by a third electronic entity that verifies desired payload parameters for payload transfer across the network boundary; A payload assurance method for a payload X according to any one of claims 5 to 7.

9. a fourth electronic entity acting as a payload sender entity and as the only electronic entity in contact with the boundary controller of the boundary control group defines at least one of the parameters included in the local token; The payload assurance method for payload X according to claim 8.

10. the third electronic entity validates the payload X against predetermined rules and / or intended payload destinations provided upon receipt of the payload transfer request and provides an evidence object of the validation for inclusion in the local token; A payload assurance method for payload X according to claim 8 or 9.

11. the second electronic entity is then configured to generate a payload header depending on the authorization token, the local token, the file token array {F t} and the hash digest of the payload X; A payload assurance method for a payload X according to any one of claims 5 to 10.

12. the payload header is prepended to the payload X before the payload X is forwarded by a fourth electronic entity to one or more boundary control devices in the boundary control group; The payload assurance method for payload X according to claim 11.

13. When at least a portion of the payload X having a payload header E arrives at the border control device, the border control device generates a session ID (S i ) g Regenerate the The payload assurance method for payload X according to claim 12.

14. At the border controller, the session ID is used together with parameters in the payload header E to generate a file token F t ' is calculated, The payload assurance method for payload X according to claim 13.

15. The payload headers E to F t '=#(#(X),L,J,HMAC(K G ', A)), and the session ID is HMAC(K G ', A) The payload assurance method for payload X according to claim 14.

16. The boundary control device t ' to the file token array {F t} located in the header E, and t }, and if there is a match, then generate a first positive event result identifier; A payload assurance method for payload X according to claim 14 or 15.

17. The boundary control device passes the payload X through a one-way function to convert X to #(X) g and #(X) g with #(X) in header E, and if a match exists, then generate a second positive event result identifier; A payload assurance method for a payload X according to any one of claims 14 to 16.

18. the boundary control device further compares other control criteria contained in the export or import header to ensure they are within predetermined limits, and if so, provides a third positive result identifier; A payload assurance method for payload X according to claim 16 or 17.

19. the boundary control device identifies the first positive result identifier, the second positive result identifier, and the third positive result identifier, and thereafter determines a positive boundary control result; A payload assurance method for a payload X according to claim 16, 17 and / or 18.

20. the border controller forwards the payload X having the header E across the network / domain boundary via the border controller if a positive boundary control result is met; 20. The payload assurance method for payload X according to claim 19.

21. the boundary control device is configured to prohibit passage of a file across a network / domain boundary and / or allow the file to be discarded if a positive boundary control result is not met; 21. The payload assurance method for payload X according to claim 20.

22. the one or more border control devices of the border control group block invalid export headers and payloads that do not correspond to valid headers according to the authorization token and the temporary ID array; A payload assurance method for a payload X according to any one of claims 1 to 21.

23. the payload X is divided into chunks smaller than the maximum size available to the boundary controllers in the boundary control group; A payload assurance method for a payload X according to any one of claims 1 to 22.

24. creating an array of payload headers, one for each payload chunk, based on the authorization token, file token, local token, and payload hash table; 24. The payload assurance method for payload X of claim 23.

25. and further comprising: prepending a payload header of the chunk to the corresponding chunked payload and forwarding the resulting signed payload chunk to one or more boundary control devices in the boundary control group.

25. The payload assurance method for payload X according to claim 24.

26. 1. A payload assurance system for a payload X to be transferred across a network boundary via at least one predetermined boundary control device, 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 being configured by the at least one computer processor to: generating an electronic authorization token defining characteristics of said payload X to be transferred; defining a boundary control group located at a network boundary, the boundary control group including at least two boundary control devices each having dedicated persistent identity information associated therewith; determining a temporary ID array according to the permanent identity information and the authorization token of each border control device in the border control group; generating an electronic release token to be transferred to a second electronic entity in the system according to the temporary ID array and the authorization token, the electronic release token being valid for use with the boundary control device in the defined boundary control group; 12. A payload assurance system comprising:

27. the electronic authorization token further comprising at least one entropy element for ensuring that multiple electronic authorization tokens authorizing the same payload characteristic are unique; 27. The payload assurance system of claim 26.

28. a plurality of separate and distinct electronic entities consisting of at least one authorizer entity, at least one sender entity, at least one signer entity, and at least one payload verification entity; 28. A system according to claim 26 or 27.

29. the signer entity configured to sign any number of payloads using the release token during the validity period of the release token; 30. The payload assurance system of claim 28.

30. When the signer entity receives the release token and receives a payload export request, it calculates the file token of each border control device in the gateway group depending on the temporary ID array, the local token, and the hash digest of the payload X to be transferred, and stores it in the file token array {F t }, 30. The payload assurance system of claim 29.

31. the hash digest is provided by passing the payload X through a one-way function before forwarding the payload X to the signer entity; 31. The payload assurance system of claim 30.

32. the local token defines parameters related to a payload, a payload destination, and / or defined by the sender entity; 32. A payload assurance system according to claim 30 or claim 31.

33. the local token includes an entropy component; 33. A payload assurance system according to any one of claims 30 to 32.

34. the parameters included in the local token are provided by the payload validation entity and / or the sender entity; 34. A payload assurance system according to any one of claims 30 to 33.

35. the payload validation entity is configured to validate the payload X against requestor and / or payload destination predefined rules, and to provide an evidence object of the validation for inclusion in the local token; 35. A payload assurance system according to any one of claims 30 to 34.

36. The signer entity is then configured to generate a payload header depending on a hash digest of the authorization token, the local token, the file token array {F t} and the payload X.

36. A payload assurance system according to any one of claims 30 to 35.

37. The payload header is prepended to the payload X before being forwarded to one or more BCDs within a gateway group.

37. The payload assurance system of claim 36.

38. The payload X is divided into chunks smaller than the maximum size available to the border controller in the gateway group.

38. A payload assurance system according to any one of claims 28 to 37.

39. a signer entity configured to create an array of payload headers, one for each payload chunk, based on the authorization token, the file token, the local token, and a hash table of payloads; 39. The payload assurance system of claim 38.

40. and further comprising: prepending a payload header of the chunk to the corresponding chunked payload and forwarding the resulting signed payload chunk to one or more boundary control devices in the boundary control group.

40. The payload assurance system of claim 39.

41. The border controller generates a gateway session ID (S) using the permanent ID information of the border controller and the authorization token from the header upon receipt of the payload X at the border controller. i ) g configured to regenerate 41. A payload assurance system according to claim 37 or 40.

42. At the border controller, the session ID is used together with the parameters in the payload header to generate a file token F t ' is calculated, 42. The payload assurance system of claim 41.

43. F from the payload header t '=#(#(X),L,J,HMAC(K G ', A)), and the session ID is HMAC(K G ', A) 43. The payload assurance system of claim 42.

44. The boundary control device t ' to the file token array {F t} located in the header E, and t }, wherein the comparator is configured to generate a first positive event result identifier if a match exists.

44. A payload assurance system according to claim 42 or claim 43.

45. The boundary control device passes the payload X through a one-way function to convert X to #(X) g and the comparator is configured to provide #(X) g with #(X) of the header E, and if a match exists, the comparator is configured to generate a second positive event result identifier.

45. The payload assurance system of claim 44.

46. the boundary control device further compares other control criteria contained in the export or import header to ensure they are within predetermined limits, and if so, the comparator is configured to provide a third positive result identifier; 46. ​​A payload assurance system according to claim 44 or 45.

47. 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 thereafter determine a positive boundary control result according to the first positive result identifier, the second positive result identifier, and the third positive result identifier; 47. A payload assurance system according to claim 44, 45 or 46.

48. the boundary controller is configured to forward the payload X across a network / domain boundary through the boundary controller if a positive boundary control result is met; 48. The payload assurance system of claim 47.

49. the boundary controller is configured to prohibit passage of a file across the network / domain boundary and / or allow the payload X to be discarded if a positive boundary control result is not met.

49. The payload assurance system of claim 48.

50. the at least one sender entity is the only electronic entity in communication with the at least one boundary control device; 50. A payload assurance system according to any one of claims 30 to 49.

51. a random or pseudo-random number generator that provides an entropy component for the electronic authorization token and / or the local token; 51. A payload assurance system according to any one of claims 30 to 50.

52. 52. A payload assurance system comprising: a payload assurance system according to any one of claims 27 to 51; An export control system comprising:

53. 52. A payload assurance system for assuring payload for transfer from an untrusted network to a trusted network (or vice versa) according to any one of claims 27 to 51. A computing device characterized in that:

Images