HI Neels,
Thanks for provided answers and tips.
Femto wich I plane to use is Alcatel.
My primary target is Packet core, so femto-osmohnbgw-osmosgsn(osmo-hlr)-osmoggsn.
Alredy know this want be easy task, But I will try, I expect also problem with SIM authentication. In past I did protocol simulators in Python (Gb, S11, Gn, Gx, Gy), wich were used in production for testing.
When I hopfuly install osmo-iuh, I wll conect femto to it and try to configure it, will sniff trafic via wireshark between and check whats happening,
Now I will try to rebulid IuH again.
BR
Goran
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,
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(a)lists.osmocom.org
Sent: Thursday, September 28, 2017 4:36 AM
To: openbsc(a)lists.osmocom.org
Subject: OpenBSC Digest, Vol 35, Issue 30
Send OpenBSC mailing list submissions to
openbsc(a)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(a)lists.osmocom.org
You can reach the person managing the list at
openbsc-owner(a)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(a)gnumonks.org>
To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Cc: openbsc(a)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(a)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(a)gnumonks.org>
To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Cc: openbsc(a)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(a)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(a)gnumonks.org>
To: Kathryn Heckman <exuberant.kathryn.heckman(a)gmail.com>
Cc: "openbsc(a)lists.osmocom.org" <openbsc(a)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(a)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(a)gnumonks.org>
To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Cc: Holger Freyther <holger(a)freyther.de>, openbsc(a)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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Yesterday I noticed that apparently we are unable to GET a variable with
argument, e.g. in OsmoHLR get the ps-enabled status of a subscriber and
passing the subscriber's IMSI along for the value we'd like to receive.
Experimenting a bit, I found that for GET commands, any tokens sent after
the variable name are ignored, dropped on the floor and cause neither an
error nor are evaluated.
With a tiny patch, we can make passing arguments to GET parameters
optional:
https://gerrit.osmocom.org/4069
But notably, by adding some CTRL parsing tests I found some interesting
behavior...
https://gerrit.osmocom.org/4067https://gerrit.osmocom.org/4068
In OsmoHLR, such a status request is so far implemented as a SET, since
SET takes an argument and also returns a result. See:
https://gerrit.osmocom.org/4062 (patch obsolete after 4069)
For that particular set of commands in OsmoHLR:
enable-ps <IMSI> (WO)
disable-ps <IMSI> (WO)
status-ps <IMSI> (semantically RO, nevertheless a SET, so technically WO)
I thought it would also make sense to just have one variable for the whole
lot, as in
subscriber-enable-ps <IMSI>,<val> (RW)
so that we reflect that single value with a single CTRL variable. After
all, that's how the CTRL API appears to be intended: GET and SET commands
on the same entity, instead of blowing up each variable by op * value range.
Or even a command to query and change various subscriber values:
subscriber <IMSI> <variable>[=<val>] [<variable>[=<val>] [...]] (RW)
e.g.
GET 1 subscriber 123456789087654 msisdn msc_nr imeisv
reply: subscriber 123456789087654 msisdn=12345 msc_nr=1 imeisv=123456789abcdef
SET 1 subscriber 123456789087654 msisdn=54321 msc_nr=4 imeisv=fab123434843823
reply: OK
or: "Cannot modify msc_nr, nothing changed"
or: "Unknown subscriber parameter: xyz"
One step further would be to pick an identification trait from imsi, msisdn or imei...
GET 1 subscriber imsi=123456789087654 msisdn imeisv
GET 1 subscriber msisdn=12345 imsi imeisv
GET 1 subscriber imeisv=12345abcdef123 imsi msisdn
(often a new subscriber in communal networks can easily find the phone's IMEI,
where the IMSI is unknown, so queries like this would be useful in general)
Would this be too much of a monster command? Rather:
GET 1 subscriber-by-imsi 123456789087654 msisdn imeisv
GET 1 subscriber-by-msisdn 12345 imsi imeisv
GET 1 subscriber-by-imeisv 12345abcdef123 imsi msisdn
Comments welcome!
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
I have two SIM card I inheritted from a previous project that I've been told came from the same vendor. When I run `pcsc_scan` on them, I get the following output for both:
Reader 0: OMNIKEY CardMan (076B:3022) 3021 00 00
Card state: Card inserted,
ATR: 3B 7D 94 00 00 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68
ATR: 3B 7D 94 00 00 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68
+ TS = 3B --> Direct Convention
+ T0 = 7D, Y(1): 0111, K: 13 (historical bytes)
TA(1) = 94 --> Fi=512, Di=8, 64 cycles/ETU
62500 bits/s at 4 MHz, fMax for Fi = 5 MHz => 78125 bits/s
TB(1) = 00 --> VPP is not electrically connected
TC(1) = 00 --> Extra guard time: 0
+ Historical bytes: 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68
Category indicator byte: 55 (proprietary format)
Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3B 7D 94 00 00 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68
SIM from sysmocom sysmoSIM-GR2
When I try to program one of the SIMs, it works fine:
$ sudo ./pySim-prog.py -p 0 -i 001010000000001 -k ffffffffffffffffffffffffffffffff -t sysmoSIM-GR2 --num=1 --mcc=001 --mnc=01
Insert card now (or CTRL-C to cancel)
Generated card parameters :
> Name : Magic
> SMSP : e1ffffffffffffffffffffffff0581005155f5ffffffffffff000000
> ICCID : 8901001010000000017
> MCC/MNC : 1/1
> IMSI : 001010000000001
> Ki : ffffffffffffffffffffffffffffffff
> OPC : f134b55cea2942ebbd213c82e084be62
> ACC : None
Programming ...
Done !
But on the other I get:
$ sudo ./pySim-prog.py -p 0 -i 001010000000001 -k ffffffffffffffffffffffffffffffff -t sysmoSIM-GR2 --num=1 --mcc=001 --mnc=01
Insert card now (or CTRL-C to cancel)
Generated card parameters :
> Name : Magic
> SMSP : e1ffffffffffffffffffffffff0581005155f5ffffffffffff000000
> ICCID : 8901001010000000017
> MCC/MNC : 1/1
> IMSI : 001010000000001
> Ki : ffffffffffffffffffffffffffffffff
> OPC : 53945a5223e299bf6cec05911922442c
> ACC : None
Programming ...
Traceback (most recent call last):
File "./pySim-prog.py", line 636, in <module>
card.program(cp)
File "/home/user/workspace/pysim/pySim/cards.py", line 382, in program
self._scc.verify_chv(0x05, pin)
File "/home/user/workspace/pysim/pySim/commands.py", line 111, in verify_chv
return self._tp.send_apdu_checksw(self.cla_byte + '2000' + ('%02X' % chv_no) + '08' + fc)
File "/home/user/workspace/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw
raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1]))
RuntimeError: SW match failed ! Expected 9000 and got 9840.
I also tried some of the other branches, as people on other forums had reported better luck with those, but I get the same error. Is there any documentation explaining the magic byte values that are sent back and forth to the card? I'm having a hard time understanding the spec by which the program is trying too communicate with the card.
Any help is greatly appreciated.
Thanks,
Billy
Hi.
There's clearly big difference between split BSC/MSC and NITB
(config files, support for SCCP-lite etc) which makes the transition rather lengthy.
What about SGSN and related stuff? It's been transitioned to libvlr at the time of
split as well, but does this transition have any user-visible consequences?
If not than we could transition gradually:
* make SGSN build optional (--enable-gprs?) in openbsc repo
* start building OsmoSGSN from osmo-sgsn repo instead of openbsc (both .deb and OE)
* test and make sure that it works the same way (both on sysmobts and on debian)
* disable SGSN build by default and announce that patches should be made against new repo
* remove gprs code from openbsc leaving placeholder readme with the link to new repo
All the steps above are unrelated to BSC/MSC items so it could be done independently.
--
Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Hi All,
We installed osmo-bts-trx using Debian 9 OS through nightly package and encountered an error after running it.
As per checking, there is an existing bug in osmo-bts regarding the "osmobts-trx: error while loading shared libraries: libosmotrau.so.1: cannot open shared object file: No such file or directory” error.
https://osmocom.org/issues/2481
So we tried to install it through building it from source.
Upon installation, we encountered an error upon running ./configure. Error message:
checking whether to enable support for sysmoBTS L1/PHY support... no
checking whether to enable support for osmo-trx based L1/PHY support... no
checking whether to enable support for Octasic OCTPHY-2G... no
checking whether to enable NuRAN Wireless Litecell 1.5 hardware support... no
checking for openbsc/gsm_data_shared.h... no
configure: error: openbsc/gsm_data_shared.h can not be found in /root/osmo-bts/../openbsc/openbsc/include
So we tried to rename the gsm_data.h found in “~/osmo-bts/include/openbsc” folder to gsm_data_shared.h.
The ./configure goes through but has an error upon running "make”.
Is there another way to install osmo-bts?
Best Regard,
Ron Menez
ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>
Hello,
I have gone through some of the documentations and now trying to install
osmoBSC i.e just the BSC part not the openBSC or osmoNITB. I am kind of
confused , can anyone please tell me if I can build just the BSC part and
in order to do that what are the packages that I have to configure.
Thanks
Anindya
To fix the osmo-msc preliminary debian package build of osmo-msc, I need these
patches in osmo-mgw to be merged:
https://gerrit.osmocom.org/3999https://gerrit.osmocom.org/4000https://gerrit.osmocom.org/4001https://gerrit.osmocom.org/4002https://gerrit.osmocom.org/4003https://gerrit.osmocom.org/4005
(topic 'new_mgw' less 4006 and 4007)
If review takes too long I am tempted to just merge it ahead to fix the state
of osmo-msc.deb in
https://build.opensuse.org/project/show/network:osmocom:nitb-split:nightly
If I do, it means that I would like to fix and improve those patches later, not
that I want to smuggle them past review. I just want to finally get the debian
builds working and off my mind again.
The osmo-msc currently fails because it needs a header file not included in
libosmo-mgcp-client-dev, because that is still tied to libosmo-mgcp headers,
which are of course not included in the libosmo-mgcp-client deb. I want them to
be separated completely to save us this kind of cumbersomeness in the future.
Only one of the above commits unties libosmo-mgcp-client from the other libs,
but small bits here and there make the change depend on the others in that
bunch. I could re-arrange, but that would take time. I'd rather just keep them
in that order, we want them merged anyway.
The large ones in the middle are dexter's work on the next generation MGW that
happened on a branch, being placed beside the legacy code. This way we can move
from legacy to new code in osmo-msc and osmo-bsc independently.
~N
