RE: OpenBSC Digest, Vol 35, Issue 30
HI,
My name is Goran, I have femto cell would like test osmo iuh. Installed libosmocore on debian server, but got lot of problems with osmo IuH compiling. Curenlty I am stucked with osmo-sccp library.
Also tried Vagrant IuH image, but there is issue with permisions,
Is there a way to get some help for solving this issues,
Thanks
Goran
-----Original Message-----
From: OpenBSC [mailto:openbsc-bounces@lists.osmocom.org] On Behalf Of openbsc-request@lists.osmocom.org
Sent: Thursday, September 28, 2017 4:36 AM
To: openbsc@lists.osmocom.org
Subject: OpenBSC Digest, Vol 35, Issue 30
Send OpenBSC mailing list submissions to
openbsc@lists.osmocom.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.osmocom.org/mailman/listinfo/openbsc
or, via email, send a message with subject or body 'help' to
openbsc-request@lists.osmocom.org
You can reach the person managing the list at
openbsc-owner@lists.osmocom.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..."
Today's Topics:
1. Re: branches in openbsc.git (Harald Welte)
2. Re: randomness of identifiers (Harald Welte)
3. Re: Retrieve OP from OPc and Ki (Harald Welte)
4. Re: ctrl interface: GET a variable with parameter (Harald Welte)
5. Re: Retrieve OP from OPc and Ki (Kathryn Heckman)
6. Re: Retrieve OP from OPc and Ki (Mychaela Falconia)
7. Re: Retrieve OP from OPc and Ki (Tomcs?nyi)
----------------------------------------------------------------------
Message: 1
Date: Thu, 28 Sep 2017 07:05:09 +0800
From: Harald Welte <laforge@gnumonks.org>
To: Neels Hofmeyr <nhofmeyr@sysmocom.de>
Cc: openbsc@lists.osmocom.org
Subject: Re: branches in openbsc.git
Message-ID: <20170927230509.pw4xug7jntrfvts2@nataraja>
Content-Type: text/plain; charset=us-ascii
On Thu, Sep 28, 2017 at 12:22:31AM +0200, Neels Hofmeyr wrote:
> another call for anyone aware of important branches on openbsc.git to
> please name them, so that they can be migrated to the new repositories.
> But foremost, please name them, thanks!
>From "my" branches, I can see the following:
* laforge/bssgp_fc -> osmo-sgsn
* laforge/gprs-suspend -> osmo-bsc
* laforge/power_control -> osmo-bsc
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
------------------------------
Message: 2
Date: Thu, 28 Sep 2017 07:15:01 +0800
From: Harald Welte <laforge@gnumonks.org>
To: Neels Hofmeyr <nhofmeyr@sysmocom.de>
Cc: openbsc@lists.osmocom.org
Subject: Re: randomness of identifiers
Message-ID: <20170927231501.zyqrali3onodi4iw@nataraja>
Content-Type: text/plain; charset=us-ascii
Hi Neels,
On Wed, Sep 27, 2017 at 06:06:48PM +0200, Neels Hofmeyr wrote:
> On Wed, Sep 27, 2017 at 07:57:43PM +0800, Harald Welte wrote:
> > For TMSI allocation, my "cryptographic gut feeling"[tm] is that
> > something like rand() or any other pseudo-random generator of
> > significantly large period is sufficient *if* it is seeded by a
> > non-predictable value. So something like seeding with getrandom() result should be fine?
> Might also make sense to periodically re-seed from /dev/urandom /
> getrandom(), like every 100 TMSIs, or based on a timeout might be
> easier to implement.
I would try to avoid any predictability here. Having a fixed time interval would be known to an attackers. So if he was somehow able to reduce/exhaust the entropy at the known time for re-seeding, it would be bad.
Similar for "every 100 TMSIs", which is something under control of any attacker as he can control the number of location updates via the public radio interface [to some extent] and thus control the time at whcih re-seeding is done.
Maybe I'm going overboard here, but I think if you want to re-seed, you want to ideally do it at a non-predictable and non-controllable point in time. Like a random time interval ;)
> > For long-term stable key (Ki/Op) generation for provisioning SIM
> > cards + populating a HLR, I would certainly opt for using stronger
> > randomness sources. However, I don't think we actually implement
> > that anywhere, do we?
>
> what does openssh use for public/private keypair generation?
I'm not sure you can compare the requirements for generation of RSA public/private keys with those for generation of symmetric keys. You can find different recommendations in the literature. But I guess that's mainly due to the fact that people usually assume you have long-term stable public/private keys and short-lived symmetric session keys. In our case, it's long-lived symmetric keys.
But as indicated, I think our focus is to find a proper solution for generation of TMSIs and for random numbers used in authentication challenges. K/OPc pair generation is not supported in current Osmocom tools anyway, as we presume the SIM cards already have sufficiently random key material and those keys are entered into the HLR.
Regards,
Harald
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
------------------------------
Message: 3
Date: Thu, 28 Sep 2017 06:52:28 +0800
From: Harald Welte <laforge@gnumonks.org>
To: Kathryn Heckman <exuberant.kathryn.heckman@gmail.com>
Cc: "openbsc@lists.osmocom.org" <openbsc@lists.osmocom.org>
Subject: Re: Retrieve OP from OPc and Ki
Message-ID: <20170927225228.u4udbuhk2fyebrl5@nataraja>
Content-Type: text/plain; charset=us-ascii
Hi Kathryn,
On Wed, Sep 27, 2017 at 05:37:36PM -0400, Kathryn Heckman wrote:
> Is there any way to retrieve the value of OP from OPc and Ki?
No, that defeats the entire purpose of having card-individual OPc values.
If you could just revert that operation, there would be no [security] advantage of card-individual OPc values over a global OP value, and hence that entire option could be dropped from the specifications altogether.
Regards,
Harald
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
------------------------------
Message: 4
Date: Thu, 28 Sep 2017 06:50:03 +0800
From: Harald Welte <laforge@gnumonks.org>
To: Neels Hofmeyr <nhofmeyr@sysmocom.de>
Cc: Holger Freyther <holger@freyther.de>, openbsc@lists.osmocom.org
Subject: Re: ctrl interface: GET a variable with parameter
Message-ID: <20170927225003.ix4qgulake4gugyu@nataraja>
Content-Type: text/plain; charset="us-ascii"
Hi Neels,
On Wed, Sep 27, 2017 at 05:27:38PM +0200, Neels Hofmeyr wrote:
> Also we do have a concept of nesting CTRL nodes separated by dots in
> the variable name, looking at bsc_ctrl_node_lookup() and fsm_ctrl_node_lookup().
correct.
> I notice though that we do still have open doors for a lot of nonsense
> being sent to it without proper validation or error messages.
>
> GET 42 existing-variable.trailing.names.ignored more nonsense
> following being ignored
>
> in effect is identical to:
>
> GET 42 existing-variable
>
> So we should probably enforce that there is no ignored nonsense...
I agree.
> Should we also enforce a numeric command ID?
I'm not following here. Where would that numeric command ID comning from?
> GET currently-any-id-is-possible-even-\t-\n-is-accepted my-command
this is also not intended, I'm quite sure.
> Going back to the OsmoHLR CTRL commands -- they are implemented in a
> way that doesn't match the CTRL interface ways. Let's collapse them.
>
> SET enable-ps <IMSI>
> SET disable-ps <IMSI>
> SET status-ps <IMSI>
indeed, this is not proper.
> SET subscriber.by-imsi.123456789098765.ps-enabled 1
> SET subscriber.by-imsi.123456789098765.ps-enabled 0
> GET subscriber.by-imsi.123456789098765.ps-enabled
makes a lot of sense to me.
> We can also expand this later to things like
>
> GET subscriber.by-imsi.123456789098765.status
> SET subscriber.by-imsi.123456789098765.msisdn 2345
> GET subscriber.by-msisdn.2342.status
> SET subscriber.by-msisdn.2342.ps-enabled 0
> GET subscriber.by-imei.987654321234565.imsi
looks good!
> We could leave the enable-ps, disable-ps, status-ps commands in place
> in case anyone is using it yet. I assume no-one is though.
I don't think we need to keep compatibility at this point.
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi Goran, Without any exact details, like error messages and commands that you tried we cannot give you much help sadly. Please provide all details possible in text format, and I’m sure someone will help. Regards, Domi 2017. szept. 28. dátummal, 11:18 időpontban Popovic Goran <Goran.Popovic@kapsch.net> írta: > HI, > My name is Goran, I have femto cell would like test osmo iuh. Installed libosmocore on debian server, but got lot of problems with osmo IuH compiling. Curenlty I am stucked with osmo-sccp library. > Also tried Vagrant IuH image, but there is issue with permisions, > Is there a way to get some help for solving this issues, > Thanks > Goran > > > > > -----Original Message----- > From: OpenBSC [mailto:openbsc-bounces@lists.osmocom.org] On Behalf Of openbsc-request@lists.osmocom.org > Sent: Thursday, September 28, 2017 4:36 AM > To: openbsc@lists.osmocom.org > Subject: OpenBSC Digest, Vol 35, Issue 30 > > Send OpenBSC mailing list submissions to > openbsc@lists.osmocom.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.osmocom.org/mailman/listinfo/openbsc > or, via email, send a message with subject or body 'help' to > openbsc-request@lists.osmocom.org > > You can reach the person managing the list at > openbsc-owner@lists.osmocom.org > > When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..." > > > Today's Topics: > > 1. Re: branches in openbsc.git (Harald Welte) > 2. Re: randomness of identifiers (Harald Welte) > 3. Re: Retrieve OP from OPc and Ki (Harald Welte) > 4. Re: ctrl interface: GET a variable with parameter (Harald Welte) > 5. Re: Retrieve OP from OPc and Ki (Kathryn Heckman) > 6. Re: Retrieve OP from OPc and Ki (Mychaela Falconia) > 7. Re: Retrieve OP from OPc and Ki (Tomcs?nyi) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 28 Sep 2017 07:05:09 +0800 > From: Harald Welte <laforge@gnumonks.org> > To: Neels Hofmeyr <nhofmeyr@sysmocom.de> > Cc: openbsc@lists.osmocom.org > Subject: Re: branches in openbsc.git > Message-ID: <20170927230509.pw4xug7jntrfvts2@nataraja> > Content-Type: text/plain; charset=us-ascii > >> On Thu, Sep 28, 2017 at 12:22:31AM +0200, Neels Hofmeyr wrote: >> another call for anyone aware of important branches on openbsc.git to >> please name them, so that they can be migrated to the new repositories. >> But foremost, please name them, thanks! > >> From "my" branches, I can see the following: > * laforge/bssgp_fc -> osmo-sgsn > * laforge/gprs-suspend -> osmo-bsc > * laforge/power_control -> osmo-bsc > > -- > - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > > ------------------------------ > > Message: 2 > Date: Thu, 28 Sep 2017 07:15:01 +0800 > From: Harald Welte <laforge@gnumonks.org> > To: Neels Hofmeyr <nhofmeyr@sysmocom.de> > Cc: openbsc@lists.osmocom.org > Subject: Re: randomness of identifiers > Message-ID: <20170927231501.zyqrali3onodi4iw@nataraja> > Content-Type: text/plain; charset=us-ascii > > Hi Neels, > >> On Wed, Sep 27, 2017 at 06:06:48PM +0200, Neels Hofmeyr wrote: >>> On Wed, Sep 27, 2017 at 07:57:43PM +0800, Harald Welte wrote: >>> For TMSI allocation, my "cryptographic gut feeling"[tm] is that >>> something like rand() or any other pseudo-random generator of >>> significantly large period is sufficient *if* it is seeded by a >>> non-predictable value. So something like seeding with getrandom() result should be fine? > >> Might also make sense to periodically re-seed from /dev/urandom / >> getrandom(), like every 100 TMSIs, or based on a timeout might be >> easier to implement. > > I would try to avoid any predictability here. Having a fixed time interval would be known to an attackers. So if he was somehow able to reduce/exhaust the entropy at the known time for re-seeding, it would be bad. > > Similar for "every 100 TMSIs", which is something under control of any attacker as he can control the number of location updates via the public radio interface [to some extent] and thus control the time at whcih re-seeding is done. > > Maybe I'm going overboard here, but I think if you want to re-seed, you want to ideally do it at a non-predictable and non-controllable point in time. Like a random time interval ;) > >>> For long-term stable key (Ki/Op) generation for provisioning SIM >>> cards + populating a HLR, I would certainly opt for using stronger >>> randomness sources. However, I don't think we actually implement >>> that anywhere, do we? >> >> what does openssh use for public/private keypair generation? > > I'm not sure you can compare the requirements for generation of RSA public/private keys with those for generation of symmetric keys. You can find different recommendations in the literature. But I guess that's mainly due to the fact that people usually assume you have long-term stable public/private keys and short-lived symmetric session keys. In our case, it's long-lived symmetric keys. > > But as indicated, I think our focus is to find a proper solution for generation of TMSIs and for random numbers used in authentication challenges. K/OPc pair generation is not supported in current Osmocom tools anyway, as we presume the SIM cards already have sufficiently random key material and those keys are entered into the HLR. > > Regards, > Harald > > -- > - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > > ------------------------------ > > Message: 3 > Date: Thu, 28 Sep 2017 06:52:28 +0800 > From: Harald Welte <laforge@gnumonks.org> > To: Kathryn Heckman <exuberant.kathryn.heckman@gmail.com> > Cc: "openbsc@lists.osmocom.org" <openbsc@lists.osmocom.org> > Subject: Re: Retrieve OP from OPc and Ki > Message-ID: <20170927225228.u4udbuhk2fyebrl5@nataraja> > Content-Type: text/plain; charset=us-ascii > > Hi Kathryn, > >> On Wed, Sep 27, 2017 at 05:37:36PM -0400, Kathryn Heckman wrote: >> Is there any way to retrieve the value of OP from OPc and Ki? > > No, that defeats the entire purpose of having card-individual OPc values. > > If you could just revert that operation, there would be no [security] advantage of card-individual OPc values over a global OP value, and hence that entire option could be dropped from the specifications altogether. > > Regards, > Harald > -- > - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > > ------------------------------ > > Message: 4 > Date: Thu, 28 Sep 2017 06:50:03 +0800 > From: Harald Welte <laforge@gnumonks.org> > To: Neels Hofmeyr <nhofmeyr@sysmocom.de> > Cc: Holger Freyther <holger@freyther.de>, openbsc@lists.osmocom.org > Subject: Re: ctrl interface: GET a variable with parameter > Message-ID: <20170927225003.ix4qgulake4gugyu@nataraja> > Content-Type: text/plain; charset="us-ascii" > > Hi Neels, > >> On Wed, Sep 27, 2017 at 05:27:38PM +0200, Neels Hofmeyr wrote: >> Also we do have a concept of nesting CTRL nodes separated by dots in >> the variable name, looking at bsc_ctrl_node_lookup() and fsm_ctrl_node_lookup(). > > correct. > >> I notice though that we do still have open doors for a lot of nonsense >> being sent to it without proper validation or error messages. >> >> GET 42 existing-variable.trailing.names.ignored more nonsense >> following being ignored >> >> in effect is identical to: >> >> GET 42 existing-variable >> >> So we should probably enforce that there is no ignored nonsense... > > I agree. > >> Should we also enforce a numeric command ID? > > I'm not following here. Where would that numeric command ID comning from? > >> GET currently-any-id-is-possible-even-\t-\n-is-accepted my-command > > this is also not intended, I'm quite sure. > >> Going back to the OsmoHLR CTRL commands -- they are implemented in a >> way that doesn't match the CTRL interface ways. Let's collapse them. >> >> SET enable-ps <IMSI> >> SET disable-ps <IMSI> >> SET status-ps <IMSI> > > indeed, this is not proper. > >> SET subscriber.by-imsi.123456789098765.ps-enabled 1 >> SET subscriber.by-imsi.123456789098765.ps-enabled 0 >> GET subscriber.by-imsi.123456789098765.ps-enabled > > makes a lot of sense to me. > >> We can also expand this later to things like >> >> GET subscriber.by-imsi.123456789098765.status >> SET subscriber.by-imsi.123456789098765.msisdn 2345 >> GET subscriber.by-msisdn.2342.status >> SET subscriber.by-msisdn.2342.ps-enabled 0 >> GET subscriber.by-imei.987654321234565.imsi > > looks good! > >> We could leave the enable-ps, disable-ps, status-ps commands in place >> in case anyone is using it yet. I assume no-one is though. > > I don't think we need to keep compatibility at this point. > > -- > - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 833 bytes > Desc: not available > URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170928/d568b5f9/attachment-0001.bin> > > ------------------------------ > > Message: 5 > Date: Wed, 27 Sep 2017 21:46:27 -0400 > From: Kathryn Heckman <exuberant.kathryn.heckman@gmail.com> > To: Harald Welte <laforge@gnumonks.org> > Cc: "openbsc@lists.osmocom.org" <openbsc@lists.osmocom.org> > Subject: Re: Retrieve OP from OPc and Ki > Message-ID: > <CAHmN-qT=5x=5XZnwhjYBSByw2ZJpWtCRMiWHu3iWxDysBQT6cA@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > I really appreciate your quick replies. > > I have a USIM that I wanted to program. However, I am getting the runtime error for exceeding the number of attempts to enter the ADM1 key. Is there any fix for it? > > -- > Kathryn > >> On Wed, Sep 27, 2017 at 6:52 PM, Harald Welte <laforge@gnumonks.org> wrote: >> >> Hi Kathryn, >> >>> On Wed, Sep 27, 2017 at 05:37:36PM -0400, Kathryn Heckman wrote: >>> Is there any way to retrieve the value of OP from OPc and Ki? >> >> No, that defeats the entire purpose of having card-individual OPc >> values. >> >> If you could just revert that operation, there would be no [security] >> advantage of card-individual OPc values over a global OP value, and >> hence that entire option could be dropped from the specifications >> altogether. >> >> Regards, >> Harald >> -- >> - Harald Welte <laforge@gnumonks.org> >> http://laforge.gnumonks.org/ >> ============================================================ >> ================ >> "Privacy in residential applications is a desirable marketing option." >> (ETSI EN 300 175-7 Ch. >> A6) >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170927/620a2963/attachment-0001.html> > > ------------------------------ > > Message: 6 > Date: Wed, 27 Sep 2017 18:04:35 -0800 > From: Mychaela Falconia <mychaela.falconia@gmail.com> > To: Kathryn Heckman <exuberant.kathryn.heckman@gmail.com> > Cc: openbsc <openbsc@lists.osmocom.org> > Subject: Re: Retrieve OP from OPc and Ki > Message-ID: > <CA+uuBqbtTfsrADC-ENCfGt2RY=XYUYN0d466=ZR3Mrn_up-L8A@mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > >> On 9/27/17, Kathryn Heckman <exuberant.kathryn.heckman@gmail.com> wrote: >> I have a USIM that I wanted to program. However, I am getting the >> runtime error for exceeding the number of attempts to enter the ADM1 >> key. Is there any fix for it? > > Someone please correct me if I am wrong, but I would assume that having exceeded the number of attempts to enter the ADM1 key means that the USIM is bricked beyond recovery. > > But the sysmoUSIM cards sold at shop.sysmocom.de are fairly inexpensive for a pack of 10, so a bricked (U)SIM shouldn't be too big of a tragedy - or is there another dimension to this problem which I am missing? > > If you are anywhere near local to me (California, USA) I could give you one of my sysmoUSIM cards, but I am guessing it probably won't help you as I bought the cheaper version without the ADM1 keys - for my application (production testing of my GSM MS hardware) it doesn't matter what the programming of the (U)SIM happens to be. > > M~ > > > ------------------------------ > > Message: 7 > Date: Thu, 28 Sep 2017 04:35:24 +0200 (CEST) > From: Tomcs?nyi, Domonkos <domi@tomcsanyi.net> > To: Mychaela Falconia <mychaela.falconia@gmail.com> > Cc: Kathryn Heckman <exuberant.kathryn.heckman@gmail.com>, openbsc > <openbsc@lists.osmocom.org> > Subject: Re: Retrieve OP from OPc and Ki > Message-ID: <1A1DD58D-617B-4FBE-B363-21A25EBCFA83@tomcsanyi.net> > Content-Type: text/plain; charset="utf-8" > > Hi Kathryn and Mychaela, > > 2017. szept. 28. d?tummal, 4:04 id?pontban Mychaela Falconia <mychaela.falconia@gmail.com> ?rta: >> Someone please correct me if I am wrong, but I would assume that >> having exceeded the number of attempts to enter the ADM1 key means >> that the USIM is bricked beyond recovery. > > This is my understanding as well. > > Cheers, > > Domi > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170928/c99fe291/attachment.html> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OpenBSC mailing list > OpenBSC@lists.osmocom.org > https://lists.osmocom.org/mailman/listinfo/openbsc > > > ------------------------------ > > End of OpenBSC Digest, Vol 35, Issue 30 > *************************************** > > > > The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately. >
Hi, Thank you very much for your response, This make me believe in this project, I have just found that there are released Nightly Builds for Osmocom GSM related software. I will reinstall my server with one of this builds and try everything again, Basically I was following procedure from Site, on my Debian server but was stucked with dependencies which I were not able to compile, Libosmo-sccp, Libosmo-netif, libosmo-abis https://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_Source I will come back with questions after I tried again. BR Goran From: Tomcsányi, Domonkos [mailto:domi@tomcsanyi.net] Sent: Thursday, September 28, 2017 1:07 PM To: Popovic Goran <Goran.Popovic@kapsch.net> Cc: openbsc@lists.osmocom.org Subject: Re: OpenBSC Digest, Vol 35, Issue 30 Hi Goran, Without any exact details, like error messages and commands that you tried we cannot give you much help sadly. Please provide all details possible in text format, and I’m sure someone will help. Regards, Domi 2017. szept. 28. dátummal, 11:18 időpontban Popovic Goran <Goran.Popovic@kapsch.net<mailto:Goran.Popovic@kapsch.net>> írta: HI, My name is Goran, I have femto cell would like test osmo iuh. Installed libosmocore on debian server, but got lot of problems with osmo IuH compiling. Curenlty I am stucked with osmo-sccp library. Also tried Vagrant IuH image, but there is issue with permisions, Is there a way to get some help for solving this issues, Thanks Goran -----Original Message----- From: OpenBSC [mailto:openbsc-bounces@lists.osmocom.org] On Behalf Of openbsc-request@lists.osmocom.org<mailto:openbsc-request@lists.osmocom.org> Sent: Thursday, September 28, 2017 4:36 AM To: openbsc@lists.osmocom.org<mailto:openbsc@lists.osmocom.org> Subject: OpenBSC Digest, Vol 35, Issue 30 Send OpenBSC mailing list submissions to openbsc@lists.osmocom.org<mailto:openbsc@lists.osmocom.org> To subscribe or unsubscribe via the World Wide Web, visit https://lists.osmocom.org/mailman/listinfo/openbsc or, via email, send a message with subject or body 'help' to openbsc-request@lists.osmocom.org<mailto:openbsc-request@lists.osmocom.org> You can reach the person managing the list at openbsc-owner@lists.osmocom.org<mailto:openbsc-owner@lists.osmocom.org> When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..." Today's Topics: 1. Re: branches in openbsc.git (Harald Welte) 2. Re: randomness of identifiers (Harald Welte) 3. Re: Retrieve OP from OPc and Ki (Harald Welte) 4. Re: ctrl interface: GET a variable with parameter (Harald Welte) 5. Re: Retrieve OP from OPc and Ki (Kathryn Heckman) 6. Re: Retrieve OP from OPc and Ki (Mychaela Falconia) 7. Re: Retrieve OP from OPc and Ki (Tomcs?nyi) ---------------------------------------------------------------------- Message: 1 Date: Thu, 28 Sep 2017 07:05:09 +0800 From: Harald Welte <laforge@gnumonks.org<mailto:laforge@gnumonks.org>> To: Neels Hofmeyr <nhofmeyr@sysmocom.de<mailto:nhofmeyr@sysmocom.de>> Cc: openbsc@lists.osmocom.org<mailto:openbsc@lists.osmocom.org> Subject: Re: branches in openbsc.git Message-ID: <20170927230509.pw4xug7jntrfvts2@nataraja<mailto:20170927230509.pw4xug7jntrfvts2@nataraja>> Content-Type: text/plain; charset=us-ascii On Thu, Sep 28, 2017 at 12:22:31AM +0200, Neels Hofmeyr wrote: another call for anyone aware of important branches on openbsc.git to please name them, so that they can be migrated to the new repositories. But foremost, please name them, thanks! From "my" branches, I can see the following: * laforge/bssgp_fc -> osmo-sgsn * laforge/gprs-suspend -> osmo-bsc * laforge/power_control -> osmo-bsc -- - Harald Welte <laforge@gnumonks.org<mailto:laforge@gnumonks.org>> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 2 Date: Thu, 28 Sep 2017 07:15:01 +0800 From: Harald Welte <laforge@gnumonks.org<mailto:laforge@gnumonks.org>> To: Neels Hofmeyr <nhofmeyr@sysmocom.de<mailto:nhofmeyr@sysmocom.de>> Cc: openbsc@lists.osmocom.org<mailto:openbsc@lists.osmocom.org> Subject: Re: randomness of identifiers Message-ID: <20170927231501.zyqrali3onodi4iw@nataraja<mailto:20170927231501.zyqrali3onodi4iw@nataraja>> Content-Type: text/plain; charset=us-ascii Hi Neels, On Wed, Sep 27, 2017 at 06:06:48PM +0200, Neels Hofmeyr wrote: On Wed, Sep 27, 2017 at 07:57:43PM +0800, Harald Welte wrote: For TMSI allocation, my "cryptographic gut feeling"[tm] is that something like rand() or any other pseudo-random generator of significantly large period is sufficient *if* it is seeded by a non-predictable value. So something like seeding with getrandom() result should be fine? Might also make sense to periodically re-seed from /dev/urandom / getrandom(), like every 100 TMSIs, or based on a timeout might be easier to implement. I would try to avoid any predictability here. Having a fixed time interval would be known to an attackers. So if he was somehow able to reduce/exhaust the entropy at the known time for re-seeding, it would be bad. Similar for "every 100 TMSIs", which is something under control of any attacker as he can control the number of location updates via the public radio interface [to some extent] and thus control the time at whcih re-seeding is done. Maybe I'm going overboard here, but I think if you want to re-seed, you want to ideally do it at a non-predictable and non-controllable point in time. Like a random time interval ;) For long-term stable key (Ki/Op) generation for provisioning SIM cards + populating a HLR, I would certainly opt for using stronger randomness sources. However, I don't think we actually implement that anywhere, do we? what does openssh use for public/private keypair generation? I'm not sure you can compare the requirements for generation of RSA public/private keys with those for generation of symmetric keys. You can find different recommendations in the literature. But I guess that's mainly due to the fact that people usually assume you have long-term stable public/private keys and short-lived symmetric session keys. In our case, it's long-lived symmetric keys. But as indicated, I think our focus is to find a proper solution for generation of TMSIs and for random numbers used in authentication challenges. K/OPc pair generation is not supported in current Osmocom tools anyway, as we presume the SIM cards already have sufficiently random key material and those keys are entered into the HLR. Regards, Harald -- - Harald Welte <laforge@gnumonks.org<mailto:laforge@gnumonks.org>> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 3 Date: Thu, 28 Sep 2017 06:52:28 +0800 From: Harald Welte <laforge@gnumonks.org<mailto:laforge@gnumonks.org>> To: Kathryn Heckman <exuberant.kathryn.heckman@gmail.com<mailto:exuberant.kathryn.heckman@gmail.com>> Cc: "openbsc@lists.osmocom.org<mailto:openbsc@lists.osmocom.org>" <openbsc@lists.osmocom.org<mailto:openbsc@lists.osmocom.org>> Subject: Re: Retrieve OP from OPc and Ki Message-ID: <20170927225228.u4udbuhk2fyebrl5@nataraja<mailto:20170927225228.u4udbuhk2fyebrl5@nataraja>> Content-Type: text/plain; charset=us-ascii Hi Kathryn, On Wed, Sep 27, 2017 at 05:37:36PM -0400, Kathryn Heckman wrote: Is there any way to retrieve the value of OP from OPc and Ki? No, that defeats the entire purpose of having card-individual OPc values. If you could just revert that operation, there would be no [security] advantage of card-individual OPc values over a global OP value, and hence that entire option could be dropped from the specifications altogether. Regards, Harald -- - Harald Welte <laforge@gnumonks.org<mailto:laforge@gnumonks.org>> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 4 Date: Thu, 28 Sep 2017 06:50:03 +0800 From: Harald Welte <laforge@gnumonks.org<mailto:laforge@gnumonks.org>> To: Neels Hofmeyr <nhofmeyr@sysmocom.de<mailto:nhofmeyr@sysmocom.de>> Cc: Holger Freyther <holger@freyther.de<mailto:holger@freyther.de>>, openbsc@lists.osmocom.org<mailto:openbsc@lists.osmocom.org> Subject: Re: ctrl interface: GET a variable with parameter Message-ID: <20170927225003.ix4qgulake4gugyu@nataraja<mailto:20170927225003.ix4qgulake4gugyu@nataraja>> Content-Type: text/plain; charset="us-ascii" Hi Neels, On Wed, Sep 27, 2017 at 05:27:38PM +0200, Neels Hofmeyr wrote: Also we do have a concept of nesting CTRL nodes separated by dots in the variable name, looking at bsc_ctrl_node_lookup() and fsm_ctrl_node_lookup(). correct. I notice though that we do still have open doors for a lot of nonsense being sent to it without proper validation or error messages. GET 42 existing-variable.trailing.names.ignored more nonsense following being ignored in effect is identical to: GET 42 existing-variable So we should probably enforce that there is no ignored nonsense... I agree. Should we also enforce a numeric command ID? I'm not following here. Where would that numeric command ID comning from? GET currently-any-id-is-possible-even-\t-\n-is-accepted my-command this is also not intended, I'm quite sure. Going back to the OsmoHLR CTRL commands -- they are implemented in a way that doesn't match the CTRL interface ways. Let's collapse them. SET enable-ps <IMSI> SET disable-ps <IMSI> SET status-ps <IMSI> indeed, this is not proper. SET subscriber.by-imsi.123456789098765.ps-enabled 1 SET subscriber.by-imsi.123456789098765.ps-enabled 0 GET subscriber.by-imsi.123456789098765.ps-enabled makes a lot of sense to me. We can also expand this later to things like GET subscriber.by-imsi.123456789098765.status SET subscriber.by-imsi.123456789098765.msisdn 2345 GET subscriber.by-msisdn.2342.status SET subscriber.by-msisdn.2342.ps-enabled 0 GET subscriber.by-imei.987654321234565.imsi looks good! We could leave the enable-ps, disable-ps, status-ps commands in place in case anyone is using it yet. I assume no-one is though. I don't think we need to keep compatibility at this point. -- - Harald Welte <laforge@gnumonks.org<mailto:laforge@gnumonks.org>> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170928/d568b5f9/attachment-0001.bin> ------------------------------ Message: 5 Date: Wed, 27 Sep 2017 21:46:27 -0400 From: Kathryn Heckman <exuberant.kathryn.heckman@gmail.com<mailto:exuberant.kathryn.heckman@gmail.com>> To: Harald Welte <laforge@gnumonks.org<mailto:laforge@gnumonks.org>> Cc: "openbsc@lists.osmocom.org<mailto:openbsc@lists.osmocom.org>" <openbsc@lists.osmocom.org<mailto:openbsc@lists.osmocom.org>> Subject: Re: Retrieve OP from OPc and Ki Message-ID: <CAHmN-qT=5x=5XZnwhjYBSByw2ZJpWtCRMiWHu3iWxDysBQT6cA@mail.gmail.com<mailto:CAHmN-qT=5x=5XZnwhjYBSByw2ZJpWtCRMiWHu3iWxDysBQT6cA@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" I really appreciate your quick replies. I have a USIM that I wanted to program. However, I am getting the runtime error for exceeding the number of attempts to enter the ADM1 key. Is there any fix for it? -- Kathryn On Wed, Sep 27, 2017 at 6:52 PM, Harald Welte <laforge@gnumonks.org<mailto:laforge@gnumonks.org>> wrote: Hi Kathryn, On Wed, Sep 27, 2017 at 05:37:36PM -0400, Kathryn Heckman wrote: Is there any way to retrieve the value of OP from OPc and Ki? No, that defeats the entire purpose of having card-individual OPc values. If you could just revert that operation, there would be no [security] advantage of card-individual OPc values over a global OP value, and hence that entire option could be dropped from the specifications altogether. Regards, Harald -- - Harald Welte <laforge@gnumonks.org<mailto:laforge@gnumonks.org>> http://laforge.gnumonks.org/ ============================================================ ================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170927/620a2963/attachment-0001.html> ------------------------------ Message: 6 Date: Wed, 27 Sep 2017 18:04:35 -0800 From: Mychaela Falconia <mychaela.falconia@gmail.com<mailto:mychaela.falconia@gmail.com>> To: Kathryn Heckman <exuberant.kathryn.heckman@gmail.com<mailto:exuberant.kathryn.heckman@gmail.com>> Cc: openbsc <openbsc@lists.osmocom.org<mailto:openbsc@lists.osmocom.org>> Subject: Re: Retrieve OP from OPc and Ki Message-ID: <CA+uuBqbtTfsrADC-ENCfGt2RY=XYUYN0d466=ZR3Mrn_up-L8A@mail.gmail.com<mailto:CA+uuBqbtTfsrADC-ENCfGt2RY=XYUYN0d466=ZR3Mrn_up-L8A@mail.gmail.com>> Content-Type: text/plain; charset="UTF-8" On 9/27/17, Kathryn Heckman <exuberant.kathryn.heckman@gmail.com<mailto:exuberant.kathryn.heckman@gmail.com>> wrote: I have a USIM that I wanted to program. However, I am getting the runtime error for exceeding the number of attempts to enter the ADM1 key. Is there any fix for it? Someone please correct me if I am wrong, but I would assume that having exceeded the number of attempts to enter the ADM1 key means that the USIM is bricked beyond recovery. But the sysmoUSIM cards sold at shop.sysmocom.de<http://shop.sysmocom.de> are fairly inexpensive for a pack of 10, so a bricked (U)SIM shouldn't be too big of a tragedy - or is there another dimension to this problem which I am missing? If you are anywhere near local to me (California, USA) I could give you one of my sysmoUSIM cards, but I am guessing it probably won't help you as I bought the cheaper version without the ADM1 keys - for my application (production testing of my GSM MS hardware) it doesn't matter what the programming of the (U)SIM happens to be. M~ ------------------------------ Message: 7 Date: Thu, 28 Sep 2017 04:35:24 +0200 (CEST) From: Tomcs?nyi, Domonkos <domi@tomcsanyi.net<mailto:domi@tomcsanyi.net>> To: Mychaela Falconia <mychaela.falconia@gmail.com<mailto:mychaela.falconia@gmail.com>> Cc: Kathryn Heckman <exuberant.kathryn.heckman@gmail.com<mailto:exuberant.kathryn.heckman@gmail.com>>, openbsc <openbsc@lists.osmocom.org<mailto:openbsc@lists.osmocom.org>> Subject: Re: Retrieve OP from OPc and Ki Message-ID: <1A1DD58D-617B-4FBE-B363-21A25EBCFA83@tomcsanyi.net<mailto:1A1DD58D-617B-4FBE-B363-21A25EBCFA83@tomcsanyi.net>> Content-Type: text/plain; charset="utf-8" Hi Kathryn and Mychaela, 2017. szept. 28. d?tummal, 4:04 id?pontban Mychaela Falconia <mychaela.falconia@gmail.com<mailto:mychaela.falconia@gmail.com>> ?rta: Someone please correct me if I am wrong, but I would assume that having exceeded the number of attempts to enter the ADM1 key means that the USIM is bricked beyond recovery. This is my understanding as well. Cheers, Domi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170928/c99fe291/attachment.html> ------------------------------ Subject: Digest Footer _______________________________________________ OpenBSC mailing list OpenBSC@lists.osmocom.org<mailto:OpenBSC@lists.osmocom.org> https://lists.osmocom.org/mailman/listinfo/openbsc ------------------------------ End of OpenBSC Digest, Vol 35, Issue 30 *************************************** The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately. The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately.
Hi Goran, for me all is ok install from that sources, I builded Openbsc, etc on kali linux just 2 weeks ago from that sources. maybe its just dependency, you need to put more info for the error and someone will help more. regards, DUO On Thu, Sep 28, 2017 at 6:34 PM, Popovic Goran <Goran.Popovic@kapsch.net> wrote:
Hi,
Thank you very much for your response, This make me believe in this project, I have just found that there are released Nightly Builds for Osmocom GSM related software. I will reinstall my server with one of this builds and try everything again, Basically I was following procedure from Site, on my Debian server but was stucked with dependencies which I were not able to compile, Libosmo-sccp, Libosmo-netif, libosmo-abis *https://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_Source* <https://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_Source> I will come back with questions after I tried again. BR Goran
*From:* Tomcsányi, Domonkos [mailto:domi@tomcsanyi.net] *Sent:* Thursday, September 28, 2017 1:07 PM *To:* Popovic Goran <Goran.Popovic@kapsch.net> *Cc:* openbsc@lists.osmocom.org *Subject:* Re: OpenBSC Digest, Vol 35, Issue 30
Hi Goran,
Without any exact details, like error messages and commands that you tried we cannot give you much help sadly.
Please provide all details possible in text format, and I’m sure someone will help.
Regards,
Domi
2017. szept. 28. dátummal, 11:18 időpontban Popovic Goran < Goran.Popovic@kapsch.net> írta:
HI, My name is Goran, I have femto cell would like test osmo iuh. Installed libosmocore on debian server, but got lot of problems with osmo IuH compiling. Curenlty I am stucked with osmo-sccp library. Also tried Vagrant IuH image, but there is issue with permisions, Is there a way to get some help for solving this issues, Thanks Goran
-----Original Message----- From: OpenBSC [mailto:openbsc-bounces@lists.osmocom.org <openbsc-bounces@lists.osmocom.org>] On Behalf Of openbsc-request@lists.osmocom.org Sent: Thursday, September 28, 2017 4:36 AM To: openbsc@lists.osmocom.org Subject: OpenBSC Digest, Vol 35, Issue 30
Send OpenBSC mailing list submissions to openbsc@lists.osmocom.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.osmocom.org/mailman/listinfo/openbsc or, via email, send a message with subject or body 'help' to openbsc-request@lists.osmocom.org
You can reach the person managing the list at openbsc-owner@lists.osmocom.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..."
Today's Topics:
1. Re: branches in openbsc.git (Harald Welte) 2. Re: randomness of identifiers (Harald Welte) 3. Re: Retrieve OP from OPc and Ki (Harald Welte) 4. Re: ctrl interface: GET a variable with parameter (Harald Welte) 5. Re: Retrieve OP from OPc and Ki (Kathryn Heckman) 6. Re: Retrieve OP from OPc and Ki (Mychaela Falconia) 7. Re: Retrieve OP from OPc and Ki (Tomcs?nyi)
----------------------------------------------------------------------
Message: 1 Date: Thu, 28 Sep 2017 07:05:09 +0800 From: Harald Welte <laforge@gnumonks.org> To: Neels Hofmeyr <nhofmeyr@sysmocom.de> Cc: openbsc@lists.osmocom.org Subject: Re: branches in openbsc.git Message-ID: <20170927230509.pw4xug7jntrfvts2@nataraja> Content-Type: text/plain; charset=us-ascii
On Thu, Sep 28, 2017 at 12:22:31AM +0200, Neels Hofmeyr wrote:
another call for anyone aware of important branches on openbsc.git to
please name them, so that they can be migrated to the new repositories.
But foremost, please name them, thanks!
From "my" branches, I can see the following:
* laforge/bssgp_fc -> osmo-sgsn * laforge/gprs-suspend -> osmo-bsc * laforge/power_control -> osmo-bsc
-- - Harald Welte <laforge@gnumonks.org> http://laforge. gnumonks.org/ ============================================================ ================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
------------------------------
Message: 2 Date: Thu, 28 Sep 2017 07:15:01 +0800 From: Harald Welte <laforge@gnumonks.org> To: Neels Hofmeyr <nhofmeyr@sysmocom.de> Cc: openbsc@lists.osmocom.org Subject: Re: randomness of identifiers Message-ID: <20170927231501.zyqrali3onodi4iw@nataraja> Content-Type: text/plain; charset=us-ascii
Hi Neels,
On Wed, Sep 27, 2017 at 06:06:48PM +0200, Neels Hofmeyr wrote:
On Wed, Sep 27, 2017 at 07:57:43PM +0800, Harald Welte wrote:
For TMSI allocation, my "cryptographic gut feeling"[tm] is that
something like rand() or any other pseudo-random generator of
significantly large period is sufficient *if* it is seeded by a
non-predictable value. So something like seeding with getrandom() result should be fine?
Might also make sense to periodically re-seed from /dev/urandom /
getrandom(), like every 100 TMSIs, or based on a timeout might be
easier to implement.
I would try to avoid any predictability here. Having a fixed time interval would be known to an attackers. So if he was somehow able to reduce/exhaust the entropy at the known time for re-seeding, it would be bad.
Similar for "every 100 TMSIs", which is something under control of any attacker as he can control the number of location updates via the public radio interface [to some extent] and thus control the time at whcih re-seeding is done.
Maybe I'm going overboard here, but I think if you want to re-seed, you want to ideally do it at a non-predictable and non-controllable point in time. Like a random time interval ;)
For long-term stable key (Ki/Op) generation for provisioning SIM
cards + populating a HLR, I would certainly opt for using stronger
randomness sources. However, I don't think we actually implement
that anywhere, do we?
what does openssh use for public/private keypair generation?
I'm not sure you can compare the requirements for generation of RSA public/private keys with those for generation of symmetric keys. You can find different recommendations in the literature. But I guess that's mainly due to the fact that people usually assume you have long-term stable public/private keys and short-lived symmetric session keys. In our case, it's long-lived symmetric keys.
But as indicated, I think our focus is to find a proper solution for generation of TMSIs and for random numbers used in authentication challenges. K/OPc pair generation is not supported in current Osmocom tools anyway, as we presume the SIM cards already have sufficiently random key material and those keys are entered into the HLR.
Regards, Harald
-- - Harald Welte <laforge@gnumonks.org> http://laforge. gnumonks.org/ ============================================================ ================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
------------------------------
Message: 3 Date: Thu, 28 Sep 2017 06:52:28 +0800 From: Harald Welte <laforge@gnumonks.org> To: Kathryn Heckman <exuberant.kathryn.heckman@gmail.com> Cc: "openbsc@lists.osmocom.org" <openbsc@lists.osmocom.org> Subject: Re: Retrieve OP from OPc and Ki Message-ID: <20170927225228.u4udbuhk2fyebrl5@nataraja> Content-Type: text/plain; charset=us-ascii
Hi Kathryn,
On Wed, Sep 27, 2017 at 05:37:36PM -0400, Kathryn Heckman wrote:
Is there any way to retrieve the value of OP from OPc and Ki?
No, that defeats the entire purpose of having card-individual OPc values.
If you could just revert that operation, there would be no [security] advantage of card-individual OPc values over a global OP value, and hence that entire option could be dropped from the specifications altogether.
Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge. gnumonks.org/ ============================================================ ================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
------------------------------
Message: 4 Date: Thu, 28 Sep 2017 06:50:03 +0800 From: Harald Welte <laforge@gnumonks.org> To: Neels Hofmeyr <nhofmeyr@sysmocom.de> Cc: Holger Freyther <holger@freyther.de>, openbsc@lists.osmocom.org Subject: Re: ctrl interface: GET a variable with parameter Message-ID: <20170927225003.ix4qgulake4gugyu@nataraja> Content-Type: text/plain; charset="us-ascii"
Hi Neels,
On Wed, Sep 27, 2017 at 05:27:38PM +0200, Neels Hofmeyr wrote:
Also we do have a concept of nesting CTRL nodes separated by dots in
the variable name, looking at bsc_ctrl_node_lookup() and fsm_ctrl_node_lookup().
correct.
I notice though that we do still have open doors for a lot of nonsense
being sent to it without proper validation or error messages.
GET 42 existing-variable.trailing.names.ignored more nonsense
following being ignored
in effect is identical to:
GET 42 existing-variable
So we should probably enforce that there is no ignored nonsense...
I agree.
Should we also enforce a numeric command ID?
I'm not following here. Where would that numeric command ID comning from?
GET currently-any-id-is-possible-even-\t-\n-is-accepted my-command
this is also not intended, I'm quite sure.
Going back to the OsmoHLR CTRL commands -- they are implemented in a
way that doesn't match the CTRL interface ways. Let's collapse them.
SET enable-ps <IMSI>
SET disable-ps <IMSI>
SET status-ps <IMSI>
indeed, this is not proper.
SET subscriber.by-imsi.123456789098765.ps-enabled 1
SET subscriber.by-imsi.123456789098765.ps-enabled 0
GET subscriber.by-imsi.123456789098765.ps-enabled
makes a lot of sense to me.
We can also expand this later to things like
GET subscriber.by-imsi.123456789098765.status
SET subscriber.by-imsi.123456789098765.msisdn 2345
GET subscriber.by-msisdn.2342.status
SET subscriber.by-msisdn.2342.ps-enabled 0
GET subscriber.by-imei.987654321234565.imsi
looks good!
We could leave the enable-ps, disable-ps, status-ps commands in place
in case anyone is using it yet. I assume no-one is though.
I don't think we need to keep compatibility at this point.
-- - Harald Welte <laforge@gnumonks.org> http://laforge. gnumonks.org/ ============================================================ ================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi thanks for suggestion, I think all dependency are installed now. This is output when I try to install osmo-iuh BR Goran From: Sandi Suhendro [mailto:djks74@gmail.com] Sent: Thursday, September 28, 2017 1:50 PM To: Popovic Goran <Goran.Popovic@kapsch.net> Cc: Tomcsányi, Domonkos <domi@tomcsanyi.net>; openbsc@lists.osmocom.org Subject: Re: OpenBSC Digest, Vol 35, Issue 30 Hi Goran, for me all is ok install from that sources, I builded Openbsc, etc on kali linux just 2 weeks ago from that sources. maybe its just dependency, you need to put more info for the error and someone will help more. regards, DUO On Thu, Sep 28, 2017 at 6:34 PM, Popovic Goran <Goran.Popovic@kapsch.net<mailto:Goran.Popovic@kapsch.net>> wrote: Hi, Thank you very much for your response, This make me believe in this project, I have just found that there are released Nightly Builds for Osmocom GSM related software. I will reinstall my server with one of this builds and try everything again, Basically I was following procedure from Site, on my Debian server but was stucked with dependencies which I were not able to compile, Libosmo-sccp, Libosmo-netif, libosmo-abis https://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_Source I will come back with questions after I tried again. BR Goran From: Tomcsányi, Domonkos [mailto:domi@tomcsanyi.net<mailto:domi@tomcsanyi.net>] Sent: Thursday, September 28, 2017 1:07 PM To: Popovic Goran <Goran.Popovic@kapsch.net<mailto:Goran.Popovic@kapsch.net>> Cc: openbsc@lists.osmocom.org<mailto:openbsc@lists.osmocom.org> Subject: Re: OpenBSC Digest, Vol 35, Issue 30 Hi Goran, Without any exact details, like error messages and commands that you tried we cannot give you much help sadly. Please provide all details possible in text format, and I’m sure someone will help. Regards, Domi 2017. szept. 28. dátummal, 11:18 időpontban Popovic Goran <Goran.Popovic@kapsch.net<mailto:Goran.Popovic@kapsch.net>> írta: HI, My name is Goran, I have femto cell would like test osmo iuh. Installed libosmocore on debian server, but got lot of problems with osmo IuH compiling. Curenlty I am stucked with osmo-sccp library. Also tried Vagrant IuH image, but there is issue with permisions, Is there a way to get some help for solving this issues, Thanks Goran -----Original Message----- From: OpenBSC [mailto:openbsc-bounces@lists.osmocom.org] On Behalf Of openbsc-request@lists.osmocom.org<mailto:openbsc-request@lists.osmocom.org> Sent: Thursday, September 28, 2017 4:36 AM To: openbsc@lists.osmocom.org<mailto:openbsc@lists.osmocom.org> Subject: OpenBSC Digest, Vol 35, Issue 30 Send OpenBSC mailing list submissions to openbsc@lists.osmocom.org<mailto:openbsc@lists.osmocom.org> To subscribe or unsubscribe via the World Wide Web, visit https://lists.osmocom.org/mailman/listinfo/openbsc or, via email, send a message with subject or body 'help' to openbsc-request@lists.osmocom.org<mailto:openbsc-request@lists.osmocom.org> You can reach the person managing the list at openbsc-owner@lists.osmocom.org<mailto:openbsc-owner@lists.osmocom.org> When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..." Today's Topics: 1. Re: branches in openbsc.git (Harald Welte) 2. Re: randomness of identifiers (Harald Welte) 3. Re: Retrieve OP from OPc and Ki (Harald Welte) 4. Re: ctrl interface: GET a variable with parameter (Harald Welte) 5. Re: Retrieve OP from OPc and Ki (Kathryn Heckman) 6. Re: Retrieve OP from OPc and Ki (Mychaela Falconia) 7. Re: Retrieve OP from OPc and Ki (Tomcs?nyi) ---------------------------------------------------------------------- Message: 1 Date: Thu, 28 Sep 2017 07:05:09 +0800 From: Harald Welte <laforge@gnumonks.org<mailto:laforge@gnumonks.org>> To: Neels Hofmeyr <nhofmeyr@sysmocom.de<mailto:nhofmeyr@sysmocom.de>> Cc: openbsc@lists.osmocom.org<mailto:openbsc@lists.osmocom.org> Subject: Re: branches in openbsc.git Message-ID: <20170927230509.pw4xug7jntrfvts2@nataraja<mailto:20170927230509.pw4xug7jntrfvts2@nataraja>> Content-Type: text/plain; charset=us-ascii On Thu, Sep 28, 2017 at 12:22:31AM +0200, Neels Hofmeyr wrote: another call for anyone aware of important branches on openbsc.git to please name them, so that they can be migrated to the new repositories. But foremost, please name them, thanks! From "my" branches, I can see the following: * laforge/bssgp_fc -> osmo-sgsn * laforge/gprs-suspend -> osmo-bsc * laforge/power_control -> osmo-bsc -- - Harald Welte <laforge@gnumonks.org<mailto:laforge@gnumonks.org>> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 2 Date: Thu, 28 Sep 2017 07:15:01 +0800 From: Harald Welte <laforge@gnumonks.org<mailto:laforge@gnumonks.org>> To: Neels Hofmeyr <nhofmeyr@sysmocom.de<mailto:nhofmeyr@sysmocom.de>> Cc: openbsc@lists.osmocom.org<mailto:openbsc@lists.osmocom.org> Subject: Re: randomness of identifiers Message-ID: <20170927231501.zyqrali3onodi4iw@nataraja<mailto:20170927231501.zyqrali3onodi4iw@nataraja>> Content-Type: text/plain; charset=us-ascii Hi Neels, On Wed, Sep 27, 2017 at 06:06:48PM +0200, Neels Hofmeyr wrote: On Wed, Sep 27, 2017 at 07:57:43PM +0800, Harald Welte wrote: For TMSI allocation, my "cryptographic gut feeling"[tm] is that something like rand() or any other pseudo-random generator of significantly large period is sufficient *if* it is seeded by a non-predictable value. So something like seeding with getrandom() result should be fine? Might also make sense to periodically re-seed from /dev/urandom / getrandom(), like every 100 TMSIs, or based on a timeout might be easier to implement. I would try to avoid any predictability here. Having a fixed time interval would be known to an attackers. So if he was somehow able to reduce/exhaust the entropy at the known time for re-seeding, it would be bad. Similar for "every 100 TMSIs", which is something under control of any attacker as he can control the number of location updates via the public radio interface [to some extent] and thus control the time at whcih re-seeding is done. Maybe I'm going overboard here, but I think if you want to re-seed, you want to ideally do it at a non-predictable and non-controllable point in time. Like a random time interval ;) For long-term stable key (Ki/Op) generation for provisioning SIM cards + populating a HLR, I would certainly opt for using stronger randomness sources. However, I don't think we actually implement that anywhere, do we? what does openssh use for public/private keypair generation? I'm not sure you can compare the requirements for generation of RSA public/private keys with those for generation of symmetric keys. You can find different recommendations in the literature. But I guess that's mainly due to the fact that people usually assume you have long-term stable public/private keys and short-lived symmetric session keys. In our case, it's long-lived symmetric keys. But as indicated, I think our focus is to find a proper solution for generation of TMSIs and for random numbers used in authentication challenges. K/OPc pair generation is not supported in current Osmocom tools anyway, as we presume the SIM cards already have sufficiently random key material and those keys are entered into the HLR. Regards, Harald -- - Harald Welte <laforge@gnumonks.org<mailto:laforge@gnumonks.org>> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 3 Date: Thu, 28 Sep 2017 06:52:28 +0800 From: Harald Welte <laforge@gnumonks.org<mailto:laforge@gnumonks.org>> To: Kathryn Heckman <exuberant.kathryn.heckman@gmail.com<mailto:exuberant.kathryn.heckman@gmail.com>> Cc: "openbsc@lists.osmocom.org<mailto:openbsc@lists.osmocom.org>" <openbsc@lists.osmocom.org<mailto:openbsc@lists.osmocom.org>> Subject: Re: Retrieve OP from OPc and Ki Message-ID: <20170927225228.u4udbuhk2fyebrl5@nataraja<mailto:20170927225228.u4udbuhk2fyebrl5@nataraja>> Content-Type: text/plain; charset=us-ascii Hi Kathryn, On Wed, Sep 27, 2017 at 05:37:36PM -0400, Kathryn Heckman wrote: Is there any way to retrieve the value of OP from OPc and Ki? No, that defeats the entire purpose of having card-individual OPc values. If you could just revert that operation, there would be no [security] advantage of card-individual OPc values over a global OP value, and hence that entire option could be dropped from the specifications altogether. Regards, Harald -- - Harald Welte <laforge@gnumonks.org<mailto:laforge@gnumonks.org>> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ------------------------------ Message: 4 Date: Thu, 28 Sep 2017 06:50:03 +0800 From: Harald Welte <laforge@gnumonks.org<mailto:laforge@gnumonks.org>> To: Neels Hofmeyr <nhofmeyr@sysmocom.de<mailto:nhofmeyr@sysmocom.de>> Cc: Holger Freyther <holger@freyther.de<mailto:holger@freyther.de>>, openbsc@lists.osmocom.org<mailto:openbsc@lists.osmocom.org> Subject: Re: ctrl interface: GET a variable with parameter Message-ID: <20170927225003.ix4qgulake4gugyu@nataraja<mailto:20170927225003.ix4qgulake4gugyu@nataraja>> Content-Type: text/plain; charset="us-ascii" Hi Neels, On Wed, Sep 27, 2017 at 05:27:38PM +0200, Neels Hofmeyr wrote: Also we do have a concept of nesting CTRL nodes separated by dots in the variable name, looking at bsc_ctrl_node_lookup() and fsm_ctrl_node_lookup(). correct. I notice though that we do still have open doors for a lot of nonsense being sent to it without proper validation or error messages. GET 42 existing-variable.trailing.names.ignored more nonsense following being ignored in effect is identical to: GET 42 existing-variable So we should probably enforce that there is no ignored nonsense... I agree. Should we also enforce a numeric command ID? I'm not following here. Where would that numeric command ID comning from? GET currently-any-id-is-possible-even-\t-\n-is-accepted my-command this is also not intended, I'm quite sure. Going back to the OsmoHLR CTRL commands -- they are implemented in a way that doesn't match the CTRL interface ways. Let's collapse them. SET enable-ps <IMSI> SET disable-ps <IMSI> SET status-ps <IMSI> indeed, this is not proper. SET subscriber.by-imsi.123456789098765.ps-enabled 1 SET subscriber.by-imsi.123456789098765.ps-enabled 0 GET subscriber.by-imsi.123456789098765.ps-enabled makes a lot of sense to me. We can also expand this later to things like GET subscriber.by-imsi.123456789098765.status SET subscriber.by-imsi.123456789098765.msisdn 2345 GET subscriber.by-msisdn.2342.status SET subscriber.by-msisdn.2342.ps-enabled 0 GET subscriber.by-imei.987654321234565.imsi looks good! We could leave the enable-ps, disable-ps, status-ps commands in place in case anyone is using it yet. I assume no-one is though. I don't think we need to keep compatibility at this point. -- - Harald Welte <laforge@gnumonks.org<mailto:laforge@gnumonks.org>> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170928/d568b5f9/attachment-0001.bin> ------------------------------ Message: 5 Date: Wed, 27 Sep 2017 21:46:27 -0400 From: Kathryn Heckman <exuberant.kathryn.heckman@gmail.com<mailto:exuberant.kathryn.heckman@gmail.com>> To: Harald Welte <laforge@gnumonks.org<mailto:laforge@gnumonks.org>> Cc: "openbsc@lists.osmocom.org<mailto:openbsc@lists.osmocom.org>" <openbsc@lists.osmocom.org<mailto:openbsc@lists.osmocom.org>> Subject: Re: Retrieve OP from OPc and Ki Message-ID: <CAHmN-qT=5x=5XZnwhjYBSByw2ZJpWtCRMiWHu3iWxDysBQT6cA@mail.gmail.com<mailto:CAHmN-qT=5x=5XZnwhjYBSByw2ZJpWtCRMiWHu3iWxDysBQT6cA@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" I really appreciate your quick replies. I have a USIM that I wanted to program. However, I am getting the runtime error for exceeding the number of attempts to enter the ADM1 key. Is there any fix for it? -- Kathryn On Wed, Sep 27, 2017 at 6:52 PM, Harald Welte <laforge@gnumonks.org<mailto:laforge@gnumonks.org>> wrote: Hi Kathryn, On Wed, Sep 27, 2017 at 05:37:36PM -0400, Kathryn Heckman wrote: Is there any way to retrieve the value of OP from OPc and Ki? No, that defeats the entire purpose of having card-individual OPc values. If you could just revert that operation, there would be no [security] advantage of card-individual OPc values over a global OP value, and hence that entire option could be dropped from the specifications altogether. Regards, Harald -- - Harald Welte <laforge@gnumonks.org<mailto:laforge@gnumonks.org>> http://laforge.gnumonks.org/ ============================================================ ================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170927/620a2963/attachment-0001.html> ------------------------------ Message: 6 Date: Wed, 27 Sep 2017 18:04:35 -0800 From: Mychaela Falconia <mychaela.falconia@gmail.com<mailto:mychaela.falconia@gmail.com>> To: Kathryn Heckman <exuberant.kathryn.heckman@gmail.com<mailto:exuberant.kathryn.heckman@gmail.com>> Cc: openbsc <openbsc@lists.osmocom.org<mailto:openbsc@lists.osmocom.org>> Subject: Re: Retrieve OP from OPc and Ki Message-ID: <CA+uuBqbtTfsrADC-ENCfGt2RY=XYUYN0d466=ZR3Mrn_up-L8A@mail.gmail.com<mailto:CA+uuBqbtTfsrADC-ENCfGt2RY=XYUYN0d466=ZR3Mrn_up-L8A@mail.gmail.com>> Content-Type: text/plain; charset="UTF-8" On 9/27/17, Kathryn Heckman <exuberant.kathryn.heckman@gmail.com<mailto:exuberant.kathryn.heckman@gmail.com>> wrote: I have a USIM that I wanted to program. However, I am getting the runtime error for exceeding the number of attempts to enter the ADM1 key. Is there any fix for it? Someone please correct me if I am wrong, but I would assume that having exceeded the number of attempts to enter the ADM1 key means that the USIM is bricked beyond recovery. But the sysmoUSIM cards sold at shop.sysmocom.de<http://shop.sysmocom.de> are fairly inexpensive for a pack of 10, so a bricked (U)SIM shouldn't be too big of a tragedy - or is there another dimension to this problem which I am missing? If you are anywhere near local to me (California, USA) I could give you one of my sysmoUSIM cards, but I am guessing it probably won't help you as I bought the cheaper version without the ADM1 keys - for my application (production testing of my GSM MS hardware) it doesn't matter what the programming of the (U)SIM happens to be. M~ ------------------------------ Message: 7 Date: Thu, 28 Sep 2017 04:35:24 +0200 (CEST) From: Tomcs?nyi, Domonkos <domi@tomcsanyi.net<mailto:domi@tomcsanyi.net>> To: Mychaela Falconia <mychaela.falconia@gmail.com<mailto:mychaela.falconia@gmail.com>> Cc: Kathryn Heckman <exuberant.kathryn.heckman@gmail.com<mailto:exuberant.kathryn.heckman@gmail.com>>, openbsc <openbsc@lists.osmocom.org<mailto:openbsc@lists.osmocom.org>> Subject: Re: Retrieve OP from OPc and Ki Message-ID: <1A1DD58D-617B-4FBE-B363-21A25EBCFA83@tomcsanyi.net<mailto:1A1DD58D-617B-4FBE-B363-21A25EBCFA83@tomcsanyi.net>> Content-Type: text/plain; charset="utf-8" Hi Kathryn and Mychaela, 2017. szept. 28. d?tummal, 4:04 id?pontban Mychaela Falconia <mychaela.falconia@gmail.com<mailto:mychaela.falconia@gmail.com>> ?rta: Someone please correct me if I am wrong, but I would assume that having exceeded the number of attempts to enter the ADM1 key means that the USIM is bricked beyond recovery. This is my understanding as well. Cheers, Domi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170928/c99fe291/attachment.html> ------------------------------ Subject: Digest Footer _______________________________________________ OpenBSC mailing list OpenBSC@lists.osmocom.org<mailto:OpenBSC@lists.osmocom.org> https://lists.osmocom.org/mailman/listinfo/openbsc ------------------------------ End of OpenBSC Digest, Vol 35, Issue 30 *************************************** The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately. The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately. -- best regards, Krazy Sandi Blue Soho Recordings Number One Recordings The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately.
Hi, first of all please pick a useful email subject when writing to a mailing list. Secondly, don't ever send a mailing list digest back to the mailing list. This is seriously bad, you are re-inserting a digest into the next digest, as well as the mail archive, as well as everyone's mail inbox. About your questions: clean your system of any previous osmocom installations, then best re-clone and rebuild everything from scratch. The errors you are seeing hint at conflicting previous installations. You may also try a top-level makefile building everything from scratch: git://git.osmocom.org/osmo-dev (see the enclosed README file) May I ask which femto cell you would like to test? You will have to be able to configure it, and it needs to expose the Iuh interface for Osmocom to work with it. You need to run: femto --> osmo-hnbgw --> osmo-stp --> osmo-msc --> osmo-hlr --> osmo-bsc_mgcp (The wiki needs updating on this) ~N
participants (4)
-
Neels Hofmeyr -
Popovic Goran -
Sandi Suhendro -
Tomcsányi, Domonkos