Motorola IV Calculation

[EI9BAB]

There was a previous discussion on this forum regarding the generation of IVs with Enhanced Privacy which fell into the usual trap of discussing how to decrypt encrypted comms and people looking for keys which is NOT what this question is about. The question is that somewhere in the standards or patents I seem to recall a specification for how to generate IVs (Initialisation Vectors) or "Message Indicators" as Motorola refers to them. I am not looking to decrypt anything but just looking to confirm how these publicly broadcast values are calculated in commercial Motorola radios from an educational perspective. IVs can be known or even predicatable and just need to be as unique as possible. Understandign where they come from should not jeapordise the associated encryption algorithm. Some systems just use a straightforward rolling counter and that is fine for many use cases but Motorola apparently use some form of Linear Forward Shift Register for this purpose.

I have seen this mechanism referenced in a couple of different places as using an LFSR with a specifically cited generator polynomial of x^32 + x^4 + x^2 + 1 and I have seen code projects that implement this. However, when looking at actual IVs that are calculated in the real-world, they do not seem to follow this pattern at all. In fact, visual examination of the sequence of bits does not appear to be consistent with the use of any form of LFSR, although I may be missing something obvious. However, the DMR encryption parameter patent does refer to using an LFSR without going into any detail about how that functions. (Although it does explicitly detail a different generator polynomial of X^ 4 + X + 1 for the CRC calculation.)

The only other factor might be a reference to concatanating the CRC and adding the FEC parity bits but I took that to be more in the context of CRC validation rather than IV generation. Also, you would still expect to see some of the input bits retained from this process and that doesn't seem to be the case.

So, without entertaining any discussions about encryption algorithms or decryption technologies, can anyone shed any light on how this IV cycling/LFSR actually works please?

For reference, here are some IVs I have observed in a single continuous transmission from a single radio as an example:

HEX:-
CB269A79
1D995981
8E52FE0E
D69C3148
4233F2D1
16E49C15
0740B9F7
98F35AE1
F92B20DA
ECD2A265
C0E59C8E
8AF72731
EFF53A15

BINARY:-
11001011001001101001101001111001
00011101100110010101100110000001
10001110010100101111111000001110
11010110100111000011000101001000
01000010001100111111001011010001
00010110111001001001110000010101
00000111010000001011100111110111
10011000111100110101101011100001
11111001001010110010000011011010
11101100110100101010001001100101
11000000111001011001110010001110
10001010111101110010011100110001
11101111111101010011101000010101

I have checked more than one installation and noted the same inconsistencies so I don't think I am capturing these incorrectly...

Many thanks

 

[EI9BAB]

It's okay. I figured out the problem.

Firstly I was not properly transforming the polynomial into the proper set of bitwise XORs and ANDs in order to give the correct value for the new feedback bit. (So in the example above, CB269A79 should give 964D34F2 but sometimes I was getting this wrong.)

And, secondly, you have to iterate this process 32 times (for 32 bits) and not just once to generate the next IV/MI. Probably that is obvious to anyone who knows how to actually use an LFSR but I hadn't really looked at these before so there you go.

Anyway, I'm just posting the answer in case anyone was curious or it might even help someone else down the line. Here is the full worked example verifying the first of the observed results above.

Observed MIs in Hex:-
CB269A79
1D995981
8E52FE0E
D69C3148
....

Round #	Input	LFSR Output	(Binary Output)
1	CB269A79	964D34F2	11001011001001101001101001111001
2	964D34F2	2C9A69E4	10010110010011010011010011110010
3	2C9A69E4	5934D3C8	00101100100110100110100111100100
4	5934D3C8	B269A791	01011001001101001101001111001000
5	B269A791	64D34F23	10110010011010011010011110010001
6	64D34F23	C9A69E47	01100100110100110100111100100011
7	C9A69E47	934D3C8E	11001001101001101001111001000111
8	934D3C8E	269A791D	10010011010011010011110010001110
9	269A791D	4D34F23B	00100110100110100111100100011101
10	4D34F23B	9A69E476	01001101001101001111001000111011
11	9A69E476	34D3C8EC	10011010011010011110010001110110
12	34D3C8EC	69A791D9	00110100110100111100100011101100
13	69A791D9	D34F23B3	01101001101001111001000111011001
14	D34F23B3	A69E4766	11010011010011110010001110110011
15	A69E4766	4D3C8ECC	10100110100111100100011101100110
16	4D3C8ECC	9A791D99	01001101001111001000111011001100
17	9A791D99	34F23B32	10011010011110010001110110011001
18	34F23B32	69E47665	00110100111100100011101100110010
19	69E47665	D3C8ECCA	01101001111001000111011001100101
20	D3C8ECCA	A791D995	11010011110010001110110011001010
21	A791D995	4F23B32B	10100111100100011101100110010101
22	4F23B32B	9E476656	01001111001000111011001100101011
23	9E476656	3C8ECCAC	10011110010001110110011001010110
24	3C8ECCAC	791D9959	00111100100011101100110010101100
25	791D9959	F23B32B3	01111001000111011001100101011001
26	F23B32B3	E4766566	11110010001110110011001010110011
27	E4766566	C8ECCACC	11100100011101100110010101100110
28	C8ECCACC	91D99598	11001000111011001100101011001100
29	91D99598	23B32B30	10010001110110011001010110011000
30	23B32B30	47665660	00100011101100110010101100110000
31	47665660	8ECCACC0	01000111011001100101011001100000
32	8ECCACC0	1D995981	10001110110011001010110011000000

 

[avkghost]

Hi EI9BAB.
Thanks for the information.

It's interesting.
I can confirm that nearby Motorola networks use the algorithm mentioned above. I tried on a lot of voice frames and got the same result as I got from the network.

 

[MUTNAV]

I didn't understand any of that...

But I do like how the groups of 1's and 0's form nice little (reverse) diagonal patterns.





I've been told I'm easily amused.


Thanks
Joel