15 Jul
2019
15 Jul
'19
1:58 p.m.
Hi Harald,
The srsLTE implementation is taken from the ETSI specs simulation program listings:
http://cryptome.org/uea2-uia2/etsi_sage_06_09_06.pdf and
http://cryptome.org/uea2-uia2/snow_3g_spec.pdf
https://www.etsi.org/intellectual-property-rights#mytoc3 and
https://www.etsi.org/images/files/IPR/etsi-ipr-policy.pdf outline the copyright licensing
details for software incorporated in ETSI standards however I have not taken legal advice
on compatibility of this license with AGPLv3.
From a quick review, it looks like the CryptoMobile and
NextEPC versions have taken the same approach.
It would be good as you say to have a
"clean copyright" implementation - perhaps this is something we could help
with.
Best regards,
Paul
Hi!
I'm now at a point where I would like to add SNOW-3G (EIA1/EEA1) support for
NAS integrity protection and ciphering to my upcoming TTCN-3 testsuite for the MME.
However, it seems there is no real FOSS implementation of the SNOW-3G algoritm
around? All I could find was:
* https://github.com/mitshell/CryptoMobile with unclear source of the code,
without a copyright statement or license annotation
* https://github.com/rcatolino/libressl-snow3g/blob/master/crypto/snow3g/main…
without a copyright statement or license annotation
* https://github.com/Jadson27101/SNOW_3G in go,
without a copyright statement or license annotation
* https://github.com/KsirbJ/SNOW-3G
without a copyright statement or license annotation
* https://github.com/open5gs/nextepc/blob/master/src/mme/snow-3g.c
without a copyright statement or license annotation. Looks rather similar
to CryptoMobile. Possible just copy+pasted from ETSI reference implementation?
* https://github.com/srsLTE/srsLTE/blob/master/lib/src/common/snow_3g.cc
also contains no coypright statement or license, but might be construed
to be AGPLv3 like all of srsLTE. However, it states it is "adapted"
from ETSI/SAGE specifications. Does that mean it is an independent
implementation of the algorithm by just reading the specs, or does it
contain actual ETSI-copyrighted code?
It's also odd that the 3GPP specs (35.215 / 35.216, with usual copyright statement)
don't contain any actual information but all just point to the ETSI SAGE
specification
which can be found (at the very least) here:
https://www.gsma.com/aboutus/wp-content/uploads/2014/12/uea2uia2d1v21.pdf
and interestingly doesn't contain any copyright statement whatsoever.
This discussion is not about any potentially 'essential patents' that may or may
not apply in some jurisdictions on the algorithm itself. I'm currently only
interested
in a "clean copyright" implementation of any of the EIA/EEA implementations
used
on the LTE NAS layer.
I'd appreciate any useful comments. Thanks!
--
- Harald Welte <laforge at gnumonks.org
<https://lists.osmocom.org/mailman/listinfo/openbsc>>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
--
________________________________________________________________
Paul Sutton Ph.D.
Software Radio Systems (SRS)
http://www.softwareradiosystems.com
paul(a)softwareradiosystems.com
PGP Key ID: 3B4A5292
Fingerprint: B0AC 19C9 B228 A6EB 86E1 82B2 90C7 EC95 3B4A 5292
________________________________________________________________
16 Jul
16 Jul
1:05 p.m.
Hi Paul,
On Mon, Jul 15, 2019 at 12:58:08PM +0100, Paul Sutton wrote:
The srsLTE implementation is taken from the ETSI specs
simulation
program listings: http://cryptome.org/uea2-uia2/etsi_sage_06_09_06.pdf
and http://cryptome.org/uea2-uia2/snow_3g_spec.pdf
thanks for your feedback.
https://www.etsi.org/intellectual-property-rights#mytoc3 and
https://www.etsi.org/images/files/IPR/etsi-ipr-policy.pdf outline the
copyright licensing details for software incorporated in ETSI
standards however I have not taken legal advice on compatibility of
this license with AGPLv3.
I personally find all I found so far on the the ETSI "IP policy" quite
shady, to be honest. It's weird how the "restricted usage undertaking"
and related documents appear to be devoid of any information about what
kind of rights or license they are talking about. "intellectual
property" is a marketing term. It could refer to anything from
trademarks, patents to copyright.
It's a bit of a surprise that the industry doesn't appear to have
developed more legal clarity around this. This is not only true for
those crypto systems, but equally true e.g. of the reference voice codec
implementations. The specs requires a bit-exact match to what is
released as their source code - yet that source code comes without
copyright statement or any indication of license terms. The big
question is how realistically one could write an independent
implementation which renders the bit-exact results without writing code
that looks identical. Also, there's typically always some collections
of constants / tables, which you have to copy 1:1. Sure, there's some
flexibility in the details of an implementation, but to me it's somewhat
questionable how that would look from a copyright point of view. Guess
I'll have to have that discussion within the FOSS legal circles I
happen to have found my way into.
It would be great to have a discussion around all of this with ETSI,
but I somehow fear they will not really have anyone on the table with
a deep understanding how FOSS works both legally and technically.
It would be good as you say to have a "clean
copyright" implementation
- perhaps this is something we could help with.
I'd very much like that idea. If you have capacity to work on that:
great!
Maybe it's also something where one could convince some FOSS-friendly
academics that it would be worth having e.g. some students work on it.
I don't really have much day-to-day contacts to academic cryptographers,
but I know quite a few and can try to ask around.
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)
1889
days inactive
1890
days old
1 comments
2 participants
participants (2)
-
Harald Welte -
Paul Sutton