On Tue, Jun 08, 2010 at 02:35:24PM +0800, Holger Hans Peter Freyther wrote:

...

Unfortunately merging the branch to master is also not really an option right now, as it is likely to cause trouble with the BSC/MSC split, as we will have to align our encryption support with how the A-Interface between BSC and MSC handles things.

Hi,

merge whatever is ready.

well, it is not ready (as it is untested right now and I had to do lots of manual fixes during rebase) ... and it introduces lots of layer3 code (encryption command, etc) in the regular gsm_04_08.c file... so I'd _really_ prefer to see the BSC/MSC split happenign before causing more obstacles that we need to separate soon later.

In case I have a patch and need some days to stabilize I will ask on this list to hold stuff back. Today I tried to merge some bigger RF Channel Release changes... but I see that I need to kill the refcounts before doing that...

Let me know if there's something I can help with.

On 06/09/2010 03:43 PM, Sylvain Munaut wrote:

Hi both of you,

I guess I must read on on what exactly is MSC domain and what is BSC domain, so far I mostly focused on 04.08 without paying attention to who is supposed to handle what ...

I have not read the code but the split is actual quite easy. Most of it is not in the BSC domain at all. The MSC will send a GSM08.08 message called Cipher Mode Command. It contains the key we will embed into the RSL message. E.g. this is when the subscriber has been authenticated (e.g. the IMSI still in the VLR, or the TMSI making sense).

The Authentication Request is simply wrapped in DTAP and there is nothing special with it from the BSC point of view. Actually everything that is needed for the BSC/MSC split is already inside the GSM 04.08 utils, so anything you put into gsm_04_08.c does not create a problem... (at one point i will replace the gsm48_sendmsg with bsc_dtap_send).

In regard to the MSC side... what will/should change is: 1.) no ref counting for lchan (maybe I start/finish it today) 2.) no direct paging calls, it should go through the subscriber code I had already checked-in.. 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.

please poke me if that does not make sense to you...

z.

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.

Hi Sylvain,

On Wed, Jun 09, 2010 at 09:43:07AM +0200, Sylvain Munaut wrote:

One thing I didn't yet figure out is the HLR part on how to have a neat interface to store retrieve keys / authentication methods available and previous tuples. What's currently implemented is not good, I misuse the AuthTuple thing to store current authentication and not possible tuples to use when we don't know Ki.

I have to check your code. My idea was to have two tables, one for actual keys (ki), and the other one for auth tuples. The tuples would probably need a 'last used' counter, so we can make sure we don't use the most recently used tuples again.

Once we move to a 'more real' HLR, there will be an asynchronous request from MSC to HLR to obtain authentication tuples. Those tuples are then stored in the MSC-internal (volatile) VLR.

...

well, it is not ready (as it is untested right now and I had to do lots of manual fixes during rebase) ... and it introduces lots of layer3 code (encryption command, etc) in the regular gsm_04_08.c file...

Should those go elsewhere ? How should it be split ?

We right now have gsm_04_08.c and gsm_04_08_utils.c... The _utils.c is used from both 'real BSC' and bsc_hack, and the plain 04_08.c is used only by the bsc_hack.

So you actually have it in the right file, I was wrong. Thus, we could merge it. However, this part will nonetheless probably change a lot once we make the split...

I put gsm48_secure_channel (and supporting code) in gsm_04_08.c mainly because it needs to be called when there is a location update request (among other cases) and the loc update handling code is entirely in gsm_04_08.c

sure.

I guess I must read on on what exactly is MSC domain and what is BSC domain, so far I mostly focused on 04.08 without paying attention to who is supposed to handle what ...

I think in general it's quite simple. The BSC handles RR (like channel request, immediate assign, paging), whereas MM, CC, SMS, etc. are handled by the MSC.

Regards, Harald

Hi,

I'll test my updated code tonight and push it to my encryption if it doesn't break.

First off, I tested the code in sylvain/encryption (which is mostly some minor db fixes from me and the code you fw-ported) and it works fine. (you also need my pending branch of libosmocore as I put the utility classmark2 a5 testing func there)

The current limitations are : * Support only 'none' & 'comp128v1' as authentication method. - I need to add 'xor' (for the racal test sim) and 'knowntuples' (for sims with unknown Ki) * Does the authentication part each time currently - I need to add support for using the last tuple. Mostly implies storing the key_seq somewhere from LOC_UPD_REQ until it's needed. * Only support ciphering for Location Updates & MS-initiated calls.

I'll probably do those first two tonight, should be simple enough.

For the last one :

The current flow for a network initiated call/sms is : - Somewhere, paging_request is called (from gsm_04_08 or gsm_04_11) with a given call back - [paging is done] - Then in gsm_04_08_utils handle_paging_resp: - We dispatch an event SS_PAGING - Stop the paging (which calls the call back)

What I would do (and imho helps the bsc/msc split) is create a 'msc_paging_request' somewhere that would wrap the paging. The flow would then be: - Somewhere, msc_paging_request is called (from gsm_04_08 or gsm_04_11) with a given call back. - msc_paging_request calls paging_request with a cb_msc_paging. - [paging is done] - gsm_04_08_utils would _not_ dispatch then SS_PAGING event it self, it would just call back cb_msc_paging given in paging_request - Inside cb_msc_paging, I would then dispatch SS_PAGING event and call the original call back.

Then to add the auth part, I could just modify cb_msc_paging to call secure channel if required.

Sylvain

Hi,

Ok, I've finished what I wanted to do before a possible merge. It now supports Kc re-use and XOR algorithm. Missing things (KnownTuples / MT-Calls encryption) should be pluggable easily afterwards without core code change.

I think it'd be good if someone else could confirm it works as expected tough. To test:

* Enable encryption in openbsc.cfg :

network encryption a5 1

* Put some Ki. (Currently either xor or comp128v1 sims, KnownTuples not supported yet). Easy to do with the VTY interface.

openbsc> enable openbsc# subscriber imsi 001010123456789 a3a8 comp128v1 5e4ab35891375d2aee812e67c309a629

Great.  As zecke can probably consider possible BSC/MSC merge fallout from all of this, I will lean back and let him decide if/how to merge your encryption branch.  Zecke: hope this is fine with you.

Zecke: Ok, I think you can have a look at the current code. It shouldn't have any impact on BSC/MSC split. The impact will come later to support MT-calls encryption but I'll wait for your subscr_get_channel modifs to be done before I look at this.

Cheers,

Sylvain