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)
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 -
Paul Sutton