Project HighFire: IceBox:
Secure Messaging & File Storage for Human Rights Organizations
Table of Contents
IceBox Introduction
The IceBox Secure Communication Server
will form part of a network of distributed servers providing secure e-mail service and
storage for FireBox users. Since the IceBox servers will be maintained in offices where they can be
monitored and physically locked up, they will be secure from
from physical tampering, as well as protected from network attacks by an integrated software firewall. Even if an IceBox were to be physically seized,
no user
decryption keys or encrypted data would be available. The IceBox is designed to communicate with the
FireBox component at local field offices, and also with other IceBox installations
(within the same organization or between organizations).
A detailed IceBox/Firebox interoperation technical diagram is available.
Configuration:
Incoming e-mail storage & Web-mail interface, out-going e-mail routing, spam
filtering, OpenPGP keyserver, Web-mail server
Protected behind NGO firewall in a non-conflict geographic location,
physically secured, and tamper-evident.
Accessed by FireBoxes and HighFire
admins. Web-mail provided for authorized
users at cybercafés or other unsecured locations (or those at secured
locations not set up to download copies of mail to local FireBox appliances).
For detailed information on IceBox (and FireBox) features, please see the HighFire Development Roadmap.
HighFire E-mail Interface
The HighFire mail system has two interfaces, basic and advanced.
- the user can toggle between at will
- the local and remote administrators can set the default
- the local and remote administrators can set an override forcing one of the views
Basic: is a "simple mode" where the cryptography is hidden and the signing and encryption options toggled on/off by the admin based on policy (e.g. where crypto is legal).
Advanced: is similar to the current SquirrelMail interface but with advanced security features available and visible to the user.
Frequently Asked Questions (and Answers)
- Why split the mail between the FireBox and the IceBox?
- Backup and recovery is more reliable in a stable environment
- A local server with no data introduces very little risk if seized
- 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 use a Web interface for e-mail?
- Critical information should not be stored on seizable devices in unencrypted format
- Currently, there are no open source, simple to use disk encryption solutions for laptops to store locally kept (POP3) information
- Developing components to encrypt e-mail for a changing variety of locally executed e-mail clients is not possible
- 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?
- SSL only protects from the client to the mail server. GPG/PGP can be used to protect the client from end to end.
- 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 hardd isk.
- 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.
- 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.
HighFire Web of Trusted Hierarchy
The applicable trust model depends on the maturation of trust between
the collaborating NGOs. The target end-state is one where a single IceBox
box, owned and supported by any trusted NGO, can provide distributed IceBox
functions for any trusted NGO (e.g., Organization A could host a server used by
Fireboxes owned by Organizations A, B & C). However, this level of efficiency
and capability requires a maturation human trust between people and
organizations which the developers cannot assume exist. Therefore, the
following trust roadmap is assumed for development of the HighFire
system.
- Internal Trust
- NGO owns all IceBox and FireBoxes
- Encrypted and Authenticated e-mail travels within NGO only
- Authentication signatures are verified
- when sent within the NGO only
- Internal Trust with export
- NGO owns all IceBox and FireBoxes
- Encrypted and Authenticated e-mail travels internally and externally
- Authentication signatures are verified
- when sent within the NGO; or
- from an external organization with a public key on the receiving NGO's organization key-ring that is signed by CRF
- Internal and External Transitive Trust
- NGO owns all IceBox and FireBoxes
- Encrypted and Authenticated e-mail travels internally and externally
- Authentication signatures are verified
- when sent within the NGO; or
- from an external organization with a public key on the receiving NGO's organization key-ring that is signed by CRF; or
- from a source with a key signed by another NGO on the receiving NGO's organization key-ring
- Internal and External Transitive Trust with cooperative hosting
- Any NGO (including CRF) in the hierarchy of trust owns and manages IceBox or FireBox.
- Encrypted and Authenticated e-mail travels internally and externally
- Authentication signatures are verified
- when sent within the NGO; or
- from an external organization with a public key on the receiving NGO's organization key-ring; or
- from a source with a key signed by another NGO on the receiving NGO's organization key-ring
If you would be interested in working with our R&D team on IceBox development, please
please contact the project administrator.
[Back to HighFire main page]
|
Overview
IceBox
