Hello,
Apologies in advance for not responding to the relevant thread/message
IDs. First time poster, long time reader.
Reviewing the relevant email thread about "randomness of identifiers"
and the design in the proposed changes [0] by Max, it seems that the
patch is reasonable with one or two exceptions.
Using OpenSSL is neither necessary, nor sufficient. My understanding is
that it brings other restrictions on the use of the RNG, the state of
the process, as well as a history of serious security concerns. There
are a number of OpenSSL forks such as LibreSSL that seem to be
addressing memory safety which might be a better choice.
Many user space PRNGs now use getrandom() internally with added
complexity in user space which does not seem strictly necessary. If the
system RNG is properly seeded at boot, getrandom() should not block at
any later point in the system's lifetime. After Nadia Heninger's work[1]
attacking the Linux PRNG, the kernel team greatly improved the state of
the kernel's RNG/RNG interfaces. If the system RNG is not properly
seeded, it is game over. Systems running OpenBSC need to have
cryptographically secure source of random numbers. If a user space
cryptographic library really is required, it would probably be better to
use NaCL [2] which is a well designed library for cryptography. It
considers many cryptographic concerns such as various side channel
attacks and properly handles each concern in a systematic manner.
OpenSSL and its family do not seem to have been so carefully designed.
There was recently an interesting design posted [3] by djb about the
design of "Fast-key-erasure random-number generators" which sounds
exactly like what is desired for this use case. It should be extremely
easy to implement. Still, the use of getrandom() without re-seeding is
probably necessary and should also be sufficient even for non GNU/Linux
systems.
Returning to Max's patch:
[4] - A lack of a good random number generator should be a hard
build/runtime failure.
[5] - GNU_TLS is suggested and on the mailing list, OpenSSL, neither
seems to be needed.
Using glibc interface is less complicated than a full user space RNG.
Has anyone reviewed it? Can it fail? If so, how does it fail? It is
simple enough that intuitively it should be safe. Using the system call
directly should ensure the guarantees of the API are met without any
issues. The issue of re-seeding [6] is also one worth re-considering.
One lesson learned from various problems with TLS is worth considering
here as well: it should be secure to expose random outputs from the
(P)RNG and still, it is better to _never_ expose random outputs directly
to the network or to an attacker. A simple design for that is simply to
hash or encrypt random bytes as djb suggests in his [3] design. Raw PRNG
bytes may allow an attacker to break your PRNG as was the case with
ExtendedRandom and DualEC [7]. The Debian OpenSSL case [8] is also
informative, though of a completely different class of worst case
failures, one hopes.
Regarding the conclusion of the reviewer: merging Max's code while
removing the rand() failure mode would be a net improvement for OpenBSC.
The build should fail without getrandom(). Is there any system where
this is an expected failure mode? Anything more complex probably
deserves a design discussion with a well defined threat model for a
given system.
Happy Hacking,
RS
As an aside: If for some reason there is no cryptographically secure
hardware RNG on the OpenBSC system, one wonders if it might be of
interest to use the available RF interfaces as part of a design for such
an RNG. There would be concerns about adversarial control of inputs, of
course. It is also reasonable to try to have multiple sources of
entropy, especially if the only hardware RNG device is one that isn't
verifiable by end users such as RDRAND [9].
[0] https://gerrit.osmocom.org/#/c/1526
[1] https://crypto.stanford.edu/RealWorldCrypto/slides/nadia.pdf
[2] https://nacl.cr.yp.to/features.html
[3] https://blog.cr.yp.to/20170723-random.html
[4] https://gerrit.osmocom.org/#/c/1526/8/utils/osmo-auc-gen.c
[5] https://gerrit.osmocom.org/#/c/1526/8//COMMIT_MSG
[6] https://blog.cr.yp.to/20140205-entropy.html
[7] https://en.wikipedia.org/wiki/Bullrun_%28decryption_program%29
[8]
https://freedom-to-tinker.com/2013/09/20/software-transparency-debian-opens…
[9] https://en.wikipedia.org/wiki/RdRand#Reception
Hi all,
upstream asn1c (https://github.com/vlm/asn1c) has made significant
progress in 2017. It now has basic support for information object
classes, and while doing some S1AP related test I also could compile an
unmodified RANAP ASN.1 syntax from osmo-iuh.git commit
8f2fb0cca5f990b26478e9ec1207fa1e39e691eb - i.e. before all the various
rewrites and hacks that we added to make it pass the much older asn1c
that we were using at the time.
In case anyone wants to play with this, I've had success with asn1c up
to git commit
https://github.com/vlm/asn1c/commit/e700b208bc0b252c85390a80ee63f3687fb2d970
until
https://github.com/vlm/asn1c/commit/ea6635bdae9667bcf6111a25d896c556c946c11a
unfortunately introduces a regression that's tracked in
https://github.com/vlm/asn1c/issues/185
Resolving that regression seems like it requires quite a bit of insight
into asn1c internals, which nobody in Osmocom currently has.
What's still missing from upstream is APER support. Sadly, he
maintainer @vlm states clearly that APER is not a short-term goal for
him. However, ss UPER is supported, and there's the somewhat incomplete
Eurecom/OAI hacks (with our fixes on top) as well as work in the
following pull-request https://github.com/vlm/asn1c/pull/125 I don't
think that's such a big issue anymore. It would be best to create
somewhat of a test suite and then get the APER code up to a state until
it passes that test suite. I'd be happy to put some of my (or sysmocom
developer) time into that.
But assuming that the regression parsing/compiling the ASN.1 syntax can
somehow be fixed, I think there's some clear "light at the end of the
tunnel" that we could compile the 3GPP syntax for RUA, HNBAP, RANAP and
S1AP as-is, without first rewriting it, and without the asn1tostruct.py
hack.
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)
Hi!
yesterday I saw that the github.com mirrors of the
osmo-{bsc,msc,hlr,mgw,sgsn,ggsn} repositories had not yet been created
so far. We have mirrors on github so we can at times look at what
people are doing in public clones of the repositories. This is useful
as in the 21st century, a lot of developers have to have adopted a
quality of "fork and never contribute back" attitude :/
In the past, we had to ask github staff to manually configure a mirror,
as this is not possible to do via their website for some reason.
It seems that this is now discouraged and they suggest to use a
post-receive hook that replicates to github.
I chose another path and used the already existing gerrit replication
plugin which we use to replicate form gerrit to git.osmocom.org. This
replication plugin is now also pushing to the respective github.com
mirrors.
I'm contacting github.com staff to convert all repositories to this
new-style setup. This ensures the setup is identical for all mirrors,
and has the added benefit that we get quicker replication than the
once-per-hour poll.
The setup is documented at
https://osmocom.org/projects/osmocom-servers/wiki/Github_mirrors
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)
Dear all,
this is a post about https://osmocom.org/issues/2362 in which I try to
resolve the "naming fuck-up" regarding the automatic export of rate_ctr.
In short:
* CTRL uses '.' to separate individual elements/nodes of the command
* a lot of rate_ctr groups we use so far use '.' in their group names
(e.g. 'bssgp.bss_ctx') and counter names (e.g. 'tx.bytes')
* This makes the counters un-exportable via CTRL
I have a libosmocore patch that verifies the validity of counter names
(to not contain spaces or dots) at registration time. This way we can
catch any application with erroneous behaviour.
However, this causes the following problem: New libosmocore versions
will make old apps crash or at least fail to have propre counters, as
their names are wrong :(
Also, I don't like to replace all '.' in the counter with '_', as in
seen in the example of 'bssgp.bss_ctx' there is a semantic difference.
'bssgp.' is denoted to indicate the code module from which the counter
is, and 'bss_ctx' denotes the specific object whose counters we refer
to. Manually replacing this with 'bssgp_bss_ctx' is ugly.
One alternative would be to replace '.' with ':' or '/', which are not
characters with a special functoin in the CTRL syntax. This could be
even done automatically at counter registration time, simply replace all
occurrences of '.' with ':' (and log a warning as a reminder to fix the
code?).
I prefer that more, but the question is which characters should be
reserved for CTRL syntactic purpoess, and which are free to use by the
applications to name elements of the CTRL string/node.
Any input to this? I personally would go for ':'. As CTRL is very
loosely modelled after sysfs, ':' also occurs frequently in sysfs names
such as '/sys/bus/usb/devices/1-3:2.0'
So we'd keep the '.' as path/node separator, and we use ':' as separator
inside counter (and possibly other) names, which is opaque to CTRL.
Opinions?
Should we further restrict the CTRL interface strings (and those of
systems exporting to CTRL) to standard US 7-bit ASCII with a limited set
of special characters such as ":-_@" but prevent any non-printable chars
or special chars like "{|}()~[]\^`'?<>=;/+*&%$#!"? I would support such
a motion. We could even make it more general and use that for all our
identifier strings and have a general validation function that all code
modules call whenever validating a string identifier used, such as e.g.
osmo_fsm names, etc.
--
- 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)
I looked at why the 420G of the Osmocombuild1 root fs are full.
1)
Slave "build1-debian9-lxc" is running as lxc called 'docker'.
/var/lib/lxc/docker/rootfs/var/lib/docker/vfs/dir contains 221G in 333 docker
snapshots. It seems to me that these are growing indefinitely, that nothing is
removing docker hashes that have been built. Does anyone have a discarding
strategy ready that we can deploy there? We need to add one to avoid the build
slave filling up again. https://osmocom.org/issues/2539
For now I did
docker rmi $(docker images -q -f dangling=true)
and rm'd a few stopped containers that had started an openbsc test:
docker rm $(docker ps -aq)
which removed hundreds of hashes and freed ~110G
But half of the 221G are still there, not sure if we need those.
I also note that this lxc is not starting automatically after I rebooted
Osmocombuild1 (to get rid of some stuck processes).
I added
lxc.start.auto = 1
to /var/lib/lxc/docker/config
Now the server is back up and running, the lxc is started, but the jenkins
slave refuses to connect. It tries port 45 but nothing is listening
there. I think I've hit this before but can't remember how to solve it :/
https://osmocom.org/issues/2540
2)
Slave "Osmocombuild1" is running as user osmocom-build on the host's OS itself.
The workspaces make up one large chunk of the disk fill: 94G.
Looking at OpenBSC@3, it builds up to 3.8G from the various build matrix
workspaces, where each has a compiled libosmocore at >110MB and osmo-iuh
at >130MB. Then the parrallel builds each make an own workspace, exploding the
total. The good news is that it should cap *somewhere* and not grow
indefinitely.
We probably should adjust the OpenBSC and various gerrit jobs to clean up the
workspace after they are done. We so far never needed the binaries.
https://osmocom.org/issues/2538
~N
Dear all,
Max has been pushing https://gerrit.osmocom.org/#/c/1526 for quite some
time, but there was still no conclusion in its review.
I guess after more than 8 months in limbo, it's about time we decide how
to move ahead with this.
In general, we *want* secure/safe identifiers like TMSIs that are not
easy to predict by an attacker. Using rand() or some other
pseudo-random generator with a predictible seed like the time of the
process start is probably not the best choice here.
Using the rather strong entropy pool of /dev/urandom or getrandom()
is apparently not a good choice either: We can exhaust the entropy pool
at whch point we would have to block/wait, which we of course cannot in
our architecture.
So what do we do? I think we first have to differentiate on the type of
randomness needed. Is it a random identifier like TMSI? Is it a random
challenge used in cryptographic authentication? Is it random data used
for a key? Those require different levels of randomness.
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?
For random challenges in authentiation I would probably go for
direct use of urandom / getrandom(). If the entropy is exhausted, the
quality of the random numbers will get lower, but getrandom() will
always return up t 256 bytes.
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 do you guys think? Is there somebody on this list more
cryptographically qualified to give us proper guidance? If you know
somebody skilled who might want to help but is not on this list, would
you invite them to join this discussion?
--
- 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)
Hi All,
We successfully installed osmo-bsc, osmo-trx, and osmo-bts-trx in Ubuntu 16.04.
All osmo elements were successfully run except for osmo-bts-trx.
Upon running osmo-bts-trx while the osmo-trx and osmo-bsc is running, “Aborted (core dumped)” error is shown:
((*))
|
/ \ OsmoBTS
<0017> control_if.c:788 CTRL at 127.0.0.1 4238
<0010> telnet_interface.c:102 telnet at 127.0.0.1 4241
<0012> input/ipaccess.c:884 enabling ipaccess BTS mode, OML connecting to 192.168.1.41:3002
<000b> trx_if.c:589 Open transceiver for phy0.0
<0012> input/ipa.c:129 connection done.
<0012> input/ipaccess.c:705 received ID get
<0001> oml.c:223 O&M Get Attributes [0], Manufacturer Dependent State is unsupported by TRX.
<0001> oml.c:223 O&M Get Attributes [0], Manufacturer Dependent State is unsupported by TRX.
Assert failed trx oml.c:156
backtrace() returned 10 addresses
/usr/local/osmo-bts/src/osmo-bts-trx/osmo-bts-trx() [0x4123f7]
/usr/local/osmo-bts/src/osmo-bts-trx/osmo-bts-trx() [0x413692]
/usr/local/osmo-bts/src/osmo-bts-trx/osmo-bts-trx() [0x42532d]
/usr/local/lib/libosmoabis.so.6(+0xbdc4) [0x7f3b6c921dc4]
/usr/local/lib/libosmoabis.so.6(+0x96ce) [0x7f3b6c91f6ce]
/usr/local/lib/libosmocore.so.8(osmo_select_main+0x242) [0x7f3b6d5c4862]
/usr/local/osmo-bts/src/osmo-bts-trx/osmo-bts-trx() [0x423b64]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7f3b6bf3e830]
/usr/local/osmo-bts/src/osmo-bts-trx/osmo-bts-trx() [0x404e19]
Aborted (core dumped)
We tried to run the osmo-bts-trx without the osmo-bsc, it only shows “Reason Abis close”:
((*))
|
/ \ OsmoBTS
<0017> control_if.c:788 CTRL at 127.0.0.1 4238
<0010> telnet_interface.c:102 telnet at 127.0.0.1 4241
<0012> input/ipaccess.c:884 enabling ipaccess BTS mode, OML connecting to 192.168.1.41:3002
<000b> trx_if.c:589 Open transceiver for phy0.0
<000d> abis.c:135 Signalling link down
<0001> bts.c:208 Shutting down BTS 0, Reason Abis close
Shutdown timer expired
We know that the latter logs is normal since no osmo-bsc is running.
May we know what causes the core dumped? Is it a configuration issue in our side?
Attached also are the pcap and config files used and taken during the testing.
We used the latest git from "https://git.osmocom.org” for the installation.
TIA
Best Regard,
Ron Menez
ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>
Comments are welcome for https://osmocom.org/issues/2534
I want to remove gsup_client code dup and need a place to put it. Can't go to
libosmocore, because it uses libosmo-abis' IPA Multiplex.
My main open question is: libosmo-abis sounds like it is specifically for the
A-bis interface.
But GSUP, which we use to talk to the OsmoHLR, is not at all related to A-bis.
Does it make sense to put it in libosmo-netif? Or move the IPA Multiplex to
libosmocore? And hence remove some duplication between libosmo-abis and
libosmo-netif?
What do you guys think is worth the trouble?
Just move gsup to libosmo-abis.git and care later?
Thanks!
~N
Hi Max,
I asked before and now we have https://gerrit.osmocom.org/4127 so let me ask
again:
What is bumpversion used for in your 'make release' setup?
I would expect version bumping to be a human choice.
How is it intended to work?
~N
