Hello.
Attached patch will bring a5/3 support to osmo_a5. The implementatin is done based on spec, results are compared to reference implementation from standard and test vectors.
Unfortunately there are several deficiencies: - it doesn't work with real phonein test network yet - no tests included - code is probably suboptimal here and there
Anyway I would love to read your comments. It would be especially great if someone will manage to test it against real phones in actual network.
Attached patch will bring a5/3 support to osmo_a5. The implementatin is done based on spec, results are compared to reference implementation from standard and test vectors.
Unfortunately there are several deficiencies:
- it doesn't work with real phonein test network yet
Maybe you need to accept the 8 byte of the key in the inverse order. There is always a mixup there because different spec refer to the key in different order and n osmo_a5() we want the key in the same order as we received from the SIM.
- no tests included
Addind a test vector to ../../tests/a5/a5_test.c should be trivial. That test is far from exhaustive but it does show gross errors.
Anyway I would love to read your comments. It would be especially great if someone will manage to test it against real phones in actual network.
I think it'd be useful to split the kasumi impl in its own file, so that we can use it to implement GEA3 GPRS cipher as well.
Also, use TAB for indentation, that's the proper style in osmocom projects. (basically the kernek coding style).
I extracted and merged the return -ENOTSUP part of this patch.
Cheers,
Sylvain
On Thu, Dec 06, 2012 at 08:24:23AM +0100, Sylvain Munaut wrote:
I think it'd be useful to split the kasumi impl in its own file, so that we can use it to implement GEA3 GPRS cipher as well.
please note that there is already a libosmo-crypt-a53 (http://cgit.osmocom.org/cgit/libosmo-crypt-a53) which implements A5/3 and GEA3. However, it's based on the reference code, which may be problematic to distribute.
I belive Erik Tews was working on a clean re-implementation without copyrighted reference code, but I'm not sure what was the result of it (maybe I don't remember)
There
06.12.2012 11:43, Harald Welte пишет:
On Thu, Dec 06, 2012 at 08:24:23AM +0100, Sylvain Munaut wrote:
I think it'd be useful to split the kasumi impl in its own file, so that we can use it to implement GEA3 GPRS cipher as well.
I'd do that in 2nd version of a patch: both Kasumi and KGcore functions are shared so it make sense.
please note that there is already a libosmo-crypt-a53 (http://cgit.osmocom.org/cgit/libosmo-crypt-a53) which implements A5/3 and GEA3. However, it's based on the reference code, which may be problematic to distribute.
Awesome, I can use it for easier testing :) Is there build instructions somewhere? Has it bean tested against actual phones?
Hi,
I think it'd be useful to split the kasumi impl in its own file, so that we can use it to implement GEA3 GPRS cipher as well.
I'd do that in 2nd version of a patch: both Kasumi and KGcore functions are shared so it make sense.
Also, please put any internal method as 'static' so we can avoid polluting the namespace.
please note that there is already a libosmo-crypt-a53 (http://cgit.osmocom.org/cgit/libosmo-crypt-a53) which implements A5/3 and GEA3. However, it's based on the reference code, which may be problematic to distribute.
Awesome, I can use it for easier testing :) Is there build instructions somewhere? Has it bean tested against actual phones?
It's automake ...
I think GEA3 has been tested, but not A5/3. It's doesn't even integrate with the osmo_a5(...) functions.
GPRS cipher and Auth use a sort of plugin system, mostly because the algorithm used in there are still secret and so implementation is sometime provided by external devices / libraries / processes. For the A5/x ciphers, they're all public so they use direct linking and not a dynamic plugin system.
Cheers,
Sylvain
06.12.2012 14:41, Sylvain Munaut пишет:
Hi,
I think it'd be useful to split the kasumi impl in its own file, so that we can use it to implement GEA3 GPRS cipher as well.
I'd do that in 2nd version of a patch: both Kasumi and KGcore functions are shared so it make sense.
Also, please put any internal method as 'static' so we can avoid polluting the namespace.
Done.
I still didn't managed to make it work with phones but now patch is split into logical parts so I hope at least some of the code will be useful.
I've tried to compile libosmo-crypt-a53 but got multitude of errors like:
configure.in:5: error: possibly undefined macro: AM_INIT_AUTOMAKE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.in:15: error: possibly undefined macro: AC_PROG_LIBTOOL configure.in:35: error: possibly undefined macro: AM_CONFIG_HEADER
and
./configure day 341, Четверг 0\0\ ./configure: line 1979: syntax error near unexpected token `dist-bzip2' ./configure: line 1979: `AM_INIT_AUTOMAKE(dist-bzip2)'
Anyway, this is exactly version from standards against which I've already tested mine. I do not want to add any test vectors until I make the code compatible with real phones.
Am Donnerstag, den 06.12.2012, 11:43 +0100 schrieb Harald Welte:
I belive Erik Tews was working on a clean re-implementation without copyrighted reference code, but I'm not sure what was the result of it (maybe I don't remember)
Hi
Yes, a student started working on the project. However, unfortunately just before she was about to finish, a colleague decided to change the schedule and she had to speed up her work. As a result, I would not reconment to use the code. Also I should add, I wasn't ever able to use the code by myself :-(
06.12.2012 15:06, Erik Tews пишет:
Am Donnerstag, den 06.12.2012, 11:43 +0100 schrieb Harald Welte:
I belive Erik Tews was working on a clean re-implementation without copyrighted reference code, but I'm not sure what was the result of it (maybe I don't remember)
Hi
Yes, a student started working on the project. However, unfortunately just before she was about to finish, a colleague decided to change the schedule and she had to speed up her work. As a result, I would not reconment to use the code. Also I should add, I wasn't ever able to use the code by myself :-(
Do you know any details about test setup used for this code? I'm still puzzled why I'm unable to make it work in real networks so any advices would be greatly appreciated.
06.12.2012 17:43, Sylvain Munaut пишет:
Do you know any details about test setup used for this code? I'm still puzzled why I'm unable to make it work in real networks so any advices would be greatly appreciated.
Did you try to swap the byte order of the key like I originally suggested ?
Yes, result is still wrong :( Either I'm doing it wrong or there's smth else which got to be swapped... or some other bugs lurking in shadows :)
When testing A5/3 one should be wary of using Samsung phones, from what I hear they have shipped models with broken A5/3 support, something which has in turn caused delays for operators wishing to roll out A5/3. The core network components have to resort to IMEI filtering to work around these incompatibilities.
f
On Wed, 2012-12-05 at 20:36 +0100, ☎ wrote:
Hello.
Attached patch will bring a5/3 support to osmo_a5... Unfortunately there are several deficiencies:
- it doesn't work with real phonein test network yet
08.12.2012 00:45, Frank A. Stevenson пишет:
When testing A5/3 one should be wary of using Samsung phones, from what I hear they have shipped models with broken A5/3 support, something which has in turn caused delays for operators wishing to roll out A5/3. The core network components have to resort to IMEI filtering to work around these incompatibilities.
Are there list of affected models somewhere? Or list of phones known to work reliable with a5/3 (everything except samsung)?
baseband-devel@lists.osmocom.org
-
Erik Tews -
Frank A. Stevenson -
Harald Welte -
Sylvain Munaut -
☎