Authentication and Encryption

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/.

Harald Welte laforge at gnumonks.org
Sun Jul 12 16:21:08 UTC 2009


Hi Dieter,

On Sun, Jul 12, 2009 at 04:50:48PM +0200, Dieter Spaar wrote:
> To implement it in a clean way in my opinion requires some discussion
> about how to do it so that it fits into the architecture:
> 
>   - When do the authentication, most certainly during the first
>     Loacation Update, but when else ?

I think first location update (until imsi detach) is fine for now. It
can always be extended later on.

What's probably more important is to enable the encryption (CIPHERING MODE
COMMAND) for every radio channel that we establish for that MS.

The entire auth+crypto should be enabled/disabled by a global switch, in
case somebody wants to typically have it, but disable it temporarily
in order to be able to obtain plaintext Um interface traces.

>   - Where to store the subscriber Ki for authentication and the
>     information about which algorithm is used ? Also store for each
>     subscriber if authentication and/or encryption should to be used.

yes, each subscriber needs the following information:
* which auth algorithm to use (none,xor,comp128v1)
* which crypto algorithm to use (a5/0,1,2)
* the secret data (Ki) for that particular algorithm
* the currently-allocated Kc

I would simply also store all that it in the sqlite database.

It makes sense to put all this authentication related information into
a separate table, indexed and referenced by the subscriber ID.  The rationale
is that later (when using real SQL databases) we might want to have different
permissions on the regular subscriber data than on the authentication data.

>   - Where to cache Kc, its not necessary to authenticate every time when
>     encryption for a channel is turned on. Kc from a previous
>     authentication can be used several times.

yes.  I think a typical value in production networks is: something like 4 calls
/ sms and then re-authenticate.  The Kc should be cached in the sqlite
database, too.

>   - Where to turn on encryption, every time a channel is allocated ?

yes, of course only if the subscriber database indicates that this subscriber
is to use encryption.

> Those are just a few thoughts. I guess discussion about the details
> probably takes longer than if you or Holger implement it during your
> ongoing work on OpenBSC. 

I'm not so sure about that.  I'm very busy and have a long todo list, so I'm
always happy to see somebody else taking care of relatively self-contained
features...

> Currently you both are the main people working on OpenBSC at several places
> of the implementation and a clean integration of authentication and
> encryption affects a lot of those places too. I am reluctant to interfere
> here, not because of the time it takes (its not that much) but because any
> changes should fit to what you plan to do. If anyone want to see the
> technical details, I can provide them, its rather simple and straightforward.

Mh. If Holger thinks it is causing interference with his work, I think we
should probably delay encryption/authentication until the BSC/MSC functional
split has been matured and merged in the code.

As for myself, I'm doing a lot of GSM related work right now, but it's not
actually extending OpenBSC that much, more reverse engineering some more bits
about the ip.access protocol extensions, writing wireshark code, as well as
work on a A-bis proxy (between BTS and BSC), allowing for OML and RSL packet
injection into the live connection, as well as a scapy plugin for
crafting/fuzzing 04.08, RSL and OML packets.  Using that infrastructure it
should be possible to do a lot of things such as
* fuzzing packets sent to the MS (MS software stability)
* fuzzing packets sent to the BTS (BTS software stability)
* fuzzing packets sent to BSC/MSC (network software stability)

Among other things, this can also be used to generate test cases for OpenBSC
and to work on OpenBSC protocol parsing stability, too.

The only part of OpenBSC that I plan to work on during the next weeks is
the SMS implementation and system information generation.  And if I find more
time after that, GPRS.

None of that should clash with support for encryption/authentication.
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)




More information about the OpenBSC mailing list