keyloading issue with upgraded dx loader "id....."

[wazzzzzzzzup]

hi all,
i recently upgraded my CX DES loader to DX. it will load my astro spectra, says pass but unfortunately it doesnt talk to the other radios loaded with the same key number.

on this new firmware when punching in the key, after you put in the 4 key rows it says I.D. and wants a 5th row for an id.
i have put various things there and nomatter what it doesnt matter and it doesnt allow the other radios to decode the astro spectra. or vise versa.

ive retyped in the key to the loader 3 times so i know i'm putting in the right key.

im a little hesitant to use the loader on my handhelds as they are already setup with inf key retention and all works good with themselves.
the astro spectra is the newest of the group and it has the same secure module part number as the hand helds aswell.
i think they are all the 1053 modules. listed as DES-XL but they also do DES on veselp too.

any ideas on what that I.D line is for and does it matter?

wazz

[sethcwilliams]

With the KVL3000s, anytime you generate a key you also generate a 4 character HEX (2 Byte binary) I.D. number (K.I.D. for ASTRO25, L.I.D. for ASN mode in the KVLs). Depending on your programming options for secure broadcast, this I.D. number is sent over the air with the transmission and is used by the receiving radio as an index reference. Depending on the squelch settings, the receiving radio may fail to unmute if it doesn't have a HEX I.D. associated with one of it's loaded encryption keys that matches what it receives over the air. I'm not familiar with the DX loaders or what type of handhelds you're using, but this might be something to look into.

[Pj]

Are you using PID or CKR on the radio? Its a secure programming option under the secure tab in CPS. I have not ran into this "ID" mode on my upgraded DX loader, but really haven't explored my loader (forgot what the actual key is in the loader, and don't want to lose it just yet!).

However, many of us have had a similar key issue due to the PID/CKR programming. The radio is just transmitting or receiving what it thinks is another key.

Anyone have a copy of the DX manual?

[sethcwilliams]

Just to tag along to PJ's post, remeber that PID and CKR are strickly "key management" terms and have no effect on the mechanics of encryption.

PID - Physical ID management - KVL-3000 ASN mode - ("slot 0, 1, 2....") - (L.I.D. FFFF, key data ABC123.........)
CKR - Common Key Reference management - KVL-3000 ASTRO25 mode - (CKR00001, CKR00002,......) - (K.I.D. FFFF, key data ABC123......)

While incompatible PID/CKR setting between a radio and keyloader will prevent a key from loading into a radio, it will not prevent one radio with one setting from talking to another with a different setting. BUT, the key ID and key data have to match or the radio will not unmute (and if it does you'll hear aliens ).

Here's a link to a pretty detailed, but HELLA long post that laid all this out pretty well. Check about half way down, you'll see a post from "515". He explained it pretty close to what I would so I'll save myself the typing.

http://batboard.batlabs.com/viewtopic.p ... 75&start=0

What I was going to ask, are you running analog or digital channels? Were your Spectras working before the upgrade, or did you upgrade because you acquired the Spectras and the upgrade would allow you to key them? Have you tried testing with a handheld, removing encryption altogether and verifying that your Specta and handheld will talk to each other in the clear based on your current personality settings? When you rekeyed the handheld and the Spectra, that'd also give you a chance to see if rekeying all the handhelds with the upgraded DX fixes your problem.

If you just read that and said "NO S**T SHERLOCK"... Then I certainly apologize, but I've caught myself missing some really basic stuff in the past so it never hurts to ask. Take it easy....

[Pj]

While incompatible PID/CKR setting between a radio and keyloader will prevent a key from loading into a radio, it will not prevent one radio with one setting from talking to another with a different setting. BUT, the key ID and key data have to match or the radio will not unmute (and if it does you'll hear aliens ).

Yeah thats where I was going with that... I really need caffine at certain hours of the day!

Excellent follow up post.

[immelmen28]

...more about the fifth set of numbers. The fifth row of 4 numbers on the line labeled "ID" in the DX loader is VERY important. This is the Logical ID (LID) of the key. It is just as critical this number match the LID in the other radios your trying to talk to as the key itself is. If the LID does not match, as the previous posts mentioned, the radio will think it does not have the correct key and will not attempt to decrypt the incoming transmission.

Here is the Good news. If you still have access to the KVL that loaded the portables you can view the LID of the key your using in them, provided the key has not been deleted. Bring up the slot of the key your using in the original loader so you get the "x ready" prompt and hold down the slot number on the keypad, this will display the LID for that key as it is saved in the KVL. That needs to match the LID in your new loader.

EDIT: This is all assuming your TXing in IMBE.

I have a DX manual if your still having trouble or need more details. Drop me a PM with an email address if you need it.

[wazzzzzzzzup]

heres an update.
the problem was found.

in the astro spectra the shop found that it was configured on the analog channels to "MIXED MODE" RX
which allows receive of analog or digital signals. this is fine under non secure analog setup but if you try to use secure, it forces it to use digital secure instead of analog secure. the solution was having it set to "NON-ASTRO" in the RX screen then go to the secure screen ind it shows "SECURENET" instead of astro.
BINGO problem solved! now it TX/RX in analog and analog DES and on digital channels it TX/RX in digital and DIGITAL DES

[radioinstl]

Not to hijack the tread, but to add on to it since someone will ask sooner or later and since we are seeing more and more non Motorola radio with DES and AES out there.

ASN mode = Motorola's own mode for loading radios
PID - Physical ID management - 3011xX and KVL-3000 or KVL3000+ ASN mode - ("slot 0, 1, 2....") - (L.I.D. FFFF, key data ABC123.........)
ASTRO mode = P25 Keyload mode. This is standard for all radios that are P25 of any brand
CKR - Common Key Reference management - KVL-3000 and KVL-3000+ ASTRO25 mode - (CKR00001, CKR00002,......) - (K.I.D. FFFF, key data ABC123......)

CKR (Motorola) = SLN ( P25 standard name)

[WCHija]

If anyone needs a copy of the 3011 DX manual I have it on PDF. I can email it to you. Perhaps it should be put on here somewhere permanently with all the questions that come up?

[MattSR]

CKR (Motorola) = SLN ( P25 standard name)

This isn't strictly true either but its close. A CKR is the 12 least significant bits of the true P25 SLN which is a 16 bit number that contains with info thats not within the scope of this thread..

[sethcwilliams]

To break down MattSR's post a little further, here's a quote from the thread I linked to earlier:

I believe CKR key managment is required for OTAR systems, and can be useful for people managing keys for large fleets of radios. With CKR, instead of the multikey radio having key slots numbered 1-16, the slots can have numbers of 1-4095 & 61440-65535. I think this would be useful for large fleets of secure radios, where hundreds of keys are in service, but each radio only needs a few keys.

And here's the math:

CKR - 12 LSB (least significant bits) - 111111111111 binary = 4095 decimal or 1-4095
SLN - 16 bits - 1111111111111111 binary = 65535 decimal or 61440-65535

You'll notice that the bottom and top end of SLN (61440-65535) are 4095 apart.

(SLAP IN THE FACE) I'm back on topic.....
Wazzzzz..... glad you worked it out!

[MattSR]

Bonus points to anyone that can explain what the 4 most significant bits of the SLN are used for...

[sethcwilliams]

This is a complete guess, I'm not running OTAR so I have no practical knowledge. Only what I've read and experimented with.

Looks like SLN and CKR are interchangeable terms in practical application. There are two identifier ranges, 1-4095 and 61440-65535. 1-4095, 12 bit binary, is used to catalog TEKs (traffic encryption keys used to encrypt the payload). 61440-65535, 16 bit binary, is used to catalog KEKs (key encryption keys used to encrypt the key exchange during rekey operation). I assume that the first four bits of the 16 bit identifier are always on (1's) which is why the range starts at 61440 (= 1111000000000000 binary). Reaching even further into la-la land, that may be done to denote the difference and pair the TEKs with the KEKs that secure them during the key transfer. The first four bits always on, the last 12 varying along with the TEK identifier used (TEK 1 with KEK 61441, TEK 4095 with KEK 65535). // EDIT - 22MAY09 1039Z // OR, just adding a HEX "F" in front of the TEK identifier to denote the KEK would be another way to describe it. // EDIT - 22MAY09 1039Z // Am I close, or just crazy?

[radioinstl]

And here's the math:

CKR - 12 LSB (least significant bits) - 111111111111 binary = 4095 decimal or 1-4095
SLN - 16 bits - 1111111111111111 binary = 65535 decimal or 61440-65535

You'll notice that the bottom and top end of SLN (61440-65535) are 4095 apart.

I do not belive this is correct per the P25 standard. Does anyone have any documentation to back up the above?

There are 16 Crypto-groups each with 4096 SLN's
Crypto-Group 0 SLN 1-4095
Crypto-Group 1 SLN 4096-8191
Crypto-Group 2 SLN 8192-12287
Crypto-Group 3 SLN 12288-16383
Crypto-Group 4 SLN 16384-20479
Crypto-Group 5 SLN 20480-24575
Crypto-Group 6 SLN 24576-28671
Crypto-Group 7 SLN 28672-32767
Crypto-Group 8 SLN 32768-36863
Crypto-Group 9 SLN 36864-40959
Crypto-Group A SLN 40960-45055
Crypto-Group B SLN 45056-49151
Crypto-Group C SLN 49152-53247
Crypto-Group D SLN 53248-57343
Crypto-Group E SLN 57344-61439
Crypto-Group F SLN 61440-65535

Now Motorola has always used Crypto-group 1 for TEKs and Crypto-group F (16) for KEKs but you are not limited to those 2 groups

[sethcwilliams]

Good call, brother. Like I said, I'm just guessing. What you just wrote is a few chapters more than I knew before I read it. (that's not saying much ) So those first four bits do change, and they're there to identify crypto groups?

[Wowbagger]

Well, at the protocol level, it works like this:

During the Header Data unit (which is sent once at the start of the call), and in the Logical Data Unit 2 (which is one of the frame types that carries voice data) the transmitter sends the data needed to track encryption. Among the data transmitted are the algorithm ID and the key ID to be used.

The receiver is supposed to use that <ALGID/KEYID> pair to locate the encryption key for that algorithm, and use that to decode the data.

The ALGID is an 8 bit value, the KEYID is a 16 bit value. So in theory the system can use up to 65536 keys for EACH algorithm supported by the radio. However, whether a given radio can handle the same KID for different ALGIDs is up in the air.

[wazzzzzzzzup]

w

[MattSR]

However, whether a given radio can handle the same KID for different ALGIDs is up in the air.

Motorolas dont seem to have a problem with this

[MattSR]

My sincerest apologies to the original poster for dragging this way off topic, but here is the original Motorola document that explains the relationship between crypto groups, keysets and SLNs.

If you have a bit of nous you will see how CKR fits in and how its different to a SLN.

http://priorartdatabase.com/IPCOM/000008997/

[sethcwilliams]

My apologies as well, Wazzzz.... If we keep this up, the Admin/Mod team may have to rename the thread.

MattSR, the more digging around I do, I'm starting to think Radioinstl was right in the first place. I ended up on the National Institute of Standards and Technologies and a few other .gov sites, most of them referring to various FIPS standards. Even some of Motorola's own documentation states that SLN and CKR are interchangeable terms. The document you linked to earlier was published in 1999, and only references 12 bits total (4 for the crypto-group, 8 for the keyset ID) even when referring to the APCO 25 standard. Is it possible that APCO25 had a revision between then and now that extended what we now know as SLN/CKR to 16 bits total (4 crypto-group, 12 keyset ID)? Thanks for making me study up, man!

[akardam]

I'd suggest you guys start a specific CKR/SLN thread, post this info (and anything else you might have), and continue the discussion there. We'll leave this thread as is so that context is preserved, and since the OP's issue has been solved, this thread will be closed.