Payload assurance at the network perimeter

Abstract

A payload assurance system and method for a payload having a header to be transferred across a network boundary via at least one predetermined boundary control device, the system comprising at least one computer processor and at least one data storage device arranged to provide an electronic authorization token authorizing characteristics of the payload to be transferred, the electronic authorization token including at least one entropy element to ensure that multiple electronic authorization tokens authorizing the same payload characteristics are unique, and a boundary transfer evaluation step can be performed at the network boundary using the payload header to indirectly determine whether the payload possesses an authorization token.

Description

[Technical Field]

[0001] The present invention is in the field of data assurance at network boundaries or gateways, and in particular to ensuring the conformance and authorization of a payload X with an associated header H to be transferred across networks of differing levels of trust via a gateway. [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. Summary of the Invention [Problem to be solved by the invention]

[0005] Therefore, a need has been identified for a cross-domain payload assurance method and system that provides payload assurance regarding the conformance of egress data at cross-domain boundaries, has improved security, is properly authorized for cross-domain transfers, provides ephemeral authorization, is agile with respect to time changes, and provides centralized administrative control. [Means for solving the problem]

[0006] Accordingly, there is provided a payload assurance system for a payload X having a header H to be transferred across a network boundary via at least one predetermined boundary control device, the payload assurance system comprising at least one computer processor and at least one data storage device, the at least one data storage device comprising instructions operable by the at least one computer processor to provide an electronic authorization token authorizing characteristics of the payload to be transferred, the electronic authorization token comprising at least one entropy element that ensures that multiple electronic authorization tokens authorizing the same payload characteristics are unique.

[0007] Thus, the uniqueness of the entropy factor ensures that all authorization tokens are unique, even if all authorization tokens are implemented to provide the same payload characteristic authorization, thereby providing authorization tokens that are always distinguishable and auditable.

[0008] At the network boundary, a boundary transport evaluation step is performed that indirectly determines whether the payload possesses an authorization token. The header is used to perform this evaluation at the boundary controller.

[0009] The payload can be in the form of a file having a payload X and a header H. For example, the file can include an export file with an export header or an import file with an import header. Either can be transferred across network domain boundaries, requiring file security and authorization to be considered before any transfer of the file's payload occurs. Alternatively, the payload can be stream data with an attached header. The boundary control device can be any device (e.g., a gateway) located at the network domain boundary, and is typically physical hardware that provides hardware security controls. Thus, a gateway can be an export gateway, an import gateway, or multiple export and / or import gateways / pairs. Alternatively, the payload can be stream data with an associated header H.

[0010] An authorizer entity is effectively a central service entity that resides on the trusted side of the network boundary and is responsible for specifying (or controlling) the characteristics of payloads that are allowed to be transferred across the network boundary.

[0011] By using different authorized payload parameters at the authorizer entity, there is no longer a requirement to perform software patches or reconfigurations of gateways at the network perimeter to allow different files or payloads to egress.

[0012] Another feature of the authorizer entity can be that it has permanent identity information. This permanent identity information is a unique identifier in the form of a 32 / 128 byte number. The permanent identity information of an electronic entity can be the same as the permanent identity information associated with a given gateway. This can be achieved by sharing a unique identifier value between the gateway and the electronic entity, or by providing a unique identifier value at the time of manufacture or commissioning.

[0013] Between the authorizer entity and the boundary controller, a sender entity is located, acting as an authorization intermediary between the authorizer entity and the gateway. Specifically, the sender entity need only be a communicative intermediary and not necessarily located in an intermediate position. The sender entity requests the transfer of a payload across a domain boundary (and therefore can also be considered a payload / file transfer requesting entity). This intermediate positioning of the sender entity provides a level of separation between (1) the authorization step in the authorizer entity and (2) the comparator step in the boundary controller; that is, the boundary controller is separated from (i) the authorizer entity that makes the top-level payload / file property authorization decision and (ii) the factors that enabled that decision. Therefore, this intermediate positioning of the sender entity provides the ability for the boundary controller to autonomously verify the allowed payload / file properties against the payload / file authorizations, without the need to configure the boundary controller with the authorized properties.

[0014] The sender entity cannot see the permanent identifier information, which is a secret value.

[0015] Authorization characteristics are payload attributes or associated criteria that are allowed to pass from a trusted network to an untrusted network or vice versa.

[0016] The payload assurance system may include a plurality of separate and distinct electronic entities, comprising at least one authorizer entity, at least one sender entity, and at least one boundary controller, which are communicatively coupled, and preferably implemented with only one authorizer entity acting as the central authorizer entity.

[0017] The authorizer entity can be configured to create an ephemeral identity for a given boundary controller using an electronic authorization token and permanent identity information associated with the given boundary controller. In effect, the system can generate short-term tokens from long-term permanent identity tokens. The tokens can allow additional characteristics of the payload (e.g., file / payload size, type, lifetime, token lifetime) to be guaranteed by the gateway. The ephemeral identity can be created at the authorizing entity. The authorizing entity is a central service that can realize a single service (more common) or multiple authorization services (providing more complex configurations). Each of these independent services can provide authorization tokens for different payload criteria, thereby providing a fail-safe.

[0018] Thus, if multiple border controllers exist, the sender must select a single device, and this selection is included in the payload transfer request.

[0019] The permanent identity information of each boundary controller in the system may be stored in the authorizer entity.

[0020] In a first embodiment of the present invention, at least one authorizer entity may be configured to transfer the temporary identity to the sender entity upon request.

[0021] The sender entity can be configured to create an export or import header according to the temporary identity forwarded to the border controller.

[0022] It is important to reiterate that the system can be implemented for payloads coming into a trusted network as well as payloads being exported from a trusted network.

[0023] In a second embodiment of the present invention, at least one signer entity may be further provided, which is arranged to communicatively mediate between at least one authorizer entity and at least one sender entity so as to prevent at least one sender entity from communicating directly with the authorizer entity. Communicatively mediating means that the physical location of the signer entity does not necessarily need to be intermediate between the authorizer entity and the sender entity, but instead prohibits the sender entity from communicating directly with the authorizer entity and passes the transfer request through the signer entity. Similarly, the signer entity is prohibited from directly communicating with the boundary controller. In practice, the signer entity is the only type of electronic entity that communicates with at least one authorizer entity. This ensures that the authorizer entity is decoupled from the boundary controller. By applying this arrangement of the sender entity and the signer entity, the risk of incorrect authorization being performed can be minimized.

[0024] In contrast to the first embodiment, the authorizer entity may be configured to transfer the temporary identity to the signer entity upon request.

[0025] The signer entity may be configured to create an export or import header according to the temporary identity and then forward it to the sender entity.

[0026] In both the first and second embodiments of the present invention, the sender entity is configured to add an export or import header to a payload to form an export payload, and then forward the export payload to a predetermined border control device.

[0027] The header associated with the export or import payload may further include a local token that defines the local characteristics of the payload being transferred.

[0028] The authorizer entity may be configured to provide a temporary identity for a boundary controller according to an electronic authorization token and the permanent identity information of a given boundary controller by implementing a one-way mathematical function, where the authorization token and the permanent identity may be concatenated before applying the mathematical function.

[0029] The one-way mathematical function may include an HMAC with an associated secret key.

[0030] The private key may contain the permanent identity information of a given boundary controller. Thus, the sender entity needs to specify the boundary controller of interest from a selection of multiple options. Alternatively, only a single boundary controller may be provided, in which case no selection step is required.

[0031] Advantageously, the at least one sender entity is the only electronic entity in communication with the at least one border control device.

[0032] The border control device may include a comparator configured to identify an authorization token in the export or import payload header upon receiving the exported or imported payload, and generate a temporary identity according to the authorization token and its locally stored permanent identity information.

[0033] The comparator may be configured to directly or indirectly compare the temporary identity generated at the at least one authorizer entity with the comparator temporary identity generated at the at least one boundary control device to determine whether they are the same.

[0034] The comparator may further be configured to compare other control criteria contained in the export or import headers to ensure that these are within predetermined limits.

[0035] Thus, the gateway can compare the respective values ​​between the local criteria and the authorization criteria that provide the file / payload delivery result. The authorizer entity and at least one predetermined gateway have knowledge of a shared key value that enables this comparison of the local criteria and the authorization criteria. The local information can include environmental information or other criteria requests from the requesting entity.

[0036] Preferably, the comparator may be configured to determine a positive boundary control result if: i. The generated temporary identity is the same as the comparator temporary identity, and ii. Other export header control criteria are within prescribed limits.

[0037] Therefore, a positive boundary result occurs only if the totality of test criteria is met. t must match, i.e. the gateway does not know the authorizer's temporary ID, i.e. the session key, but tCalculating this indirectly indicates that a session ID has also been agreed upon.

[0038] The border controller may be configured to forward payload X with header H across the network / domain boundary through the border controller if a positive border control result is met.

[0039] The border control device may also be configured to prohibit payload X and associated header H from passing through the network / domain boundary and / or allow payload X to be discarded if a positive border control result is not met.

[0040] This configuration can provide autonomous handling of files / payloads at the gateway (or other domain border device) for authorization (or otherwise) of the transfer of the files / payloads.

[0041] For example, the gateway does not understand the meaning of any header value, but instead is instructed to calculate a comparator for the header value and perform a test against the header. The gateway's factory settings already apply certain standards, which cannot be changed even by an authorized entity. Therefore, the method of calculating the comparator 10 and the test steps performed in the gateway can enable powerful and reliable enforcement functions to be performed.

[0042] The payload assurance system may further include a random or pseudo-random number generator that provides the entropy element of the electronic authorization token. The random or pseudo-random number generator is located in the authorizer entity. This unique quantity must be random or pseudo-random, and the value is located in the payload / file header. For practical implementations, the value should not be predicted prior to token creation.

[0043] The electronic authorization token may be publicly known.

[0044] In a further aspect of the present invention, there is provided an export control system for transferring an export file having an export header and a payload X across network boundaries, the export file comprising a payload assurance system according to any preceding claim.

[0045] For the avoidance of doubt, the file / payload being transferred comprises an export file / payload having an export file / payload header that is dependent on (and appended to) the electronic authorization token.

[0046] Another aspect of the invention provides a computing device including a system for securing a payload for transfer from an untrusted network to a trusted network (or vice versa), including any of the features described above.

[0047] A further aspect of the present invention provides a network including a system for securing a payload for transfer from an untrusted network to a trusted network (or vice versa), the system including any of the features described above.

[0048] A further aspect of the present invention provides a method for securing a file / payload for transfer across a network boundary via a boundary control device using a system including at least one computer processor and at least one data storage device, wherein the at least one data storage device includes instructions operated by the at least one computer processor, and the method includes providing an electronic authorization token configured to authorize the payload to be transferred, the electronic authorization token including at least one element related to characteristics of the payload and at least one entropy element that ensures that multiple electronic authorization tokens authorizing the same payload characteristics are unique. The payload-based authorization is provided and signed by another entity to an authorizer entity. This authorization is performed by a sender entity (in embodiment 1) or a signer entity (in embodiment 2). In effect, creating an export header is a signature process.

[0049] If the system further comprises at least one authorizer entity and at least one sender entity configured to communicatively mediate between the authorizer entity and the boundary control device, the method may further include creating a temporary identity for the given boundary control device using the electronic authorization token and permanent identity information associated with the given boundary control device.

[0050] The temporary identity of a given boundary controller can be provided according to the electronic authorization token and the permanent identity information of the given boundary controller by implementing a one-way mathematical function.

[0051] The one-way mathematical function involves an HMAC with an associated secret key. The secret key may contain the permanent identity information of a given boundary controller. In effect, this boundary controller is the boundary controller of interest. Alternatively, a hash function may be applied.

[0052] The method may further include storing permanent identity information for each boundary controller in the system in an authorizer entity.

[0053] Advantageously, the permanent identity information can be barred from access by the sending entity.

[0054] The authorizer entity can forward the temporary identity to the sender entity upon request, which can then create an export or import header according to the temporary identity.

[0055] The system further comprises a signer entity, and the method includes the authorizer entity transferring the temporary identity to the signer entity upon request, which may then create an export or import header in accordance with the temporary identity and forward the export or import header to the sender entity. For the avoidance of doubt, an export file / payload is created having an export file / payload header that is dependent on the electronic authorization token.

[0056] Once the header for payload X is created, the payload header contents can be checked against both the payload, environmental information (e.g., time), and internal information of the gateway (e.g., pre-configured factory settings or the identity of the gateway). Once the payload passes all tests, it is released from the gateway, i.e., forwarded from the trusted network across the network boundary to the less trusted network.

[0057] The method may further include providing a temporary identity of the given border controller in an export or import header.

[0058] The method may further include adding an export or import header to the payload at the sender entity to create an export or import file / payload, respectively, and then forwarding the export or import file / payload to a predetermined border control device.

[0059] The method may further include providing local characteristics of the transferred payload in an export or import header.

[0060] Beneficially, at least part of the file / payload header includes a hash generated by a hash function.

[0061] The method may further include, upon receiving the export or import file / payload at the border control device, identifying an authorization token in the export file / payload header, and creating a comparator temporary identity according to the authorization token and permanent identity information stored locally in the border control device.

[0062] The electronic entity's permanent identity information must be identical to the permanent identity information of a given border controller, otherwise the border controller will not allow the export file / payload to pass through.

[0063] The method may further include directly or indirectly comparing the temporary identity generated at the authorizer entity with the comparator temporary identity generated at the boundary control device to determine whether they are identical.

[0064] The comparator may further be configured to compare other control criteria contained in the export header to ensure that these are within predetermined limits.

[0065] The method may further include determining a positive boundary control result if: i. The temporary identity generated at the authorizer entity is the same as the comparator temporary identity generated at the boundary controller, and ii. Other export header control criteria are within prescribed limits.

[0066] A file with payload X can be transferred across a network / domain boundary via a boundary control device if a positive boundary control result is met.

[0067] If a positive boundary control result is not met, the file may be prohibited from passing through and / or the file's payload X may be discarded.

[0068] The method may include randomly or pseudo-randomly generating values ​​to provide the entropy component of the electronic authorization token. For example, a lava lamp bubble approach may be implemented to provide the random numbers, or alternatively a pseudo-random number generator may be applied.

[0069] The method may further comprise: determining an electronic authorization token lifetime T such that authorization is determined to be valid over the electronic authorization token lifetime; S1 ≦T t ≦T S2 This can include determining:

[0070] The method sets the export period to T so that export of the file / payload is only allowed if the export period is met. M1 ≦T t ≦T M2 This can include determining:

[0071] The method may include calibrating and / or agreeing on a time reference between the authorizer entity and at least one predetermined boundary control device.

[0072] Once the characteristics of a payload are authorized through the issuance of an authorization token, there is no option to change the characteristics of the authorized payload. That is, the border controller only needs to know the interrelationships between entities within the scheme rather than the details of the validation scheme; for example, a gateway considers only checkable assertions between headers, inherent characteristics of the payload (e.g., size), and environmental factors (e.g., time constraints). This allows sealed-for-life gateways to be used to make release decisions autonomously. Autonomous in this example means that the decision is made without reference to other electronic entities. This maintains isolation between authorization decisions (at the CRA) and validation decisions at the gateway, eliminates the need to request authorization decisions from another electronic entity, and improves security at the gateway by eliminating the ability for third parties to eavesdrop on this decision information. Thus, border devices can include the simplest devices that never need to be replaced or updated and never change.

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

[0074] 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.

[0075] A "file" is formed by a header H and a payload X. However, the file assurance system and method can also be used on packets of data that still include associated headers and payloads, and can also be used for streaming data where an export header is prepended to the streaming data.

[0076] 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.

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

[0078] [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] 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 3] FIG. 10 illustrates a representation of an authorization token. [Figure 4]FIG. 10 illustrates a representation of a release token. [Figure 5] FIG. 10 illustrates a representation of an export header. [Figure 6] 1 is a schematic diagram of a system for payload assurance at a network domain boundary including a signer entity. DETAILED DESCRIPTION OF THE INVENTION

[0079] 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.

[0080] 1 shows a payload authorization control system 1 including a computer processor 4 and a data storage device 5 for a file having a payload X to be transferred across a network boundary 2 via a boundary control device G3 (e.g., a hardware-implemented network gateway). The system 1 and associated method provide immutable hardware boundary control for use, for example, in an export gateway, to ensure that export payloads meet the following criteria: - have undergone an approved assurance process; - The format and content will not change after undergoing the certification process; Compatible with released licenses, The name will not change, - be uniquely identifiable (even if it is an identical copy of another payload); · Have a uniquely identifiable authorization (even if it is identical to other payloads); Ensuring that authorization does not change from the time of providing the file to the entity responsible for releasing the file; Ensuring that the scheme's separation of roles is enforced whenever the scheme is executed.

[0081] For the file assurance scheme to work, there are several roles or entities that must perform specific assigned functions. These entities include: Sender 6: This entity requests authorization appropriate to its role to enable it to create export headers for approved payloads that it sends to a network boundary device 3 (such as a gateway), either autonomously on its own behalf or acting on behalf of another entity (such as a requester (not shown)). Requestor (not shown): This optional entity is an entity external to the export admission control that wishes to send a payload across a selected gateway. · Central Release Authority (CRA) 7: This entity manages the access to the Gateway Identity Block and the creation of authorizations when queried by senders. Export Gateway 3: This entity owns a unique identity block and will not allow any file with i. an invalid export header and / or ii. an incompatible export header to pass through, even if the export file is valid.

[0082] In a first embodiment of the present invention, an authorization control and assurance system 1 (hereinafter referred to as the authorization system) is configured to provide authorized payload export to a single, predetermined gateway 3. The authorization scheme (including checks to be undergone at the gateway itself) allows for control of some specific characteristics of the payload (e.g., size), 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 utilizes a payload-specific export header containing three separate subtokens prepended to a particular payload. A payload can successfully pass through the export gateway 3 as requested by the sender 6 only if the information in the export header can be guaranteed to be valid.

[0083] The export header and its 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 export header for use in functions supporting the scheme. For simplicity, we refer to both representations as "tokens" (e.g., "authorization tokens"), clarifying the form of the token (information or binary) where important.

[0084] The data store 5 stores an authorization token A, which will be described in more detail below. t The authorization token A includes instructions operable by the processor 4 to provide the authorization token A. t provides a single level of signature by an authorized entity that can be applied consistently across a variety of export authorization requests.

[0085] The authorization scheme involves the four electronic entities (or roles) introduced above (three roles if the requester entity is actually the sender entity): An export gateway is a predefined border controller 3 located at the network domain boundary 2, i.e., a position that allows transit between a first network 8 and a second network 9 (or vice versa, depending on whether payload export or import is required).

[0086] A requester entity (not shown) initiates the scheme by sending a request for a sender entity 6 to send an export file through a predetermined boundary controller 3 located at a network boundary 2 .

[0087] The sender entity 6 generates a local token L for the export file. t Create a L t and payload X and release token R t By combining the file token F t Create a local token L tcontains details on the specific characteristics of the payload, including: A nonce used to disambiguate identical payloads, Information about the payload itself, such as its UUID and original hash, Time limits - setting time thresholds such as "invalid before" or "invalid since" to prevent "old" payloads from being exported; Classification - Assertion of the classification of the payload.

[0088] Also, the sender entity 6 is iA t , L t and F t ii. creating an export header by combining the export header with the payload, ii. signing the payload by combining the export header with the payload, and iii. sending the signed payload to a predetermined gateway 3. The sender entity 6 is authorized to export only files that meet predetermined file criteria.

[0089] CRA7 receives a release token R, which is a unique token generated upon query of the sender entity 6. t CRA7 mainly holds the permanent identifier of the boundary control device, and provides the gateway key and authorization token A. t From session ID S i The session ID is a moderately sensitive temporary value (or temporary identity) that poses no long-term risk because it expires periodically. t and session ID S i are transferred in pairs in response to a query from the sender entity 6. The pairs define a release token.

[0090] The sender entity 6 requests a release token from the CRA and generates export headers for payloads that require authorization for export according to the release token.

[0091] The authorization token created by the CRA7 is an electronic token formed of at least a first part relating to authorized file 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 7 will allow to traverse a specified or predetermined gateway 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 file characteristics are each unique. This allows for centralized control of the specification of characteristics and associated authorizations, and ensures that each authorization request and associated response is distinguishable and therefore auditable. In this embodiment, the file is an export file that is transferred between a trusted network 8 and a less trusted network 9 across a predetermined border controller 3, such as a gateway G.

[0092] The permanent identity information, such as an identity block or other key type associated with this boundary controller, 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 identity information (K) associated with the border controller 3 selected for the file transfer G ) must be shared exclusively between the CRA7 and the selected boundary controller when it is placed in service. The selected boundary controller must use a manufacturing-created K that is securely presented to the i.CRA. G ii. K created by the CRA loaded into the boundary control device G iii. K created by an independent source loaded into the boundary control device G This same K G is loaded into the CRA.

[0094] 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 export control system use the same mapping. The authorization token is a component of the export header that must be provided to the sender entity 6.

[0095] For the avoidance of doubt, the authorization token includes central authorization controls that are assertions of what is permitted to be exported across the boundary control device 3; for example, these may include: version number, Entropy (ensuring the uniqueness of each authorization header), Time Limits - "Invalid before" or "Invalid after" to control token expiration, size - the maximum size (in bytes) of the payload (zero means no limit), Type - BMP, or other specified preferred file type as needed, or any file type.

[0096] A release token R containing the authorization token and the session ID t is created by the CRA 7, given to the sender entity 6, and used in the generation of all export payload headers until its validity period expires or until it is replaced by a refreshed release token on a subsequent request from the sender 6 to the CRA 7. Only the entropy factor guarantees a unique response to each authorization token request.

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

[0098] CRA7 is a one-way mathematical function, i.e., S i =f(KG ,A t ) to obtain the authorization token and the permanent ID K of the selected gateway. 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).

[0099] For the avoidance of doubt, the session ID is created at the CRA and the one-way mathematical function f corresponds to the predetermined boundary controller selected for the file transfer.

[0100] In this example of the invention, the one-way mathematical function may comprise an HMAC function, and the associated secret key is formed with the permanent ID of the boundary controller known to the CRA, i.e., S i =HMAC(K G , A t )

[0101] Alternatively, the one-way mathematical function may include a hash, and the associated secret key may be a boundary control device K known to the CRA. G formed with the permanent ID of S i =#(K G ,A t )

[0102] For all of these functions, the underlying cryptographic hash function is immaterial and any cryptographic hash function can be used. The choice of a suitable cryptographic hash algorithm by an implementor is motivated by considerations of the algorithm's longevity and cryptographic strength, among other things.

[0103] S iThe step of generating a temporary identity derived from the shared permanent ID effectively creates a temporary identity that is used by the sender entity 6 when transferring the file for transfer across network boundaries, thereby alleviating the need to transmit the permanent ID value. The permanent ID remains an unknown value to the sender entity 6 (i.e., the permanent ID is effectively a secret value unknown to the sender entity 6 or the original external requester).

[0104] CRA7, upon receiving a valid request from sender entity 6 to use export gateway G, computes an HMAC and generates a Release Token R T =(A t , S i ) back to the sender entity 6. As will be explained later, S i The HMAC calculation used to create the t is recreated at the gateway to ensure that it must be authentic.

[0105] For simplicity, each of the following examples assumes that the sender entity 6 is currently authorized to use a particular boundary controller. If the sender is currently authorized to use a boundary controller, the sender does not need to contact a CRA for further authorization.

[0106] The sender entity is R t If you have a file token F like this: t Generate. F t =g(X,L t ,S i ).

[0107] The function g corresponds to a selected predetermined boundary control device, but need not be of the same functional type as the function f described above. In this example, g is F t =#(X,L t , S i ), where # denotes hash as is standard in the art.

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

[0109] For example, sender entity 6 may send a file token F t To create a signature, when a payload X is requested to be signed, the following is calculated: F t =#(X,L t ,J,S i ) where: X is the payload byte stream, L t is the local token (in byte format), J is the file name (in byte format), ·S i is the session ID (in byte format), ·# is a suitable hash function that can also be used by the boundary control device.

[0110] File token F created above t A t Tokens and L t Combine this with the token to create an export header for the payload like this: E=A t ||L t ||F t

[0111] Finally, the sender entity 6 creates a signed payload file to be sent to the border controller 3 by adding an export header E to the payload X to give a signed export payload. P=E||X

[0112] The signed export payload is then forwarded to the designated border controller 3 .

[0113] In the boundary control device 3, a comparison is made between the file characteristics and the preset boundary control device parameter criteria. t The file characteristics that form part of the CRA7 standard are checked for compliance against the parameter criteria.

[0114] The Boundary Controller 3 holds the key and is configured to check the signed payload by checking that it is intended and that it corresponds to the local token and the authorization token. The CRA7 defined parameters are only accessible if the Boundary Controller 3 has undergone various authorization criteria checks to ensure that they are indeed authorized parameters. The most important criteria to be met is that the A received from the sender entity 6 at the Boundary Controller 3 is t (i.e., Header 1) and the local permanent identity information ID of the border controller (configured to be the same as that used by CRA7 as described above), to generate a session key (or temporary identity) S i The release token R provided by the sender entity 6 is t Assuming that the release token created in the boundary controller 3 yields the same result, the parameters are determined to be validly authorized and a payload compliance check is performed in the boundary controller.

[0115] The boundary controller 3 has a comparator 10 configured to perform a simple comparison test of the file payload contents against both CRA specified parameter criteria and internal criteria specified in the boundary controller (which are pre-configured factory settings).

[0116] Importantly, the CRA provides "critical" file criteria that must be met in order for a payload to be effectively allowed to be transferred across network domain boundaries.

[0117] Only after all these tests have been performed can the comparator 10 determine the file delivery result to be applied. For example, if all test criteria are met, the file will be released by the border controller 3, i.e., transferred across the network boundary 2 from the trusted network 9 to the less trusted network 10. If any of the test criteria are flagged as failed, the file with payload X will not be allowed to pass through the border controller 3 between the trusted network 8 and the less trusted network 9. Therefore, in this case the file payload will not be transferred across the network domain boundary.

[0118] 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 files between the trusted and untrusted networks via the border controller.

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

[0120] Another check and session key S i As an indirect way of checking, the export gateway can access its K'G and check F t ' can also be calculated. F t =F t ', then Gateway 3 can be confident that all elements used in the calculation are authentic, and can use these values ​​to check payload authorization against other release constraints (time, type, size).

[0121] In this embodiment, the sender entity inserts further local file characteristic criteria that can be of the same type (e.g., time constraints) or different type (e.g., nonce) as specified by the CRA 7 via the local token, allowing the sender entity 6 to impose further constraints on the payload release decision made in the boundary controller.

[0122] Therefore, the file token F t is #(X,L t ,S i ) and the export header is (A t ||L t ||F t ) The export header is again prepended to the payload X before it is transferred from the sender entity to the boundary controller. Thus, a file header is created for use with the file payload X to be exported, and at least part of the export header is provided by the file token F. t Includes.

[0123] The comparator 10 is now configured to perform a simple comparison test of the file header contents 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, the comparator 10 can only determine the file delivery outcome to apply once all of these tests have been performed. For example, if all of the 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, the file with payload X will not be allowed to pass through the gateway between the trusted and less trusted networks. Thus, in this case, the file and its payload will not be transferred across the network domain boundary.

[0124] This further 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.

[0125] 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. t and local token L t This can be further enhanced by providing (respectively).

[0126] 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

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

[0128] In yet another embodiment of the present invention, the CRA 7 may generate an authorization token A containing additional information that is not used to guarantee the release of the file or to authorize, but is instead used to ensure efficient management of the scheme. t For example, A T may contain a reference to the target gateway of the signed payload to enable network and information routing entities to direct the signed payload to the correct gateway through a typical enterprise network.

[0129] The boundary controller 3 is configured to check that data sent to it is authorized by the CRA 7. If the data is authorized and meets predetermined criteria (stored in a data file header appended to the beginning of the data file to be released), the file is sent. If the check determines that the data is not authorized or does not meet the file header, the boundary controller discards the file.

[0130] CRA7 is Authorization Token A t A random number generator 11 is used to provide the entropy factor of the Permanent ID information. The Permanent ID information is stored in a secure storage area 11 within the CRA. Alternatively, a pseudo-random number generator 11 can be used.

[0131] In use, a method is provided for securing payloads for transfer across network boundaries via the boundary controller 3 using the system described above.

[0132] This method, which can be initiated by an external requester entity (not shown), begins with a sender entity 6 requesting authorization from a CRA 7 to transfer a file across at least one predetermined boundary controller 3. The file has a payload X. The CRA 7 sends a release token R to the sender entity 6. t Issue.

[0133] Authorization Token A t is a unique release token R that is transferred to the sender entity 6 in response to the file transfer authorization request. tThe sender entity 6 uses a one-way function to create an export header that depends on the electronic authorization token. The sender entity 6 prepends the export header to the payload X to form a signed export file and forwards the signed export file to the border controller 3. The border controller 3 then compares the contents of the header with known local values ​​hard-programmed in the border controller and authorized parameters specified by the CRA 7.

[0134] The Border Controller 3 is configured to store a permanent ID and access it internally / locally to enable the calculation of various functions. As mentioned above, the CRA 7 is entrusted with a secret copy of each border controller. The permanent ID is determined when the gateway is manufactured, never changes, and is 32 bytes in size. The permanent ID is included in the request token T issued to authorized sender entities. t The session ID S contained in i This allows the sender entity to send the signed file through a preferred predetermined gateway. The goal is for the sender entity 6 to generate an export header containing the file token and authorization token to be sent to the border controller 3 along with the payload X.

[0135] The CRA 7 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 6 must be able to request the token within the time constraint T S1 and T S2 , maximum file size S, and file type F must be requested, or the CRA may impose predetermined values ​​for any or all of these fields. This can be accomplished in two ways: the sender may request values ​​and the CRA 7 may agree, or the sending entity may request "use of a gateway" and the CRA 7 may mandate specific values.

[0136] In all cases, the CRA7 response contains the following parameter assertion information: V: A version parameter to ensure that a given gateway supports the header. This parameter is simply a number that starts at 1 and increments by one. S: The maximum file size (in bytes) of a file that may be transferred across the gateway for this particular authorization token. This parameter is a 4-byte parameter, and a value of 0 will adopt the gateway's maximum size. F: File type, 4 bytes in size. 0x0 == any, 0x1 = BMP. T S1 : 4 bytes, the midpoint of the valid epoch time. If the epoch time is earlier than this value, the export must not be accepted. T S2 : byte, an intermediate value "valid until" a time in epoch time. Exports must not be accepted if the epoch time is later than this value. Alternatively, the intermediate value Iv can be considered a session ID.

[0137] In the structure shown in Figure 3, these values ​​combine to give A t becomes. key K g Using A t Taking the SHA-256 HMAC of S i =HMAC(K G ,A t ) and A new 32-byte value S i In the structure shown in Figure 4, this is A t Combined with the release token R t is given.

[0138] The first 96 bytes of this structure are a well-known electronic authorization token A that is reused in this scheme. tThe entire 128-byte structure of the release token consists of an intermediate value, the session ID S i Includes.

[0139] The checking criteria for a file type F can be set in the boundary control device to determine whether the file meets the specifications of a particular type. For example, a bitmap format has a common format including a BMP header and a pixel array. Each entry in the header has a known good value range, and the size of the pixel array matches the size of the indicated BMP header. When the file type is set to BMP, the boundary control device can be configured to check that the payload complies with the BMP specifications implemented in the checking criteria of the boundary control device. Multiple file types can be set in the boundary control device.

[0140] Once the sender entity has the release token containing the authorization parameters, it responds to the request to export the file by creating a local token L containing the following parameter assertion information: t Generate. N: A nonce of size 4 bytes. T M1 : 4 bytes, "useful since" time in epoch time. Exports must not be accepted if the epoch time is earlier than this value. T M2 : 4 bytes, "good until" time in epoch time. Exports must not be accepted if the epoch time is later than this value.

[0141] T provided in the authorization token by CRA7 S1 and T S2 Similarly, the local token is generated by the sender entity 6. M Pairs are provided. (T S time-based) session ID S i The expiration time of can be measured in days, T SAny payload that arrives at the boundary controller during the time limit is a valid A t However, in some applications, the message is considered to have the A of the authorization token. 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 3 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 file "valid since" the epoch time, and exports should not be accepted if the epoch time is earlier than this time. M2 can be considered a signed file "valid until" a time in the epoch, and exports must not be accepted if the epoch is later than this time. M1 =T M2 = 4 bytes.

[0142] Token information and session ID S i is transferred to the sender entity, the local parameter T M1 , T M2 is re-evaluated. Then, the sender entity t , L t and F t A file token F is used to create an export header containing t The nonce is generated randomly for each file to be sent. The purpose of the nonce N generated by the sender entity is to t The goal is to provide entropy to the .identifier., so that identical files authorized by the same authorization token will have different export headers and thus be uniquely identified.

[0143] For the avoidance of doubt, the hash function ist The following parameters must be supplied as a single byte stream to form A. Local Token L t , B. A (non-null-terminated) filename byte stream J, CS i , and D. Payload X.

[0144] The output of the hash calculation is F t =#(X,L t ,J,S i ) which we use to create the export header shown in Figure 5.

[0145] The first 96 bytes are the authorization token A obtained from the CRA. t and the next 32 bytes are the local header L padded to 32 bytes. t (assertion by the sender and other values). The last 32 bytes are the file token Ff.

[0146] The filename parameter is used to create the hash but does not appear in the header.

[0147] The header is provided with null padding (which is an artifact to make 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.

[0148] The boundary control unit performs HMAC(K G , A t ) to get the equivalent session ID S i is determined.

[0149] For convenience, three tokens are added to the exported file as shown in Figure 5. The first part is a 96-byte authorization token A. t A tis used as the message for the HMAC function, and the boundary control device K G ' as the key to the session ID S of the boundary controller. i ' to provide.

[0150] There is no filename in the header, but this can be determined at the egress file transfer gateway using shared identity information.

[0151] In the boundary control unit, BCD file token F t '=#(X,L t ,J,S i This computation is identical to that performed by the sender entity and is made possible by the shared knowledge of the secret permanent ID (except that the sender entity 6 never receives the identity, but instead uses the release token S i Therefore, to reiterate, the sender entity 6 receives the permanent ID K G or K G '(K if the correct boundary control device is used G =K G ') cannot be accessed. i Both "" and H' have a size of 32 bytes.

[0152] In order to operate correctly, the boundary controller 3 must have agreed time standards with the CRA 7 and sender entity 6. Additionally, the boundary controller is configured to only accept or send file formats that it is configured to handle.

[0153] The payload passes the boundary control device if the file token generated by the sender entity is identical to the file token generated in the given boundary control device 3, i.e., F t =F tAlthough it has been described that transfer is permitted only if ', certain other conditional criteria must also be met. For example, the following must also be true to allow transfer through the boundary controller: 1. The file type indicated must match the file format criteria specified in the boundary control. 2. Test time T in the boundary control device t must satisfy the following: aT M1 ≦T t ≦T M2 bT S1 ≦T t ≦T S2 3. File size is S determined ≦S or S=0 must be satisfied. 4. Version parameter standard is V gateway = V must be satisfied.

[0154] The comparator temporary identity S generated by the boundary controller 3 i ' is an unmodified authorization token A with valid size, type, version and validity time values t The S generated by CRA7 is only available if the payload contains an export header containing i Also, F calculated by the boundary control device 3 can be the same as t 'F' t can be the same as that generated by the sending entity only if the same authorization token, local token, and session ID are used to generate the

[0155] In another example of the present invention, a user wishes to export a Word Document.

[0156] Sender entity 6 has previously requested a release token from CRA 7 in order to perform this task in accordance with the authorization requirements of CRA 7. If sender entity 6 possesses a valid release token containing a temporary identity, it creates an export header containing the assertion "This is a releasable Word Document" and creates an export payload by prepending an export header derived from the authorization token, temporary identity, and local parameters to the document.

[0157] The export header is A t , L t and F t It is formatted from three headers: A t are the allowed top-level properties that must be true and are specified by CRA7. H3 contains local assertions, i.e., local assertions made by the sender entity 6 that relate to payload properties. F t In the boundary control device 3 (the correct boundary control device is F t The output of a hash function that can also be determined using a secret permanent identity (ID) (assuming that the computation of ' is performed).

[0158] Next, this new export file (export header and payload) is passed to a border control device 3 such as a gateway. t =F t ', after which criteria checks are initiated. These criteria checks are for constraints that can be guaranteed at the boundary controller, i.e. the gateway performs a sole evaluation of parameter checks such as file size or file type assigned during factory shipment. If and only if all checks are valid, payload X is released.

[0159] For the avoidance of doubt, this conditional criteria comparison and testing in the Border Controller 3 means that the Border Controller alone verifies the truth of the suitability of file payload transfers across network domain boundaries.

[0160] The simplest system (A T and F t ), there is only one exit header per file, and the sender entity 6 must select the actual physical boundary control device to be used for exit when requesting an authorization token, so as to enable the use of the correct covert identifier information K.

[0161] It is also possible to add fields to the various tokens to provide further required criteria as desired by the user. For example, the boundary controller 3 is not able to determine the classification of a file, as it is unlikely that there is a mechanism in place to determine classification based on the payload.

[0162] For example, to allow for the 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 the user, and no such scheme has an ambiguous lifespan.

[0163] One such scheme creates 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 that has the same allowed values ​​as the classification value asserted by the sender.

[0164] 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

[0165] To implement this, the boundary controller must be instructed to compare pairs of encoded values ​​in the export header with a specific logical operation. In this case, A t :Classification≧L t :Classification.

[0166] 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.

[0167] Alternatively, to more easily and directly determine the intended gateway from the header, six bytes of the header can be used to allow direct identification of the border controller 3, as an example. These six bytes identify the MAC address of the border controller 3, which is a full six bytes (48 bits). To map this to a namespace such as that required by DNS, it is sufficient to hex-encode the byte values. For example, if the MAC address is represented in hexadecimal as "14-B3-1F-12-CB-E7," the DNS query would be "gw14B31F12CBE7.domain.tld," resolving the gateway's IP address based on the contents of the Exports header using locally determined conventions. The gateway does not perform any comparisons to this field, but uses it as part of the normal Authorized header in the hash calculations it performs as part of the authorization assurance process.

[0168] Various modifications of the above principles will occur to those skilled in the art. For example, in another embodiment of the present invention, authorization token A tHowever, it does not incorporate approved file parameters in the form of approved values, and there is no provision for file size or other criteria checks related to file parameters in, for example, CRA7, and therefore A t =<entropy factor> that provides a unique value for each required token element. The session ID is created by taking a one-way function of the permanent boundary controller ID (known to CRA7) and the authorization token. Then, the authorization token A t and session ID S i A release token is constructed from the file token F and sent to the sender entity 6. The sender entity then generates the file token F as described above. t =#(X,J,S i ), and in this particular embodiment, there is no local token, so this is called the authorization token A t In combination with this, in this example E=A t ||F t The export header is prepended to the payload X to be transferred across the boundary controller 3. In the most basic embodiment of the invention, only the most basic validation checks are performed at the boundary controller, and there are no checks performed against properties asserted by a central service. In this embodiment, there is significantly less CRA control of the files or payloads passing through the boundary controller 3. However, the boundary controller does have the ability to determine its K g A temporary key derived from the criterion F can be determined. t =F t ', it can be ensured that a signed export file with payload X is forwarded by the given boundary controller.

[0169] The function that generates the temporary key does not include HMAC, but may include another hash function such as simple Hash.

[0170] An alternative implementation of the scheme shown in Figure 6 splits the role of the sender 6 described above between the signer entity 13 and the sender entity 6, with the signer entity 13 being responsible for interacting with the CRA 7 and creating the export header, and the sender entity 6 being responsible for requesting the export header for the payload.

[0171] In an alternative embodiment where the payload is essentially anonymous, such as a network packet, the file token can be constructed without using the filename value J. F t =#(X,L t ,S i )

[0172] Alternatively, a fixed string J such as "PACKET" may be used in such applications.

[0173] In another embodiment, values ​​in the header can be used individually as parameters to a hash function. Similarly, portions of the header can be zeroed out before use. These approaches allow intermediate systems between the sender and the border control system to write certain portions of the header for administrative purposes that are independent of the export control scheme, and allow the export control scheme to enforce any necessary security consequences.

[0174] It is assumed that the sender entity has other suitable release controls known to those skilled in the art that must also be satisfied prior to signing and subsequent transfer of the payload.

[0175] It should be noted that the scheme does not specify how identification, authentication, and authorization between the various non-gateway parties is performed, as this is considered to be outside the scope of this invention, but the invention described herein assumes that this is completed well before any payload transfer requests are made.

[0176] All parameters may be sized differently than shown in the embodiments described herein, and the parameter sizes mentioned above are merely examples and should not be considered limiting features of the present invention.

[0177] Alternatively, in use, the system may be an integral component within a computing device.

[0178] Alternatively, the system may be a modular component of a network infrastructure that ensures self-authorized and secure transfer of payloads between network nodes.

[0179] In a further embodiment of the present invention, the payload characteristic is simply the time required at which the system will at least grant permission to be used for a limited period of time.

[0180] In another embodiment of the present invention, the file token is an authorization token F t =g(X,A t ,L t ,S i ), e.g., F t =#(X,A t ,L t ,S i ) Therefore, although the assurance scheme remains valid if additional information is incorporated into the calculation, this is likely to increase the processing effort without providing any significant benefit.

[0181] Generally, in the above-described embodiments of the present invention, the first network 8 is a trusted network and the second network 9 is a less trusted network, however, in further embodiments of the present invention, the payload may be an import payload in the form of an import payload / file, and therefore the first network may be a less trusted network and the second network may be a trusted network.

[0182] The system has the following advantages: i. By eliminating the need to reconfigure payload forwarding criteria at the boundary controller, it eliminates the need to patch software located at the boundary controller; and ii. It eliminates the need to locally manage the boundary controller, thus providing the ability to use Shield for Life gateways maintained at factory settings. All of the above advantages can minimize the attack surface associated with the boundary controller at a local level. Because decisions are guaranteed to be defined and enforced at the CRA 7, the number of guarantable assertions at the boundary controller 3 can be advantageously reduced, allowing for a relatively immutable boundary controller that can provide stronger security capabilities than existing security devices. This security advantage is achieved by providing an agile apparatus and method in which the authorizer entity (CRA 7) provides the specification of authorization parameters remotely from the gateway, while eliminating the need for the boundary controller 3 to have knowledge of the decision-making process regarding preferred payload forwarding parameters.

[0183] The above-described embodiments of the present invention all enable the following advantages: Transmitters and gateways can be made highly scalable and highly available. · CRA (with sensible ticket book validity periods) does not require high availability. · Keys are highly sensitive and can be stored very securely. Session IDs are moderately sensitive and do not pose a long-term risk as they are periodically expired. Careful selection of export header content can optimize efficiency for practical applications.

Claims

1. 1. A payload assurance system for a payload X having a header H to be transferred across a network boundary via at least one predetermined boundary control device, comprising: at least one computer processor and at least one data storage device, said at least one data storage device including instructions operable by said at least one computer processor to provide an electronic authorization token authorizing characteristics of said payload to be transferred, said electronic authorization token including at least one entropy factor to ensure that multiple electronic authorization tokens authorizing the same payload characteristics are unique; A payload assurance system comprising:

2. a plurality of separate and distinct electronic entities including at least one authorizer entity, at least one sender entity, and at least one boundary controller; The payload assurance system of claim 1 .

3. the authorizer entity is configured to create a temporary identity for a given boundary controller using the electronic authorization token and permanent identity information associated with the given boundary controller; The payload assurance system of claim 2 .

4. the permanent identity information of each boundary control device in the system is stored in the authorizer entity; The payload assurance system of claim 3 .

5. the at least one authorizer entity is configured to transfer the temporary identity to the sender entity upon request; 5. The payload assurance system according to claim 3 or claim 4.

6. the sender entity is configured to create an export or import header according to the temporary identity to be forwarded to the border control device; The payload assurance system of claim 5 .

7. and further comprising at least one signer entity, the signer entity being arranged to communicatively mediate between the at least one authorizer entity and the at least one sender entity so as to prevent the at least one sender entity from communicating directly with the authorizer entity. A payload assurance system according to any one of claims 2 to 4.

8. the authorizer entity is configured to transfer the temporary identity to the signer entity upon request; A payload assurance system according to claim 7 when dependent on claim 3 or claim 4.

9. the signer entity is configured to create an export or import header according to the temporary identity and then forward the export or import header to the sender entity; The payload assurance system of claim 8.

10. the sender entity is configured to add the export or import header to the payload to form an export payload, and then forward the export payload to the predetermined border control device; A payload assurance system according to claim 6 or claim 9.

11. the export or import payload header further includes a local token that defines local characteristics of the payload to be transferred; The payload assurance system of claim 10.

12. the authorizer entity is configured to provide a temporary identity of the boundary control device according to the electronic authorization token and the permanent identity information of the given boundary control device by implementing a one-way mathematical function; A payload assurance system according to any one of claims 3 to 11.

13. the one-way mathematical function comprises an HMAC with an associated private key; The payload assurance system of claim 12.

14. the private key includes the permanent identity information of the given boundary control device; The payload assurance system of claim 13.

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

16. The border control device includes a comparator configured to directly or indirectly identify the electronic authorization token in the export or import payload header upon receiving a payload to be exported or imported, and generate a temporary identity according to the electronic authorization token and its locally stored permanent identity information; A payload assurance system according to any one of claims 2 to 15.

17. the comparator is configured to directly or indirectly compare the temporary identity generated at the at least one authorizer entity with the comparator temporary identity generated at the at least one boundary control device to determine whether they are identical; 17. The payload assurance device of claim 16.

18. the comparator is further configured to compare other control criteria included in the export or import payload header to ensure they are within predetermined limits.

18. The payload assurance device of claim 17.

19. The comparator i. the generated temporary identity is the same as the comparator temporary identity, and ii. The other export or import header control criteria are within the predetermined limits; 20. The payload assurance system of claim 18, configured to determine a positive boundary control outcome if

20. the border controller is configured to forward payload X having associated header H across a network / domain boundary through the border controller if a positive boundary control result is met; 20. The payload assurance system of claim 19.

21. the boundary control device is configured to prohibit the payload X having the associated header H from crossing a network / domain boundary and / or to allow the payload X to be discarded if a positive boundary control result is not met.

20. The payload assurance system of claim 19.

22. a random or pseudo-random number generator that provides the entropy component of the electronic authorization token; 22. A payload assurance system according to any one of claims 1 to 21.

23. The electronic authorization token is publicly known; 23. A payload assurance system according to any one of claims 1 to 22.

24. 24. Forwarding an export payload X having a header H across the network boundary comprising a payload assurance system according to any one of claims 1 to 23. An export control system comprising:

25. 1. A method of securing a payload for transfer across a network boundary via a boundary control device using a system comprising at least one computer processor and at least one data storage device, the at least one data storage device comprising instructions operated on by the at least one computer processor, the method comprising providing an electronic authorization token configured to authorize the payload to be transferred, the electronic authorization token comprising at least one element related to characteristics of the payload and at least one entropy element that ensures that multiple electronic authorization tokens authorizing the same payload characteristics are unique. A method characterized by:

26. the system further comprising at least one authorizer entity and at least one sender entity configured to communicatively mediate between the authorizer entity and the boundary controller, the method further comprising creating a temporary identity for the given boundary controller using the electronic authorization token and permanent identity information associated with the given boundary controller.

26. The method of claim 25.

27. and providing a temporary identity of the given boundary controller according to the electronic authorization token and the permanent identity information of the given boundary controller by implementing a one-way mathematical function.

27. The method of claim 26.

28. the one-way mathematical function comprises an HMAC with an associated private key; 28. The method of claim 27.

29. the private key includes the permanent identity information of the given boundary control device; 29. The method of claim 28 when dependent on claim 26 or 27.

30. storing the permanent identity information of each boundary control device in the system in the authorizer entity; 30. The method of any of claims 26 to 29.

31. prohibiting the sender entity from accessing the permanent identity information.

30. The method of claim 26 or 29.

32. the authorizer entity forwards the temporary identity to the sender entity upon request, and the sender entity subsequently creates an export or import header according to the temporary identity; 32. The method of any one of claims 26 to 31.

33. the system further comprises a signer entity, wherein the authorizer entity, upon request, forwards the temporary identity to the signer entity, the signer entity subsequently creating an export or import header according to the temporary identity, and subsequently forwarding the export or import header to the sender entity; 32. The method of any one of claims 26 to 31.

34. providing the temporary identity of the given boundary controller in the export or import header.

34. The method of claim 32 or 33.

35. at the sender entity, adding the export or import header to the payload, respectively, to create an export or import payload with header H, and then forwarding the export or import payload with header H to the predetermined border control device.

35. The method of claim 34.

36. providing local characteristics of the payload to be transferred in the export or import header; 36. The method of any of claims 32 to 35.

37. The method further includes, when receiving the export or import payload having a header H at the border control device, identifying the authorization token in the export or import payload header, and creating a comparator temporary identity according to the authorization token and the permanent identity information stored locally on the border control device.

37. The method of any of claims 32 to 36.

38. and further comprising directly or indirectly comparing the temporary identity generated at the authorizer entity with the comparator temporary identity generated at the boundary controller to determine whether they are identical.

38. The method of claim 37.

39. the comparator is further configured to compare other control criteria included in the export or import header to ensure they are within predetermined limits.

39. The method of claim 38.

40. i. the temporary identity generated at the authorizer entity is the same as the comparator temporary identity generated at the boundary control device, and ii. The other export or import header control criteria are within the predetermined limits; determining a positive boundary control result in the case, 40. The method of claim 39.

41. when the positive boundary control result is satisfied, forwarding the payload X with the associated header H across a network / domain boundary through the boundary control device.

41. The method of claim 40.

42. if a positive boundary control result is not met, prohibiting passage of the payload X with the associated header H and / or enabling discard of the payload X.

41. The method of claim 40.

43. randomly or pseudo-randomly generating a value to provide the entropy component of the electronic authorization token; 43. The method of any of claims 25 to 42.

44. The lifetime of the electronic authorization token is set to T so that the authorization is determined to be valid over the lifetime of the electronic authorization token. S1 ≦T t ≦T S2 including determining as follows:

43. The method of any of claims 25 to 42.

45. The respective export or import period is set to T such that the export or import of the payload X is allowed only if the export or import period is satisfied. M1 ≦T t ≦T M2 including determining as follows:

44. The method of any of claims 25 to 43.

46. calibrating and / or agreeing on a time reference between said authorizer entity and said at least one predetermined boundary control device; 46. ​​The method of any of claims 26 to 45.

47. 25. A system for securing a payload for transfer from an untrusted network to a trusted network (or vice versa) according to any one of claims 1 to 24. A computing device characterized in that:

48. 25. A system for securing a payload for transfer from an untrusted network to a trusted network (or vice versa) according to any one of claims 1 to 24. A network characterized by:

Images