160 likes | 247 Views
This academic paper outlines privacy concerns in VoIP services, focusing on secure signaling and data traffic. Recommendations provided to Voice Service Providers (VSPs) and users to enhance transparency, security, and privacy in communications.
E N D
Agenda • Problem Description • Scope • Recommendations
Problem Description • Skype spying on users • Academic paper. • Press article in English • Press article in German • Weak/broken security • Blog post about WhatsApp • Cryptocat: German article / English article • Government surveillance • XKeyscore
Introduction to Communication Protocols • Alice & Bob register with application server. • Alice wants to call Bob. • Signaling message travels to server • Server does a lookup on Bob’s current IP address. • Server sends signaling msg to Bob. • Alice and Bob exchange data traffic.
What route does data take? • What data? • Voice, video, real-time text, text, data • Routing: • “Directly” between the two endpoints • Example: ICE use with XMPP Jingle • Via application servers • Example: Regular XMPP instance messaging • Via some other servers • TURN relays, VPN overlays,Onion routing network • In general, an application provider can influence data path routing.
Extending Basic ScenarioInterconnection Common scenario for VoIP-PSTN interworking.
Typical Questions • What technology is used by the two providers? • What interconnection technology is used? • How many intermediaries are along the path? • What do the intermediaries get to see? (signaling only? Data as well?)
Outsourcing the Identity Provider WebRTC-based JavaScript APIs
Security & Privacy • Protect signaling traffic (hop-by-hop) • Protect data traffic (end-to-end) • Convey identity information (or hide it)
Protect Signaling Traffic • Server-to-Server: • Use TLS (or IPsec) with mutual authentication between servers. • End device-to-Server: • Use server-side authenticated TLS between end device and application server. • Various user authentication techniques deployed. • Protects against eavesdroppers on the wire. • Does not protect against application servers collecting data about user behavior.
Protect Data Traffic • Depends on the assumptions of who to trust and the anticipated capability of the adversary. • There are also challenges in the interworking with existing technologies. • Examples: • ZRTP assumes that calling parties recognize their voice. • DTLS-SRTP assumes that SIP identity protects the fingerprints. • A summary of the requirements and use cases can be found in RFC 5479.
Convey or Hide Identity Information • In the context of VoIP this typically means the calling party identifier (phone number or URI) + contact information. • Two approaches have been developed: • Chain of Trust approach (e.g., P-Asserted-Identity) • Cryptographic approach (e.g., SIP Identity) • Various problems surfaced with the chain of trust approach (which is also used in today’s telephone system) with caller-id spoofing and telephony denial of service attacks. • A more detailed discussion of the topic can be found here.
Recommendations(To VSPs) • Transparency about the Data Collection and Use • What information is collected by whom and for what purpose? What is the retention period? • User Participation • What are the controls for users to control sharing with other users and with intermediaries? e.g., identity information • Ability to review and revoke access to camera, microphone, etc. • Security • Mandatory security for signaling traffic • Mandatory E2E security for data traffic? • Perfect forward secrecy to avoid future compromise? • Protection against unauthorized access • Regular software updates to address vulnerabilities • Privacy-friendly defaults
Recommendations, cont.(To VSPs) • Re-use open standards / open source that enjoyed wider community review ( transparency) • Allow users to choose their identity provider ( competition and choice) • Offer federated use and data portability ( competition and choice) • Preference for cryptographic identity conveyance ( misattribution & intrusion) • Offer capabilities for direct exchange of data ( data minimization)
Recommendations(To Users) • Select application providers operating in jurisdictions you feel comfortable with ( applicable data protection laws)
Final Remarks • Are these recommendations detailed enough? • What is the likelihood that those recommendations will be considered by VSPs? • Should we provide recommendations to other parties as well? (e.g., open source developers, standardization organizations) • How to support innovation in the application space?