Skip to content

Instantly share code, notes, and snippets.

@kmontenegro
Last active July 12, 2017 23:51
Show Gist options
  • Save kmontenegro/b8b8cf58529825f116382a5b1e0e0b8e to your computer and use it in GitHub Desktop.
Save kmontenegro/b8b8cf58529825f116382a5b1e0e0b8e to your computer and use it in GitHub Desktop.

More Secure Communications for Incident Intake

Background

I work at a legal services nonprofit where the direct legal services team is always challenging or inviting the technology team to help us all do our work better. Sometimes, the "better" takes the shape of securing existing workflows.

We have a legal hotline that handles over 5 Asian languages. Some of these calls are immigration related where an individual might be "out of status" or "without lawful presence". For these calls, and other sensitive work like family law, expungements, etc, we're exploring what options exist to do intakes in a way that reduces the digital footprint of the person seeking assistance and scales beyond one person.

Tangent: I'm using incident response instead of rapid response because incident response has a framework that might be very helpful in a social movement and access to justice context that is missed by "rapid response" which is sometimes neither rapid nor an affirmative response.

Tool Options

We've looked at the following tools:

  • native PBX
  • outsourced PBX
  • Signal
  • Wire
  • OSTel

Native PBX

Currently, we deliver the hotline service through a traditional PBX with call-center features enabled. These features allow us to track things such as average hold/wait time; hang-up/abandon rate; volume handled by call center staff; and call duration. Ideally, a secure solution would allow us to have these important metrics AND add an element of security.

Challenges with securing traditional system is that they are built to run like a tank and be accessible. Software updates from the manufacturer are not very frequent and features such as SRTP and ZPhone are not implemented in a practical way.

Moving to something like an Asterix, FreeSwitch, or other on premise PBX would solve only part of the equation as though these PBXs would support SRTP and maybe ZRTP, they wouldn't address what happens to data once it leaves our network or how the phone signal/data would have to accept both secure and insecure endpoints.

Which, unless folks are exchanging keys or certificates between PBXs, I think the search for a more secure PBX is hopeless. It's also important to remember that a traditional phone system is insecure from a eavesdropping/surveillance point of view.

Outsourced PBX

An outsourced PBX, like Telzio, has lots of promise because there are staff both securing those systems as well as putting important items on their development roadmap. Telzio has "secure calling" on their roadmap but, due to issues raised above, it remains to be seen what the implementation would look like. Inter-domain securing is really hard.

As with all outsourced or cloud services, the other issue is figuring out what data looks like both in transit and at rest because, if not encrypted there, all hope of privacy is lost.

Finally, with an outsourced PBX, the questions of notification of subpeonas, data breaches, and metadata are larger issues as an outsourced provider is a big tree with lots of fruit versus the smaller office which may have fruit but not in the same quantity. Metaphor pointer...fruit = data.

Signal

When "digital security" training was becoming au courant, there was the illusion that installing Signal was all you needed to do for secure communications. While I appreciate Signal, there's an unreasonable expectation of Signal being the solution to secure communications.

When I have organizational conversations about security, I make it a point to remind folks that security is really hard to scale. Signal is a great example of that. Not only do you have to have folks using Signal at both end-points to securely communicate, folks should be doing it on secured devices...and how do you create a hotline for this to happen? There isn't a way.

A point raised by a wise comrade at Access Now also highlighted the issue of voice verification...how do we know the person who called me from 213-555-1212 is the same person who I talked to last time at that number? Moreover, how can I build redundancy so that number is ringing on multiple end-points so that it works like a call-center. You can't do that with Signal.

A good work-around is to use the secure SMS feature in Signal so you can have 6 people communicate, via text, with folks needing help. All you'd have to do is buy a smart phone like this and a SIM card. Once you have those two elements, you can have folks secure SMS to the secure number, assuming they're using Signal, and whomever has had Signal installed on their desktop can communicate with them by SMS. Directions for Signal Desktop are here.

Drawback: moving away from call-center to SMS exchanges which leave out low-literacy communities and present documentation challenges.

Wire

I like Wire. It's a good platform that's open source and lets you host your own Wire server for secure voice and video. Of course, the challenges are multiple:

  • You need folks to jump on the Wire client
  • Not all the pieces of the Wire server are currently available...and when they are, you're going to need a technologist to spin up the server and address issues of what relatively secure hosting would look like

The other issue with Wire is that it allows association with a phone number and an account name which might present metadata challenges (e.g. unless you're very intentional at setup which folks looking for incident response are often not).

Ostel

The Open Sourced Telephony Network had lots of promise but it seems that project development has stalled or been abandoned. It is still usable but, based on feature-set and usability, Signal meets the functionality Ostel used to provide in a way that is substantially more transparent and functional.

Were this project under active development, and PBX integration possible, it would be a strong contender for secure voice communication. But, again, between Signal and Wire, there isn't a feature that would make Ostel a recommended solution.

Pseudo-Conclusion

Vernacularly, my assessement of this challenge is "esta cabron".

I believe the big challenge is that to do relatively secure communicatiosn we have to be on the same platforms using the same protocols. We're very far from that.

I also believe the closesst model for a solution is Signal, particulalry for community oriented incident response scenarios. The startup cost are negligible and, apart from making sure the handset is secured and frequently updated (both phone software & Signal), it's a relatively low maintenance solution. There's also the issue of making sure someone is tracking utilization so that the SIM card does not run out of minutes or data.

@kmontenegro
Copy link
Author

While this is somewhat dated, the anonymizing approach is solid and can serve as a template if the functional requirements warrant such precautions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment