Protected Communication Infrastructure (Procom)

Comprehensive project abstract and bid

Introduction

Modern electronic communication tools like ✉ email, ☺ instant messaging, and ✆ telephone systems have made strides in appealing to the public, but fall behind in protecting the information communicated. The protected communication infrastructure will produce deliverables after one year to help bridge this gap.

Please see competing efforts towards the end for a comparison to similar projects.

Target Audience

Procom serves desktop and mobile device users who seek easy communication while excercising their right to privacy via secure channels.

Promotion Strategy

The project gently introduces users to core concepts of protected communication, informs them of current status, and promotes Procom deliverables via education.

Users find this information in:

  • Project websites
  • ‘About’ in software
  • Manuals and documents
  • Conference lectures
  • Application repositories
  • Journals and magazines

Understanding Procom

One-minute Project Presentation Film

Three-minute Overview Starter Film

Legal Basis

The infrastructure upholds the law of United Nations member states. Particularly, article 12 of the universal declaration of human rights ① is considered which states that “no one shall be subjected to arbitrary interference with his privacy, family, home or correspondence.”

① http://www.un.org/en/documents/udhr/

Deliverables, Early Stage

Deliverables include software components and ready to use applications able to connect over common network technology according to staged releases.

Stage 1

Two client applications are made available. Profon RTC is a simple voice over IP application. Prochat WGT is a embeddable chat widget.

Notebook computer running procom chat widgets Mobile telephone running procom video widget
Prochat WGT
Profon RTC

Deliverables, Late Stage (click to expand)

Stage 2

Session border controller (SBC) server applications are made available to offload procom seed service. This allows anyone with system administrator skills and (few) resources to become their own carrier‼ The DNS and STUN based SBC plays the role of a signalling broker, is independent of existing SIP and GSM practices and provides robust operation across diverse network landscapes as expected by users.

Stage 3

Additional client applications are made available. Procam RTC is a web cam video streaming and monitoring application. Promon RTC is a baby phone audio streaming and monitoring application. Protext RTC is a instant messaging application. All communications are protected by the same underlying procom infrastructure.

Mobile telephone running procom video widget Mobile telephone running procom audio widget Mobile telephone running procom text widget
Procam RTC
Promon RTC
Protext RTC

Stage 4

Client applications are made available to serve advanced use cases such as:

  • Email-like (over P2P transport)
  • Skype alternative (audio/video)
  • Joyn alternative (over GSM)
  • Remote control (over GSM)

Stage 5

Additional service applications are provided according to client technology employed. These could include Tor, DNS, HTTP, XMPP, SIP, RTP, and IKE service or routing. The service layer is intended to be reproduced by anyone with the appropriate resources and is documented to this end.

Stage 6

Lastly, developer services include a collection and logical assembly procedure of protected communication building blocks. A high level recipe is provided according to developer requirements (OS, architecture) for implementing a particular use case (voice, video surveillance, text chat, email, etcetera.)

Target Platforms

The infrastructure focuses development efforts on those emerging platforms providing the software manufacturer the most freedom. This includes Firefox OS, Tizen, and Blackberry 10 due to their high degree of web runtime conformance. It includes Sailfish and Ubuntu Touch due to their high degree of standardized (POSIX for example) interfaces.

The target goals doesn't exclude platforms however, and provide logic for systems such as Android, iOS, and Windows Phone wherever practical.

Deployment Strategy

Ubiquity among users is achieved by leveraging technology built into modern web browsers. Namely, in addition to those mentioned (WebRTC, JavaScript, WebSockets) Procom is packaged in web widgets (WGT) for widespread deployment.

Technology Employed

Front end technology includes PhoneGap, Cordova, Appcelerator Titanium, and possibly Rhomobile. These products act as abstraction layers to the native frameworks of mobile platforms lacking HTML5 and JavaScript runtimes.

WebRTC logo describing the next generation WebRTC emerting standard

For its client back ends, the infrastructure leverages WebRTC along with its components controlling mediastreams, peer communication, data channels, and routing. Both DTLS-SRTP and SDES (assuming its standardized inclusion) are implemented through use of existing peer reviewed libraries, and wherever possible ZRTP allow for more comprehensive end-to-end encryption.

A number of JavaScript cryptographic libraries ②③④ exist which are both useful and secure when originating from local storage and parsed by an integrated web runtime.

WebRTC logo describing the next generation WebRTC emerting standard

② http://www.clipperz.com/open_source/javascript_crypto_library/

③ http://code.google.com/p/crypto-js/ (math.random)

④ http://crypto.stanford.edu/sjcl/

☗ Preliminary Design (click to expand)

Regardless of shifting APIs in core technology, a preliminary design proceeds. For more information please refer to the following documents to download.

Legend:
Normal
Important
Geeky!

The purpose of this section is to indicate the general design of Procom, a protected communication infrastructure useful for building network connected communications software. Its scope is small due to the early stage of project negotiations as well as the untested nature of the interface standards involved. The intended audience of this section includes those with knowlege in legacy communications protocols like SIP and XMPP and find value in applying WebRTC technology to similar use cases. The project is named Procom, a contraction of the terms 'protected', 'communication', and 'infrastructure.' The name describes the underlying technology leading to server and client (mostly P2P) products of similar names. The products are rolled out in stages to manage complexity. This preliminary design section is part of a larger project proposal document found on the project website. While there are no prerequisite documents, a software requirements specification is due to appear before release of a detailed design document. A number of background documents exist to complement the preliminary design and are listed above and available for download. A test plan will follow the development of a detailed design document.

System Overview

The software system serves to facilitate communication between parties. Each party consists of an individual person or group of people using a single device to establish a unicast network connection. The initiating party depends on the peer to accept the connection after which data is transmitted and received over a RTCDataChannel in observation of the WebRTC standard. The basic design approach resembles that of a plain old telephone system with added features leveraging WebRTC. An exception to this design relates to automatic peers which reverse the initiation sequence and transmit on a multicast network connection.

Design Considerations

This design attempts to leverage past successes with similar models serving similar use cases. WebRTC, the emerging standard which rests in the core of the system, necessitates a careful review of procedures to broker connections. A number of other considerations exist of which most shall be clarified in comparison to the SIP standard as well as review of existing products using other standards.

Assumptions and Dependencies

The user assumes responsibility for the care and maintenance of a working web runtime in their device. The system depends on target platforms' complete implementation of the core APIs. Namely, RTCPeerConnection, RTCDataChannel, and MediaStream APIs must be available. Hardware allowing the transmission of media as negotiated must be in good working order. In some cases, a low latency network connection provides for speech transmission and in some cases the network must be robust enough to carry UDP datagrams with few errors. Verification and validation is carried out in accordance with the test plan. Support is offered to end users on the project website to address quality goals. The user must be experienced enough to dial a typical modern full screen telephone.

General Constraints

The hardware environment may include battery powered devices which require optimization of energy consuming operations. As the system intends to power a number of platforms, portable APIs of the supporting software environment are prioritized. Time critical services run on client devices which in some cases are low powered, requiring adequate memory. The underlying platform must comply with the following W3C and IETF standards.

Standards

    HTML5 logo describing the next generation HTML quasi standard
  • WebRTC 1.0: Real-time Communication Between Browsers
    W3C Working Draft 10 September 2013
  • Web Storage
    W3C Recommendation 30 July 2013
  • Packaged Web Apps (Widgets)
    Packaging and XML Configuration (Second Edition)
    W3C Recommendation 27 November 2012

The underlying platform must interoperate with WebRTC tests as presented on <website in question>. The system requires IPv4 connectivity in its first release stage. DTLS, SCTP, TCP, and UDP are required. RemoteStorage and LocalStorage APIs are used for data storage. A number of JavaScript libraries and security requirements exist which are not described in this preliminary design.

Requirements

A forthcoming software requirements specification includes functional and nonfunction requirements to be observed.

Goals and Guidelines

Priority to portable APIs and attention to simple constructs dominate the design. In principle, complex behaviour or feature bloat is avoided and high cohesion embodies the design of the system. The project should produce releases that work, look, and feel like an existing product to improve the user experience.

Development Methods

It is expected that few developers work on this project and as such little attention has been given to negotiation of a development method. While the waterfall method is generally avoided, clear software engineering documentation is valued in accordance with the project plan, with a weak intention to apply the agile engineering method.

Architectural Strategies

  • Progressive enhancement applies advanced logic.
  • Graceful degradation protects weak platforms.
  • JavaScript is a central programming language.
  • Software reuse is of importance in controlling costs.
  • Releases are staged to manage complexity.
  • Revision control of source code is distributed.
  • Comments accompany all blocks of source code.
  • Hungarian notation is used whenever practical.

System Architecture

  • A MVC family pattern is applied to manage coupling.
  • The Kernel, core, WRT, and framework form a sandwich.
  • Deliverables are packaged in WGT archives whenever possible.

Policies and Tactics

  • Classic software engineering policy is observed.
  • Open licenses, interfaces, and sources are provided.
  • Releases follow closure of alpha and beta testing phases

Glossary

WRT
Web Runtime
RTC
Real Time Communications
Web RTC
RTC built into web runtimes and browsers
RTCPeerConnection
Session interface of the WebRTC norm
RTCDataChannel
Channel interface of the WebRTC norm
MediaStream
Media interface of the WebRTC norm
Peer
A party participating in communication
Broker
Session establishing server component
SIP
Session Initiation Protocol
RTP
Realtime Transport Protocol
SRTP
Symmetric encrypted RTP
ZRTP
A secure key exchange algorythm
DTLS
Datagram Transport Layer Security
SCTP
Stream Control Transmission Protocol
UDP
User Datagram Protocol
DNS
Domain Name System
SBC
Session Border Controller
NAT
Network Address Translation
ICE
Interactive Connectivity Establishment
STUN
Session Traversal Utilities for NAT
XMPP
Extensible Messaging and Presence Protocol
Jingle
XMPP multimedia session broker protocol
WGT
Standard widget packaged web app
POSIX
Portable Operating System Interface
IETC
Internet Engineering Task Force
RFC
Request For Comments
W3C
World Wide Web Consortium

☂ Preliminary Security Plan (click to expand)

Protection against government censorship and ☣ secret court orders is provided by implementing the ☠ dead man's switch design pattern, in which regular transparency reports indicate lack of manipulation:

☢ The Procom seed service has received zero secret orders from law enforcement and spy agencies. Watch closely for this notice to disappear.

HTTP and Websocket transmissions are encrypted using TLS. Self signed certificates are acceptable in deliverables before stage 5.

Where conditions (bandwidth, latency, technology, use case) allow, defense against surveillance is improved by means of IP route anonymization on OSI layer 7 and data encryption on OSI layer 3.

↺ Reuse Strategy and Review

Being that code and concept reuse from existing solutions is maximized, a careful review of other projects must be undertaken. Key concepts receiving scrutiny include:

  • End-to-end encryption
  • End-to-end authentication
  • End-to-site encryption
  • End-to-site authentication

…with implementation of the most practical match to the use cases motivating the project and attention to avoid storing keys on any server.

Integration and Compatability

As the number of candidate mobile platforms and associated communication standards mature, the utility of tactics employed depends on a clear understanding of interoperation. Research will determine just which combinations are practical and how far to take the principle of implementing the least common denominator.

Interoperability

A mobile client built on the infrastructure determines the standard technology in use and interoperate with other clients regardless of manufacturer. An example of this procedure could involve inspection of URI syntax, and resolution (with security implications) of DNS based (ENUM, SRV, NAPTR) and local (contacts database) communication endpoints.

Future Undertakings

If Procom grows to include email protection or digital commerce (like bitcoin), it will likely reach such distant goals after consideration of a carefully planned road map.

Competing Efforts

A number of other groups have produced infrastructure falling short of the goals stated here, despite similar intentions and interests. Regardless of this, outreach has resulted in ongoing cooperation with important competing project developers.

† 1st Generation Failures (click to expand)

A number of proprietary infrastructures allowed for communication, but forbid peer review or required nonstandard extensions or plugins to work. Such RTC implementations included Flash ⑤, Silverlight ⑥, and Java ⑦. While solving the email use case, pretty good privacy (PGP) ⑧ failed to solve others as well as being too complicated for most tastes. Others like Skype and WhatsApp achieved notoriety for bait and switch tactics swaying users from open standards.

⑤ http://www.adobe.com/devnet/flash.html
⑥ http://msdn.microsoft.com/silverlight/
⑦ http://www.java.com/
⑧ http://www.ietf.org/rfc/rfc4880.txt

✕ 2nd Generation Ventures (click to expand)

Other infrastructures mostly conforming to standards include those manufactured by Whisper Systems ⑨, Silent Circle ⑩, Wickr ⑪, and Heml.is ⑫12. Although their implementations are open source they lack portability, in all cases producing code appropriate for a fraction of the mobile platforms available.

Additionally, many of these solutions enforce a business model through requirement of a opaque server component, reducing freedom of choice in network topology ☍.

⑨ http://www.whispersystems.org/
⑩ http://www.silentcircle.com/
⑪ http://www.mywickr.com/
⑫ http://www.heml.is/

✓ Best of Breed Contenders

Cryptocat ⑬, Scramble ⑭, and Mailpile ⑮ deserve special mention in that they almost fulfill the project interests. While components taken from them could be be reused, unfortunately these projects fail to completely meet all goals.

⑬ http://www.crypto.cat/
⑭ http://scramble.io/doc/
⑮ http://www.mailpile.is/

Venture Funding

Arrow pointing to the right

The Procom project is presently seeking an investment partner to work with existing management and engineering staff. For information, please contact management .

A business plan is available on request.

The file or operation you chose is not available due to the early stage in which the project still finds itself. Please try again another day.

Press Materials

Michael Schloh von Bennewitz is a computer scientist specializing in network software, mobile computing, and client server design. Responsible for development of network software and maintanance of packages in several community software repositories, Michael actively nourishes the Opensource development ecosystem.

Michael additionally speaks at technical events every year. He has lectured for companies and events including Cable & Wireless, Nokia, Intel, the Linux Foundation, Mobile World Congress, DroidCon, AstriCon, and ClueCon.

Fake signature vector

For more about Michael see

More Information

For more information about Procom, please visit http://procom.europalab.com/ or ✍ contact engineering via email.

Member of The Internet Defense League IPv6 logo