WO2005119462A1 - Dispositif multiniveau de transfert securise d'informations - Google Patents

Dispositif multiniveau de transfert securise d'informations Download PDF

Info

Publication number
WO2005119462A1
WO2005119462A1 PCT/AU2005/000773 AU2005000773W WO2005119462A1 WO 2005119462 A1 WO2005119462 A1 WO 2005119462A1 AU 2005000773 W AU2005000773 W AU 2005000773W WO 2005119462 A1 WO2005119462 A1 WO 2005119462A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
releaser
guard
network
server
Prior art date
Application number
PCT/AU2005/000773
Other languages
English (en)
Inventor
Peter Drewer
Peter Duffett
Maris Ozols
John Desborough Yesburg
Original Assignee
The Commonwealth Of Australia
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from AU2004902875A external-priority patent/AU2004902875A0/en
Application filed by The Commonwealth Of Australia filed Critical The Commonwealth Of Australia
Publication of WO2005119462A1 publication Critical patent/WO2005119462A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3265—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/76—Proxy, i.e. using intermediary entity to perform cryptographic operations

Definitions

  • This invention relates to a security device that provides services that facilitate the secure flow of information between different computer networks.
  • the device can provide these services in different ways depending on the particular architecture utilised.
  • Information is a valuable asset in many circumstances and organisations. As with any asset, access to it must be controlled in order to maintain its value. The risk of unauthorised access is related to the motivation for, and likelihood of, unauthorised access, and the severity of the consequences of such access. Most information systems (including computers, local area networks, and wide area networks) provide access control mechanisms, to prevent users from having unauthorised access to information.
  • owners of the information assets may consider that the protection offered by these information systems is sufficient.
  • a common form of additional protection is to provide a measure of physical isolation. By reducing opportunities for physical access to the information system, the likelihood of certain threat agents getting access to the information can be reduced. Further, if the information system's access control mechanisms happen to fail for any reason, the impact of the consequence will be reduced, because the information will only have leaked to a smaller, more trustworthy population.
  • System High means that only users who are authorised to access all information in an information system will be allowed to have physical access to (ie. be allowed in the same room as) that system. This means that if any access control mechanisms built into the system (such as login processes, access permissions on various files) were to fail, the worst that could happen would be that information may be disclosed to staff who were authorised to see it. Thus, although the system may have access control mechanisms built into it, there is no reliance on those mechanisms - technically the control mechanisms are not “trusted”.
  • the Wang/Getronics High Assurance Guard is a combination of the XTS-400 hardware and the STOP operating system it is described in the literature and at http://www.getronicsgov.com/solutions/information assurance /xts400 trusted sy s.htm
  • the Trusted Network Interface Unit (TNIU) work of Rushby and Randall has been described in IEEE Computer 16(7) pp 55-67, 1983, and is available at http:/ /www.cs.ncl.ac.uk/research/pubs/articles/papers/401.pdf
  • the TNIU or SNIU architecture allows multiple classifications of data to be communicated along a single network. Typically unclassified data will not be encrypted, but other data (ie. communication sessions) will be encrypted.
  • the untrusted host can be virtually connected to one or more other computers, all using TNIUs with common keys, and all sharing information at a similar level.
  • the present invention is different, because it allows not just untrusted hosts, but entire untrusted (albeit classified) networks. Then use is made of a collection of one or more devices that allow the isolation of a particular data element (which could be, a document, keystrokes, mouse movement information, or other), so that that element can be transferred to another network.
  • the device or devices acquire specific approval of one or more users for the transfer process. Then, it (or they) provides strong confidence that only the particular data element, and no other, is transferred.
  • the embodiment of the arrangement and function of the various devices would depend on a number oi factors including (a) the security policies of the various networks, (b) the architecture of existing systems, (c) processes and procedures in use, (d) the software in use on the different networks, and (e) the characteristics and amount of information that needs to be transferred between networks.
  • the following sections describe different aspects of the Trusted Information Release Architecture, and how it can be used (sometimes in conjunction with other similar or different devices or in a particular architecture) to provide particular services.
  • the architecture is comprised of ordinary untrusted computers, routers, servers, and other untrusted components, and selected trusted components including the following: • Information releaser devices • Guards • Quarantine Servers • Audit Servers • Audit Server Guards • Quarantine Server Guards • Automatic Information Labellers
  • an information releaser system 1 further includes; at least one information releaser guard connected to the one computer network each information releaser guard further connected to one or more other computer networks, operating according to a set of rules located within the information releaser guard to control the passage of information from the information releaser guard to one or more other computer networks.
  • an information releaser system further includes; a quarantine server connected to the one network arranged to receive information and other commands sourced from the information releaser device for processing that information into a representation of the information according to a set of rules located within the quarantine server that operate to control the processing applied by the quarantine server to the information, and communicating the processed information and other information relating to the processed information to the information releaser device.
  • an information releaser system further includes; a quarantine server guard connected to the one computer network that operates according to a set of rules located within the quarantine server guard to control the passage of information from the quarantine server guard received from the information releaser device and to the information releaser device from the quarantine server guard, and a quarantine server connected to the quarantine server guard to receive information and other commands sourced from the information releaser device and process the information according to a set of rules located within the quarantine server that operate to provide a representation of the information, and communicate the processed information to the quarantine server guard.
  • an information releaser system further includes: an audit server connected to the one network arranged to receive information from one or more devices in the one network for processing received information and other commands and recording one or more characteristics of the information and according to a set of rules located within the audit server which operate to control the processing applied by the audit server.
  • an information releaser system further includes: an audit server guard connected to the one computer network for receiving information and commands from one or more devices in the one network that operates according to a set of rules located within the audit server guard to control the passage of information from the audit server guard to the audit server and to the information releaser device from the audit server guard, and an audit server arranged to receive information from the audit server guard sourced from the information releaser device for processing that information and other commands from the information releaser device and recording one or more characteristics of the information according to a set of rules located within the audit server which operate to control the processing applied by the audit server.
  • an information releaser system further includes: an information releaser guard connected to the one computer network for receiving information from one or more selected information releaser devices and processing that information according to a set of rules located within the information releaser guard that operate to control the passage of information from the information releaser, a staging server for processing information according to a set of rules located within the staging server that operates to control the processing applied by the staging server on information received from a predetermined information releaser guard and to control the release of predetermined information from the staging server, and a further information releaser guard connected between the staging server and an other network, that operates according to a set of rules located within the information releaser guard to control the passage of information from the information releaser guard to the other computer network. Further wherein upon the receipt of a valid request for predetermined processed information from another network the staging server releases the processed information to the further information releaser guard.
  • a data diode is connected between the staging server and a predetermined other network arranged to permit the flow of information between the other network and the staging server but not between the staging server and the predetermined other network.
  • Fig.1 depicts a computer and peripherals connected to a trusted releaser device which in turn is connected to the same network as the user;
  • Fig. 2 depicts a computer and peripheral connected to a trusted releaser device that in turn is connected to the same network as the user and another network;
  • Fig. 2a depicts a computer and peripheral connected to a trusted releaser device that in turn is connected to the same network as the user and multiple other networks;
  • Fig. 3 depicts a computer and peripheral connected to a trusted releaser device that in turn is connected to the same network as the user and a guard on that same network that in turn is connected to another network;
  • Fig. 4 depicts a computer and peripheral connected to a trusted releaser device that in turn is connected to the same network as the user and an audit guard that is connected to an audit server and to a guard on that same network that in turn is connected to another network
  • Fig. 5 depicts a computer and peripheral connected to a trusted releaser device that in turn is connected to the same network as the user and quarantine server and to a guard on that same network that in turn is connected to another network;
  • Fig. 6 depicts a computer and peripheral connected to a trusted releaser device that in turn is connected via a VPN along the same network as the user to a quarantine guard and quarantine server and to a guard on that same network that in turn is connected to another network;
  • Fig. 7 depicts the use of a staging server that stores documents which have been processed by a first guard, and which will be released through a second guard at an appropriate time.
  • Fig. 8 depicts the use of a staging server that stores documents which have been processed by a first guard, and which can be released through a second guard to a low network when the staging server receives appropriate requests from that low network through a data diode.
  • Fig. 9 depicts the use of multiple desktop systems, each incorporating a computer, peripherals, and a information releaser device, with a single centralised guard.
  • Fig. 10 depicts the use of two separate (and yet still centralised) guards, each one providing a means by which appropriately labelled documents can he released to a different network.
  • Fig. 11 depicts the use of a physically separate network to connect the information releaser device, quarantine server, and guard.
  • Fig. 12 depicts a computer and peripheral connected to a trusted releaser device that in turn is connected to the same network as the user and an audit server on that same network and to a guard on that same network that in turn is connected to another network;
  • Fig. 13 depicts an automatic information labeller that is connected to label information flowing from a low network to a high network.
  • a user on one network may require that certain information (a document) be transferred (copied, or "released") to another network, known as the low network.
  • a document may be transferred (copied, or "released" to another network, known as the low network.
  • the high and low networks may be for example Australian Secret and Coalition Secret respectively.
  • the high and low networks may be for example Australian Secret and Australian Restricted respectively.
  • the user After reviewing the document, the user indicates whether the document is indeed suitable for transfer to the low network.
  • the overall security relies on a number of aspects.
  • a user on one network may want to perform interactive operations (such as logging on, or web browsing) on another network, known as a low network.
  • a user using this facility would be able to use interactive facilities including, for example, video conferencing, live chat, collaboration, and other services. Ideally, this would be achievable without the user having to leave their desk and single monitor, keyboard, and mouse.
  • the information releaser device is a per-user device within the trusted information release architecture. That is, there may be many of the devices on the network, as shown in figure 9. In contrast, the preferred embodiment would have a single centralised audit server, and quarantine server. Also, although there may be multiple guards for different low networks as shown in figure 10, they would also be centralised in the preferred embodiment. Centralisation offers advantages of improved physical security.
  • 5.3.1 Information releaser device contains a microprocessor.
  • the microprocessor is programmed to perform the functions of the device.
  • the microprocessor may use a COTS operating system or it may use a custom operating system that may or may not be trusted to the required levels applicable to the risk assessment and application. Additional levels of trust can be implemented in the physical and software domain as described in the following paragraphs.
  • 5.3.2 Information releaser device attaches to network. Requests for particular services may be sent to the device via the (high) network, or via another interface, such as serial, parallel, USB (Universal Serial Bus), SCSI (Small Computer System Interface), IEEE1394 (Firewire), or Bluetooth. It is also possible that the device could be installed as a card inside a computer, using for example a PCI bus connection.
  • Network or other communication required within or between elements described in this document may be implemented using wires, optical, radio frequency, or other technology.
  • wireless communications are used between any of the components described herein, the use of encryption may be appropriate. This encryption may make use of, or extend the use and scope of, cryptographic keys that are required for other aspects of the operation of the device or the architecture. 5.3.3 In ormation releaser device can preferably take over screen keyboard mouse.
  • the information releaser device is connected between the computer's video output and the monitor.
  • the information releaser device When the information releaser device is idle, it forwards video signals from the computer's video output through to the monitor. At times when the information releaser device requires user interaction, for example during document review, the information releaser device sends its own video signals to the monitor, and the computer's video signal is no longer displayed. When the interaction is complete, the information releaser device returns to the state in which it transfers the computer's video output to the monitor.
  • the keyboard and mouse can also be switched.
  • the keyboard and mouse are connected to the information releaser device, which is then connected to the computer's keyboard and mouse inputs.
  • information releaser device is idle, information from the keyboard and mouse is transmitted to the computer's keyboard and mouse inputs.
  • the information releaser device requires user interaction, information received from the keyboard and mouse is processed by the information releaser device, and not transmitted to the computer.
  • KVM switches Keyboard Video Mouse
  • KVM switches are typically controlled by keyboard data (such as pressing particular key combinations) or buttons on the KVM switch the information releaser device in its preferred embodiment controls the switch mode directly.
  • the information releaser device may switch additional input and output devices, such as microphones and speakers, in the same way as the keyboard, monitor, and mouse. 5.3.4 Information releaser device User Interface
  • the device preferably has a user interface, which may include LEDs, LCD, and one or more buttons or a keypad.
  • This user interface is a means by which the user and the device can communicate without risk of interference from the user's computer (which may, for security analysis purposes, be assumed to be hostile).
  • this user interface is a trusted path.
  • Information releaser device is evaluatable.
  • the device is preferably evaluatable to a high level (for example Common Criteria EAL7, ITSEC E6, or Orange Book Al), due to its limited functionality, simplicity, and special design features.
  • the device does not require frequent updates.
  • the device only executes software from ROM. It does not have a floppy disk drive or any other means for uncontrolled updating software (except by tampering with the case).
  • the information releaser device might allow code to be updated in a controlled way, perhaps through floppy disk or network or other connections, but only if the code is suitably signed.
  • the device's root public key can be used to verify the integrity of such software and the authority under which it is issued.
  • the information releaser device performs much simpler and fewer functions than the user's PC. For these reasons, it becomes cost effective to perform a very detailed evaluation on the device. This can provide owners (or delegated protectors) with a high level of confidence that use of the device will not cause a security breach.
  • Security authorities will usually require that the information releaser device will be tamper-evident and tamper resistant, and incorporate zeroise features.
  • the preferred embodiment of the device will have mechanisms that will unambiguously indicate to the user if it has been physically tampered with.
  • the information releaser device may have a zeroise mechanism which ensures that any records or the key are securely erased as soon as any tampering is detected.
  • That token may implement its own zeroise features.
  • Information releaser device might use a (preferably already evaluated) COTS (Commercial Off-The-Shelf) RTOS (Real Time Operating System), or have negligible OS (Operating System).
  • COTS Common Off-The-Shelf
  • RTOS Real Time Operating System
  • OS Operating System
  • the software for the device will not include a large general-purpose operating system like Windows or Unix. It may utilise a small operating system that has been designed for embedded systems. It may be that a certified secure operating system is used. Such a certified operating system may reduce the degree to which other sof ware written specifically for the device needs to be evaluated.
  • 5.3.8 Information releaser device may have a public key identity.
  • the public key (or more importantly, the root public key) must be protected against unauthorised modification.
  • a public key token such as a smart card or PCMCIA card.
  • the token may be locked in place physically to provide the necessary security.
  • the token may provide certain cryptographic operations (such as signing and encryption), which facilitate the maintenance of key security.
  • the device may perform various cryptographic operations such as encryption, decryption, hashing, signing, and verifying signatures, using a variety of services from the token.
  • signature verification may use the root public key from the token, but the actual cryptography may be performed in the device, rather than on the token.
  • signature verification may not be possible to retrieve the private key from the token, and hence signing and some cryptographic operations (including encryption, decryption, and creating and validating digital signatures) may need to be performed on the token.
  • the keys may be stored electronically in a form of non-volatile memory, with appropriate protection. 5.3.9 Information releaser device is retrof ittable.
  • the device offers security services, which may be of benefit to users.
  • the device can be added to a pre-existing network. Individual computers and other infrastructure within the network can be upgraded without detracting from the services provided by the device.
  • user's computers may have certain software installed.
  • the security of the system or network as a whole is not dependent upon the correct operation of that software, or of any aspect of the user's computer hardware or software.
  • the device may have a means by which a user can authenticate to it.
  • the authentication may use a password.
  • the preferred embodiment would simply use the keyboard attached as described in 5.3.3.
  • the information releaser device may incorporate a full keyboard or numeric keypad.
  • the authentication may use a token, such as a smartcard.
  • the information releaser device would have a token interface, such as a smartcard reader.
  • the authentication may use a biometric mechanism, such as a fingerprint.
  • the information releaser device would incorporate a biometric transducer, such as a fingerprint scanner, or an interface into which such a transducer can be connected.
  • the authentication may use a combination of the above techniques.
  • users may have cryptographic tokens such as smartcards for authentication and other services.
  • cryptographic tokens such as smartcards for authentication and other services.
  • Using one token in multiple systems of different classifications may create a risk of unauthorised covert information flow between these systems. For example, sensitive information from a high computer might be stored onto the card in such a way that it could be recovered by a computer on the low network.
  • the information releaser device might act as a proxy for various machines (eg. the user's PC on the low network, and the user's PC on the high network) to request services of the user's token, in order to minimise the possibility of covert channels via the token. By doing this, the information releaser device could remove, or at least reduce, the likelihood that the token may provide such a covert channel.
  • various machines eg. the user's PC on the low network, and the user's PC on the high network
  • the device may implement various locking and synchronisation mechanisms so that each client can "believe" it has exclusive access to the token.
  • the user's PCs would require modified token access libraries in order to use these facilities.
  • the token access libraries are typically trusted to some degree, it need not, in general, be to the same degree as would be required for a multilevel security device.
  • New (replacement) libraries provided for use with this device would not need to be evaluatable to the high levels (eg. EAL7) that apply to the device; they would typically only be required to meet the same level as the rest of the OS or application software (eg. EAL3 or EAL4).
  • the information releaser device is connected only to a single network, it may be advantageous to use the device as an interface to the user's token, as this will be able to provide higher assurance than the PC that no information is being inappropriately stored onto the token.
  • the information releaser device may take precautions to prevent even exceptional circumstances from resulting in contamination of the token. For example, when the PC requests encryption of certain information, the information releaser device could send that information to the token for encryption, receive the encrypted data, and then send new dummy information to the token to overwrite any potentially stored cleartext (and possibly also ask for this new dummy information to be encrypted).
  • the information releaser device might incorporate a keyboard, video, and mouse switching function.
  • a trivial extension of that function would allow the information releaser device to offer KVM-switch functionality, effectively thereby incorporating an Interactive Link Multiple Computer Switch
  • MCS Keyboard Switch
  • KBS Keyboard Switch
  • the device could be trivially extended to perform other security- critical tasks, if it is unacceptable for such tasks to be performed on an untrustworthy platform such as a PC.
  • the information releaser device is required to transform (or "render") a document into an image that a user can review.
  • this function is relatively simple.
  • word processor documents, databases, or spreadsheets the task may be more complex.
  • the requirement of having highly trustworthy software on the device is incompatible with the need to execute word processors, databases, spreadsheets, and other arbitrary software of unknown quality into the device.
  • file formats are proprietary, and not documented. New versions of the software and corresponding file formats are frequently released, and have only relatively short lifetimes. This means that developing highly trustworthy software to perform the rendering is not practical.
  • the Quarantine Server performs tasks like a Windows Terminal Server (and some Quarantine Server embodiments may incorporate an actual Windows Terminal Server).
  • the QS will assess the document to determine how it should be displayed. The appropriate software will be started, and the resulting display information passed back to the desktop device. Should user interaction be required, for example in order to select different pages of the document, to zoom in, to examine formulas within a spreadsheet, or other inspection activities that are required to assess a document's classification accurately, the desktop device will send keyboard and/ or mouse information to the QS to allow that interaction.
  • the device may set up a suitably secure channel with a quarantine server.
  • the device may pass keystroke and mouse movement information to the quarantine server, in the same way that a thin client sends information to a terminal server.
  • the quarantine server would start whatever program is necessary to render the document, and pass the display information back via the secure channel to the device.
  • the quarantine server may be configured to accept connections only from a specified set of devices, in order to reduce the possibility of the quarantine server being contaminated with low-integrity information and reducing the effectiveness of its rendering integrity.
  • the quarantine server may be configured to perform various checks on the information. Such checks may include scanning for suspicious or prohibited words.
  • the quarantine server may be configured to display the contents of a file in one or more specific ways, depending on its format. For example, it may list the formulas used in a spreadsheet, as well as the values. Or it may activate features in a word processor which display changes that have been tracked, words in the spelling dictionary, and details recorded about the people who have edited the file and the dates and times of such edits.
  • the quarantine server may indicate to the information releaser device exactly which ormat or formats were used when rendering the document, so that these details can be recorded in audit logs and signed labels if required.
  • the quarantine server may, in certain situations, be configured to make certain types of modifications to documents. For example, all formulas may be deleted from a spreadsheet, so that only the values can be exported. Or, all graphics may be deleted from a word processor document.
  • the quarantine server may, in some instances, be implemented using a system based on a commercial-grade operating system with lower trustworthiness than the device itself, in order to provide a means to render documents in proprietary word- processor (or other) file formats.
  • the quarantine server would be in a "locked down” or “hardened” configuration, with only a minimal set of services, and minimal access rights to non-administrative users.
  • a variant of the Guard may be used to ensure that only specified devices are able to connect to the quarantine server, as shown in figure 6. These specified devices would have to sign or otherwise authenticate and authorise information being transmitted to the Quarantine Server. The Quarantine Guard would not permit unauthenticated or unauthorised information to reach the Quarantine Server.
  • IPsec protocols such as AH and ESP as defined by the IETF in RFC2411 and related documents.
  • a quarantine server As such the basic elements of a quarantine server are a processor, memory for storing one or more applications and communications software and hardware for communicating with the trusted reviewer via the user's network as well as one or more other networks and network devices such as a guard and an audit server.
  • the Guard is a device that allows documents to pass from the high network to the (appropriate) low network, but only ii there is a valid label indicating that such a transfer has been approved by a valid user using a valid device.
  • the basic elements of a guard are a processor, a memory for storing one or more security policies and communications software and hardware for communicating with the trusted reviewer via the user's network as well as one or more other networks and network devices such as a quarantine server and an audit server.
  • a guard receives information arriving at the high network interface.
  • the guard checks to ensure that this information includes evidence that an authorised user or users have approved a document for release to the low network. This checking may involve the verification of one or more digital signatures, particularly those generated by information releaser devices.
  • a guard may be configured with a root public key that allows it to verify those signatures.
  • a guard may be configured with details of the classification of the low network, so that it can compare the assigned classification of a document with the classification of the low network, in order to decide whether the document should be released.
  • a guard may be configured to allow only certain portions of a network (for example classification-labelled paragraphs) to be transferred to the low network in accordance with a security policy.
  • a guard may be use a configuration or policy file which it receives from the high network after checking its validity using signature verification and other public key technology.
  • a configuration file could be created using untrusted elements, but approved (and thus signed) on a information releaser device.
  • a guard may pass all, some, or none of the document approval information to the low network with the document. For example, it may pass only the document, or it may pass the document and its classification, or it may pass the document and the entire signed label.
  • the guard may be configured with a policy so that, after checking the approval information, it removes that information and replaces it with different information that is exported to the low network.
  • the guard may receive a document with a classification and release approved by a particular user. Having checked the authority of that user to release the document, the signature of the information releaser device, and that the classification the user applied means that the document is appropriate to release to this particular low network, the guard will remove all of that information, and create a new signed label giving the classi ication with the authority of the network owner (rather than the individual user).
  • a guard may be configured to enforce a particular policy indicating which users, roles, or combinations of users or roles is authorised to release documents to different destinations.
  • the policy may permit different combinations of releasing officers for documents of different classifications, different types (perhaps only certain users are qualified to release documents of type "database", for example), different reviewing formats applied by a quarantine server, an indication of whether a quarantine server or "native" rendering was used, different times of day, different low networks, or other factors.
  • a guard may be configurable to operate as a Quarantine Guard or Audit Server
  • the guard In such a mode, the guard would receive information from the high network interface, check that the information has originated from a information releaser device, and then pass it to the other port (where there would be a Quarantine Server or Audit Server). Any response from the Quarantine Server or Audit Server would be authenticated by the guard and transmitted back to the information releaser device.
  • the proof ⁇ of-origin authentication used in such an arrangement may use proper digital signatures, or may use a session-key-based VPN, or may use a HMAC scheme as described in RFC2104 available from http: / / www.ietf.org/rfc/rfc2104.txt.
  • a guard may have similar tamper resistance and tamper evidence properties as described above in section 5.3.6.
  • a guard may be constructed to be evaluatable as described in section 5.3.5.
  • guards can also be used to protect elements such as Audit Servers and Quarantine Servers from integrity breaches.
  • the guard's function is to check that information arriving from the high network comes with appropriate authenticity information.
  • the guard may use network protocols that provide integrity protection through signatures or message authentication codes or hash message authentication codes.
  • the resulting secure channel can be described as a virtual private network (VPN). This mechanism is also used when the guard is employed for teleporting. In essence, the secure network protocol is simply a different format for a label.
  • An audit server is a centralised device that records details of documents released from the high network.
  • An audit server is a computer system with a network interface, processor, memory and long-term data storage facility.
  • Figure 12 is an illustration of how an audit server may be connected in a trusted information release architecture.
  • the audit server will receive details of approval for a document's release from a information releaser device.
  • the audit server will record these details in its long-term data storage facility.
  • the details may include the document's file name, creation date, creator, file size, and other Meta data.
  • the details may include the file itself.
  • the details may include information about the time and manner of user's approval, the information releaser device's identity, and the identity and various attributes of the user(s) approving the document's release.
  • the details may include information about which network(s) the document has been released to.
  • the details may include a label with one or more signatures.
  • the details may include information about filtering of the document, software versions used to display the document, and the identity of the quarantine server used to render the document for review.
  • the audit server may record additional details such as the date and time that the information was recorded.
  • the audit server may also record details of potentially security relevant events that occur at information releaser devices, quarantine servers, guards, or the audit server itself. Such events may include user authentications, failed user authentication attempts, device start-ups and shutdowns, device configuration changes, cancellation of document review processes by the user, arrival of unsuitably reviewed or labelled material at guards for transfer to other networks, and tamper indications.
  • the audit server may generate a signed receipt, for example according to the Enhanced Security Services (ESS) for Secure Multipurpose Internet Mail Extensions (S/MIME) RFC2634 of June 1999 available from http: / / ww.faqs.org/rfcs/rfc2634.html.
  • This receipt may be forwarded either to the information releaser device, or to the guard, as evidence that the audit record has been made.
  • Such a mechanism may be useful where the security policy requires that such evidence must be recorded before a signed label is created, or before a document is released to another network.
  • the audit server may enforce a policy of only accepting connections from trusted devices such as information releaser devices, guards, or quarantine servers.
  • Security protocols such as IPSEC Authentication Header (as described in RFC 2402 of 1998 http://www.faqs.org/rfcs/rfc2402.htrnl) could be used for this purpose. This may help to prevent the audit server from being compromised by attack from the network.
  • An audit server guard device has most of the properties of a information releaser device and guard, in that it has limited functionality, two network (or similar) interfaces, anti-tamper properties, is evaluatable, and may have a public key identity.
  • One network interface of the audit server guard device would be connected to the high network, and the other interface to the audit server.
  • the high network interface would only accept connections from suitably trusted devices. Again, security protocols such as IPSEC Authentication Header could be used.
  • the audit server may have a policy of accepting messages from any network source at all. This would provide a general audit service not only to devices involved in the trusted release activities, but also to any other device on the network that generated events that required auditing. This could include information-security related events, such as users attempting to log on to PCs (and the result), or other events such as authorisation of financial transactions.
  • a general audit service with a trustworthy clock, that provided signed receipts could be used as a time-stamping authority.
  • Any document requiring notarisation such as a diary entry, copyright work, laboratory notebook, or patent application, could be submitted to the audit server.
  • the audit server would store appropriate details (possibly including the whole document itself, otherwise at least a hash of the document) and issue a cryptographically signed receipt. This receipt would allow the submitter to prove later to a third party that the document had been produced and notarised by the claimed time.
  • An audit server may have similar tamper resistance and tamper evidence properties as described above in section 5.3.6.
  • An audit server may be constructed to be evaluatable as described in section 5.3.5.
  • a document may be forwarded from a low network to a high network. It may happen that at a later time that document needs to be released from the high network to the same (or a different) low network. If the document has not been modified since it arrived on the high network, we can conclude that its classification is (at most) the classification of the original low network that it came from.
  • a restricted document on a restricted network. At some time, it may be required on the Secret network. At a later date, it may need to be forwarded back to the restricted network (or another restricted network). If the document has not changed since it entered the secret network, then it must still be restricted.
  • An automatic information labeller can apply labels to documents automatically, when there is a trustworthy non-human means for identifying the classification of the document.
  • any document in a (say, restricted) network can automatically be labelled at the classification of that network (that is, in the example, restricted).
  • the label would contain at least one signature that links it to the document, so that any verification of the label will only be successful if the document has not been modified since the label was signed.
  • the automatic information labeller may be configured to use any indication for identifying the classification of a document.
  • the indication is the document's presence on a particular network.
  • Any trusted system such as a trusted multilevel secure database management system may store classifications with data. Hence, the output from such a trusted system can be used as the basis for an automatic information labeller to create a label.
  • a typical architecture may have an automatic information labeller in series with a data diode that allows documents to be transmitted from a low network to a high network. Guards, information releaser devices, quarantine servers, audit servers would typically also be present on the high network.
  • Figure 13 illustrates the key elements of the connection of the automatic information labeller in such an architecture.
  • a user on a high network may determine that a document from that network ought to be released to another destination network.
  • the user would use some software on a computer (PC) to send that document to the information releaser device. This might be by using a right-click menu, dragging the file's icon into a file-transfer location, or other mechanism.
  • PC computer
  • Document review and release processes may also be initiated by an automatic mechanism, such as the generation of a daily report, or arrival of a certain message.
  • the software on the PC may gather any additional information required for the release process, such as certificates describing the authority of the user, or certificates describing the policies in force at the time. Such additional information may be gathered from a variety of sources, including directories, databases, certificates, and policy files.
  • the PC would send the document, along with any additional information gathered above, and send it (over whatever physical interface is necessary - network, USB, serial, etc) to the information releaser device.
  • the information releaser device might receive the request from the user's PC to release a particular document to a particular destination
  • the information releaser device might ensure that the user is authenticated to the system. Authentication could be achieved using passwords, tokens, biometrics, or a combination of these or other mechanisms.
  • a preferred embodiment would require that the user's smart card has been inserted into the information releaser device, and the user has entered a PIN to log on to the smartcard.
  • Local administrative policy would preferably require that users have smartcards attached via a lanyard (or similar) so that they cannot be left in a information releaser device when the user moves away from that desk.
  • the information releaser device may send information about authentication attempts and results to the audit server. It may wait for the return of a signed receipt that proves the information was received and processed by the audit server, before continuing with any other operations.
  • the device may check that the particular user is authorised to release documents to the particular destination. This may involve acquiring some certificates, either from the request sent from the PC, from the user's smart card, from a database inside the information releaser device, or perhaps another device on the network. It may also require the verification of signatures and certificates or certificate chains.
  • the information releaser device might change to a mode where its own video output is displayed on the user's monitor, instead of the video from the user's computer. Connections to allow this are shown in Figure 1.
  • the information releaser device's own user interface may preferably indicate that the screen is now in such a mode, with the use of a LED or LCD message controlled by the device. If the video switching is not implemented, then the information releaser device will use its own document display mechanism.
  • the information releaser device may render, or cause to be rendered, and then display, an image of the document to be released.
  • the image may include details of the classification of the document and the proposed destination, from the request.
  • the information releaser device may be capable of rendering an image of the document using its own software. If the document type is such that the trusted releaser device is unable to render the image, then the document may be communicated to the Quarantine Server for rendering.
  • the communications between the information releaser device and Quarantine Server may be protected using cryptographic mechanisms (ie. a virtual private network), or by using a physically secure communications network.
  • Part of the rendering process may involve filtering the document to detect and/ or remove certain types of information from the document.
  • the rendering may highlight instances of certain words considered to be possibly indicative of a document being too sensitive to release.
  • the review process may require the user to explicitly acknowledge each such word, for example, by pressing a certain key or button.
  • the user would be responsible for checking that the image displayed on the screen was appropriate. This may include checking that the classification (which came from the request) is indeed appropriate for the document, and that the document has not been modified in any way, nor contains any information that may mean the classification is not correct. If the user approves the document for release, the user will signify this by pressing a button on the device's user interface. The device will then revert to a mode in which the computer's video output is routed to the user's monitor. The device will then take whatever action is necessary for the document to be released. The specific actions will depend on the architecture involved, for example whether there is an audit server (and if so, it's configuration), and whether there is a guard or a direct connection. These options are described below.
  • the action required to release the document may consist of outputting the document to a physically separate network interface, which is connected to the low network, as shown in Figure 2.
  • the device may have several different low network connections, for a number of different low networks, as shown in Figure 2a.
  • the device may not have a direct connection to the destination (low) network as in figure 3.
  • the device would create a secure label (which is sometimes referred to as a "signed label”, or “seal”, or “passport”, or “visa”, or similar).
  • the label is an indication that the document can be released.
  • This label may include one or more digital signatures (preferably using the device's PKI (Public Key Infrastructure) identity and preferably also the user's PKI identity) to provide label integrity, proof-of-origin authentication, and non-repudiation properties.
  • PKI Public Key Infrastructure
  • the label may include the time and date that it was constructed.
  • the label may include the name, rank, and/ or role of the user who created the label.
  • the label may include the identity of the information releaser device, the quarantine server, and/ or audit server used to process the document.
  • the label may include the classification of the document.
  • the label may include the name, classification, or other details of the destination network for the document.
  • the label may include other attributes.
  • the device may return this label to the PC in response to the release request, so that the PC can send the document and the label to a guard when required, or possibly send the document and label to another user for further processing, as described in section 5.8.2.
  • the device may send this label and the document directly to the Guard.
  • the label will protect the document against undetectable-tamper during transit to the guard. If the document or label is tampered with before they arrive at the guard for release, the cryptographic signature(s) in the guard will be found to be invalid, and the guard will not release the document.
  • a physically secure network may be used. Such a configuration is illustrated in Figure 11. Both mechanisms may be used together.
  • the guard may use a complex policy to determine whether a document should be released, perhaps considering a number of different elements in the label, and contextual information such as the time, the classification of the low network, current threat levels, the authority of different users, and the file type of the document.
  • the guard may, according to policy, either removes the label from the document before it is passed to the low network, or it may transmit the label, or part thereof, to the low network as well.
  • the guard may remove the label constructed by the information releaser device, and replace it with a new label created by the guard itself. This would be useful for situations in which policy requires that the names and details of people who review documents are not to be released to other networks, but that the results of the review are to be released.
  • a desktop trusted reviewer device label might indicate that Flight Boat Paul Jones reviewed the document on information releaser device 123.45.67.89 with public key 47283845 94728574 9576 04778442 at 8:42pm on 3 March 2000, he acknowledged individual occurrences of words from 'dirty- word-list-0381', and recommended a classification of SECRET RELE ASABLE INTERFET, and that Wing Commander
  • guard's label may simply indicate "this document was released from Australia in accordance with its official policies, with a classification of SECRET RELEASABLE INTERFET on 4 March 2000.”
  • the guard may send event information to the audit server. Examples of events include the arrival of a document for release, start-up and shutdown, configuration changes, detection of invalid signatures, and the release of a document.
  • the guard may be configured to wait for a signed receipt from the audit server, and to verif this receipt, before continuing.
  • guard function is the use of an access control mechanism at the user's desktop, rather than between distinct networks.
  • the user's computer is only able to access the document from the network if the user has the necessary privileges for the document's label.
  • An example of such an access control mechanism is in the Content Based Information Security (CBIS) Advanced Concept Technology Demonstration (ACTD) project of the US Department of Defense.
  • CBIS Content Based Information Security
  • ACTD Advanced Concept Technology Demonstration
  • Organisational policy may be more complex than described above. For example, it may require that documents cannot be released without authorisation from at least two people all of whom are appropriately authorised. In another example, either one senior approving officer or two junior approving officers (none of whom is the original reviewer) may need to authorise the document's release.
  • the Guard may implement such a policy by checking that a label has two user signatures (each created on a Device, as evidenced by the device's signature).
  • the label and signatures may include various certificates that indicate the authority with which the users approve and/or release documents.
  • the policy may be complex enough to permit senior officers to release documents without further approval, but to require that junior officers need a per-document approval from a supervisor.
  • a system security officer or other "master" signer may describe the guard's policy in an electronic policy file that is signed.
  • Such a scheme might allow the device/ system to cope with many simultaneous and dynamic network access requirements.
  • the same (more complex) approval processes may apply for Teleport session establishment, which is described later.
  • policies are enforced by the guard, it may be that untrusted software interprets that policy, and assists users to comply with it by recommending a suitable workflow even before there is any connection made to the guard.
  • DMZ demilitarised zone
  • Documents in the DMZ may be subject to searches and queries that are received from a low network via (for example) a data diode, as illustrated in Figure 8.
  • An example of such an application is an intelligence organisation. It may want to prepare reports on various topics that could be released to allies on receipt of an official request, but that are not "pushed" to allies immediately. Such reports could be reviewed by users, and released to a DMZ staging server. Requests from allies could reach the staging area through a diode. Any documents meeting the criteria of the request could be released through the second guard to the low (allied) network. This would reduce the concern about threats from foreign networks entering the Australian network, as foreign requests can only get as far as the staging area.
  • Teleporting functionality Some of the key aspects of Teleporting functionality are described in prior art, including Australian patent 691102 and US patents 5,828,832 and 5,832,228. . However, the Teleporting implementation described herein differs in the following ways from the disclosures in those patents:
  • a it reuses the mechanisms for establishing and maintaining a secure connection to the Quarantine Server and/ or Guard, as mechanisms to establish and maintain a connection to the Teleporting guard
  • b it reuses the display used to display documents for review to the user as the purgable thin-client display for displaying Teleport sessions.
  • c it may reuse the guard used for document release as the Teleporting guard
  • d it may reuse the user authentication and authorisation mechanisms used to control document release, to control user access to the Teleporting function
  • e it may reuse a trusted display on the desktop unit, to indicate to the user the type, level and/ or name of the Teleport session
  • the user may request the commencement of a Teleport service via the user's computer or via the device's user interface.
  • the device may require that the user be authenticated before a Teleport session can commence. • The device may require authorisation from other user(s) (as described earlier) before a Teleport session can commence.
  • the device may offer a number of Teleport destinations, from which the user must select one.
  • the request (including destination) is initiated from an untrusted source such as the user's computer, the details may be confirmed using the trusted review mechanism already described, before the connection is initiated or terminated as the case may be.
  • the device acts as a thin terminal for a terminal server, which is on a low network.
  • the device may create a secure channel over the high network to a guard, over which is transferred keystroke and mouse information in one direction, and display information in the other direction.
  • the Teleporting guard functions are similar to the guard functions described earlier, and may (but will not necessarily) be provided in the same device.
  • the guard will only transfer keystroke in ormation out to the low network if it arrives on a suitably authenticated channel such as a VPN.
  • Information arriving from the low network ie. display, video, audio or similar information
  • the device may support multiple destinations by connecting to a different guard for each destination.
  • the device may be able to connect to multiple destinations (each potentially at different security classifications, and therefore not normally easily connectable) using a single guard.
  • the low side of the guard may connect to a single key agile encryptor, which can effectively connect the guard into a number of different virtual private networks.
  • a single guard may be able to connect to a number of different encryptors.
  • destination networks may be national sovereign networks at other classifications.
  • Other destination networks may be multinational networks, perhaps associated with a particular combined military operation (ie. an operation involving several nations), or perhaps networks that exist outside the scope of particular operations, typically to support longer-term interoperability. Such multinational networks are frequently known as coalition networks.
  • the device may act as a thin client for multiple "destination" networks, which may have different classifications. It may be important to ensure that information from one such network is not (even accidentally) transferred to another network.
  • Mechanisms may be required to ensure that the thin client part of the device is cleared of all potentially sensitive information. These mechanisms may involve a combination of one or more of the following:
  • Another mechanism to ensure that information from one network does not leak to another network is to separate the data streams into a "keyboard & mouse data out” stream and a "display/ video/ audio/ other data in” stream. This may be achieved with high assurance using an architecture like that of the Interactive Link described in Australian Patent No. 691102, where a proxy server on the destination network is able to pass display information via a diode (to ensure one-way information flow) to the thin client device, and the keyboard and mouse processing components are in a separate component (to ensure that they are not contaminated by sensitive information).
  • ASG sends AS a "ASG startup" event (including the current time) for storage in log.
  • Guard starts up. 5. Guard fetches ASG address from network (eg. Via protocols such as DNS (Domain Name System) or DHCP (Dynamic Host Configuration Protocol))
  • DNS Domain Name System
  • DHCP Dynamic Host Configuration Protocol
  • ASG sends details of guard startup event to AS for logging. (ASG may have to check that event is signed first)
  • AS stores details of guard startup event in log file. AS may send an acknowledgement back to ASG.
  • ASG creates signed receipt of "guard startup” event using PKI/ token/ crypto, and sends receipt back to G 10.
  • G knowss” that the startup event has been audited successfully, and is therefore now available for operational use.
  • QG When QG confirms that QS is ready, QG sends ASG startup event for logging. 13. QG waits for a receipt from the ASG.
  • DTRDs Desktop Trusted Releaser Devices
  • KVM Keyboard Video Mouse switch
  • DTRD switches KVM to DTRD mode, where the keyboard, video, and mouse are no longer connected to the PC, but to the DTRD itself.
  • DTRD displays a message to the user requiring user to authenticate to card by entering Personal Identification Number (PIN) on keyboard.
  • PIN Personal Identification Number
  • DRS locates policy information file on computer network. 5. DRS gathers user's identity and attribute certificates from directory.
  • DRS reads document file, and by (say) keyword search, guesses classification of Confidential, determines document type as MS Word.
  • DRS interprets policy file.
  • DRS displays dialog box asking user to confirm or adjust classification, user's role (from those allowed by the attribute certificates), whether document is to be releases immediately (or merely labelled in preparation for later release), and other details.
  • User selects Restricted Releasable AS/ CA/NZ/UK/US.
  • DRS interprets policy to check whether guard will allow this. Identifies that an additional approver will be required.
  • DRS calculates which additional users or combinations of users whose approvals would allow the document to be released.
  • DRS displays a list to the user asking who the document should be sent to next for review.
  • DRS emails the document, doubly signed label, policy (perhaps), and certificates (perhaps) to the identified next user.
  • step 8 If dialog in step 8 indicated that document was merely to be labelled in preparation for eventual release, document is now saved with doubly signed label.
  • DRS opens connection to guard.
  • DRS sends document, policy, certificates, and doubly signed label to guard.
  • DRS sends document, certificates, policy, and proposed label information to DTRD.
  • DTRD receives document, certificates, policy, and proposed label info from DRS. 2. DTRD verifies all certificates, and signature on policy file, using high-integrity public key.
  • DTRD determines that for documents of type MSWord (as described in the label) a "native" render is not possible, and that a QS rendering is required.
  • DTRD initiates a VPN (Virtual Private Network) connection to the QG.
  • VPN Virtual Private Network
  • DTRD uses VPN to start a session on QS.
  • QS interprets policy, finding instruction that all "track changes” information is to be discarded by executing "accept change”.
  • QS accepts all changes, and indicates this to the DTRD.
  • QS interprets policy, finding instruction that suspicious white text and graphics are to be removed.
  • QS executes process to delete suspicious white text and graphics, and indicates this to the DTRD.
  • QS interprets policy, finding that a restricted range of formats is required.
  • QS executes software to restrict the range of formats available, and indicates this to the DTRD.
  • QS interprets policy, finding that a keyword check is required.
  • QS starts software to perform keyword check.
  • QS For each suspicious word found, QS produces a screen display data showing the word in context, and forwards it via QG and the VPN to the DTRD. Note that all screen displays produced by the QS incorporate the classification proposed in the label.
  • DTRD switches KVM to DTRD mode.
  • DTRD receives screen display data from QS and displays it to screen.
  • QS creates general display of document, and forwards to DTRD.
  • DTRD allows user to use document navigation features such as Page Up and Page Down, and document search, to review the document, by sending these requests to QS, and receiving ensuing display updates from QS.
  • the DTRD If the DTRD has not received the "all pages reviewed" signal from the QS, it prompts the user either to cancel the review, or to continue so that all pages are reviewed.
  • DTRD If the DTRD has received the "all pages reviewed" signal, it terminates the review process with a "success" status. 34. DTRD sends details (including whether the session terminated successfully, or was aborted by the user, or aborted by some policy check, such as an illegal word check) to the ASG for auditing.
  • DTRD waits for signed receipt from ASG acknowledging receipt of the information.
  • the DTRD creates a label for the document, incorporating: a. Details of all the security checks applied. b. Configuration details of the QS. c. Date and time of the review. d. Identity and role of the user performing the review. e. Classification.
  • the DTRD signs the label using the user's card.
  • the DTRD signs the signed label again using its own private key (possibly stored on another card).
  • the DTRD sends the document and the doubly-signed label to the QG, and waits for the receipt to arrive.
  • the DTRD sends the doubly-signed label back to the DRS (on the PC), and all connections are closed.
  • Guard determines whether security checks and reviews attested by the label are sufficient for release to the low network in accordance with the policy.
  • Guard signs label.
  • Guard sends new signed label, old doubly signed label (and document perhaps) to ASG for logging.
  • Staging server stores document and label.
  • Staging server indexes keywords in document.
  • Staging server awaits search requests from low network via data diode. 4. Staging server searches for documents matching requests.
  • Staging server sends matching documents and corresponding signed labels to second guard.
  • Second guard verifies label signature.
  • the email program uses an API such as the CryptoAPI or GSSAPI to request services from the user's token.
  • API such as the CryptoAPI or GSSAPI
  • the API provider on the PC communicates the request to the DTRD. 4.
  • the DTRD receives a token access request from the PC.
  • the DTRD will queue the token access request until the token is available.
  • the DTRD will ensure that the API complies to the appropriate security policy. (Eg. It is not permissible to read cleartext from the card before either cleartext is written to the card, or a decryption is performed.)
  • the DTRD may switch the KVM to DTRD mode, confirm that this is a suitable request, and then switch the KVM back to PC mode. 8. If the request is assessed as unsuitable, the request can be aborted.
  • the DTRD executes the token access as requested. Results from the token access request are sent back to the PC. 10. When the PC closes its token session, the DTRD clears relevant parts of the card's memory, to prevent possible information leakage to other systems.
  • Teleporting 1 The user identifies that an interactive session on a server on a low computer network is required.
  • the user presses the Teleport button on the DTRD. (In another embodiment, the user could click on an icon on the PC to execute Teleport Initiation software that sends a Teleport signal to the DTRD.) 3.
  • the DTRD selects the KVM to DTRD mode.
  • the DTRD displays to the user a list of services that are available, as defined by the policy file.
  • That signal may have included an indication of which service was required, which would be the default when the list is suggested to the user.
  • the DTRD makes a VPN connection to the appropriate guard for that service (as defined by the policy).
  • the DTRD indicates to the guard which service is required.
  • the guard makes a Remote Desktop Connection to the appropriate service, as a proxy for the DTRD.
  • the remote service sends display, sound, and other signals to the guard, which forwards them to the DTRD, where they are displayed, played, or otherwise effected.
  • Keystrokes, mouse movements, and other signals from the user are forwarded to the remote service via the DTRD and the Guard over the VPN.
  • the user may press a button on the DTRD to arrange for the DTRD to set the KVM switch to PC mode, so that the user can operate the PC, without ending the teleport session.
  • the user may press another button on the DTRD to arrange for the DTRD to set the KVM back to DTRD mode, so that the user can resume the teleport session.
  • the user can end the teleport session by pressing a button on the DTRD.
  • the DTRD When the DTRD ends a teleport session, it purges its memory of any potentially sensitive information which ought not to be available to any other teleport server.
  • the user can initiate a teleport session with more than one server at a time.
  • the DTRD will partition state information so that information from one session cannot leak to any other session.
  • the user would use a button on the DTRD to switch from one session to another.
  • the user's PC is connected to an Australian Secret network.
  • the user teleports to a Coalition Network server. 3. On that server, the user identifies a press release document that needs to be released from the Coalition to the Internet. This user has (certificated) attributes within the coalition environment that would authorise such transfers.
  • the coalition server sends the document via the guard to the user's DTRD. 5.
  • the DTRD displays the document (possibly using a Quarantine Server, as appropriate), for the user to review.
  • the Coalition server may then subsequently send the document and label through a coalition guard to the Internet.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Storage Device Security (AREA)

Abstract

La présente invention se rapporte à un système de diffusion d'informations permettant de diffuser sélectivement des informations depuis un réseau informatique vers au moins un autre réseau informatique de classification inférieure. Ce système possède un certain nombre de configurations possibles dont l'une inclut un dispositif de diffusion d'informations connecté audit réseau informatique, ce dispositif de diffusion d'informations comportant une unité de traitement pouvant répondre à une commande utilisateur pour sélectionner les informations à diffuser; au moins une entrée pour informations pouvant être commandée par l'unité de traitement de manière à recevoir les informations provenant d'un ordinateur et/ou d'un dispositif d'entrée d'ordinateur commandé par un usager; au moins une sortie d'informations pouvant être commandée par l'unité de traitement pour délivrer en sortie des informations à afficher à l'intérieur dudit réseau informatique; au moins une autre sortie pour informations pouvant être commandée par l'unité de traitement de manière à délivrer en sortie des informations, lesdites informations à délivrer en sortie devant au moins être communiquées à l'intérieur dudit réseau informatique aux fins d'un traitement ultérieur et renvoyées pour affichage; ou devant être diffusées directement à partir dudit réseau informatique à l'intérieur duquel le dispositif de diffusion est situé et à destination d'un autre réseau informatique; ou devant être communiquées à l'intérieur du réseau informatique aux fins d'un traitement ultérieur et diffusées vers l'autre réseau; dans ce système, les actions sont déterminées par l'unité de traitement et des actions prédéterminées sont possibles si et seulement si un utilisateur du dispositif de diffusion d'informations commande à l'unité de traitement de diffuser sélectivement des informations à l'autre réseau. Ce système implique également l'utilisation de sentinelles de diffusion d'informations permettant de diffuser des informations à d'autres réseaux et d'autres dispositifs du type serveurs de quarantaine permettant de traiter les informations et de délivrer des versions mieux adaptées à la diffusion, des serveurs d'audit permettant d'enregistrer les opérations du système et des serveurs de stadification permettant de délivrer à partir dudit réseau des informations qui peuvent être demandées par les autres réseaux.
PCT/AU2005/000773 2004-06-01 2005-05-31 Dispositif multiniveau de transfert securise d'informations WO2005119462A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
AU2004902875 2004-06-01
AU2004902875A AU2004902875A0 (en) 2004-06-01 Multilevel secure information transfer device

Publications (1)

Publication Number Publication Date
WO2005119462A1 true WO2005119462A1 (fr) 2005-12-15

Family

ID=35463059

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2005/000773 WO2005119462A1 (fr) 2004-06-01 2005-05-31 Dispositif multiniveau de transfert securise d'informations

Country Status (1)

Country Link
WO (1) WO2005119462A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008040811A1 (fr) 2006-10-06 2008-04-10 Thales Systeme securise pour transferer des donnees entre deux equipements
FR2923967A1 (fr) * 2007-11-21 2009-05-22 Eads Information Technologies Procede de securisation d'une connexion distante d'un terminal a un reseau d'entreprise
CN102622687A (zh) * 2012-03-30 2012-08-01 云南远信科技有限公司 一种电子印章系统
DE102017223099A1 (de) * 2017-12-18 2019-06-19 Siemens Aktiengesellschaft Vorrichtung und Verfahren zum Übertragen von Daten zwischen einem ersten und einem zweiten Netzwerk

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4831367A (en) * 1984-12-29 1989-05-16 Baus Heinz Georg Information device
GB2370660A (en) * 2000-10-06 2002-07-03 Bright Station Plc File sharing
US20030112781A1 (en) * 2001-12-17 2003-06-19 Kermode Roger George Communications unit for secure communications
US20030167410A1 (en) * 2002-03-01 2003-09-04 Rigstad Peter M. System for providing firewall to a communication device and method and device of same
US20040039829A1 (en) * 2002-08-23 2004-02-26 Tim Bucher Peer to peer remote data storage and collaboration

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4831367A (en) * 1984-12-29 1989-05-16 Baus Heinz Georg Information device
GB2370660A (en) * 2000-10-06 2002-07-03 Bright Station Plc File sharing
US20030112781A1 (en) * 2001-12-17 2003-06-19 Kermode Roger George Communications unit for secure communications
US20030167410A1 (en) * 2002-03-01 2003-09-04 Rigstad Peter M. System for providing firewall to a communication device and method and device of same
US20040039829A1 (en) * 2002-08-23 2004-02-26 Tim Bucher Peer to peer remote data storage and collaboration

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008040811A1 (fr) 2006-10-06 2008-04-10 Thales Systeme securise pour transferer des donnees entre deux equipements
FR2906953A1 (fr) * 2006-10-06 2008-04-11 Thales Sa Systeme securise pour transferer des donnees entre deux equipements.
US8327038B2 (en) 2006-10-06 2012-12-04 Thales Secured system for transferring data between two equipments
FR2923967A1 (fr) * 2007-11-21 2009-05-22 Eads Information Technologies Procede de securisation d'une connexion distante d'un terminal a un reseau d'entreprise
CN102622687A (zh) * 2012-03-30 2012-08-01 云南远信科技有限公司 一种电子印章系统
DE102017223099A1 (de) * 2017-12-18 2019-06-19 Siemens Aktiengesellschaft Vorrichtung und Verfahren zum Übertragen von Daten zwischen einem ersten und einem zweiten Netzwerk

Similar Documents

Publication Publication Date Title
US10904014B2 (en) Encryption synchronization method
Firesmith Engineering security requirements.
Lin et al. At the nexus of cybersecurity and public policy: Some basic concepts and issues
US8266676B2 (en) Method to verify the integrity of components on a trusted platform using integrity database services
US8327450B2 (en) Digital safety deposit box
US7395436B1 (en) Methods, software programs, and systems for electronic information security
US7844832B2 (en) System and method for data source authentication and protection system using biometrics for openly exchanged computer files
US20090055924A1 (en) Trusted records using secure exchange
KR101387600B1 (ko) 전자 파일 전달 방법
WO2008024135A2 (fr) Procédé de vérification de l'intégrité de composants sur une plate-forme de confiance à l'aide de services de base de données d'intégrité
JP2002351661A (ja) セキュア・ソリューションを体系化する方法及びシステム
Alsmadi et al. Practical information security
WO2005119462A1 (fr) Dispositif multiniveau de transfert securise d'informations
Loshin Practical anonymity: Hiding in plain sight online
Clark et al. At the nexus of cybersecurity and public policy
Zimmermann PGP User's Guide, Volume II: Special Topics
Birnstill et al. Building blocks for identity management and protection for smart environments and interactive assistance systems
Jansen et al. Guidelines on Active Content and Mobile Code:.
Panek Security fundamentals
Abghour et al. Specification of authorisation services
Simpson et al. Digital Key Management for Access Control of Electronic Records.
US20240070303A1 (en) File Encapsulation Validation
JP4081517B2 (ja) 電子ファイル管理システムおよび電子ファイル管理プログラム
Dimitrios Privacy and Data Protection in mobile applications.
Cowan Security and confidentiality on laboratory computer systems

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase