Encryption branch / BSC-MSC split

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Holger Freyther zecke at selfish.org
Wed Jun 9 09:58:13 UTC 2010


On 06/09/2010 05:45 PM, Sylvain Munaut wrote:

> Ok, when I look back at the code, most of it was gsm_04_08.c only. But
> not all of it. I needed some change in the paging system because once
> a paging succeded, I needed to be able to 'inject' myself before the
> callback was called. (So that I could secure the channel in the
> meantime).

Makes sense. This will certainly be more easy with the split but we need
a dispatcher in the MSC code. That is doing auditing, then does other
stuff, then hands it over to the subsystem, once the subsystem is done,
we can hand it to the next one or close (leaving SMS during a phonecall
out of the picture).


> 
> 
>>        3.) better lchan management and this is where encyrption comes
>>            in. When we have a new connection, we should run it through
>>            auth first... and then hand it to the subsystem.
> 
> One thing that makes a 'transparent' implementation tricky is that a
> CIPHER MODE COMMAND is considered to be an implicit CM SERVICE ACCEPT.
> So what the code did it to offer a simple function to call whenever
> you wanted to secure the channel and offer a callback with the result.

Oh, I didn't know that, that is funny. Well we have two settings here...
one is if we want encryption on, the second is if that subscriber can do
encryption. With what I have in mind, you would get the subscriber
connection (currently embedded in the lchan) on a new connection and
then your function can decide to close the channel, or to secure it and
then hand it to someone else.





More information about the OpenBSC mailing list