From: Kurtis H. <khe...@cs...> - 2011-05-22 02:31:30
|
As an ongoing research project, we generally don't really understand what we intend to do either. One of the points of this email is to clarify exactly that, so thanks for pointing out that issue. As far as the Tor layer, because the BTS is the only mechanism for network access to the users (via GPRS or GSM), it's an optimal place for an anonymity middle box. Basically, the application I envision allows users to send an SMS to the BTS, which then sends ALL of that user's traffic through an anonymization layer (such as Tor, or a VPN link). This will allow for some modicum of privacy for even legacy handset owners. VoIP traffic (GSM), general internet, or even messaging could go through these layers. Advanced users (with advanced phones) can of course harden their phones using more traditional "end-to-end" encryption. Of course, being a middlebox, it invites a variety of attacks. There's no way for the handset to ensure the communications are encrypted and secured, for example. As another, the BTS owner could likely undermine any of these measures via basic machine learning or port tracing. However, this is better than the current state of the art, where legacy (dumb) phone users know that ALL of their communications are inherently insecure, and at locations very far from their homes. Does that make more sense? I'd love more feedback, the privacy layer isn't as well reasoned as some other research "planks" in this project. I'm personally most worried that we're not resolving any real world problems (an issue I generally have with liberation technology as a field...), but I'm going to meet with some human rights folks soon. That might help. Thanks again! On Sat, May 21, 2011 at 6:28 AM, Anders Brownworth <and...@gm...> wrote: > Kurtis, > > We're using FreeSWITCH with OpenBTS. Your project and goals sound very > interesting. I don't really understand what you intend to do with the > privacy aspects. Short term / dynamic phone numbers are clear but how > do you intend to implement a security layer higher up without support > in the handsets? (I'm thinking about Tor) or are you doing something > on the handsets as well? > > -Anders > Bandwidth.com > > Sent from my iPhone > > On May 20, 2011, at 3:40 PM, Kurtis Heimerl <khe...@cs...> wrote: > >> Hello OpenBTS-discuss! >> >> This is an email I sent out to the freeswitch mailing list a week ago, >> asking that community for their feedback on our goals regarding >> OpenBTS. I've decided to send it to this mailing list as well, given >> your in-depth knowledge of OpenBTS. The short version is that we're >> modifying freeswitch to operate better with OpenBTS, allowing for new >> applications co-located on the base station itself. >> >> As an example of an artifact that should come out of this work, I've >> been working for the past few days on porting (or rewriting, that >> debate is ongoing) smqueue to freeswitch, preferably as a freeswitch >> module. This should allow application developers to make OpenBTS >> shortcodes in a much more intuitive (and modular) manner than what's >> currently out there. >> >> Are any of you using freeswitch for your OpenBTS deployments? Is there >> anything else you think should be added to support "local" >> applications? >> >> The original message follows: >> >> My name is Kurtis Heimerl, and I'm a graduate researcher at the >> University of California, Berkeley in the Technology and >> Infrastructure for Emerging Regions (TIER) group under Eric Brewer. >> We're currently investigating the use of OpenBTS >> (http://openbts.sourceforge.net/) for providing cellular coverage via >> low-cost base stations in low-density parts of the world. This project >> is called The Village Base Station. In support of that project, we're >> also investigating the use of Freeswitch to support OpenBTS and >> provide a flexible, extensible, and simple platform for deploying >> voice/sms/data applications on the basestation itself. Towards this >> end, I'm asking you, the freeswitch community, for advice and >> direction on some of our research goals. >> >> The basic story is simple. OpenBTS uses a software radio and generic >> PC to provide cellular service. As a byproduct of this architecture, >> we also gain the ability to run freeswitch applications "locally" >> (concurrently with OpenBTS), and take advantage of the benefits this >> tight coupling provides us. These benefits are numerous; calls/SMS >> between BTS users can be much cheaper, as they do not use any backhaul >> bandwidth. Applications can query the system for more information >> about users, such as location or status. As an example, unlike >> traditional GSM telephony applications, we are able to query if users >> are currently available on the network. This could be used to create >> voice "chat lists", which tell participants which of their friends are >> currently within cellular range. >> >> We foresee 6 features required to support these "local" freeswitch >> applications on our OpenBTS system. I'm very curious how the >> freeswitch community feels about these possible additions, as well how >> they might be implemented. >> >> There are a few that are already available in freeswitch, but may be >> rougher than we would like. These include: >> >> 1) Identity: The ability to query for user's status, numbers, etc. >> This seems simple enough in the existing system. However, we'd like to >> provide hooks for applications to act on these sign-ons or offs. For >> instance, an app may hold messages until a phone logs onto the system >> and push them then. My understanding is that this should be simple, >> probably hooking onto "SIP presence" events? >> 2) Storage: Freeswitch currently seems to support only per-application >> storage, with limited support for cross-application storage (mostly >> user directories). This is occasionally problematic: one issue we've >> heard is that it is difficult to place messages into voice mailboxes >> from other apps. We'd like a more unified storage framework. Or... >> 3) "Pipes": This is the ability to pass messages between freeswitch >> apps. This seems pretty well supported though simple dialplan >> interactions, though the modules themselves may not provide enough >> functionality. Is there a way to do this inside of apps? I consider >> this an alternative to the storage framework discussed in #2 >> >> Lastly, there are three functions we don't believe are well-supported >> in freeswitch. These are... >> 1) Privacy: We expect our BTS to be used in politically sensitive >> areas. Given this, freeswitch could provide an anonymity layer, >> providing short term phone/SMS numbers, or directing communications >> through more secure layers (e.g., Tor). >> 2) Asynchrony: While freeswitch seems to support basic asynchrony >> though its event system, I couldn't find any way to delay events for >> indeterminate times. For instance, we may want to schedule a traffic >> warning for 1PM every Wednesday to every phone currently on the >> system. Is there a way to do that currently? >> 3) SMS: Freeswitch seems to currently support SIP chat messages (using >> SIMPLE?). We need to either extend OpenBTS to speak SIMPLE, or extend >> freeswitch to speak OpenBTS's SMS protocol. Neither seems particularly >> difficult. This will allow our apps to send and receive both voice and >> SMS messages from users. >> >> We believe these core functions will enable a wide variety of BTS >> applications. I have a laundry list of those, but I'll omit them for >> sake of space. >> >> If any members of the community (that means you!) have any directions, >> ideas, projects, or thoughts, please pass them on! We're just >> beginning this part of the project, and getting the lay of the land. >> Feedback is critical at this point. >> >> Thanks! >> >> ------------------------------------------------------------------------------ >> What Every C/C++ and Fortran developer Should Know! >> Read this article and learn how Intel has extended the reach of its >> next-generation tools to help Windows* and Linux* C/C++ and Fortran >> developers boost performance applications - including clusters. >> http://p.sf.net/sfu/intel-dev2devmay >> _______________________________________________ >> Openbts-discuss mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openbts-discuss > |