Patent Description:
Information transfer across networks between different domains having various security levels is commonplace. The need for an interface that provides the ability to manually or automatically access and transfer information between domains without jeopardizing the data is becoming more important. A cross-domain approach provides the ability to manually or automatically access or transfer information between two or more different domains. These approaches offer integrated hardware and software that enable information transfer among incompatible security domains, allowing commercial, intelligence, and law enforcement operations to depend on the timely sharing of information. A cross-domain approach allows an isolated, critical network to exchange information with other networks and users without introducing a security threat that normally comes from network connectivity.

End-to-end encryption is a potential cross-domain approach, but network routers may be limited in their capacity to route fully encrypted data, since the endpoint addresses in the payload are also encrypted. To maintain efficient routing in many cross-domain information transfer systems, data payloads are encrypted, but the data addresses and destinations are not encrypted. As a result, packets in these systems are vulnerable to traffic flow analysis. An efficient cross-domain approach allows an isolated critical network to exchange information without introducing the security threats that normally come from network connectivity. Three elements that are common in cross-domain approaches may include: <NUM>) data confidentiality imposed by hardware-enforced, one-way data transfer; <NUM>) data integrity using filtering for viruses and Malware, including content examination utilities and high-to-low security transfer audited human reviews; and <NUM>) data availability provided by security-hardened operating systems, role-based administration access, and redundant hardware.

For example, a cross-domain information transfer system for transferring data from a low to high security domain may include an anti-virus scanning before transfer. Transfer from high to low security domains, however, usually requires complex data analysis, including time-consuming human review, where individuals examine and prove a document before release. One-way data transfer systems, such as data diodes, are sometimes used to move information from low security domains to higher security enclaves, while ensuring information will not escape. Some cross-domain approaches may include a high assurance guard, for example, a multilevel secure device that communicates between different security domains and runs multiple virtual machines or physical machines.

One or more subsystems may be included for a lower classification, and one or more subsystems may be included for a higher classification. Some devices operate an acknowledgment management software system that examines data and rejects higher classified data. These devices, however, may require complex and computationally intensive digital signature algorithms and may not be computationally efficient, and for this reason, often they are not implemented with battery-operated devices, e.g., radios used by first responders or by other commercial operators.

Document XP055632415 discloses an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality.

Document <CIT> discloses cryptographic key distribution techniques to be used in large computer networks. The techniques require trusted key release agent systems in each security domain. The encryptor of a data message nominates the set of authorized decryptors, using a set of access control attributes recognized by a key release agent in a target security domain. Data enabling the message decryption key and the access control attributes to be recovered are sent to the decryptor in an access controlled decryption block, which is encrypted under a separate key. The access controlled decryption block can only be decrypted by a key release agent in the correct security domain. The key release agent recovers the decryption key and supplies it to an authorized decryptor, which allows the decryptor to recover the original data message.

Document XP055730256 discloses an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD <NUM>) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

The invention is denned in the independent claims.

In general, a cross-domain information transfer system may include a key distribution center configured to generate a plurality of private encryption keys, and a respective signature key pair for an attribute from among a plurality of different attributes. Each attribute may be associated with a given domain among a plurality of different domains, and each signature key pair may comprise a secret signing key and a secret verifying key. A sender device may be configured to receive a respective private encryption key and generate ciphertext from plaintext based upon the private encryption key, append a respective attribute for a given domain to the ciphertext, receive a respective signing key and generate ciphertext with a concealed attribute from the ciphertext with the appended attribute based upon the secret signing key, and broadcast the ciphertext with the concealed attribute through an untrusted network.

A plurality of domain gateway devices are in communication with the untrusted network. Each domain gateway device may have a respective attribute associated therewith and configured to receive a respective secret verifying key, receive the ciphertext with the concealed attribute from the untrusted network, and use the secret verifying key to determine if the concealed attribute matches the attribute associated with the domain gateway device, and, when so, pass the ciphertext to at least one receiver device coupled with the domain gateway device.

In some embodiments, the plurality of different domains may have different security levels associated therewith. At least one receiver device may be configured to decrypt the ciphertext into plaintext based upon the private encryption key. Each attribute may comprise a binary attribute. Each private encryption key may be based upon an Advanced Encryption Standard (AES). Each signature key pair may be based upon an the Elliptic Curve Digital Signature Algorithm (ECDSA). The sender device may be configured to process information to generate multiple broadcasts to different domains.

Another aspect is directed to a method of cross-domain information transfer that may comprise operating a sender device to receive a respective private encryption key and generate ciphertext from plaintext based upon the private encryption key, append a respective attribute for a given domain to the ciphertext, receive a respective signing key and generate ciphertext with a concealed attribute from the ciphertext with the appended attribute based upon the secret signing key, and broadcast the ciphertext with the concealed attribute. The method further includes operating a plurality of domain gateway devices, each domain gateway device having a respective attribute associated therewith. Operating each domain gateway device may comprise receiving a respective secret verifying key, receiving the ciphertext with the concealed attribute from the untrusted network, and using the secret verifying key to determine if the concealed attribute matches the attribute associated with the domain gateway device, and, when so, pass the ciphertext to at least one receiver device coupled with the domain gateway device.

The present description is made with reference to the accompanying drawings, in which exemplary embodiments are shown. However, many different embodiments may be used, and thus, the description should not be construed as limited to the particular embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete.

Referring initially to <FIG>, a cross-domain information transfer system is illustrated generally at <NUM> and includes a Key Distribution Center (KDC) <NUM> that is configured to generate a plurality of private encryption keys <NUM>, given the designation pk<NUM>,<NUM>,<NUM>, i.e., the first private encryption key corresponding to pk<NUM>. The Key Distribution Center also generates a respective signature key pair <NUM> for an attribute <NUM> from among a plurality of different attributes, with each attribute associated with a given domain among a plurality of different domains <NUM>.

In <FIG>, attributes <NUM> are each designated with the letter "A" and a subscript numerical indicia, indicating a separate attribute, such as A<NUM>, A<NUM>, and A<NUM>. Each signature key pair <NUM> includes a secret signing key 26a and a secret verifying key 26b. In this example, each signing key 26a is given a designation ski with a numerical indicia as a subscript for each individual secret signing key, such as sk<NUM>, sk<NUM>, and sk<NUM>, and each secret verifying key 26b is given a designation vki with a numerical subscript, such as vk<NUM>, pk<NUM>, and vk<NUM>. Three different domains <NUM> are illustrated, e.g., a Level One domain 32a, Level Two domain 32b, and a Level Three domain 32a.

A sender device <NUM> includes basic components of a processor 37a and transceiver 37b, and is configured to receive a respective private encryption key <NUM>, e.g., pki, and generate ciphertext (CT) <NUM> from plaintext (PT) <NUM> based upon the private encryption key. The private encryption key <NUM> may be a symmetric key enabling block cipher encryption to form the ciphertext <NUM>. As illustrated in greater detail in <FIG>, the sender device <NUM> appends (CT || Ai) 37c a respective attribute (Ai) for a given domain <NUM>, such as the Level Three domain 32c, to the ciphertext <NUM>. As will be explained in greater detail below, the sender device <NUM> receives a respective secret signing key 26a and generates the ciphertext <NUM> with one or more concealed attributes <NUM> (X<NUM>, X<NUM>, X<NUM>) from the ciphertext based upon the secret signing key.

Referring again to <FIG>, the sender device <NUM> broadcasts the ciphertext <NUM> (CT) with one or more concealed attributes <NUM>, e.g., CT and X<NUM>, X<NUM>, and X<NUM>, to an untrusted network <NUM>. A plurality of domain gateway devices <NUM> are in communication with the untrusted network <NUM>. Each domain gateway device <NUM> has a respective attribute <NUM> (A<NUM>, A<NUM>, and A<NUM>) associated therewith and receives a respective secret verifying key 26b, and receives a ciphertext <NUM> with the concealed attribute <NUM> from the untrusted network <NUM>. As will be explained in greater detail below, each domain gateway device <NUM> uses its secret verifying key 26b to determine if the concealed attribute <NUM> matches the attribute associated with the domain gateway device, and, when so, passes the ciphertext <NUM> to at least one receiver device <NUM> coupled with the domain gateway device. Three domain gateway devices <NUM> are illustrated with the first domain gateway device 50a associated with the Level One domain 32a, and the Level Two and Level Three domain gateway devices 50b, 50c associated with the respective domains 32b, 32c.

Each domain <NUM> has at least one receiver device <NUM> that is configured to decrypt the ciphertext <NUM> into plaintext <NUM> based upon the private encryption key <NUM>, such as the pk<NUM> that the receiver device <NUM> in the top secret domain employs. The corresponding secret verifying key 26b (vk<NUM>) had been transmitted to that third domain gateway device 50c, which operates as the gateway for the top secret domain 32c and any receiver devices <NUM> contained in that top secret domain. Each domain gateway device <NUM> may include a processor 54a and transceiver 54b as shown in the larger block diagram of the Level Three domain gateway device 50c. Each receiver device <NUM> may include a processor 60a and transceiver 60b associated therewith as shown in the enlarged block diagram of the receiver device associated with the Level Three domain 32c and connected to the Level Three domain gateway device 50c. The sender device <NUM> is configured to process information and generate multiple broadcasts to different domains <NUM>, such as showing the three transmissions to the domain gateway devices 50a, 50b, 50c in <FIG>.

In an example, the private encryption key <NUM> may be based upon an Advanced Encryption Standard (AES) and the signature key pair <NUM> may be based upon an Elliptic Curve Digital Signature Algorithm (ECDSA). Each attribute <NUM> may include a binary attribute, such as illustrated by the Ai (<NUM> or <NUM>) (<FIG>), and used to form the concealed attribute Xi where the attribute is appended to the ciphertext <NUM>, i.e., CT || Ai at 37c.

Referring to <FIG>, a domain gateway device <NUM> may have two verifications 70a, 70b as will be explained in greater detail below, for example, based on appending to the ciphertext (CT) <NUM> a logical <NUM> in the first verification i.e., CT || <NUM> at 71a. When a binary <NUM> is obtained after the secret verifying key 26b is applied in the first verification 70a, the domain gateway device <NUM> would not pass the ciphertext <NUM> to at least one receiver device <NUM> coupled with the domain gateway device <NUM>. If a logical <NUM> is obtained after appending a logical <NUM> to the ciphertext <NUM> in the second verification 70b, i.e., CT || <NUM> at 71b, and verifying with the secret verifying key 26b, then the ciphertext is passed to at least one receiver device <NUM> coupled with the respective domain gateway device <NUM>.

Referring now to the block diagram of <FIG> for the cross-domain information transfer system <NUM>, more than one sender device <NUM> may be used, e.g., sender devices labeled V, W, X, Y, and Z, with each sender device receiving a respective private encryption key pki <NUM> for generating ciphertexts <NUM> from plaintext <NUM> based upon a received private encryption key. Each sender device <NUM> will append a respective attribute <NUM> for a given domain <NUM> to the ciphertext <NUM> and receive a respective secret signing key ski 26a and generate ciphertext with a concealed attribute <NUM> from the ciphertext based upon the secret signing key. Each sender device <NUM> broadcasts its ciphertext <NUM> with the concealed attribute <NUM> through the untrusted network <NUM> to each of the domain gateway devices <NUM>. Each domain gateway device <NUM> has already received its respective secret verifying key vki 26b and receives the ciphertext <NUM> with the concealed attribute <NUM> from the untrusted network <NUM> and uses the secret verifying key to determine if the concealed attribute <NUM> matches the attribute associated with the domain gateway device <NUM>, and, when so, pass the ciphertext <NUM> to at least one receiver device <NUM> coupled with the domain gateway device <NUM>. Each domain <NUM> may have more than one receiver device <NUM>, such as shown in the Level Three domain 32c and Level One domain 32a, each shown with two receiver devices (ATS, BTS and Ec, Fc) respectively.

Referring now to <FIG>, there is illustrated a flowchart showing a sequence of steps that may be used for operating the cross-domain information transfer system <NUM> as shown in <FIG>, with the method indicated generally at <NUM>. The process starts at Block <NUM>. The sender device <NUM> receives a respective private encryption key <NUM> (Block <NUM>). The sender device <NUM> generates ciphertext <NUM> from plaintext <NUM> based upon the private encryption key (Block <NUM>). The sender device <NUM> appends a respective attribute <NUM> for a given domain <NUM> to the ciphertext <NUM> (Block <NUM>), receives a respective secret signing key 26a (Block <NUM>), and generates ciphertext with a concealed attribute <NUM> from the ciphertext with the appended attribute based upon the secret signing key 26a (Block <NUM>). The sender device <NUM> broadcasts the ciphertext <NUM> with the concealed attribute <NUM> (Block <NUM>). Each domain gateway device <NUM> receives a respective secret verifying key 22b (Block <NUM>) and receives the ciphertext <NUM> with the concealed attribute <NUM> from the untrusted network <NUM> (Block <NUM>). The secret verifying key 26b is applied to the concealed attribute <NUM> (Block <NUM>) and a determination made if there is a match of the attribute <NUM> associated with the respective domain gateway device <NUM> (Block <NUM>). If no, the domain gateway device <NUM> will not pass the ciphertext <NUM> to at least one receiver device <NUM> coupled with the domain gateway device <NUM> (Block <NUM>), and the process ends (Block <NUM>). If yes, then the domain gateway device <NUM> passes the ciphertext <NUM> to at least one receiver device <NUM> coupled with the domain gateway device <NUM> (Block <NUM>) and the process ends (Block <NUM>).

The cross-domain information transfer system <NUM> as described has security benefits because a domain gateway device <NUM> may not determine the plaintext <NUM> because it lacks the private encryption key <NUM> and it may not determine any attribute <NUM> value that is not its own because it does not have the secret verifying key 26b that belongs to other respective domain gateway devices. A domain gateway device <NUM> may not forge or offer altered ciphertexts <NUM> or concealed attributes <NUM> because it lacks the secret signing key 26a used to form the concealed attributes and cannot deduce the secret signing key as a digital signature. An intruder may not determine the plaintext <NUM> because the intruder lacks the private encryption key <NUM> and may not determine the value of any attribute <NUM> because the intruder lacks any secret verifying keys 26b. The intruder may not forge or alter ciphertexts <NUM> or concealed attributes <NUM> because the intruder lacks the secret signing key 26a.

The cross-domain information transfer system <NUM> as described is applicable to various applications, including the communication of sensitive sensor data over heterogeneous networks. For example, in a commercial airline, the flight control data could be sent to a sensitive domain in the aircraft, such as a pilot navigation system, while a more limited set of flight control data may be sent to a less secure domain as part of an in-flight entertainment system for displaying the location of the aircraft to the passengers.

In operation, a sender device <NUM> generates a sensitive message as plaintext <NUM> and using a symmetric or block cipher, i.e., the private encryption key pki <NUM>, and generates in its processor 37c a ciphertext <NUM> from the plaintext. As shown in the example of <FIG>, the sender device <NUM> attaches one or more Boolean-valued attributes <NUM> to the ciphertext <NUM> at CT || Ai 37c and conceals the attribute values using the secret signing key ski 26a as described in greater detail below.

A domain gateway device <NUM> receives the ciphertext <NUM> along with the attached, concealed attributes <NUM>. A particular receiver device <NUM> has the secret verifying key 26b to process the ciphertext <NUM> and attached concealed attributes <NUM> to learn the true/false value of a particular attribute. The domain gateway device <NUM> cannot learn the true/false value of any attribute <NUM> for which that particular domain gateway device is not authorized, i.e., it does not have the particular secret verifying key 26b. As a result, a domain gateway device <NUM> cannot correctly attach any concealed attributes <NUM> to any ciphertexts <NUM>. A domain gateway device <NUM> cannot learn any plaintext.

An intruder or hacker to the system <NUM> cannot learn any plaintext <NUM> since the intruder does not have the private encryption key <NUM> and cannot correctly attach any concealed attributes <NUM> to any ciphertexts <NUM>. An intruder cannot learn the true/false values of any attributes <NUM>. If an intruder alters a ciphertext <NUM> and/or its concealed attributes <NUM>, it will not be possible for any domain gateway device <NUM> to learn the attribute values and as a result, the intruder's attack becomes, in effect, a denial-of-service attack. That attack, however, does not break the security of the system <NUM>.

As noted before, the encryption protocol for the signature key pair <NUM> includes the secret signing key 26a and secret verifying key 26b and relies on a digital signature algorithm, e.g., the Elliptic Curve Digital Signature Algorithm (ECDSA) defined in FIPS PUB <NUM>-<NUM> Digital Signature Standard (DSS) with Curve P-<NUM>. As noted before, the private key may use an Advanced Encryption Standard (AES) such as AES-<NUM>-GCM (Galois/Counter Mode) and combines Galois field multiplication with a counter mode of operation for block ciphers.

The Key Distribution Center (KDC) <NUM> is a trusted key source generating the private encryption key <NUM> and a signature key pair <NUM> for each attribute Ai, i.e., the secret signing key 26a (ski) and secret verifying key 26b (vki). Both the secret signing key 26a and the secret verifying key 26b are both maintained secret. The secret verifying key 26a in this system <NUM> is not made public, as is often the case for signature key pairs. The key distribution center <NUM> securely sends each attribute's secret signing key 26a to each sender device <NUM>. The key distribution center <NUM> securely sends each attribute's secret verifying key 26b to each domain gateway device <NUM> that is authorized to learn the true/false value of that attribute <NUM> corresponding to a specific domain <NUM> when a binary attribute is used.

A sender device <NUM> may generate a ciphertext <NUM> (C) and determine the value of each attribute Ai, and may generate each concealed attribute Xi as follows:
If the value of Ai is false:.

The sender device <NUM> attaches the concealed attributes Xi to the ciphertext <NUM> (C) and transmits the message. With ECDSA/P-<NUM>, each concealed attribute <NUM> as a signature occupies <NUM> bits = <NUM> bytes. A domain gateway device <NUM> receives a ciphertext <NUM> (C) along with its attached concealed attributes Xi. The domain gateway device <NUM> that contains the complement secret verifying key 26b to the secret signing key 26a is authorized to learn the true/false value of a particular attribute Ai when a binary attribute is used. The domain gateway device <NUM> operates as follows:.

Because no domain gateway devices <NUM> or intruder has the private encryption key <NUM> used to generate the ciphertexts <NUM>, no other domain gateway device <NUM> or intruder, such as a hacker, can learn the plaintexts <NUM>.

If a domain gateway device <NUM> or intruder is not authorized to learn the true/false value of Ai, then that domain gateway device or intruder will not have vki as the secret verifying key 26b, and that domain gateway device or intruder will not be able to carry out the above computation. If an intruder tries to learn the value of an attribute <NUM> using the wrong secret verifying key 26b, both signature verifications for Xi will fail.

Because no domain gateway device <NUM> or intruder, such as a hacker, has the secret signing key ski for any attribute, no domain gateway device <NUM> or intruder can generate a correct concealed value Xi for any attribute <NUM>. Also, it is not possible to derive the secret signing key ski 26a from the secret verifying key vki 26b. If an intruder tries to generate Xi using the wrong secret signing key ski 26a, then both signature verifications for Xi will fail. If an intruder alters a ciphertext <NUM> (C) or a concealed attribute Xi, both signature verifications for Xi will fail.

Because the ECDSA algorithm used for the signature key pair <NUM> includes a random ephemeral value in every signature computation, the concealed attribute value Xi may be different in every message, even if the attribute value Ai is the same. Therefore, no intruder or domain gateway device <NUM> not having the secret verifying key 26b for the attribute <NUM> will be able to correlate the concealed attribute values with the actual attribute values.

There now follows an example description for a sensitive document distribution. In this example, the ciphertexts <NUM> are encrypted sensitive documents. There are four Boolean attributes: <NUM>) an A1 document may be sent to a Level One domain as a network; <NUM>) an A2 document may be sent on a Level Two domain as a network; <NUM>) an A3 document may be sent on a Level Three domain as a network; <NUM>) an A4 document may be sent on another level domain, with a special access program as a network.

The sender devices <NUM> create documents as ciphertexts <NUM>. A sender device <NUM> that creates a document at a particular secrecy level attaches concealed attributes to the ciphertext as follows:.

The domain gateway devices <NUM> operate with the receiver devices for the domains <NUM> as networks. Each domain <NUM> as a network has a security level. A specific domain gateway device <NUM> for a device <NUM> determines whether a specific document is allowed to be sent on a specific domain as a network. The domain gateway device <NUM> receives and processes data within its processor 54a and determines the true/false value of the attribute <NUM> associated with the secrecy level of the specific domain <NUM> and allows the document to be sent on the domain <NUM> as the network only if the attribute is true.

In this example, multi-valued attributes may be used so that a number of attributes may be used, i.e., A<NUM>, A<NUM>, A<NUM>, etc. The technique as described can be extended to attributes with "N" possible discrete values (N > <NUM>). To create a concealed attribute, sign (C || <NUM>), (C || <NUM>), (C || <NUM>),. or (C || N-<NUM>) as appropriate. Determining the actual attribute value from the concealed attribute value takes longer, e.g., up to N signature verifications may have to be performed. In some cases, it may be possible to apply functional/homomorphic encryption.

Claim 1:
A cross-domain information transfer system (<NUM>) comprising:
a key distribution center (<NUM>) configured to generate a plurality of private encryption keys (<NUM>), and a respective signature key pair (<NUM>) for each attribute (<NUM>) from among a plurality of different attributes, each attribute associated with a given domain (<NUM>) among a plurality of different domains (<NUM>), and each signature key pair (<NUM>) comprising a secret signing key (26a) and a secret verifying key (26b);
a sender device (<NUM>) comprising a processor (37a) and a transceiver (37b) coupled thereto, and configured to receive a respective private encryption key (<NUM>) and generate ciphertext (<NUM>) from plaintext (<NUM>) based upon the private encryption key (<NUM>), append a respective attribute (<NUM>) for a given domain to the ciphertext, receive a respective secret signing key and generate ciphertext (<NUM>) with a concealed attribute (<NUM>) from the ciphertext (<NUM>) with the appended attribute based upon the secret signing key (26a), and broadcast the ciphertext (<NUM>) with the concealed attribute (<NUM>) through an untrusted network (<NUM>); and
a plurality of domain gateway devices (<NUM>) in communication with the untrusted network (<NUM>), wherein the plurality of different domains has different security levels associated therewith, each domain gateway device (<NUM>) comprising a processor (54a) and a transceiver (54b) coupled thereto, and having a respective attribute associated therewith and configured to :
receive a respective secret verifying key (26b),
receive the ciphertext (<NUM>) with the concealed attribute (<NUM>) from the untrusted network (<NUM>), and
use the secret verifying key (26b) to determine if the concealed attribute (<NUM>) matches the attribute (<NUM>) associated with the domain gateway device (<NUM>), and, when so, pass the ciphertext (<NUM>) to at least one receiver device (<NUM>) coupled with the domain gateway device (<NUM>), wherein the at least one receiver device (<NUM>) comprising a processor (60a) and a transceiver (60b) coupled thereto, is configured to decrypt the ciphertext (<NUM>) into plaintext (<NUM>) based upon the private encryption key (<NUM>).