History

Open {Secure,Source,Standards} Telephony Network (OSTN)

This documentation was written primarily for reporting purposes for the initial grant funded research and development of ostel.co. For the results of the findings and technical details of the software stack, read the ostel.co documentation

OSTN is a de-facto standard by which a voice over internet protocol service can be considered end-to-end secured, with verifiable encryption, minimal logging, and a decentralized model of deployment and use. From this standard, we will work to deploy a network of compliant server/service instances and client software, mobile and desktop, that are federated, audited and interoperable.

Summary

All of the necessary technologies and communications standards exist today to secure realtime voice and video communications. Many proprietary and open source solutions exist for desktop and mobile devices that already implement the necessary bits to provide a solution many times more secure than Skype, without dependence upon one global service provider. Yet people who are security conscious enough to use Skype will still hold sensitive discussion on mobile phones. The problem is simplicity, usability and reliability. This project will provide recommended software for a full stack to build a VoIP backend compatible with existing open source client applications.

OSTN will interface with a variety of projects to ensure compatibility with new standards around peer-to-peer VOIP communication. We have interoperability from other competitive, proprietary solutions and our own implementation as a reference design for privacy and security standards.

This project would not exist without the support of our good friends at Freeborn.Devio.us

Details

Project Output

Client Software

Name OSTN Tutorial License Security Platform Link
CSipSimple Available GPL TLS, ZRTP, SRTP Android http://nightlies.csipsimple.com/
Twinkle In Progress GPL TLS, ZRTP, SRTP Linux <br/>
Telephone &nbsp; &nbsp;? in progress MacOS <br/>
Acrobits Available closed TLS, ZRTP, SRTP iOS http://www.acrobits.cz/27/acrobits-mobile-voip-solutions
Jitsi Available open-source TLS, ZRTP, SRTP Linux, Win, Mac http://jitsi.org/
SFLPhone &nbsp; open-source TLS, ZRTP, SRTP Linux http://sflphone.org/
PrivateGSM Available Closed TLS, ZRTP, SRTP Blackberry, Nokia, iPhone, Android http://www.privatewave.com/
PhonerLite &nbsp; closed TLS, ZRTP, SRTP Windows http://www.phonerlite.de/

Server Software

Application Type
Kamailio Modular SIP server (registrar/proxy/router/etc)
FreeSwitch Multi-protocol softswitch
GNU Sipwitch SIP registrar, call router
Mumble Push To Talk server
Asterisk Multi-protocol PBX
YATE Multi-protocol softswitch

Hosted VoIP Services

Service TLS/SSL SRTP ZRTP Personal Info Reqd Data Retention
ostel.co Yes; RapidSSL RootCA Yes Yes Email
Ekiga
IPtel
Callcentric
Sectel.io Yes Yes Yes Email / Billing Minimal

Legal/Regulatory Concerns

The legal regimes surrounding voice-over IP services varies by country by being aware of the particular details and context for each national legal and regulatory regime, we aim to make sure OSTN functions across borders around the world. According to a recent Ipsos survey, only 14% of internet users in the 24 countries surveyed had used VoIP technology in the past three months. As these services become more popular, legal and regulatory regimes will continue to change.

Use Cases

Some examples illustrating how different the regulation of VoIP can be from country to country and region to region:

User Survey

Ostel Survey

Useful Resources

Infrastructure

For Developers

You can install and run your own instance of OSTN. To do so, visit our Server Documentation.

Research Questions

  • Real-time voice (VoIP) versus Async Voice (Push-to-talk)
  • Is encrypted real-time voice calls the best solution to aim for, or does a push-to-talk model better address issues such as network latency and bandwidth limitations?
  • Is pure standards based mobile SIP/VoIP viable as a solution? Do proprietary extensions need to be made to handle low-power modes and background notifications?
  • Do encrypted VoIP protocols do anything to obfuscated the type of traffic, such to avoid network fingerprint and filtering of all SIP and VoIP communications?
  • How well do public free SIP providers support secure configurations and best practices for protecting user privacy?
  • Can VoIP communications be sent over single or multi-hop proxy services?

Auditing

This work will consist of design a set of criteria for rating the security and privacy capability of various free services and software in order to develop an accurate model of the state of the market and available solutions.

  • Audit security state of main free VoIP service providers
  • TLS, SRTP, ZRTP capable, VPN capable
  • Compatibility with CSipSimple Android open-source client
  • Audit, Compare to RedPhone from WhisperSystems
  • Interoperability between mobile and desktop clients (Jitsi, Twinkle)
  • Audit security state of Freeswitch and Asterisk

Development & Deployment

This work will involve the development of customizations to existing software in order to ensure it is as secured as it can be within its known limits. This includes work on server software, such as Freeswitch, and on client software, such as CSipSimple for Android. All changes will be documented, tested and audited within an initial private testbed of servers. Once a level of stability has been reached, access to this network will be broadened to other qualified users and organizations, all still within the goal of verifying the proposed solutions. In this phase, we will also reach out to other partner testbed and audit projects, including the UC Berkeley DETER testbed, to help better understand how our solution performs in a simulated high-surveillance and filtering environment.

  • Deploy small network of server instances
  • Create customized turnkey Android client that connect to these servers
  • Work with test group of users and organizations to verify from around the globe

Task Detail

  • Auditing
    • Existing software and services will be inspected, tested and vetted
  • Development Sprint
    • Each sprint will last 6 weeks
    • All code will be managed and logged in a public version control system
  • User Testing and Design Review
    • Promote the current stable release of prototype to a select group of users
    • Hold design review meetings with all team, partners and others relevant
  • Publishing Papers / Specifications
    • Publicly share proposal for any new specifications or services
    • Post documentation of best practices determined

Events and press

Summer ostel training
proposal for eyebeam workshop -- http://eyebeam.org/research/calls/request-for-proposals-prism-break-up
SIP Tutorial

Kamailio Resources

ostel.co Kamailio configuration
Build Kamailio on a Raspberry Pi

Rails Generator for Kamailio

Problem: The role of the Kamailio SIP server is misunderstood in a VoIP
backend. This scares otherwise skilled developers away due exclusively to
unfamiliarity.

Answer: Develop a Rails generator and/or plugin which writes out schema and bootstraps models to
represent the required objects for persistance in Kamailio. Write a generator
that creates ugly forms to acquire user input and display data. Branch the
OSTel project to include this plugin. Write a fancy advertisement page and a
tutorial.

Consequences:
  • Kamailio releases have a schema versioning system and so does Rails. Keeping this in sync will be a chore.
  • Configuration management for Kamailio continues to be an issue. Defining all the variables through Rake tasks would be awesome. Currently the user is required to edit text files associated with Kamailio's initial state.

Docker repository for VoIP services.

Problem: The full stack of backend endpoint connections are implicit.

Answer: Each component in the server documentation should be split out into
it's own container. Everything! If it can listen on an IP address, it's in a
container! Network endpoints can be connected by a script on the host OS. Draw
pretty pictures! It's like Qubes but with out the VM overhead!

Consequences: This will require testing the networking system of docker.

  • Is it possible to have symmetric NAT?
  • Can Kamailio use a specific IP address despite the address of the interface in the container?
  • How does rtpproxy proxy work behind NAT?

Also available in: PDF HTML TXT