WO2005119462A1

WO2005119462A1 - Multilevel secure information transfer device

Info

Publication number: WO2005119462A1
Application number: PCT/AU2005/000773
Authority: WO
Inventors: Peter Drewer; Peter Duffett; Maris Ozols; John Desborough Yesburg
Original assignee: Australian Government
Current assignee: Australian Government
Priority date: 2004-06-01
Filing date: 2005-05-31
Publication date: 2005-12-15
Anticipated expiration: 2006-12-01

Abstract

The specification discloses an information releaser system for selectively releasing information from one computer network to at least one other computer network of lesser classification. The system has a number of possible configurations one of which includes an information releaser device connected to the one computer network, wherein the information releaser device has a processor responsive to a user command to selectively release information; at least one information input operable with the processor for receiving information from a computer and/or a computer input device operable by a user; at least one information output operable with the processor for outputting information to be displayed within the one computer network; at least one further information output operable with the processor for outputting information, wherein the information to be output is at least; to be communicated within the one computer network to be further processed and returned for display; or to be released directly from the one computer network within which the releaser device is located to another computer network; or to be communicated within the one computer network to be further processed and released to the other network; whereby the actions are determined by the processor and predetermined actions are available if and only if a user of the information releaser commands the processor to selectively release information to the other network. The system also includes the use of information release guards for releasing information to other networks and other devices such as quarantine servers for processing the information and providing versions more suitable for release, audit servers for recording the operations of the system and staging servers for providing information from the one network that can be requested by the other networks.

Description

MULTILEVEL SECURE INFORMATION TRANSFER DEVICE

1. Field of the Invention

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.

2. Background

2.1 Information Systems and Network Security

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.

If the risk associated with unauthorised access is sufficiently low, owners of the information assets (or those delegated with responsibility for its protection) may consider that the protection offered by these information systems is sufficient.

If the risk is higher, the owners or protectors may not be satisfied with the level of protection offered by the information systems themselves, and hence they may demand additional protection.

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.

A specific application of this addition of physical protection is called "System High". "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".

Note that organisations with strict security requirements often have a "need to know" policy. Even if a person has a particular clearance, and is therefore "authorised" to access any information classified at that level, they are additionally charged to access only information that is necessary for their particular duties, rather than "browsing". Even though an information system's built in access control mechanisms may be considered insufficiently trustworthy to prevent uncleared people from seeing classified information, those mechanisms may be considered sufficiently trustworthy for the implementation of need-to-know security.

2.2 Multiple Networks

Organisations that process very sensitive information (information where the impact of unauthorised access is very great) may require system high networks. These same organisations may require extensive connectivity with other organisations through, for example, the Internet. Such organisations may choose to implement multiple networks. One network, accessible to all members of the organisation, may be connected (perhaps through a firewall) to the Internet; another network may only be accessible by specifically authorised individuals within that organisation. In some cases, there may be several different System High networks, which different sets of individuals are authorised to access.

When we consider two networks, we will often label one network "high", and the other "low". This means that there is information on the high network that is sufficiently highly classified that not all users of the low network have permission to access it. In contrast, all users of the high network are considered to have sufficient clearances to be users of the low network as well. It is possible to have two networks that cannot be compared in this way. However, in describing this invention we are primarily concerned with a high network and a low network.

2.3 Information Transfer between Networks

When organisations operate separate networks, it can frequently happen that information on one network needs to be transferred (copied) to another network. A number of mechanisms for transferring information are possible.

These include: 1. Printing from one network, and re-typing on the other.

2. Saving the information on floppy disk, cdrom, or similar media, and transferring the media.

3. Making an electronic connection between the networks, possibly using a firewall or other technological means to reduce the risk of unauthorised access. An ideal information transfer mechanism will have a number of properties.

1. It is convenient (fast, easy to use) for authorised users.

2. It does not significantly increase the risk of unauthorised access to sensitive information. 2.4 Previous Inventions by the applicant

The patents mentioned below are incorporated by reference into this specification.

2.4.1 Australian Patent

Communications Security and Trusted Path Method and Means. Australian Patent No. 706073

2.4.2 Australian Patent

Method and means for interconnecting different security level networks. Australian Patent No. 691102.

2.4.3 Australian Patent High assurance digital signatures. Australian Patent No. 760021.

2.4.4 Australian Patent

Complex document security. Australian Patent No. 673404.

2.4.5 Australian Patent

Message document security. Australian Patent No. 675816. 2.5 Other Prior Art

2.5.1 Guards

There are many guards already in use, including Radiant Mercury, ISSE Guard, High Assurance Guard.

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 ISSE Guard is described in the literature and at http:/ /www.rl.af.mil/tech/programs/isse/ Radiant Mercury is described in the literature and at http://www.fas.org/irp/program/disseminate/radiant mercury.htm

2.5.2 KVMs

There are many keyboard/ video/mouse switches already available. 2.5.3 Other Network Security Devices

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 Secure Network Interface Unit (SNIU) work of Holden et al as described in US Patents 5,828,832 and 5,832,228.

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.

3. Brief Description of the Invention

We propose an architecture, which assists the transfer of information between networks. There are many different potential applications for the device. 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.

In this specification, we identify a number of approaches under investigation for implementing certain features that can be associated with the following types of devices and system configurations.

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

In a broad aspect of the invention an information releaser system for selectively releasing information from one computer network to at least one other computer network includes: an information releaser device connected to the one computer network, the information releaser device having: a processor responsive to a user command to selectively release information; at least one information input operable with the processor for receiving information from a computer and/ or a computer input device operable by a user; at least one information output operable with the processor for outputting information to be displayed within the one computer network; at least one further information output operable with the processor for outputting information, wherein the information to be output is at least i) to be communicated within the one computer network to be further processed and returned for display; or ii) to be released directly from the one computer network within which the releaser device is located to another computer network; or iii) to be communicated within the one computer network to be further processed and released to the other network; whereby the actions i), ii) or Hi) are determined by the processor and actions ii) and iii) are available if and only if a user of the information releaser commands the processor to selectively release information to the other network.

In an aspect of the invention 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.

In yet another aspect of the invention 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.

In another aspect of the invention 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.

In yet a further aspect of the invention 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.

In another aspect of the invention 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. In another aspect of the invention 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.

In yet an other aspect of the invention including the staging server 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.

Throughout this specification unless the context requires otherwise, the words 'comprise¹ and 'include' and variations such as 'comprising' and 'including' will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.

Specific embodiments of the invention will now be described in some further detail with reference to and as illustrated in the accompanying figures. These embodiments are illustrative, and not meant to be restrictive of the scope of the invention. Suggestions and descriptions of other embodiments may be included within the scope of the invention but they may not be illustrated in the accompanying figures or alternatively features of the invention may be shown in the figures but not described in the specification.

4. Brief Description of the Figures

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.

5. Detailed Description of Embodiments of the Invention

5.1 Document Release Capabilities A user on one network, known as the high network, may require that certain information (a document) be transferred (copied, or "released") to another network, known as the low network. We find it convenient to use the term "released" because it indicates that the document leaves the protective custody of the high network, and is allowed into the less strictly controlled environment of 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.

In order to preserve security, it is a fundamental requirement that information can only be placed on a system high network if the classification of that material is low enough. For a document to be released from a high (eg. Secret) network to a "low" (eg. Unclassified) network, we need to ensure that the classification of the document is (at most) "low" (Unclassified, in this example). The process of checking the classification of a document, for example, is called "review".

After reviewing the document, the user indicates whether the document is indeed suitable for transfer to the low network.

The owners of (or people with responsibility for protecting) the information need to be confident in the overall security of this process.

The overall security relies on a number of aspects.

1. Only the information that has been reviewed by the user is released.

2. The information is only released if that user indicates their approval. 3. The user is able and authorised to make the release decision.

If we rely on computer systems to per orm any of the review and release process, we need to consider the possibility of the computer not performing the task correctly. Although computer systems may be very reliable, in situations where extremely sensitive information is being protected, we may not have sufficient confidence that computer software (including applications and operating systems) will work correctly. Security authorities may be unwilling to rely on the correct operation of such systems for the security of their overall system. We therefore propose the use of new devices to perform these functions that are important for providing overall security. These new devices will have characteristics that allow security authorities to have more confidence in their correct operation.

5.2 Teleporting Capabilities

A user on one network, known as the high 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. There may be multiple low networks for the user to interact with. The user may be able to select the low network that they want to start a session on, by interacting with (a) the device's user interface, or (b) a combination of the user's PC and the device's user interface.

Note that some elements described under the Document Release section to be described later in this specification may also apply to the Teleporting function, and vice versa.

5.3 Basic Elements of the Information releaser device

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.

We propose that most or all of the following elements are required for the device in some or all of the applications proposed.

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. When 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.

In our preferred embodiment, the information releaser device is connected between the computer's video output and the monitor. 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.

In the same way that the monitor is effectively switched between receiving the computer's video output and the information releaser device's video output, 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. When the information releaser device is idle, information from the keyboard and mouse is transmitted to the computer's keyboard and mouse inputs. When 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.

This switching functionality is used in prior art known as Keyboard Video Mouse (KVM) switches. However, whereas 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).

Using "Orange Book" parlance, this user interface is a trusted path.

5.3.5 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.

Whereas a user's PC needs frequently to be updated with newer operating systems and application software that has not been rigorously analysed for security, 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.

5.3.6 Information Releaser Device Anti-Tamper Measures

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.

If the information releaser device implements its own private key storage mechanism, it may have a zeroise mechanism which ensures that any records or the key are securely erased as soon as any tampering is detected.

If the information releaser device uses a token that contains keys, that token may implement its own zeroise features.

5.3.7 Information Releaser Device Operating System

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).

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.

An example of such an operating system is Green Hills Software's "Integrity" OS.

5.3.8 Information releaser device may have a public key identity.

This means that there may be a public and private key pair that is associated with the device. The private key must be protected against unauthorised disclosure.

The public key (or more importantly, the root public key) must be protected against unauthorised modification.

It may be that these keys are stored on 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.

For example, 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. For private key protection purposes, it 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.

There may need to be mechanisms for allowing keys to be changed. 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.

In order to operate effectively with 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.

5.3.10 Information releaser device May Authenticate Users

The device may have a means by which a user can authenticate to it. The authentication may use a password. In this case, the preferred embodiment would simply use the keyboard attached as described in 5.3.3. Alternatively the information releaser device may incorporate a full keyboard or numeric keypad.

The authentication may use a token, such as a smartcard. In this case, 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. In this case, 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.

5.3.11 Information releaser device May Offer Token Access to Computers

In multilevel security environments, such as found in Defence and Intelligence organisations, users may have 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.

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. Although 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).

Even in situations where 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).

5.3.12 Information releaser device May Incorporate Other Related Functions

We have already identified that 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) or Keyboard Switch (KBS) function as already implemented in Tenix devices sold under the trade name Data Gate and Veto as well as being described in Australian Patent No's 706073 and 691102. In this way, the new devices would be seen as upgrades to the existing KBS/MCS devices.

It may also be economically viable to include other functionality (eg. High Assurance Digital Signatures, Australian Patent No 760021) in the same information releaser device because of the synergies of the functionality of the two components.

It is possible that 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.

5.4 Basic Elements of a Quarantine Server

The information releaser device is required to transform (or "render") a document into an image that a user can review. For some types of document, such as plain text, this function is relatively simple. For other types of document, such as 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. Often 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 solution to this problem is to "outsource" the job of rendering various types of documents to another system, which we will call the quarantine server, as shown in figure 5.

The Quarantine Server performs tasks like a Windows Terminal Server (and some Quarantine Server embodiments may incorporate an actual Windows Terminal Server). When a document is sent to the Quarantine Server (QS), 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.

It may become necessary to display (for review) some complex or new document types for which no suitable rendering software exists in the device. 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.

While use of a quarantine server with lower trustworthiness would reduce the level of trust one may place in the rendering of the file, and potentially the isolation between files, this will not diminish the confidence provided by the device in ensuring that only reviewed and approved files can be transferred, and that (in situations where auditing by an Audit Server is required) all transfers will be audited and associated unequivocally with a user (or a sequence of users). Organisations may be willing to accept the increased risks involved in consideration of the significant benefits.

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 (or some similar device such as a firewall) 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.

This would reduce the vulnerability of the (potentially less trustworthy) quarantine server to various denial-of-service or other attacks from the high network and to unauthorised changes in it operation, say by a malicious program that intends to subvert the veracity of displayed information. Secure connections would typically need only to be authenticated, and not encrypted.

Secure connections may be made using IPsec protocols such as AH and ESP as defined by the IETF in RFC2411 and related documents.

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.

5.5 Basic Elements of a Guard

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. As such 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. Such 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. For example 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

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. Note that 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.

Although the description above has concentrated on the application of a guard in preventing the transfer of data from one network to another to prevent unauthorised breaches of confidentiality, guards can also be used to protect elements such as Audit Servers and Quarantine Servers from integrity breaches. As in the previous application, the guard's function is to check that information arriving from the high network comes with appropriate authenticity information. However in contrast, whereas in the previously identified cases where the guard used a signed label to determine whether information was authorised to be transmitted through the guard, when protecting these other elements, 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.

5.6 Basic Elements of an Audit Server

Organisational security policies often require that detailed records are kept of security critical events. 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.

One way of implementing this policy with a high level of assurance would be to use an audit server guard device as shown in figure 4. 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.

Note that 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.

5.7 Basic Elements of an Automatic Information abeller

Sometimes 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.

For example, consider 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. In the situation above, 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. In the example above, 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.

5.8 Implementation of Document Release

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.

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.

5.8.1 Direct release vs use of a guard. In the simplest embodiment, 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.

In a more complex but more flexible situation, the device may not have a direct connection to the destination (low) network as in figure 3. In this case, 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.

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.

An example configuration is shown in Figure 3.

Instead of using signatures to provide security for the label information and 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. Alternatively, 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. For example, a desktop trusted reviewer device label might indicate that Flight Lieutenant 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

Stephen James approved the classification on 4 March 2000 using the same reviewer. Instead, the 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.

An alternative implementation of the guard function is the use of an access control mechanism at the user's desktop, rather than between distinct networks. In this case 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 Defence.

5.8.2 Multiple users to approve release.

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. Note that while 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.

5.8.3 Staging area for pre-released documents.

Under certain threat scenarios, it may be desirable to have two guards in series, as illustrated in Figure 7. The area between the guards may be considered a demilitarised zone (DMZ). 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.

5.9 Implementation of Teleporting

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, and to individual networks 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

5.9.1 Initiation of Teleport Operation

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.

If 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.

5.9.2 Establishment of Channel

During Teleporting sessions, 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) may not need to be secured once it is on the high network - that is, only information travelling in the downward direction may need to be authenticated

5.9.3 Multiple Destinations

The device may support multiple destinations by connecting to a different guard for each destination. Alternatively, 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. In this case, 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. Or, a single guard may be able to connect to a number of different encryptors.

Some of the 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.

Coalitions may be very dynamic, with different nations entering and leaving at various stages. The configurability of the device and the guard policies would enhance its ability to support interactions with multiple dynamic coalitions. 5.9.4 Purging

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:

1. Hardware that clears all memory

2. Hardware that reboots or otherwise initialises the thin client system

3. High assurance software that clears appropriate memory

4. Interrupt routine software that clears memory

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).

This approach would be particularly compatible with the concept of providing a secure channel for the downward keyboard and mouse information, and a separate (not necessarily secured/ confidential/ authenticated) channel for the upward flowing display information. 5.10 Implementation of Various Operational Sequences

The previous paragraphs have provided the context of the operation of the elements that make up a number of embodiments including what they can and mat do, what they are connected to and how and what is communicated between them, what operations they perform and what considerations are required to use them. The following include a step by step description of very specific embodiments of the use of the elements described previously.

5.10.1 Start up 1. Audit server (AS) starts up.

2. Audit Server Guard (ASG) starts up.

3. ASG sends AS a "ASG startup" event (including the current time) for storage in log.

4. Guard (G) starts up. 5. Guard fetches ASG address from network (eg. Via protocols such as DNS (Domain Name System) or DHCP (Dynamic Host Configuration Protocol))

6. Guard sends "guard start-up" event to ASG. (Guard may have to sign this event first)

7. ASG sends details of guard startup event to AS for logging. (ASG may have to check that event is signed first)

8. AS stores details of guard startup event in log file. AS may send an acknowledgement back to ASG.

9. ASG creates signed receipt of "guard startup" event using PKI/ token/ crypto, and sends receipt back to G 10. G "knows" that the startup event has been audited successfully, and is therefore now available for operational use.

11. Other devices also start up.

12. When QG confirms that QS is ready, QG sends ASG startup event for logging. 13. QG waits for a receipt from the ASG.

14. Desktop Trusted Releaser Devices (DTRDs) also startup and send records to ASG for auditing, and await replies. On startup, DTRD Keyboard Video Mouse switch (KVM) is in "PC mode" where keyboard, video, and mouse are connected to PC, rather than the DTRD.

15. When DTRD starts up, it waits for a card for user authentication. 5.10.2 User Authentication

1. User inserts card into DTRD.

2. DTRD switches KVM to DTRD mode, where the keyboard, video, and mouse are no longer connected to the PC, but to the DTRD itself.

3. DTRD displays a message to the user requiring user to authenticate to card by entering Personal Identification Number (PIN) on keyboard.

4. User enters PIN to DTRD via keyboard.

5. DTRD sends PIN details to card. 6. If PIN is wrong and card is still unlocked, try again.

7. If card locks after too many failed authentication attempts, display this to the user on the screen, wait for acknowledgement, and then switch back to PC mode. Await a new card for authentication.

8. When authentication is complete, switch KVM back to PC mode. 5.10.3 Document Release Software

1. User identifies a document to be transmitted to low network.

2. User right-clicks on file and chooses Send To > Low Network.

3. PC starts up document release software (DRS).

4. DRS locates policy information file on computer network. 5. DRS gathers user's identity and attribute certificates from directory.

6. DRS reads document file, and by (say) keyword search, guesses classification of Confidential, determines document type as MS Word.

7. DRS interprets policy file. 8. 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. 9. User selects Restricted Releasable AS/ CA/NZ/UK/US.

10. DRS interprets policy to check whether guard will allow this. Identifies that an additional approver will be required.

11. Go to Document Review flowchart

12. DRS calculates which additional users or combinations of users whose approvals would allow the document to be released.

13. If the document could be released already, skip to step ...

14. DRS displays a list to the user asking who the document should be sent to next for review.

15. User selects a user (or set of users). 16. DRS emails the document, doubly signed label, policy (perhaps), and certificates (perhaps) to the identified next user.

17. When that user receives the email and clicks on the attachment, the DRS software on his machine is executed, and commences from step 7

18. 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.

19. If document is to be released, then DRS opens connection to guard.

20. DRS sends document, policy, certificates, and doubly signed label to guard.

21. DRS sends document, certificates, policy, and proposed label information to DTRD.

5.10.4 Document Review

1. 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.

3. DTRD interprets policy file.

4. 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.

5. DTRD initiates a VPN (Virtual Private Network) connection to the QG.

6. QG checks that DTRD session is authentic using VPN.

7. DTRD uses VPN to start a session on QS.

8. DTRD sends document, policy, and proposed label to QS. 9. QS verifies policy signature.

10. QS interprets policy, finding instruction that all "track changes" information is to be discarded by executing "accept change".

11. QS accepts all changes, and indicates this to the DTRD.

12. QS interprets policy, finding instruction that suspicious white text and graphics are to be removed.

13. QS executes process to delete suspicious white text and graphics, and indicates this to the DTRD.

14. QS interprets policy, finding that a restricted range of formats is required.

15. QS executes software to restrict the range of formats available, and indicates this to the DTRD.

16. QS interprets policy, finding that a keyword check is required.

17. QS starts software to perform keyword check.

18. QS check document for occurrences of any illegal or suspicious words, and indicates this to the DTRD. 19. If any illegal words (for this classification, document type, user, etc) are found, the review session aborts, and the QS indicates the reason to the DTRD.

20. 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.

21. DTRD switches KVM to DTRD mode.

22. DTRD receives screen display data from QS and displays it to screen. 23. User reviews each occurrence and presses a key to indicate approval of that work.

24. If user does not approve any of the occurrences, the review session aborts.

25. When user approves each instance, this is signified to QS, which then displays next occurrence. 26. When all occurrences are approved, QS creates general display of document, and forwards to DTRD.

27. DTRD displays document.

28. 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.

29. When the QS determines that all pages of the document have been reviewed by the user, this is indicated to the DTRD.

30. If at any stage, the user cancels the review, the review is terminated.

31. When the user is convinced that the document can legally be labelled with the proposed classification, including that all uses of any suspicious words are appropriate and do not indicate a higher classification, the user presses the Accept button on the DTRD.

32. 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.

33. 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.

35. DTRD waits for signed receipt from ASG acknowledging receipt of the information.

36. If the termination was successful, 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.

37. The DTRD signs the label using the user's card.

38. The DTRD signs the signed label again using its own private key (possibly stored on another card).

39. The DTRD sends the document and the doubly-signed label to the QG, and waits for the receipt to arrive.

40. The DTRD sends the doubly-signed label back to the DRS (on the PC), and all connections are closed. 5.10.5 Guard Release

1. Guard checks certificates and signatures on policy and label.

2. Guard determines whether security checks and reviews attested by the label are sufficient for release to the low network in accordance with the policy.

3. If sufficient, Guard creates new label indicating date, time, classification. 4. Guard signs label.

5. Guard sends new signed label, old doubly signed label (and document perhaps) to ASG for logging.

6. When receipt arrives, Guard sends document and new label to staging server. 5.10.6 Staging Server Release

1. Staging server stores document and label.

2. Staging server indexes keywords in document.

3. Staging server awaits search requests from low network via data diode. 4. Staging server searches for documents matching requests.

5. Staging server sends matching documents and corresponding signed labels to second guard.

6. Second guard verifies label signature.

7. If correct, document and signed label are released to low network. 5.10.7 Token Access

1. The user creates an email on his PC which he wishes to sign.

2. The email program uses an API such as the CryptoAPI or GSSAPI to request services from the user's token.

3. The API provider on the PC communicates the request to the DTRD. 4. The DTRD receives a token access request from the PC.

5. If a review process or any other token access is underway, the DTRD will queue the token access request until the token is available.

6. When 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.)

7. At the beginning of a session (or for each request) 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.

9. 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.

5.10.8 Teleporting 1. The user identifies that an interactive session on a server on a low computer network is required.

2. 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.

4. The DTRD displays to the user a list of services that are available, as defined by the policy file.

5. The User selects an appropriate service.

6. If the teleporting session was initiated by the PC, 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.

7. The DTRD makes a VPN connection to the appropriate guard for that service (as defined by the policy).

8. The DTRD indicates to the guard which service is required. 9. The guard makes a Remote Desktop Connection to the appropriate service, as a proxy for the DTRD.

10. 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. 11. Keystrokes, mouse movements, and other signals from the user are forwarded to the remote service via the DTRD and the Guard over the VPN. 12. 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.

13. 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.

14. The user can end the teleport session by pressing a button on the DTRD.

15. 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.

16. 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.

17. The user would use a button on the DTRD to switch from one session to another.

5.10.9 Releasing via Teleport

1. The user's PC is connected to an Australian Secret network.

2. 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.

4. 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.

6. The user reviews it in the normal way, as discussed above. 7. When the review is complete, the DTRD sends doubly signed label via the VPN and the guard to the Coalition server.

8. The Coalition server may then subsequently send the document and label through a coalition guard to the Internet.

It will be appreciated by those skilled in the art that the invention is not restricted in its use to the particular application described. Neither is the present invention restricted in its preferred embodiment with regard to the particular elements and/ or features described herein. It will be appreciated that various modifications can be made without departing from the principles of the invention. Therefore, the invention should be understood to include all such modifications within its scope.

Claims

Claims defining the invention are as follows:

1. An information releaser system for selectively releasing information from one computer network to at least one other computer network including: an information releaser device connected to the one computer network, the information releaser device having: a processor responsive to a user command to selectively release information; at least one information input operable with the processor for receiving information from a computer and/ or a computer input device operable by a user; at least one information output operable with the processor for outputting information to be displayed within the one computer network; at least one further information output operable with the processor or outputting information, wherein the information to be output is at least iv) to be communicated within the one computer network to be further processed and returned for display; or v) to be released directly from the one computer network within which the releaser device is located to another computer network; or vi) to be communicated within the one computer network to be further processed and released to the other network; whereby the actions i), ii) or iii) are determined by the processor and actions ii) and iii) are available if and only if a user of the information releaser commands the processor to selectively release information to the other network.

2. An in ormation releaser system according to claim 1 further including 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.

3. An information releaser system according to claim 1 further including 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.

4. An information releaser system according to claim 1 further including 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.

5. An information releaser system according to claim 1 further including 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.

6. An information releaser system according to claim 1 further including 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.

7. An information releaser system according to claim 1 further including an in ormation 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.

8. An information releaser system according to claim 7 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.

9. An information releaser system according to claim 7 further including a data diode 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.

10. An information releaser system according to claim 9 wherein the staging server stores received and processed information, indexes keywords in information, and waits for a search requests from another network through the data diode.

11. An information releaser system according to claim 10 wherein the staging server searches for documents matches requests and documents and communicates signed labels for predetermined information to the further information releaser guard.

12. An information releaser system according to claim 7 the information releaser guard checks a signed label as being from the staging server and if correct releases information associated with the signed label to another network

13. An information releaser system according to claim 1 the information releaser device further including a display information switching device for directing display information to a predetermined display within the one network.

14. An information releaser system according to claim 1 the information releaser device further including a trusted operation system operable on the processor.

15. An information releaser system according to claim 1 the information releaser device further including a display for displaying received information.

16. An information releaser system according to claim 1 the information releaser device further including an information labeller that labels information that is communicated external of the information releaser device.

17. An information releaser system according to claim 2 the information releaser device further including a teleporting functionality when at least one information input receives information from a computer input device that is communicated to at least one information releaser guard for release to an other network and information is received back from the other network for provision to the information output for display.

18. An information releaser system according to claim 1 the information releaser device further including a private key store for encryption by the processor and use of the private key by the processor to encrypt information to be output in accordance with actions i), ii) and iii).

19. An information releaser system according to claim 1 the information releaser device further including keypad operable by a user and an information authenticator that checks the identity and permission of a user to release information from the information releaser device.

20. An information releaser system according to claim 1 the information releaser device further including a smart card reader for accepting a smart card containing one or more of the following: a user identity token, a private and/ or public cryptographic key, a secret cryptographic key, a token for use by the releaser device.

21. An information releaser system according to claim 1 the information releaser device further including an information classification means and once classified provision of the classification to an information output for display of the classification and other metadata associated with the information.

22. An information releaser system according to claim 1 the information releaser device further including trusted functionality including high assurance digital signature security wherein the processor is trusted to apply a digital signature to information to be communicated external of the information releaser device.

23. An information releaser system according to claims 3 or 4 the quarantine server further including an information filter for eliminating information of a predetermined type from received information.

24. An information releaser system according to claims 3 or 4 the quarantine server further including an information correction function for correcting information of a predetermined type in received information.

25. An information releaser system according to claims 3 or 4 the quarantine server further including an information process recorder and labeller for recording what processes including filters that are applied to information received and labelling the information with a record of those processes and filters.

26. An information releaser system according to claims 3 or 4 wherein the quarantine server is a Win Term Server.

27. An information releaser system according to claims 5 or 6 wherein the audit server records one or more of the following: information labels, information signatures, information releaser user identity associated with the release or attempted release of information.

28. An information releaser system according to claims 5 or 6 the audit server further including a digital signature of the audit server and a trusted processor for signing with the digital signature predetermined information that leaves the audit server as a receipt of the auditing of the information process recorded.

29. An information releaser system according to any preceding claim wherein the audit server records the cancelled information releases of the information and other potentially security relevant information related to processes of one or more of the information releaser, audit server, audit server guard, quarantine server, quarantine server guard and one or more information releaser guards.

30. An information releaser system according to claim 2 wherein when information is being released to another network by an information releaser guard additional information associated with the information is also released by the guard.

31. An information releaser system according to claim 2 the information releaser guard further including a digital signature of the information releaser guard and a trusted processor for signing with the digital signature predetermined information that leaves the information releaser guard.

32. An information releaser system according to claim 2 the information releaser guard further including a data diode connected between the information releaser guard and a predetermined other network arranged to permit the flow of information between the other network and the information releaser guard but not between the information releaser guard and the predetermined other network.

33. An information releaser system according to any preceding claim wherein communications between the information releaser device and one or more of the information releaser guard, quarantine server, quarantine server guard, audit server, audit server guard uses a virtual private network protocol.