Project HighFire: FireBox:

Firewall & Encrypting Message Center for Human Rights Fieldworkers

Table of Contents

• FireBox Introduction
• Configuration
• HighFire E-mail Default Message Sources and Destinations
• HighFire FireBox E-mail Use Case Scenarios
• Frequently Asked Questions (and Answers)

FireBox Introduction

HighFire's "FireBox" component is a secure network appliance that combines firewall capabilities to protect the local field office network with send-only mailserver functions, automated cryptographic key management and secure Internet voice capabilities. The FireBox can be placed in a high-risk environment: it will only briefly store outgoing e-mail while other data is kept on the distant IceBox server. To improve local e-mail client performance and reduce connection faults, it has a secure store-and-forward capability to minimize connectivity costs and problems in locations where only dial-up Internet is available. The FireBox is designed to communicate with other FireBoxes directly, when necessary, as well as the IceBox server component of HighFire.

A detailed FireBox/IceBox interoperation technical diagram is available.

Configuration:

The FireBox can be configured in one of two ways depending on the uplink conditions and security level required:

FireBox can be configured to replicate IMAP mail locally to protect the user from poor internet links, increase speed and reduce link cost if the field office must pay by the connection time. This comes at the lost of some security, since mail is now stored (though still encrypted) on the more easily seized FireBox as well as the physically secured IceBox component.

For detailed information on the FireBox (and IceBox) features, please see the HighFire Development Roadmap.

HighFire E-mail Default Message Sources and Destinations

Default Message flow of HighFire generated messages:

*    Depending on legal restrictions of the countries involved and the NGO's wishes.
**  Should provide a warning.

HighFire FireBox E-mail Use Case Scenarios

(See IceBox component's page for additional HighFire use cases that do not involve the FireBox)

Regardless of use-case, the worker's view of their Web-mail includes:

• all of their folders
• language preferences/and other personal settings
• all in-bound message headers as of the FireBox's last message sync with the IceBox
• the time of the FireBox's last message sync with the IceBox

If you would be interested in working with our R&D team on FireBox development, please please contact the project administrator.

Frequently Asked Questions (and Answers)

• Why split the mail between the FireBox and the IceBox?
  1. Backup and recovery is more reliable in a stable environment
  2. A local server with no data introduces very little risk if seized
  3. In situations where the NGO believes having incoming e-mail available while the Internet connection is down is more important than the risk introduced by keeping the mail locally, the incoming e-mail can be cached to the local Firebox.
• Why do we need a physical server on-site? Why not just use a remote Web service?
  1. The telecommunications links are unreliable so that a break in connection may lose an e-mail in composition
  2. The telecommunications links are often priced by the time connected (metered) such that a persistent connection is cost prohibitive
  3. A browser connecting to the Web-server via a LAN or running directly on the same machine will provide far greater performance compared to remote (dial-up/ISDN/DSL) Web-mail
  4. A local machine allows for a secured platform upon which additional functionality (Voice over IP, and encrypted file storage/backup) can be added.
• Why use a Web interface for e-mail?
  1. Critical information should not be stored on seizable devices in unencrypted format
  2. Currently, there are no open source, simple to use disk encryption solutions for laptops to store locally kept (POP3) information
  3. Developing components to encrypt e-mail for a changing variety of locally executed e-mail clients is not possible
  4. Human rights workers require access to critical data after information has been lost due to seizure/theft or laptop hardware failure
• Why not just use SSL and a local mail client like Eudora?
  1. SSL only protects from the client to the mail server. GPG/PGP can be used to protect the client from end to end.
  2. Even if GPG/PGP is used, there is a risk the mail is exposed by decrypting it and keeping it saved on the local hard drive. Disk encryption such as PGPDisk can be used to protect the client on the hard disk.
  3. SSL + GPG/PGP + Disk encryption is an excellent solution. However, experience has shown that current tools are challenging for non-technical users and their adoption has been hindered by this.
  4. Additionally, a Web-mail client adds the ability to compose and encrypt outgoing e-mails from cybercafés (with one's own laptop) which are the only network access in many locations.
• Why support a secured terminal off the same machine (FireBox) as the local HighFire Web-mail server?
  1. Other computers are not always available
  2. Voice over IP (VoIP) applications require a known hardware platform
  3. E-mails requiring the utmost security should only be sent from a secured terminal directly from the FireBox to the IceBox.

[Back to HighFire main page]