Results 1 to 25 of 25

Thread: XTS5000 encryption key issue

  1. #1
    Join Date
    May 31, 2012
    Posts
    229
    Thanks
    41
    Thanked 61 Times in 31 Posts

    Default XTS5000 encryption key issue

    Got a strange one here. At least I think it's strange, I don't get to play with encryption all that much.

    Have an existing customer with a fleet of XTS5000's, being used in Astro digital mode on a legacy SmartZone system. Been using encryption for years, no issues. Recently purchased a dozen new XTS5000's. Flashcodes are identical, so the programming from an existing unit was cloned into the new radios with unique ID's.

    Customer using their KVL3000 to keyload the new units, the keyload shows that it's loading slot 001 to 001, and says 'successful' afterwards...all appears identical to loading one of their 'older' units. The new radio shows "HwKey1" upon power up or channel change, same as the older units. But...the new radio will not talk to the old radio in encrypted mode. Clear mode is fine.

    I haven't confirmed yet whether all the new radios can talk to one another, waiting for the customer to verify yes or no.

    Could it be a firmware issue? The older radios are all v12.xx.xx vintage and the UCM is v5.06.00. The new radios are 17.01.01, with UCM v7.11.10.

    Any ideas?


  2. #2
    Join Date
    Dec 21, 2011
    Posts
    4,892
    Thanks
    4,950
    Thanked 8,389 Times in 2,315 Posts
    Country: Canada

    Default

    Quote Originally Posted by Ice-T View Post
    Got a strange one here. At least I think it's strange, I don't get to play with encryption all that much.

    Have an existing customer with a fleet of XTS5000's, being used in Astro digital mode on a legacy SmartZone system. Been using encryption for years, no issues. Recently purchased a dozen new XTS5000's. Flashcodes are identical, so the programming from an existing unit was cloned into the new radios with unique ID's.

    Customer using their KVL3000 to keyload the new units, the keyload shows that it's loading slot 001 to 001, and says 'successful' afterwards...all appears identical to loading one of their 'older' units. The new radio shows "HwKey1" upon power up or channel change, same as the older units. But...the new radio will not talk to the old radio in encrypted mode. Clear mode is fine.

    I haven't confirmed yet whether all the new radios can talk to one another, waiting for the customer to verify yes or no.

    Could it be a firmware issue? The older radios are all v12.xx.xx vintage and the UCM is v5.06.00. The new radios are 17.01.01, with UCM v7.11.10.

    Any ideas?
    Sounds like a programming problem.

    - Check key strapping per-talkgroup. (this wouldn't have cloned over without the system key/ASK present)
    - Check to make sure it's DES-OFB and not DES-XL which is strapped to the personality
    - Check to make sure the same PID is being used (your description makes it sound like ASN is the KVLing method)
    - Check your slots. In programming, "Key 1" is slot 0 when you're loading keys. So "Load key 1 --> slot 0" Make sense?

    I doubt it's firmware related. It's all cross-compatible.

  3. #3
    Join Date
    May 31, 2012
    Posts
    229
    Thanks
    41
    Thanked 61 Times in 31 Posts

    Default

    Thanks for the response Mars, I know you're very knowledgeable when it comes to encryption, and was hoping you'd respond. See my answers below. I'm still a bit stumped.

    Sounds like a programming problem. This is what I thought at first, thus the cloning.

    - Check key strapping per-talkgroup. (this wouldn't have cloned over without the system key/ASK present) I have the system key. Everything is cloned.
    - Check to make sure it's DES-OFB and not DES-XL which is strapped to the personality Again, cloned, so it's identical.
    - Check to make sure the same PID is being used (your description makes it sound like ASN is the KVLing method) It is indeed ASN...I can keyload the 'older' radio, then simply switch the cable to the 'newer' radio and press 'load'...no other changes, so the PID is the same.
    - Check your slots. In programming, "Key 1" is slot 0 when you're loading keys. So "Load key 1 --> slot 0" Make sense? Yep, I understand slots...the keyloader shows the same slots for both 'older' and 'newer' radios when keyloading.

    I doubt it's firmware related. It's all cross-compatible. As I've always thought, and never had an issue before this...just grasping at straws now.

    I did double check all the above, despite cloning, just in case.

  4. #4
    Join Date
    Dec 21, 2011
    Posts
    4,892
    Thanks
    4,950
    Thanked 8,389 Times in 2,315 Posts
    Country: Canada

    Default

    One thing I noted with interest is your UCM has firmware version R07.xx.xx. The ASTRO25 line uses R05.xx.xx UCM firmware. I know Motorola released a new "MACE" for the ASTRO25 radios, as there's reference to it in the firmware notes. I've never seen one of these modules before. Can you take a picture of it for us? (both sides, with macro lens shots of the chip stamps)

    It could be the new MACE thing is not compatible with PID/ASN loading. Or there's a bug with the PID/ASN operation. Have you tried setting the new radio to use CKR, and using the KVL in ASTRO25 mode to key this new R07.xx.xx MACE module? If you don't know the key, don't worry -- you can use the PORT command in the KVL to copy the key over to the other key database (mode) in the KVL itself. It will just ask you to specify a CKR slot you wish to use.

    I'm really curious too!

  5. #5
    Join Date
    May 16, 2012
    Location
    terra australis incognita
    Posts
    474
    Thanks
    0
    Thanked 5 Times in 4 Posts

    Default

    Just to echo what Mars already said, it doesn't (well, it shouldn't) matter if one radio is using ASN/PID to store keys and another is using ASTRO25/CKR, the only things transmitted over-the-air are the ALGID and the KID. It shouldn't even matter if keys are stored in different slots so long as OTAR isn't involved?

    If every one of the new radios refuses to talk with every one of the old radios, and both subsets will talk among themselves, I would tend to agree that you're probably looking at hardware/firmware incapability problems, if that's the case I think Motorola (and quite a few people here) would be very interested in your findings!
    Andrew

  6. #6
    Join Date
    May 31, 2012
    Posts
    229
    Thanks
    41
    Thanked 61 Times in 31 Posts

    Default

    Quote Originally Posted by Bigfella237 View Post
    Just to echo what Mars already said, it doesn't (well, it shouldn't) matter if one radio is using ASN/PID to store keys and another is using ASTRO25/CKR, the only things transmitted over-the-air are the ALGID and the KID. It shouldn't even matter if keys are stored in different slots so long as OTAR isn't involved?

    If every one of the new radios refuses to talk with every one of the old radios, and both subsets will talk among themselves, I would tend to agree that you're probably looking at hardware/firmware incapability problems, if that's the case I think Motorola (and quite a few people here) would be very interested in your findings!
    Indeed, once I get confirmation from the customer whether the 'new' radios can talk among themselves or not while , I'll be opening up a GCC with Motorola. Mars, I haven't tried using the CKR/Astro25 mode with the new radio to see if it makes a difference. I've never loaded with anything other than ASN mode, so it never really occurred to me. I know their KVL has both modes, so I can try that although I need to get them to bring it back in to me.

    Would loading a key in Astro25 mode still allow the encryption to work over the older legacy 3600bps SmartZone digital?

    I will open up the radio and take some pics for you in the meantime.

  7. #7
    Join Date
    May 16, 2012
    Location
    terra australis incognita
    Posts
    474
    Thanks
    0
    Thanked 5 Times in 4 Posts

    Default

    Quote Originally Posted by Ice-T View Post
    ~ Would loading a key in Astro25 mode still allow the encryption to work over the older legacy 3600bps SmartZone digital? ~
    Yes, the only things that matter to the outside world are the ALGID, the KID and of course the key itself.

    Over-simplifying here, the two modes (ASN / ASTRO 25) are just different ways of storing keys within the radio.
    Andrew

  8. #8
    Join Date
    Apr 09, 2012
    Location
    Australia
    Posts
    944
    Thanks
    297
    Thanked 694 Times in 258 Posts
    Country: Australia

    Default

    I think even simpler than that, its just an interface between the KVL and the radio itself. Once the keys are loaded in the slots, its all the same

  9. #9
    Join Date
    May 31, 2012
    Posts
    229
    Thanks
    41
    Thanked 61 Times in 31 Posts

    Default

    Quote Originally Posted by Bigfella237 View Post
    Yes, the only things that matter to the outside world are the ALGID, the KID and of course the key itself.

    Over-simplifying here, the two modes (ASN / ASTRO 25) are just different ways of storing keys within the radio.
    Quote Originally Posted by MattSR View Post
    I think even simpler than that, its just an interface between the KVL and the radio itself. Once the keys are loaded in the slots, its all the same
    Thanks for the clarification guys. I was assuming as much, but I've been wrong before!

  10. #10
    Join Date
    May 16, 2012
    Location
    terra australis incognita
    Posts
    474
    Thanks
    0
    Thanked 5 Times in 4 Posts

    Default

    When the time comes, porting keys is fairly straight forward, if you don't have the KVL user guide I believe it's still available for download from this forum, toward the back of the manual under the "Migration" tab is the chapter you need.

    Basically, starting in ASN mode, you go into the "PORT" menu, select the encryption key you want to transfer, enter the new CKR and "ACCEPT". You may also be asked to specify whether you want a DES key to be ported to DES-XL (for analog use) or DES-OFB (for digital).

    In terms of KVL memory, this will require the same additional amount of available memory as creating a new key from scratch; very few people would be using that much memory in their KVLs but it's worth mentioning I guess?

    Just a note on choosing a CKR too, you may want to consult with the customer here to see if they have specific CKRs allocated for their future keys, the reason being that there may be issues with interoperability? For example, if agency A agrees to share a secure talkgroup with agency B for liaison, neither agency would normally be willing to just email the encryption key details to the other, they would most likely just take their radios to the other agency and have them physically add their keys to the radios.

    The problem here (and of course this applies to LIDs/KIDs as well) is if both agencies individually decide to use CKR "0001", and then later decide to share keys, there will obviously be a conflict. What would happen in this case is that agency B would overwrite agency A's original key and the radio would no longer correctly decrypt agency A's traffic.

    It's not a big deal by any means, and in terms of your testing may not worth worrying about, but something to consider if your customer is forced to move to ASTRO 25 mode for all their radios?

    And of course there is the caveat on TEK and KEK CKRs; traffic keys can have a CKR in the range of 0001-4095 (0x001-0xFFF)*, shadow keys (used for OTAR) must have a CKR in the range of 61440-65535 (0xF000-0xFFFF).

    *Note: The manuals states this range is 0001-4095 but I believe some here have recently discovered that "0000" is also a valid CKR?
    Andrew

  11. #11
    Join Date
    Dec 21, 2011
    Posts
    4,892
    Thanks
    4,950
    Thanked 8,389 Times in 2,315 Posts
    Country: Canada

    Default

    Note to everyone: I've split the MACE discussion (pics, etc.) from this thread into a new thread.

    If OP could let us know the results of the ASTRO25 vs. ASN keyloading tests/outcome in THIS thread, that would be great. If it is an ASN bug in the new MACE module, it should be relayed to Moto for investigation/bugfix.

    Please discuss the MACE itself, in the new thread. Thanks!

  12. #12
    Astro Spectra's Avatar
    Astro Spectra is offline T S - Moderator
    CS Forums $upporter
    Join Date
    Nov 22, 2012
    Posts
    968
    Thanks
    391
    Thanked 719 Times in 340 Posts
    Country: Great Britain

    Default

    @Bigfella, you're thinking KID (key ID) rather than CKR. The name CKR is for the slot in the radio that holds the key but the CKR number is not relevant to the over-the-air key selection. Each CKR slot holds a key and an associated KID (AKA legacy TLA LID). The CKR can't be zero but I've found that the KID/LID in the loader can be 0000 (at least for the Astro25 platform and the KVL3k+) and that 0000 works the over the air. However, there may be some reason (security or compatibility) for restricting the KID range.
    Last edited by Astro Spectra; Feb 14, 2013 at 07:31 PM.
    It is a fine thing to be honest, but it is also very important to be right

  13. #13
    Join Date
    May 16, 2012
    Location
    terra australis incognita
    Posts
    474
    Thanks
    0
    Thanked 5 Times in 4 Posts

    Default

    DOH! Yes you are correct sir, I was thinking of the "0000" KID mentioned in the other thread, apologies.
    Andrew

  14. #14
    Astro Spectra's Avatar
    Astro Spectra is offline T S - Moderator
    CS Forums $upporter
    Join Date
    Nov 22, 2012
    Posts
    968
    Thanks
    391
    Thanked 719 Times in 340 Posts
    Country: Great Britain

    Default

    No worries. Your post reminded me to do some more reading on the KID/LID number range.
    It is a fine thing to be honest, but it is also very important to be right

  15. #15
    Join Date
    May 31, 2012
    Posts
    229
    Thanks
    41
    Thanked 61 Times in 31 Posts

    Default

    Quote Originally Posted by Mars View Post
    If OP could let us know the results of the ASTRO25 vs. ASN keyloading tests/outcome in THIS thread, that would be great. If it is an ASN bug in the new MACE module, it should be relayed to Moto for investigation/bugfix.
    Will do, on both accounts! I'm out of the office for the Motorola convention in Vegas next week, so if the customer doesn't get back to me tomorrow, it'll be a week or so before any updates.

  16. #16
    Alpha's Avatar
    Alpha is offline T S - Moderator
    CS Forums $upporter
    Join Date
    Feb 12, 2012
    Location
    Directly above the center of the earth.
    Posts
    2,780
    Thanks
    1,235
    Thanked 1,530 Times in 738 Posts
    Country: Christmas Island

    Default

    KID's of 0000 are "special" in that they don't send any key ID. When using key steering, KID's of 1 and higher will be sent along with the data stream and cause the receiving radio to auto-swtich the active key to the one being used by the transmitting radio. Using a KID of 0000 will cause that auto-select slaving action to not work, for some reason it's a special "reserved" KID that is designated "don't send a KID". KID's index the physical slot in the radio, so if the order of the keys isn't the same in both radios the older KID system will fail. This is why CKR was invented - this sends an ID unique to each key regardless of what physical slot it's residing in, so the 3rd key will match up to the 6th key in another radio, assuming the keys (and thus the CKR) would be the same number. With the older ASN Key ID system, that would fail as the radios would try to use different keys from slots 3 or 6 and would not match up.

    In short if you're using the older ASN Key ID's, as long as they are both loaded from the same KVL the key slots should match up OK. If you're using CKR's then you have no worries at all.


    Quote Originally Posted by Astro Spectra View Post
    @Bigfella, you're thinking KID (key ID) rather than CKR. The name CKR is for the slot in the radio that holds the key but the CKR number is not relevant to the over-the-air key selection. Each CKR slot holds a key and an associated KID (AKA legacy TLA LID). The CKR can't be zero but I've found that the KID/LID in the loader can be 0000 (at least for the Astro25 platform and the KVL3k+) and that 0000 works the over the air. However, there may be some reason (security or compatibility) for restricting the KID range.

  17. #17
    Join Date
    May 31, 2012
    Posts
    229
    Thanks
    41
    Thanked 61 Times in 31 Posts

    Default

    Quote Originally Posted by Alpha View Post
    KID's of 0000 are "special" in that they don't send any key ID. When using key steering, KID's of 1 and higher will be sent along with the data stream and cause the receiving radio to auto-swtich the active key to the one being used by the transmitting radio. Using a KID of 0000 will cause that auto-select slaving action to not work, for some reason it's a special "reserved" KID that is designated "don't send a KID". KID's index the physical slot in the radio, so if the order of the keys isn't the same in both radios the older KID system will fail. This is why CKR was invented - this sends an ID unique to each key regardless of what physical slot it's residing in, so the 3rd key will match up to the 6th key in another radio, assuming the keys (and thus the CKR) would be the same number. With the older ASN Key ID system, that would fail as the radios would try to use different keys from slots 3 or 6 and would not match up.

    In short if you're using the older ASN Key ID's, as long as they are both loaded from the same KVL the key slots should match up OK. If you're using CKR's then you have no worries at all.
    Great summary Alpha, makes very good sense to me now.

  18. #18
    Astro Spectra's Avatar
    Astro Spectra is offline T S - Moderator
    CS Forums $upporter
    Join Date
    Nov 22, 2012
    Posts
    968
    Thanks
    391
    Thanked 719 Times in 340 Posts
    Country: Great Britain

    Default

    Well I can confirm that a KID of 0000 actually appears to be sent. This was found during investigation of the Quantar V.24 stream where the KID can be seen recovered, to be precise reported, by the Quantar from the over-the-air CAI. But you raise a good point and I will test and see if a KID of 0000 prevents 'auto-switch' key selection. I found this by accident on the XTS/XTL platform as KIDs from 1 up were already filled in the loader and because I didn't want to overwrite them with my known test key, I put it in 0000 as that was unused.
    Last edited by Astro Spectra; Feb 15, 2013 at 08:19 PM.
    It is a fine thing to be honest, but it is also very important to be right

  19. #19
    Join Date
    May 31, 2012
    Posts
    229
    Thanks
    41
    Thanked 61 Times in 31 Posts

    Default

    Ok, the customer brought in some more radios and their keyloader. Now the issue is solved (somewhat) and it's not any sort of firmware/UCM issue but rather mine and the customer's lack of knowledge, and me providing you incomplete information. It did turn out to be a 'slot' issue (As Mars previously alluded to).

    I've learned a few things today. I knew about "slots" and knew if you didn't keep things "lined up" so to speak, you could have issues. But, I didn't have a full understanding of them either.

    So, I'll explain it as best as I can. The customer for whatever reason, had always loaded his keys into the KVL in locations 20 or higher. When you do that, and you keyload into a radio, it defaults the transfer to "slot 0" in the radio. So, whether they had single key or multi-key capable radios, it always worked fine, and they never paid attention to the actual transfer slot.

    This time around, the customer loaded the key into KVL location 1...which defaults the transfer to "slot 1" in the radio. This is what I learned today...locations 1-15 in the KVL by default want to transfer the key into slots 1-15 in the radio. Locations 16 and above, default is "slot 0".

    Problem is, none of the radios were set for multi-key in the codeplug. So, the key appeared to load fine into "slot 1" in all their radios, but "slot 1" isn't a valid programmed slot.

    Here is where it gets a little murky for me...all their existing radios with old key "A" in 'slot 0' were loaded with new key "B" in 'slot 1', and all talked to one another. Their dozen new radios, which did not have a key in them at all, were loaded with new key "B" in 'slot 1', which wasn't valid, yet the radio believed it had a key in slot 0, as the dozen radios did not show 'keyfail' and would talk to one another in secure mode, but not to the old radios.

    I thought that logically, their original radios were actually still using old key "A" in slot 0 and was why they would not talk to the new radios. But, we tried loading old key "A" into slot 0 in the new radios, and they still wouldn't talk. It almost seems like writing key "B" into invalid 'slot 1' in the radios resulted in a key "C" in the valid slot 0.

    Anyway, to fix things, they are going to re-key all their radios from locations 20 or higher in the KVL again, to ensure they are always writing to slot 0.

    Clear as mud?

    On the upside...we did learn about the new MACE being used in the latest Astro25 series radios because of this!

  20. #20
    Alpha's Avatar
    Alpha is offline T S - Moderator
    CS Forums $upporter
    Join Date
    Feb 12, 2012
    Location
    Directly above the center of the earth.
    Posts
    2,780
    Thanks
    1,235
    Thanked 1,530 Times in 738 Posts
    Country: Christmas Island

    Default

    Well, if you say you have confirmed it sends it it doesn't surprise me, it's evidently the receiver's decision to not do anything when KID of 0000 is received, KID 0001 references Hardware Key slot 1, etc. I have both confirmed this in testing, plus is says so right in the T3011DX manual! If you care to re-test, have at it. It is simply AMAZING what you can glean from actually reading the manuals!


    Quote Originally Posted by Astro Spectra View Post
    Well I can confirm that a KID of 0000 actually appears to be sent. This was found during investigation of the Quantar V.24 stream where the KID can be seen recovered, to be precise reported, by the Quantar from the over-the-air CAI. But you raise a good point and I will test and see if a KID of 0000 prevents 'auto-switch' key selection. I found this by accident on the XTS/XTL platform as KIDs from 1 up were already filled in the loader and because I didn't want to overwrite them with my known test key, I put it in 0000 as that was unused.

  21. #21
    Join Date
    Apr 09, 2012
    Location
    Australia
    Posts
    944
    Thanks
    297
    Thanked 694 Times in 258 Posts
    Country: Australia

    Default

    Hi Alpha,

    I'm not sure what you mean by this - KeyID 0001 references KeyID 0001 - regardless of what slot its in. I just tested this then - I had KeyID 0x3780 in slot 1 on radio 1, and KeyID 0x3780 in slot 48 on radio 2. The two radios could talk to each other fine. If I selected say, slot 10 on the second radio, and transmitted with Key 0x3780 on the first radio, the second radio simply switched to KeyID 0x3780 (slot 48)....

    Cheers,
    Matt

    Quote Originally Posted by Alpha View Post
    KID 0001 references Hardware Key slot 1, etc.
    Last edited by MattSR; Feb 16, 2013 at 11:37 AM. Reason: Spelling

  22. #22
    Alpha's Avatar
    Alpha is offline T S - Moderator
    CS Forums $upporter
    Join Date
    Feb 12, 2012
    Location
    Directly above the center of the earth.
    Posts
    2,780
    Thanks
    1,235
    Thanked 1,530 Times in 738 Posts
    Country: Christmas Island

    Default

    Quote Originally Posted by MattSR View Post
    I'm not sure what you mean by this - KeyID 0001 references KeyID 0001 - regardless of what slot its in.
    Is it possible you are maybe referring to CKR (Astro25 mode)? I am speaking of ASN KID's (LID's), there are only 16 physical "slots" (and 16 shadows) AFAIK, so if you have a key in slot 48, I am thinking that must not be ASN, then. I was under the impression that the key steering would select a physical slot in the receiving radio, if it scans the key set to find the one with a matching LID, then it's working pretty much the same way that CKR mode works. The only difference is that with CKR's, you dedicate a particular slot to a specific key with a particular CKR value.

    But zero (0000) is still a special value of LID, the manual says it's for mode-slaved ID's but the net effect is that the steering doesn't do it's thing for LID's of 0000.

  23. #23
    Join Date
    Apr 09, 2012
    Location
    Australia
    Posts
    944
    Thanks
    297
    Thanked 694 Times in 258 Posts
    Country: Australia

    Default

    I'm definitely talking about KeyID. KeyID - or KID is the same thing as ASN LID. The KID/LID doesn't reference a slot at all.

    ASN mode references slots by Physical ID - PID. This value is 1-16. It is totally separate from KID/LID. Each slot holds a Key variable, a Key ID (LID) and algorithm ID.

    P25 mode (aka CKR) references slots by CKR number. The CKR number is a 16 bit number that refers to the slot only. It is totally separate from KID/LID. Each slot holds a Key variable, a Key ID (LID) and algorithm ID.

    Slots and CKR's are only used for keyloading when referencing physical slots. KID/LID is used on the air interface to tell the receiving radios which key is being used. When the receiver hears an encrypted transmission, it searches all of its "slots" for a key that has a matching KeyID and ALGID. If a match is found, then it will use this key to decrypt the transmissions. The slot is irrelevant, the radio simply searches all slots for a key with a matching ALGID and KID. Actually, you can also fool the receiving radio by loading a key that has a matching KID and ALGID, but a different key variable. The radio will see the KID and ALGID match, and will use this key to decrypt even though its the wrong key...

  24. #24
    Alpha's Avatar
    Alpha is offline T S - Moderator
    CS Forums $upporter
    Join Date
    Feb 12, 2012
    Location
    Directly above the center of the earth.
    Posts
    2,780
    Thanks
    1,235
    Thanked 1,530 Times in 738 Posts
    Country: Christmas Island

    Default

    Ah, OK. I was confusing PID and LID, then. I was under the impression that the key slaving worked by PID in ASN mode, I stand corrected - thanks for the clarification!


  25. #25
    Join Date
    Jul 12, 2012
    Posts
    28
    Thanks
    68
    Thanked 17 Times in 12 Posts

    Default

    MattSR's post #23 should become a sticky. That's the best way I have seen it explained.