Project HighFire:

Development Page

Table of Contents

• HighFire Project Phases in Detail
• HighFire Development Team
• Relevant IETF RFCs

HighFire Project Phases in Detail

The HighFire development project duration will be approximately 12 months, Apr. 2003 - Mar. 2004, with continuing support, and ultimately leading to ongoing production of post-development systems in 2004 forward. The development cycle includes five inter-dependent phases:

• Phase 1: Communications Needs Assessment (Research, Surveying, Outreach)
• Phase 2: Alpha Development (Engineering, Internal Testing)
• Phase 3: Beta Development (Refinement, Documentation)
• Phase 4: Beta Trials (Field Deployment & Training
• Phase 5: Support & Client Services (Tech Support, Testing & Reporting, Further Refinement)

Phase Chart:

CRF is presently in the Needs Assessment and Alpha Development phases of the project, having launched the Communications Assessment Tool (CAT) for the project, at the Computers, Freedom & Privacy Conference, New York, Apr. 2, 2003. Our ongoing development at present focuses on infrastructure and components that will be required regardless of the CAT survey results.

Phase 1: Communications Needs Assessment

CRF is currently identifying ideal NGO participants to help us ensure that the result of the HighFire project is an optimum solution tailored for the real-world needs of human rights groups. Our Communications Assessment Tool (CAT) survey will allow the development work to be informed by an understanding of end-users' communications technologies, capabilities and limitations. CAT will also generate an analysis for participating NGOs, detailing where their security needs are not currently met.

For more detailed information on the CAT survey, please see the CAT homepage.

Phase 2: Engineering (Alpha Development)

Based on the NGO participants' input, CRF will develop two HighFire system components (both including hardware and software).

1. The IceBox secure communications server will form part of a network of distributed servers providing secure e-mail service and storage. 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).
2. HighFire's "FireBox" component will be 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 network. 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.
   Configuration: FireBox can be configured one of two ways, depending upon uplink conditions and security level required. When less security is needed, the user may download their mail to the FireBox (e.g. when there is only a poor or expensive connection to the Internet available, not an always-on connection, and repeated accessing of the IceBox would be difficult or prohibitive.) When highest security is needed, mail is kept only on the IceBox, despite the potential expense or loss of convenience.

Phase 3: Refinement & Documentation (Beta Development)

The beta development phase will introduced further refinements based on user requirements and input regarding the proof-of-concept model (alpha product), with a focus on feature prioritization to mature the product to a full beta release for broader, non-internal testing and use. Also in this phase, CRF will develop documentation and training materials for the users and administrators of the beta systems. (This is essential, as the lack of adequate documentation and training easily leads to adoption failure, and is currently one of the principal reasons for the poor public deployment and use of communications security tools.)

Phase 4: Field Deployment & Training (Beta Testing)

While the design of HighFire should minimize the necessity for support, CRF recognizes on-site installation and training may be required during the Beta trials.  In this phase, CRF Client Services will send trainers and technicians into the field to the NGO sites to deliver, install and configure the HighFire systems and train the local NGO users and admins in their proper operation, including a server administrator training and certification program. CRF has pre-selected several locations for these field services based on previous fieldwork and existing NGO relationships. At CRF HQ in the US, we will set up a secure IceBox hosting facility and provide all administration of the actual e-mail services while phasing in the NGO system admins, who will eventually take over complete control of their own organizations' systems, ca. 2004.

Phase 5: Tech Support, Testing & Reporting (Client Services & Followup)

In this phase, CRF will provide technical support for all system components via e-mail, Web forms, telephone and/or fax to the participating NGOs. CRF's Client Services & R&D teams will conduct usability studies of the effectiveness of the system, of user satisfaction and of system performance. This data will be collated by CRF and presented to the NGO participants, CRF's funders and the general public in regular CRF Journal reports, published on paper and online.

HighFire Development Team:

Project Manager:

• John Nanninga, HighFire project administration

Principal Investigators:

• Dr. David Chaum, cryptography
• Dave Del Torto, security architecture
• Dr. Steve Mann, computer science

Engineering Team:

• John Nanninga, engineering management
• Bill Frantz, security engineer
• Mark Holtz, security engineer
• Jim Morris, security engineer
• Brian Peterson, security engineer
• Walter Torres, security engineer
• Aaron van Meerten, security engineer
• Josh Vermette, security engineer
• Dave Del Torto, public key architecture
• And generous volunteers among the human rights-friendly open-source security community

Documentation & User Interface Team:

• Stanton McCandlish, documentation management

If you can contribute to this project, please contact the project administrator.

Relevant IETF RFCs

Overview RFCs

• 2401 Security Architecture for the Internet Protocol
• 2411 IP Security Document Roadmap

Basic protocols

• 2402 IP Authentication Header
• 2406 IP Encapsulating Security Payload (ESP)

Key management

• 2367 PF_KEY Key Management API, Version 2
• 2407 The Internet IP Security Domain of Interpretation for ISAKMP
• 2408 Internet Security Association and Key Management Protocol (ISAKMP)
• 2409 The Internet Key Exchange (IKE)
• 2412 The OAKLEY Key Determination Protocol

Details of various things used

• 2085 HMAC-MD5 IP Authentication with Replay Prevention
• 2104 HMAC: Keyed-Hashing for Message Authentication
• 2202 Test Cases for HMAC-MD5 and HMAC-SHA-1
• 2207 RSVP Extensions for IPSEC Data Flows
• 2403 The Use of HMAC-MD5-96 within ESP and AH
• 2404 The Use of HMAC-SHA-1-96 within ESP and AH
• 2405 The ESP DES-CBC Cipher Algorithm With Explicit IV
• 2410 The NULL Encryption Algorithm and Its Use With IPsec
• 2451 The ESP CBC-Mode Cipher Algorithms
• 2521 ICMP Security Failures Messages
• 3156 MIME Security with OpenPGP

Older RFCs which may be referenced

• 1321 The MD5 Message-Digest Algorithm
• 1828 IP Authentication using Keyed MD5
• 1829 The ESP DES-CBC Transform
• 1851 The ESP Triple DES Transform
• 1852 IP Authentication using Keyed SHA

RFCs for secure DNS service, which IPsec may use

• 2137 Secure Domain Name System Dynamic Update
• 2230 Key Exchange Delegation Record for the DNS
• 2535 Domain Name System Security Extensions
• 2536 DSA KEYs and SIGs in the Domain Name System (DNS)
• 2537 RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)
• 2538 Storing Certificates in the Domain Name System (DNS)
• 2539 Storage of Diffie-Hellman Keys in the Domain Name System (DNS)

RFCs labelled "experimental"

• 2521 ICMP Security Failures Messages
• 2522 Photuris: Session-Key Management Protocol
• 2523 Photuris: Extended Schemes and Attributes

Related RFCs

• 1750 Randomness Recommendations for Security
• 1918 Address Allocation for Private Internets
• 1984 IAB and IESG Statement on Cryptographic Technology and the Internet
• 2144 The CAST-128 Encryption Algorithm

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

[Back to HighFire main page]